<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>I started work on the above and added an parameter to the CLI to pass in my peer port/USB path, as an option. I expected the upgrade to work then but it did not, it still could not recognise the port was suitable.</div><div>I delved deeper into the code and found a line that is an issue in <i>qfu-udev-helpers.c</i>:</div><div><br></div><div><br></div><div><div><font face="monospace, monospace">static void</font></div><div><font face="monospace, monospace">handle_uevent (GUdevClient *client,</font></div><div><font face="monospace, monospace"> const char *action,</font></div><div><font face="monospace, monospace"> GUdevDevice *device,</font></div><div><font face="monospace, monospace"> GTask *task)</font></div><div><font face="monospace, monospace">{</font></div><div><font face="monospace, monospace"> WaitForDeviceContext *ctx;</font></div><div><font face="monospace, monospace"> GFile *file;</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> ctx = (WaitForDeviceContext *) g_task_get_task_data (task);</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> if (!g_str_equal (action, "add") && !g_str_equal (action, "move") && !g_str_equal (action, "change"))</font></div><div><font face="monospace, monospace"> return;</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> file = device_matches_sysfs_and_type (device, ctx->sysfs_path, ctx->device_type);</font></div><div><font face="monospace, monospace"> g_print ("peer port is: %s\n",ctx->peer_port);</font></div><div><font face="monospace, monospace"> g_print ("file is: %s\n",file);</font></div><div><font face="monospace, monospace"> if (!file && ctx->peer_port) {</font></div><div><font face="monospace, monospace"> gchar *tmp, *path;</font></div><div><font face="monospace, monospace"> g_print ("Path didn't exist but peer port does, attempting to build path...\n");</font></div><div><font face="monospace, monospace"> <b>tmp = g_build_filename (ctx->peer_port, "device", NULL);</b></font></div><div><font face="monospace, monospace"> g_print ("tmp is: %s\n",tmp);</font></div><div><font face="monospace, monospace"> path = realpath (tmp, NULL);</font></div><div><font face="monospace, monospace"> g_free (tmp);</font></div><div><font face="monospace, monospace"> g_print ("path is: %s\n",path);</font></div><div><font face="monospace, monospace"> if (!path)</font></div><div><font face="monospace, monospace"> return;</font></div><div><br></div></div><div>There is not a <i>device </i>file in my path so the <i>realpath </i>check fails - <i>path is: (null)</i>, the contents of my directory are below, what exactly is expected to be in the device file? Perhaps one of these other files would work as an alternative?</div><div><br></div><div><div><font face="monospace, monospace">1-6:1.0/ busnum port@</font></div><div><font face="monospace, monospace">authorized configuration power/</font></div><div><font face="monospace, monospace">avoid_reset_quirk descriptors product</font></div><div><font face="monospace, monospace">bConfigurationValue dev quirks</font></div><div><font face="monospace, monospace">bDeviceClass devnum removable</font></div><div><font face="monospace, monospace">bDeviceProtocol devpath remove</font></div><div><font face="monospace, monospace">bDeviceSubClass driver@ serial</font></div><div><font face="monospace, monospace">bMaxPacketSize0 ep_00/ speed</font></div><div><font face="monospace, monospace">bMaxPower idProduct subsystem@</font></div><div><font face="monospace, monospace">bNumConfigurations idVendor uevent</font></div><div><font face="monospace, monospace">bNumInterfaces ltm_capable urbnum</font></div><div><font face="monospace, monospace">bcdDevice manufacturer version</font></div><div><font face="monospace, monospace">bmAttributes maxchild</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Thanks,</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">--</font></div><div><font face="monospace, monospace">Paul</font></div><div><font face="monospace, monospace"><br></font></div><div><br></div></div><div><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 8 Jan 2019 at 13:10, Paul Gildea <<a href="mailto:gildeap@tcd.ie">gildeap@tcd.ie</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Was thinking about this again on it's anniversary, as it's becoming more of an issue, both due to upgrading MC7455's but also since getting EM7455's recently.<div>For the upgrade using peers, I'm going to have a look now at the code to decipher it and maybe change it, haven't used the language much. I think the S/N method sounds good. The upgrade pause suggested by Aleksander would be good since S/N's can match. </div><div>Alternatively, I was thinking that being able to manually enter a path for the peer as a parameter when upgrading would be good? Or even allowing the user to enter an expected ttyUSB? Will have a think. </div><div><br></div><div><div>As an aside, looking at the serial numbers, I noticed that in Linux the S/N is two characters longer than that reported with AT commands? After researching this the AT command one is correct and the Linux one is not, anybody noticed that before?</div><div>E.G.: AT: LQ714304880310 Linux: LQ71430488031020</div></div><div><br></div><div>--</div><div>Paul</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 25 Jan 2018 at 21:00, Aleksander Morgado <<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 25, 2018 at 9:19 PM, Dan Williams <span dir="ltr"><<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Thu, 2018-01-25 at 18:26 +0000, Paul Gildea wrote:<br>
> Yep, was fairly clear from your patch, nice! I guess that depends on<br>
> prevalence of congruent S/N's (at least for modems where that will be<br>
> needed, unlike your EM7565 which upgrades in SuperSpeed).<br>
> My ports seem predictable for manual setting, and if not at least the<br>
> user<br>
> can solve it with trial/error to get around the problem.<br>
<br>
</span>I'd be hesitant to use the serial number; this is often the same for<br>
different devices of the same model. So if you have two of the same<br>
modem on your system, it could become confused.<br>
<span class="gmail-m_-2043733527505687182gmail-m_-8245431700737201818HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">We could always halt the automatic upgrade process if we find some other modem with the same s/n around. Or worst case, we could even make qmi-firmware-update processes synchronize so that they are never run at the same time for the same s/n. Just thinking out loud here...</div></div></div><div><br></div>-- <br><div class="gmail-m_-2043733527505687182gmail-m_-8245431700737201818gmail_signature">Aleksander<br><a href="https://aleksander.es" target="_blank">https://aleksander.es</a></div>
</div></div>
</blockquote></div>
</blockquote></div>