Wow, I can't believe no one has said anything about this yet...
Great ideas Johannes, my comments are embedded below:
On Fri, Mar 24, 2000 at 06:01:38PM -0800, Johannes Erdfelt wrote:
>
> If we match, then we call a driver function. The device probing function
> may proactively claim interfaces. It may also change the default
> configuration.
So I am assuming that each driver needs to register the fact that it can
handle these particular idVendor/idProduct/bcdDevice pairs in some
manner.
And if the driver changes the default configuration at this time, does
it still "own" the device? Or does the probing sequence start up again?
(I'm thinking of the case where a device wants to switch to the firmware
download mode, which is a different configuration. A different driver
might want to now catch this device, instead of the one that caused the
switch to happen. Or am I just making things too complicated here than
they really have to be?)
> Next, the interfaces are matched against a driver.
Do you mean, "Next, if the device didn't match the above pairing"? Or
will the interfaces always be matched against a driver?
> Drivers won't have specific interface probing functions anymore, they will
> have a _connect function which gets called after the election process and
> a driver has been selected for the interfaces. From the _connect function,
> any remaining unclaimed interfaces may be claimed (is this last part
> needed?).
So the logic for choosing whose _connect function lives in usbcore now,
instead of the driver electing to choose. I like this a lot better, it
should get rid of the race conditions in which drivers in the past have
"accidentally" claimed devices that they shouldn't have (like usb-serial
grabbing the root hubs :)
I think that the _connect function should be allowed to grab interfaces
that it knows about, and hasn't told the rest of the world about (lots
of vendor specific things can happen here.)
> Should we make decisions on which configuration to use based on the MaxPower
> (or other attributes) defined by the configuration?
I think that the selection should be up to the driver for the power
issue. But at least let the driver know how much power it is currently
allowed to use. That way, if the device wants more power than is
available, it can just not start up the device at all. Or would this
logic be better if it stayed in usbcore? It needs to be somewhere.
> This was a rough first draft. Any comments/opinions?
Good job. Have you tried this out with any devices yet to see how it
works?
You also mention that this is for userspace. Do you think that any of
these ideas can trickle into the core for those drivers that can't live
in userspace?
Are you envisioning this as a 2.4.x change, or do you think we should do
this sooner (like this week)?
greg k-h
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
