Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration() can change configs
Am Donnerstag, 5. Juni 2003 22:16 schrieb David Brownell: This patch: - moves the config-specific sysfs updates out of usb_new_device() into usb_set_configuration(), where it belongs. - makes usb_set_configuration() get rid of sysfs state for the previous configuration, including driver unbinding - makes the bConfigurationValue device attribute be writable through sysfs. - makes usb/core/message.c debug output work In short, usb_set_configuration() now does what it's supposed to do: it changes the device config, and all usbcore state depending on it. Way cool. A few points. 1. We need a special function for devices that just reset the current config. It seems that there are really buggy devices which need this. 2. You can set hubs to config 0. What will that do? Regards Oliver --- 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
Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration()can change configs
2. You can set hubs to config 0. What will that do? You can set anything to config 0 -- perfectly reasonable. I take it you're suggesting that hubs are special enough that allowing that to happen would be a Bad Thing? Makes sense to me. Suggestion? I take that back. Your implementation even handles hubs correctly. I am just unsure about virtual root hubs, but these are just details. Regards Oliver --- 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
Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration()can change configs
On Thu, 5 Jun 2003, David Brownell wrote: Oliver Neukum wrote: Am Donnerstag, 5. Juni 2003 22:16 schrieb David Brownell: In short, usb_set_configuration() now does what it's supposed to do: it changes the device config, and all usbcore state depending on it. Way cool. A few points. 1. We need a special function for devices that just reset the current config. It seems that there are really buggy devices which need this. Yes, something like usb_reset_config(dev) call is needed. As well as converting code to use it, instead of the current calls to usb_set_configuration() in drivers. I want to echo Oliver's sentiment; this is a great patch. Implementing usb_reset_config(dev) will be tricky. Since it is called from within probe() it can't call usb_set_configuration() directly because the sysfs lock is already held. Somehow it needs to tell the process that's registering the interfaces to stop -- no point binding any more drivers when you're just going to change the configuration anyway -- and then do the set_config. Your current scheme of unbinding the drivers before changing the configuration doesn't lend itself easily to invoking a callback in the driver once the set_config is complete. How do you propose to let the driver know whether the call succeeded or failed? Come to think of it, what use could the driver make of that information? If the call failed there's nothing the driver can do, and if it succeeded the driver will be probed again anyway. Alan Stern --- 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
Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration()can change configs
On Fri, 6 Jun 2003, David Brownell wrote: The way I see it, usb_reset_config(dev) should actually be easy ... but it'll necessarily have significant restrictions when used on devices with multiple interfaces. Basically, don't use it unless you're the only driver bound (or being bound) to the device -- else you'll likely break the other driver(s). In those cases, usb_set_interface() provides the relevant single-driver scope. The reset_config() implementation could just issue control requests directly, either set_config to zero then set_config back to previous value; or just set_config to current. And it'll clear reset all toggles (and halt status, if we keep that). It's not _changing_ the config, so it'd be safe to call within probe() ... Come to think of it, what use could the driver make of that information? If the call failed there's nothing the driver can do, and if it succeeded the driver will be probed again anyway. You mean, for a usb_reset_config(dev)? I'd imagine that it wouldn't even bother unbinding. As I recall, the current usage is almost exclusively in probe() calls for single-interface devices. Sorry, I misspoke in my original message. I didn't mean usb_reset_config(); I was thinking about drivers that want to change to a different configuration during their probe(). How do you plan to accomodate that? Alan Stern --- 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
Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration()can change configs
Alan Stern wrote: On Thu, 5 Jun 2003, David Brownell wrote: Yes, something like usb_reset_config(dev) call is needed. As well as converting code to use it, instead of the current calls to usb_set_configuration() in drivers. I want to echo Oliver's sentiment; this is a great patch. Needed a few others to be merged first though ... :) Implementing usb_reset_config(dev) will be tricky. Since it is called from within probe() it can't call usb_set_configuration() directly because the sysfs lock is already held. Somehow it needs to tell the process that's registering the interfaces to stop -- no point binding any more drivers when you're just going to change the configuration anyway -- and then do the set_config. The way I see it, usb_reset_config(dev) should actually be easy ... but it'll necessarily have significant restrictions when used on devices with multiple interfaces. Basically, don't use it unless you're the only driver bound (or being bound) to the device -- else you'll likely break the other driver(s). In those cases, usb_set_interface() provides the relevant single-driver scope. The reset_config() implementation could just issue control requests directly, either set_config to zero then set_config back to previous value; or just set_config to current. And it'll clear reset all toggles (and halt status, if we keep that). It's not _changing_ the config, so it'd be safe to call within probe() ... Your current scheme of unbinding the drivers before changing the configuration doesn't lend itself easily to invoking a callback in the driver once the set_config is complete. How do you propose to let the driver know whether the call succeeded or failed? A reset_config() call would just return zero-or-negative-errno, and wouldn't unbind. Come to think of it, what use could the driver make of that information? If the call failed there's nothing the driver can do, and if it succeeded the driver will be probed again anyway. You mean, for a usb_reset_config(dev)? I'd imagine that it wouldn't even bother unbinding. As I recall, the current usage is almost exclusively in probe() calls for single-interface devices. - Dave Alan Stern --- 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
Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration()can change configs
Alan Stern wrote: Sorry, I misspoke in my original message. I didn't mean usb_reset_config(); I was thinking about drivers that want to change to a different configuration during their probe(). How do you plan to accomodate that? As I said earlier on a different thread: by adding a new struct usb_driver method that returns the right config: u8 configure (struct usb_device *dev); Multi-configuration devices would get an additional enumeration step: scan the drivers that match its device descriptor, and which have a configure() method, asking them what config to use. Presumably the same thing could happen in certain modprobe scenarios, after enumeration. Details TBD. - Dave --- 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
Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration()can change configs
Sorry, I misspoke in my original message. I didn't mean usb_reset_config(); I was thinking about drivers that want to change to a different configuration during their probe(). How do you plan to accomodate that? Let the perverts use a workqueue. Regards Oliver --- 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
Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration()can change configs
Alan Stern wrote: On Thu, 5 Jun 2003, David Brownell wrote: Yes, something like usb_reset_config(dev) call is needed. As well as converting code to use it, instead of the current calls to usb_set_configuration() in drivers. I want to echo Oliver's sentiment; this is a great patch. Needed a few others to be merged first though ... :) Implementing usb_reset_config(dev) will be tricky. Since it is called from within probe() it can't call usb_set_configuration() directly because the sysfs lock is already held. Somehow it needs to tell the process that's registering the interfaces to stop -- no point binding any more drivers when you're just going to change the configuration anyway -- and then do the set_config. The way I see it, usb_reset_config(dev) should actually be easy ... but it'll necessarily have significant restrictions when used on devices with multiple interfaces. Basically, don't use it unless you're the only driver bound (or being bound) to the device -- else you'll likely break the other driver(s). In those cases, usb_set_interface() provides the relevant single-driver scope. The reset_config() implementation could just issue control requests directly, either set_config to zero then set_config back to previous value; or just set_config to current. And it'll clear reset all toggles (and halt status, if we keep that). It's not _changing_ the config, so it'd be safe to call within probe() ... Your current scheme of unbinding the drivers before changing the configuration doesn't lend itself easily to invoking a callback in the driver once the set_config is complete. How do you propose to let the driver know whether the call succeeded or failed? A reset_config() call would just return zero-or-negative-errno, and wouldn't unbind. Come to think of it, what use could the driver make of that information? If the call failed there's nothing the driver can do, and if it succeeded the driver will be probed again anyway. You mean, for a usb_reset_config(dev)? I'd imagine that it wouldn't even bother unbinding. As I recall, the current usage is almost exclusively in probe() calls for single-interface devices. - Dave Alan Stern --- 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
Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration()can change configs
Oliver Neukum wrote: Am Donnerstag, 5. Juni 2003 22:16 schrieb David Brownell: In short, usb_set_configuration() now does what it's supposed to do: it changes the device config, and all usbcore state depending on it. Way cool. A few points. 1. We need a special function for devices that just reset the current config. It seems that there are really buggy devices which need this. Yes, something like usb_reset_config(dev) call is needed. As well as converting code to use it, instead of the current calls to usb_set_configuration() in drivers. 2. You can set hubs to config 0. What will that do? You can set anything to config 0 -- perfectly reasonable. I take it you're suggesting that hubs are special enough that allowing that to happen would be a Bad Thing? Makes sense to me. Suggestion? - Dave --- 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
