Re: [PATCH] rndis_host: support Novatel Verizon USB730L

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Miller <davem@xxxxxxxxxxxxx> writes:

> From: Aleksander Morgado <aleksander@xxxxxxxxxxxxx>
> Date: Wed, 27 Sep 2017 23:31:03 +0200
>
>> I'm not sure if binding this logic to a specific vid:pid (1410:9030)
>> would be more appropriate here, or if it's ok to just bind
>> class/subclass/protocol (as in the activesync case).  Let me know
>> what you think.
>
> I don't have enough USB Networking knowledge to make a decision here.
>
> Some things seem confusing.  For example, if we should be matching
> USB_CLASS_MISC, subclass=4, protocol=1 for RNDIS over Ethernet, then
> we why aren't we also matching USB_CLASS_MISC, subclass=4, protocol=2
> for RNDIS over wireless and instead are matching "Remote RNDIS" in
> the form of USB_CLASS_WIRELSS, subclass=1, protocol=3?
>
> I really don't understand any of this magic :-)
>
> So someone more knowledgable needs to review this.

Let me just say that I am not qualified.  But since this needs a review,
I am going to offer my view anyway.  FWIW, I don't think *anyone*
understand this magic...  I certainly don't.

We can pretty much ignore the USB-IF and any specs, since that is what
the vendors appear to do.  They provide device specific drivers for
Windows, so all they care about is that their device "works" with their
driver.

But in Linux we prefer to create drivers for device classes whenever we
can, to avoid having to add every single device by ID.  So we try to
guess future patterns based on the devices we have observed, even when
there is no clear spec.  This is what Aleksander does here. He has a
device with a 'Cls=ef(misc ) Sub=04 Prot=01' function.  This device
works with the rndis_host driver. That is all we know.

We cannot prove that a class match is correct. But it does make sense to
try it.  At least we know that this works for one device.

Adding anything else, e.g. based on the table at
http://www.usb.org/developers/defined_class/#BaseClassEFh , is a bit
more risky.  We don't know if a driver will work with *any* such device
until we've actually seen one.

This is just my opinion, and probably full of bogus assumptions as
usual.  I was sort of hoping that some expert would speak up so I didn't
have to :-)

But FWIW:

Reviewed-by: Bjørn Mork <bjorn@xxxxxxx>



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux