> > Wouldn't it make more sense to rename usb_free_dev to usb_dec_dev_use
> > and get rid of the macro? usb_free_dev isn't unconditionally freeing
> > the dev, so I think its name is confusing.
What I find confusing is related to the notion of "configurations".
Something that SHOULD work in Linux, but doesn't, is:
- connect device
- enumerate it, poke at it a bit, set initial config, probe drivers, use...
- some driver says "I can need to change config"
- (*) existing device state is cleared out, drivers unbound, etc
- new config is set, ideally (*) allocating new state
- drivers are probed for the new config
The bit that's not happening is the coupling of HCD state to each
config, and cleanup there -- marked (*) above.
Why do I bring that up here? Because that state is what the HCDs
get rid of when they "free_dev()" the devices! They can only implicitly
allocate that state. (Roman has pointed out problems in this area
before ... :) Oh, and I just noticed the "in usb_destroy_configuration()"
qualifier on the subject line!
Something that Linux will permit today:
- connect, enumerate device, bind drivers to interfaces
- those drivers issue I/O requests. Say, to EP-2-IN-INTR
and to EP-4-OUT-BULK.
- Some other driver changes the config, binds (hey, what
happened to the old bindings??) to one of the new interfaces.
- That new driver uses I/O to endpoints in the new config.
Say, EP-2-IN-ISO and EP-4-OUT-ISO.
- (Highly likely optional step: ) Oops. Either one of the old
interface bindings broke, or the HCD realized that two
drivers had wildly different beliefs about the endpoints
that were legal (and what they do), or karma struck.
What I think SHOULD happen at this level is that the HCDs
should get calls to free configuration-specific state, and then
initialize it. (Maybe also altsetting-specific state.)
To device drivers, different configurations are essentially
different logical devices. So apart from fixing some issues
with behavior of setting configs/altsettings, and clearing up
some lurking configuration/enumeration issues, that might
all but purely internal to usbcore.
> How about this:
>
> Split out usb_free_dev into usb_dev_dev_use and usb_free_dev. Have
> usb_dec_dev_use call usb_free_dev if the count hits zero. Make
> usb_free_dev static and change all calls to usb_free_dev to
> usb_dec_dev_use?
Right direction, sure. Device drivers should inc/dec use counts;
though maybe it'd be better to adopt the get (a ref) put (it back)
idiom instead. Changing that wouldn't break much code, sadly
enough; mostly the HCDs.
However, I'd still like to see a bit more policy checking/enforcement
on these counts. We know that khubd is there to make sure that
when hardware disconnects, all driver state is cleaned up. If anything
else tries to, that should trigger some sort of fault so the drivers will
be fixed. If it's nobody's job to guarantee it's cleaned up NOW, then
it'll never get reliably cleaned.
That is, maybe dec-to-zero should BUG(), and the hubd code should
just verify that the count is one before it wipes all that state clean...
[ Which seems to have come up in separate email. ]
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
