Instead of a whole new plugin, why not just override the lock status loading in the Option plugin, so that we don't check the PS lock if the modem reports nozomi driver?

(In reply to comment #1)
> Instead of a whole new plugin, why not just override the lock status loading in
> the Option plugin, so that we don't check the PS lock if the modem reports
> nozomi driver?

Yeah, probably a better idea.

Could you test with the 'aleksander/nozomi-fix' branch to see if it fixed the issue?

Looks ok, but I can't test due to other problems; nozomi cards aren't driven by Option, not sure why I didn't catch this earlier.

1) mm-device.c doesn't get IDs from PCI devices.  I've pushed a fix for this to your nozomi branch

2) the 'option' plugin specifies both vendor and product filters; the vendor filter is 0x0af0, while the product filter is { 0x1931, 0x000c }.  The nozomi card is 1931/000c.  But failing either the vendor or product check appears to fail the device:

    /* If we got filtered by vendor or product IDs  and we do not have vendor
     * or product strings to compare with: unsupported */
    if ((vendor_filtered || product_filtered) &&
        !self->priv->vendor_strings &&
        !self->priv->product_strings &&
        !self->priv->forbidden_product_strings) {
        mm_dbg ("(%s) [%s] filtered by vendor/product IDs",
                self->priv->name,
                g_udev_device_get_name (port));
        return TRUE;
    }

in our case, the nozomi card does not match the vendor filter, so vendor_filtered == TRUE, but product_filtered == FALSE, and thus the device is marked unsupported by the option plugin.

But we can't just change to (vendor_filtered && product_filtered) since that will make every other plugin claim to support the device (tried it).  Are the vendor + product filters supposed to be logical AND, or logical OR?  If they're logical OR we have more extensive fixes to do, so I'd rather punt that if we can.

The quick fix is to just add 0x1931 to the Option plugins' vendor IDs, since that is Option's assigned PCI VID (0x0af0 is their USB VID) and remove the product match.  This does work.

3) with 1 & 2 done, I get:

WARNING **: g_object_new_valist: object class 'MMBroadbandModemOption' has no property named 'iface-modem-3gpp-ignored-facility-locks'

I spent 2 minutes trying to find that and failed; usually that's because of a missing override, but the override is already there in mm-broadband-modem.c so I don't know.

(In reply to comment #4)
> Looks ok, but I can't test due to other problems; nozomi cards aren't driven by
> Option, not sure why I didn't catch this earlier.
> 
> 1) mm-device.c doesn't get IDs from PCI devices.  I've pushed a fix for this to
> your nozomi branch

Great.

> 
> 2) the 'option' plugin specifies both vendor and product filters; the vendor
> filter is 0x0af0, while the product filter is { 0x1931, 0x000c }.  The nozomi
> card is 1931/000c.  But failing either the vendor or product check appears to
> fail the device:
> 
>     /* If we got filtered by vendor or product IDs  and we do not have vendor
>      * or product strings to compare with: unsupported */
>     if ((vendor_filtered || product_filtered) &&
>         !self->priv->vendor_strings &&
>         !self->priv->product_strings &&
>         !self->priv->forbidden_product_strings) {
>         mm_dbg ("(%s) [%s] filtered by vendor/product IDs",
>                 self->priv->name,
>                 g_udev_device_get_name (port));
>         return TRUE;
>     }
> 
> in our case, the nozomi card does not match the vendor filter, so
> vendor_filtered == TRUE, but product_filtered == FALSE, and thus the device is
> marked unsupported by the option plugin.
> 
> But we can't just change to (vendor_filtered && product_filtered) since that
> will make every other plugin claim to support the device (tried it).  Are the
> vendor + product filters supposed to be logical AND, or logical OR?  If they're
> logical OR we have more extensive fixes to do, so I'd rather punt that if we
> can.
> 
> The quick fix is to just add 0x1931 to the Option plugins' vendor IDs, since
> that is Option's assigned PCI VID (0x0af0 is their USB VID) and remove the
> product match.  This does work.

I think that the original idea was to have either vendor filter or product filter; a merged logic would end up being more complex I think. For now, I think that adding 0x1931 to the vendor filter, and removing the product filter, should be more than enough.


> 
> 3) with 1 & 2 done, I get:
> 
> WARNING **: g_object_new_valist: object class 'MMBroadbandModemOption' has no
> property named 'iface-modem-3gpp-ignored-facility-locks'
> 
> I spent 2 minutes trying to find that and failed; usually that's because of a
> missing override, but the override is already there in mm-broadband-modem.c so
> I don't know.

enums vs flags... :) Fixed that, I believe.

I pushed a couple of commits to the branch. If you think it looks good, I'll rebase them to remove the fixup! and merge them to master.

Pushed a quick fixup for a stray }.  It all works now, feel free to rebase and merge.

Rebased and merged now.

*** Bug 682643 has been marked as a duplicate of this bug. ***