On 4 Jun 2003 at 19:29, Leigh Bassett wrote:
> On 4 Jun 2003 at 19:29, Oliver Neukum wrote:
>
> > > > As for cdc-acm, I don't think it should be doing that. The code
> > > > that chooses a configuration can reasonably change its mind, for
> > > > example if there was a choice and no driver could bind to that
> > > > initial selection ... I don't think probe() should be allowed to
> > > > change configurations.
> > >
> > > To the contrary, probe() is the only component in the system that
> > > actually understands a device configuration. The higher-level code
> > > is just blindly flipping through a list looking for help.
> > >
> > > The driver is the component that understands the attached device and
> > > should be able to determine its configuration. That's the
> > > definition of a driver, IMHO.
> >
> > A device may have several interfaces in its configurations. Which
> > driver shall decide? And who shall decide which driver is to decide?
> >
> > But of course there may be vendor specific devices whose drivers
> > should set configuration. We need to accomodate both. The question is,
> > how exactly?
> >
> > Regards
> > Oliver
>
> The only information the core has is the vendor and product IDs.
> This is certainly not sufficient to determine which of multiple
> configurations should be used / activated.
>
> It is the responsibility of the driver to take control of a device if
> it can, including multiple dissimilar internal functions. Since it
> was registered with a matching vendor and product ID in the first
> place, it can presumably handle all aspects of that device.
>
> A good example is my Brother MFC 9200C. It contains a printer, a fax
> machine, a scanner, and a smart-card reader. Each of these has
> different driver requirements, yet they should all be supported (or
> not support) by a single driver and a single probe() call. IMHO.
It should be possible to have two styles of drivers. Roughly speaking
generic class drivers and vendor specific drivers.
Class drivers should only consider the smallest area of management
available to them, probably the interface.
Vendor provided drivers will need to be able to control and manage an
entire device. It may also be interesting to allow a vendor driver to
request that a class driver be used for an interface.
If we don't make it possible and easy for vendors to support their
devices under Linux don't be suprised if they continue to not offer
support for Linux.
--
__O
Belcarra - Embedded Linux USB Software _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[EMAIL PROTECTED]> 604-461-7532
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
