> 1. Must it be legal for a driver to set configuration during probe ?
I think the current expectation is that it should be legal in some cases, like maybe when no probe() yet succeeded. BUT: there are bugs in this area, and maybe that doesn't work. Drivers that change config today are rare, bugs would hardly be noticed. And I don't much like the implications of calling it then, either. If it's not legal to do that then, my question is when _would_ it get done. We might need another kind of driver mechanism here. Maybe a driver flag (device_id.match_flags) that says the driver knows how to make config choices (new method)? Maybe no kernel hooks at all, and only do it through driverfs! > 2. Is a patch that adds a struct usb_device* to struct usb_interface > acceptable? I'd say no, given intf_to_usbdev() is already there. Re the locking issue, maybe what we need is an rwlock on the config, and binding any driver to one of its interface grabs a readlock. If you can get the writelock, you know it's safe to change the config (since nobody is bound to any interface, nobody could care). Since probe() would need to be done with a readlock, it would then not be possible to change config then, which would make folk happy. > 3. Where in the generic device model is the configuration stored > and how can it be manipulated ? There's a readonly driverfs attribute that usb adds to the model. Arguably it should get writable, calling usb_set_configuration(). In such a case I'd consider it a bug if this didn't forcibly disconnect() each driver from its interface: the sysadmin clearly said what to do, and usb should just do it. Hmm ... if you call usb_set_configuration() today, nothing updates driverfs to know that the previous configuration's interfaces just became irrelevant. Only the default config ever shows in driverfs?? > 4. May I split usb_disconnect() into an interface and a usb_device part ? That needs other work too ... like, shouldn't the driver model core be handling children-first disconnect, which includes both interface shutdown and (for hubs) port shutdown? If you mean that we need something to clear out all "previous config" state, which would replace part of usb_disconnect(), I'd agree. The other user of that routine should be usb_set_configuration() ... all this being usbcore-internal. And clearly I'd like to see that issue fixed, where something like the hcd framework's free_config() should be getting called to scrub out records of all (non-control) endpoints before the new config is expected to be usable. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
