[PATCH] qmi-firmware-update: support USB3->USB2 mode changes during upgrade

[Paul Gildea]

Hi all,

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.
I delved deeper into the code and found a line that is an issue in
*qfu-udev-helpers.c*:


static void
handle_uevent (GUdevClient *client,
               const char  *action,
               GUdevDevice *device,
               GTask       *task)
{
    WaitForDeviceContext *ctx;
    GFile                *file;

    ctx = (WaitForDeviceContext *) g_task_get_task_data (task);

    if (!g_str_equal (action, "add") && !g_str_equal (action, "move") &&
!g_str_equal (action, "change"))
        return;

    file = device_matches_sysfs_and_type (device, ctx->sysfs_path,
ctx->device_type);
    g_print ("peer port is: %s\n",ctx->peer_port);
    g_print ("file is: %s\n",file);
    if (!file && ctx->peer_port) {
        gchar *tmp, *path;
        g_print ("Path didn't exist but peer port does, attempting to build
path...\n");
        *tmp = g_build_filename (ctx->peer_port, "device", NULL);*
        g_print ("tmp is: %s\n",tmp);
        path = realpath (tmp, NULL);
        g_free (tmp);
        g_print ("path is: %s\n",path);
        if (!path)
            return;

There is not a *device *file in my path so the *realpath *check fails - *path
is: (null)*, 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?

1-6:1.0/             busnum               port@
authorized           configuration        power/
avoid_reset_quirk    descriptors          product
bConfigurationValue  dev                  quirks
bDeviceClass         devnum               removable
bDeviceProtocol      devpath              remove
bDeviceSubClass      driver@              serial
bMaxPacketSize0      ep_00/               speed
bMaxPower            idProduct            subsystem@
bNumConfigurations   idVendor             uevent
bNumInterfaces       ltm_capable          urbnum
bcdDevice            manufacturer         version
bmAttributes         maxchild


Thanks,

--
Paul





On Tue, 8 Jan 2019 at 13:10, Paul Gildea <gildeap at tcd.ie> wrote:

> 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.
> 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.
> 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.
>
> 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?
> E.G.: AT: LQ714304880310 Linux: LQ71430488031020
>
> --
> Paul
>
>
>
> On Thu, 25 Jan 2018 at 21:00, Aleksander Morgado <aleksander at aleksander.es>
> wrote:
>
>>
>>
>> On Thu, Jan 25, 2018 at 9:19 PM, Dan Williams <dcbw at redhat.com> wrote:
>>
>>> On Thu, 2018-01-25 at 18:26 +0000, Paul Gildea wrote:
>>> > Yep, was fairly clear from your patch, nice! I guess that depends on
>>> > prevalence of congruent S/N's (at least for modems where that will be
>>> > needed, unlike your EM7565 which upgrades in SuperSpeed).
>>> > My ports seem predictable for manual setting, and if not at least the
>>> > user
>>> > can solve it with trial/error to get around the problem.
>>>
>>> I'd be hesitant to use the serial number; this is often the same for
>>> different devices of the same model.  So if you have two of the same
>>> modem on your system, it could become confused.
>>>
>>>
>> 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...
>>
>> --
>> Aleksander
>> https://aleksander.es
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20190110/84e5de41/attachment.html>