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

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.


More information about the Usbatm mailing list