lkml.org 
[lkml]   [2002]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] USB driver conversion to use "struct device_driver"
On Mon, Aug 12, 2002 at 11:30:38AM -0700, David Brownell wrote:
> >>Why are devices children of the hub _interface_ now?
> >
> >Good point, I noticed that this had changed, but haven't fixed it, I'll
> >make sure it goes back to the way it was before.
>
> Thanks ... those paths were getting really atrocious!
>
> The other thing I noticed about the tree structure was that
> the /drivers/bus/usb/devices directory has symlinks to both
> interfaces and devices. That's good for completeness, but
> the device links aren't very useful (and they really clutter
> up that directory, IMO, with two different kinds of object).
> Do they need to show up there?
>
> We know "<interface>/.." always gives the USB device, so we
> don't really need such additional entries.

Yeah, it is a bit ugly, and the whole symlink thing is going to be
revisited. So for now I'm ignoring them, and hopefully Pat will decide
on something later on :)

> Even so. This particular change also happens to make the
> usb_device_id->driver_data useless ... if the driver API
> changes, I'd need to see the MODULE_DEVICE_TABLE entry,
> or at least its driver_data, get passed too. That's a
> key level of bus-specific glue that the driver model
> doesn't explicitly acknowledge (seemingly expects to be
> handled transparently by the bus glue).

Ugh, forgot about ->driver_info. Ok, I'll go work on that, pci gets
around it by duplicating the "old" probe() interface. I don't want to
throw away that info, as it is useful for some drivers.

> I guess I shouldn't be too sensitive about incompatible
> changes to the USB driver API, but in this case it bothers
> me a bit even though I do like the idea of making drivers
> think "correctly" (interface drivers, not device drivers).
>
> Oh, and "new_disco" ... I thought "Disco is Dead"? :)

"new_disco" will be dead, once all the drivers are converted :)

> >What APIs would those be?
>
> From a quick scan of <linux/usb.h>, I see these calls ...
> all of which would be less error prone if they just passed
> the relevant descriptor. (Errors happen when folk assume
> both two kinds of integer ID are the same... and it's also
> just confusing.) The interface->dev backlink you added is
> useful, and help get rid of the need for many of these:
>
> usb_set_configuration(struct usb_device *dev, int);
> usb_set_interface(struct usb_device *dev, int, int);
>
> usb_find_interface_driver_for_ifnum(struct usb_device *dev, int);
>
> usb_bind_driver(struct usb_driver *,struct usb_device *, int);
> // usb_unbind_driver takes interface handle already!!
>
> usb_ifnum_to_ifpos(struct usb_device *dev, int);
> usb_ifnum_to_if(struct usb_device *dev, int);
> // basically, abolish the need for these calls
>
> usb_epnum_to_ep_desc(struct usb_device *dev, int);
>
> Plus I'm strongly tempted to group all the "dev + pipe" calls
> the same way ... better to just pass the endpoint descriptor
> than to encode descriptor values as bitfields and then later
> waste time (repeateadly) tearing apart those bitfields.

Agreed, I'll look into fixing up the above functions, unless someone
wants to send me a patch doing it first :)

> Related issue to the suspend/resume code ... I recently noticed
> (again) that the hub code was disconnecting top-down rather than
> bottom up. That should eventually get delegated to the driver
> framework ... any idea whether there was a reason not to do that
> bottom-up in the first place? At what point does the driver model
> kick in to handle that part of what the hub driver now does? If
> the patch you sent around did that, my quick look missed it ... :)

Hm, I didn't realize it was going top-down at all. What changes caused
that? And no, I don't think I changed it, as I didn't realize it had
been changed in the first place :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.125 / U:1.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site