public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Oliver Neukum <oliver@neukum.name>
Cc: linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, Patrick Mochel <mochel@osdl.org>
Subject: Re: [linux-usb-devel] [RFC] USB driver conversion to use "struct device_driver"
Date: Sat, 10 Aug 2002 08:40:18 -0700	[thread overview]
Message-ID: <20020810154018.GB32083@kroah.com> (raw)
In-Reply-To: <200208101157.28759.oliver@neukum.name>

On Sat, Aug 10, 2002 at 11:57:28AM +0200, Oliver Neukum wrote:
> Am Samstag, 10. August 2002 02:10 schrieb Greg KH:
> > Hi all,
> 
> > The USB subsystem only binds drivers to USB "interfaces".  A USB device
> > may have many "interfaces", so a single device may have many drivers
> > attached to it, handling different portions of it (think of a USB
> > speaker, which has a audio driver for the audio stream, and a HID driver
> > for the speaker buttons.)  Because of this I had to create a "empty"
> > device driver that I attach to the USB device structure.  This ensures
> > it shows up properly in the driverfs tree, and that no USB drivers try
> > to bind to it.
> 
> Hi,
> 
> the probe/disconnect changes are an improvement.
> But what do we call a device? IMHO the device in
> terms of driverfs is the interface, thus the usb_device
> should be seen as a bus, which interfaces are attached to.

Hm, I don't really understand your question, but I'll try to explain
how I did this.

Both struct usb_device and struct usb_interface now have a struct
device.  This is because _both_ things need to show up in the driverfs
tree.  I tried only making interfaces be devices (which is more of what
the USB core code things of as devices), but the tree just didn't make
much sense.  Also, a USB device contains such things as the control
pipe, and the usb descriptors and strings.  So it is useful to show the
device, as that's where you get the device name and serial number from :)

Does that help?

Try looking at the usb driverfs implementation as it is in 2.5.30, both
the interfaces and the main device show up in the tree, I didn't change
this.  All this patch does is start to use "struct device_driver", and
bind the drivers to the interfaces, _which_ is what the USB core has
always done (no change in functionality here.)  What this allows us to
do is remove (eventually) the USB list of devices, and remove some other
device list logic, as well as clean up the probe/disconnect interface.

thanks,

greg k-h

  reply	other threads:[~2002-08-10 15:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-10  0:10 [RFC] USB driver conversion to use "struct device_driver" Greg KH
2002-08-10  9:57 ` [linux-usb-devel] " Oliver Neukum
2002-08-10 15:40   ` Greg KH [this message]
2002-08-10 21:18 ` David Brownell
2002-08-12 16:45   ` Greg KH
2002-08-12 18:30     ` David Brownell
2002-08-12 21:30       ` Greg KH
2002-08-12 23:36         ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020810154018.GB32083@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=mochel@osdl.org \
    --cc=oliver@neukum.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox