Re: new usb LTE modem device

[Dan Williams]

On Wed, 2017-08-09 at 11:19 +0700, Lars Melin wrote:
> On 8/9/2017 02:33, Bjørn Mork wrote:
> > 
> > The qmi_wwan part looks fine to me. But you
> > will need to split it in two patches since the two
> > drivers are parts of different subsystems.
> > 
> > The option driver use interface blacklists
> > instead of multiple match entries. You should
> > probably follow the same style there. But this
> > is up to Johan...
> > 
> > Use the get_maintainer script to figure out
> > where the patches should be sent.
> > 
> > 
> > Bjørn
> 
> 
> Whitelisting all 6 interfaces in the option driver and
> then blacklist 4 of them (3 qmi + 1 Android debug) is
> not efficient when you so easily can selectively whitelist
> the ones (0 and 2) that the option driver should handle.
> Giuseppe is doing it the right way imho.

Yeah, in this case you're right.

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new usb LTE modem device

[Lars Melin]

On 8/9/2017 02:33, Bjørn Mork wrote:





The qmi_wwan part looks fine to me. But you
will need to split it in two patches since the two
drivers are parts of different subsystems.

The option driver use interface blacklists
instead of multiple match entries. You should
probably follow the same style there. But this
is up to Johan...

Use the get_maintainer script to figure out
where the patches should be sent.


Bjørn



Whitelisting all 6 interfaces in the option driver and
then blacklist 4 of them (3 qmi + 1 Android debug) is
not efficient when you so easily can selectively whitelist
the ones (0 and 2) that the option driver should handle.
Giuseppe is doing it the right way imho.


/http://vger.kernel.org/majordomo-info.html

Re: new usb LTE modem device

[Bjørn Mork]

On August 8, 2017 9:22:29 PM CEST, Giuseppe Lippolis  
wrote:
>> But we already have many Sierra devices with 2 QMI interfaces (the
>3rd one
>> is documented and verified non-functional for unknown reasons). And
>these
>> tend to come with multiple OEM device IDs.  So a whitelist method
>could
>> reduce the number of matching entries considerably.  Feel free to
>submit
>> patches if you like :-)
>
>Dear Bjorg,
>I'm going to prepare the following patch. 
>If you think it is ok, I will build and test it and if working I will
>submit it.

The qmi_wwan part looks fine to me. But you
will need to split it in two patches since the two
drivers are parts of different subsystems.

The option driver use interface blacklists
instead of multiple match entries. You should
probably follow the same style there. But this
is up to Johan...

Use the get_maintainer script to figure out
where the patches should be sent.


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new usb LTE modem device

[Bjørn Mork]

"Giuseppe Lippolis"  writes:

> Hi all,
> I'm working to port OpenWRT/LEDE on a new router with embedded usb LTE
> modem.
> The modem have 3 qmi_wwan interfaces and 2 option.
>
> I would like to prepare the patch, but before I would like to know if using
> the QMI_FIXED_INTF macro is the best way to identify the interface or if
> there is a better way.

That is currently the only implemented way, so it's definitely
simplest. And most likely the only method suitable for stable backports.

I agree that it is very inefficient to add 3 match lines for a single
device. We could consider adding an alternative matching method for this
kind of device, using an interface whitelist or blacklist.  I guess we
should if there are many more of these.

But we already have many Sierra devices with 2 QMI interfaces (the 3rd
one is documented and verified non-functional for unknown reasons). And
these tend to come with multiple OEM device IDs.  So a whitelist method
could reduce the number of matching entries considerably.  Feel free to
submit patches if you like :-)


> Here the info grapped from cat /proc/bus/usb/devices using the stock
> firmware:
>
> T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=1435 ProdID=0918 Rev= 2.32
> S:  Manufacturer=Android
> S:  Product=Android
> S:  SerialNumber=0123456789ABCDEF
> C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
> E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
> E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
> E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
> E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
> E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
> E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
> E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
> E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=125us


Two questions: Did you verify that all 3 QMI interfaces work as
expected?  What is the storage function (last interface) good for on an
embedded USB modem?


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html