On Mon, Sep 24, 2001 at 05:39:19PM +1000, Brad Hards wrote:
> Greg KH wrote:
> > Any reason they acm driver shouldn't use the
> > SB_DEVICE_ID_MATCH_INT_INFO() macro instead of specifying just
> > USB_DEVICE_ID_MATCH_INT_CLASS and USB_DEVICE_ID_MATCH_INT_SUBCLASS like
> > you did?
> I did it to avoid selecting on protocol. IIRC, the CDC spec uses a couple of
> protocol variations for the abstract control model - AT commands for one set,
> and something else for the other.
>
> Having looked at the acm_probe() code, I note that there is an explicit check
> for protocol of 1 (which is the AT command set, I think - I really need to
> find my copy of the CDC spec...), so the table could be
> SB_DEVICE_ID_MATCH_INT_INFO(USB_CLASS_COMM, 2, 1), and then we could simply
> remove the check in acm_probe():
> if (ifcom->bInterfaceClass != 2 || ifcom->bInterfaceSubClass != 2 ||
> ifcom->bInterfaceProtocol != 1 || ifcom->bNumEndpoints < 1)
> continue;
>
> Makes no real difference - just so long as the acm driver doesn't claim
> CDCEther devices, and vice versa.
I just received an e-mail that some modems do not work in 2.4.10 ...
They have
Device Class:SubClass:Protocol = 02:00:00
...
And the ACM driver should probe on device and not on interfaces. Well,
maybe getting the probe called for an interface and then grabbing other
interfaces on the device would work too ...
>
> Do you want another patch?
>
> Brad
--
Vojtech Pavlik
SuSE Labs
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
