<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Am 10.02.2012 um 16:27 schrieb Flemming Richter Mikkelsen:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Fri, Feb 10, 2012 at 16:07, Dr. H. Nikolaus Schaller <span dir="ltr"><<a href="mailto:hns@goldelico.com">hns@goldelico.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><br>Am 10.02.2012 um 15:46 schrieb Radek Polak:<br>
<div class="im"><br>> Hi,<br>> i found a problem with modem serial device. Probably after suspend/resume the<br>> device node is renamed from /dev/ttyHS3->/dev/ttyHS6 and i cant send AT<br>> commands then. Attached is dmesg output, you can search for ttyHS6 to find the<br>
> place.<br>><br>> These are all /dev/ttyHS before suspend:<br>><br>> ttyHS0 ttyHS1 ttyHS2 ttyHS3 ttyHS4 ttyHS5<br>><br>> and this is how it looked after resume:<br>><br>> ttyHS0 ttyHS1 ttyHS2 ttyHS4 ttyHS5 ttyHS6<br>
<br></div>Hm. Maybe the driver knows that ttyHS3 is active before<br>resume and therefore shuts it down differently from the other ports?</blockquote>
<div> </div>
<div>grep ttyH dmesg.txt tells us that for ttyHS{0,1,2,4,5} the devices is shut down:</div>
<div> device_unregister</div>
<div> device_create_release</div>
<div>but nothing similar for ttyHS3.</div>
</div></blockquote><div><br></div>This appears to be a good hint.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div> Maybe this is because we don't power off the modem completely?</div></div></blockquote><div><br></div><div>Well, then it should handle all /dev/ttyHS ports in the same way.</div><div>They are all to communicate with the modem.</div><div><br></div>Or because it is in use (opened)?</div><div><br></div><div>Ah, please try:</div><div><br></div><div>sleep 1000 </dev/ttyHS0 # this is the diagnostics ports</div><div><br></div><div>then suspend and see if ttyHS0 also remains registered.</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote">
<div> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">But the driver code is open and I think it is in drivers/net/usb/hso.c<br><br>So it should be possible (at least in theory) to understand how this<br>
renumbering happens.<br>
<div class="im"><br>><br>> This is with kernel 3.2 and i have udev running on my system (could it be the<br>> problem?)<br>><br>> Another question: i am always assuming /dev/ttyHS3 as modem device for AT<br>
> commands. Is it correct?<br><br></div>Not 100%, although it is after a Reset.<br><br>Please look into the 'root/dial' or 'root/pin' script:<br><br> <a href="http://download.goldelico.com/gta04/unstable/config.tgz" target="_blank">http://download.goldelico.com/gta04/unstable/config.tgz</a><br>
<br>It scans the /sys entries to locate the "Application" port, even if<br>it is being renumbered. During our automatic hardware tests we do<br>a AT_ORESET and I have observed that sometimes ttyHS3 and ttyHS4<br>
have swapped their roles.<br><br>Scanning /sys is also recommended by OPTION.<br><br>Nikolaus<br>_______________________________________________<br>Gta04-owner mailing list<br><a href="mailto:Gta04-owner@goldelico.com">Gta04-owner@goldelico.com</a><br>
<a href="http://lists.goldelico.com/mailman/listinfo/gta04-owner" target="_blank">http://lists.goldelico.com/mailman/listinfo/gta04-owner</a><br></blockquote></div><br><br clear="all"><br>-- <br> The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and<br>
how) you may access your data; but nobody's threatening your freedom: we<br> still allow you to remove your data and not access it at all."<br>
_______________________________________________<br>Gta04-owner mailing list<br><a href="mailto:Gta04-owner@goldelico.com">Gta04-owner@goldelico.com</a><br>http://lists.goldelico.com/mailman/listinfo/gta04-owner<br></blockquote></div><br></body></html>