speedtch Makefile, 1.12, 1.13 cxacru2.c, 1.3, 1.4 usbatm.h, 1.5,
1.6 usbatm2.c, 1.15, 1.16
Roman Kagan
rkagan at mail.ru
Tue Feb 1 02:07:34 EST 2005
Hi Duncan,
On Mon, Jan 31, 2005 at 10:05:46PM +0100, Duncan Sands wrote:
> > Now I'm really confused. I thought the whole purpose of these
> > usbatm_(de)register was to eliminate the need for the subdrivers to
> > write their own probe and disconnect adhering to a certain calling
> > order.
>
> they don't have to - but they can if they need to. Most minidrivers will
> just use the usbatm probe and disconnect methods, like cxacru now does (check
> it out).
Look, now minidrivers have to maintain a full-fledged struct usb_driver,
call usb_(de)register in their module_{init,exit}, and what you're
saying is that in the trivial case, instead of writing a one-line probe
function
static int xxx_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
return usbatm_usb_probe(intf, id, &xxx_usbatm_driver);
}
and reusing the common disconnect function, they have to add
usbatm_(de)register calls accompanied by error handling somewhere, which
is more code even on the subdriver's side, much more complexity on the
core side and has other issues (see below).
> > [...] risk of multiple
> > subdrivers registering the same usb_device_id (breaking the list stuff
> > BTW).
>
> I noticed that too. Maybe we should try all minidrivers until we find
> one for which ->bind succeeds?
This is a bad idea: the USB core calls probe method with a particular
usb_driver in mind, and the whole purpose of that parallel list of
usbatm_drivers is to find the _only_ one matching the usb_driver it was
called with. If we have multiple suspects on the list, and call ->bind
of a wrong usbatm_driver, we'll at the very least confuse the USB core
(to say nothing about ourselves :).
> See above. usb-serial does it like this too by the way.
Sure, that's where I borrowed the idea :) Doesn't justify replicating
its deficiencies, though.
Cheers,
Roman.
More information about the Usbatm
mailing list