On Sun, Mar 26, 2000, Greg KH <[EMAIL PROTECTED]> wrote:
>
> 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.
I don't know if this can be manually done or not. The intent was to have
this coded in a user space config. Perhaps when a user updates a kernel
to add a new driver, they update devfsd or something. I figured this
was alright since the same had to be done for conf.modules as it is.
> 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?)
The device function (which is not quite a probe) can claim interfaces if it
wishes. If it claims them all, then the interface election process doesn't
take place (since there are no interfaces to elect).
> > 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?
Next always happens. However, it only does something useful if there are
interfaces which have not been claimed (by the device function).
> > 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.)
This is fine. The _connect functions only get called after the election
process, so claiming them to be correct/complete is fine.
> > 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.
The hub code needs to do this, but it doesn't currently. Since the hub code
is compiled into the core, having some functions to report available power
would be possible.
> > 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?
I have some semi working code. The problem is modifying the USB drivers to
use the new scheme. It's not too different, but it's different enough to
take a bit of time to read the code. Plus, I need to work on some of the
devfs code since I found a couple of small problems in the plan when I
was writing it up for the list.
I expect to have the standard drivers, like hub, hid, keyboard, mouse and
also cpia done early in the week so I can do some more testing to see if
there's anything I forgot about.
> 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?
The idea is to have the election process occur in userspace and pick
which kernel driver is responsible for each device.
This is what necessitated the devfs like interface.
It would also modprobe any drivers which aren't currently loaded.
If this userspace daemon doesn't exist or isn't running, then the current
scheme would be used.
> Are you envisioning this as a 2.4.x change, or do you think we should do
> this sooner (like this week)?
I'd like something to go into 2.4.x since there is not current scheme
(no demand loaded modules). We'll see how well this works. I expect to
have some initial code eary this week.
Thanks for the feedback!
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
