Re: [linux-usb-devel] [RFC] USB driver conversion to use "struct device_driver"

[David Brownell <david-b@pacbell.net>]

Good to start seeing "driver model" changes as well as just "driverfs"
changes ...


 > Also, the driverfs representation of the USB devices has changed,
 > possibly for the worse.  Just try the patch to see what I mean :)

Why are devices children of the hub _interface_ now?  Today they're
children of the hub device.  The hub spec requires only one interface
for all hub devices, so it's safe the way it is today.  With devices
as children of hubs devices, things look more familiar ... hubs act
like pci bridges (which they logically resemble).


 > +static int usb_device_bind (struct device *dev, struct device_driver *drv)

Minor rough spot, please rename to usb_device_match() since it's
the bus_type->match() callback.  Might even be nice to split out
some of the relevant code into "usb-device.c", mirroring what the
"pci-device.c" code does but with bus-specific differences.  There's
too much random code in "usb.c" still for my taste!  And all code
at this level is usbcore-internal anyway, shouldn't be mixed with
public driver APIs. :)


>  struct usb_driver {
>  	struct module *owner;
>  	const char *name;
> +
> +	int	(*new_probe)	(struct usb_interface *intf);
> +	int	(*init)		(struct usb_interface *intf);
> +	void	(*new_disco)	(struct usb_interface *intf);
> +
> +	struct device_driver driver;
>  
>  	void *(*probe)(
>  	    struct usb_device *dev,		/* the device */

I don't see why this isn't done as a transparent wrapper around
the existing probe()/disconnect() routines.  PCI did this without
any such major changes to the driver API, and I thought being able
to do that was a (good!) device model design goal.

If we want to change the API to refocus on interfaces, rather
than device plus whichever kind of identifying number is used in
the relevant context, I'd rather start by getting rid of the
APIs that have been problematic (device + number).  That'd be
nice for configurations and endpoints too, but I think most of
those calls involve interfaces.  Those changes would be a lot
less invasive so far as device drivers are concerned.


Also, the generic driver model calls are probe/disconnect,
suspend/resume, and release.  Today, USB has probe/disconnect
but not the others.  I'd expect to see suspend/resume in there
before a new init callback ... but I see the init routine is
unused, maybe that just snuck in by accident.

- Dave