[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0809100949410.2408-100000@iolanthe.rowland.org>
Date: Wed, 10 Sep 2008 09:55:31 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Denis Joseph Barrow <D.Barow@...ion.com>
cc: Paulius Zaleckas <paulius.zaleckas@...tonika.lt>,
<linux-usb@...r.kernel.org>, netdev <netdev@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: hso: remove usb_driver_claim_interface()
On Wed, 10 Sep 2008, Denis Joseph Barrow wrote:
> Hi Paulius,
> I'm not in a position yet to know if this patch is good, yet at least.
> hso_probe gets called once for each serial ttyHSx device
> usually four per usb stick modem & once for the hsox network device
> per modem.
>
> From the comment on usb_driver_claim_interface
> * This is used by usb device drivers that need to claim more than one
> * interface on a device when probing (audio and acm are current examples).
>
> I'm not used to USB terminology
> From my understanding of the code
> we are claiming more than one interface on the usb modem multiple ttyHSx devices
> & one network device. However we get probed once for each interface
The idea behind usb_driver_claim_interface() is that it allows a driver
to bind to an arbitrary interface, generally because the driver needs
control of multiple interfaces in order to manage the device. For
example, an audio device might include both a control interface and a
data interface -- the driver would claim the data interface when it is
probed for the control interface, since both are needed to run the
device.
But if the interfaces are independent and the driver is going to be
probed for both of them anyway then there is no need to claim either
one. Just let the usual probing mechanism do its job.
And there is never any need to claim the interface for which the driver
is being probed, since the driver is already getting bound to that
interface.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists