On Fri, 18 Aug 2006, David Brownell wrote: > On Friday 18 August 2006 9:28 am, Alan Stern wrote: > > > The one interesting aspect is that the dev_set_drvdata calls were > > moved from the usb_create_hcd and usb_put_hcd routines, where they > > clearly don't belong, into usb_add_hcd and usb_remove_hcd. This > > shouldn't cause any problems. > > Actually it'd be best to not do that. When initializing an integrated > dual role controller -- basically a set of FIFOs programmable to act as > either host or peripheral mode, taking maybe 1/4 the silicon of separate > controllers and likely OTG-capable -- it turns out to be important to be > able to strongly decouple host side setup/create from activation/add. > > That's because activating the host needs to be delayed until it's also > possible to activate the peripheral role (that is, the gadget driver > has been registered too) ... but it must also be possible to do things > like "rmmod" the combined host/peripheral driver before a gadget driver > is loaded, and that means that the driver needs to get at the information > currently stored by create() via set_drvdata().
Then you're saying that although it won't cause any problems currently, it would make things difficult in the future or for out-of-tree drivers. > If they "clearly don't belong", it would be because the driver itself, > rather than the glue layer, ought to control that driver data field. I'll buy that. > For example, by pointing to the driver-private structure used to manage > both roles (host, peripheral), rather than a usbcore structure that's > irrelevant if usbcore isn't configured (e.g. a peripheral-only board). > But I don't see that as currently being practical. So meanwhile, > please leave that part of the setup/create logic as-is. The thing is, they _can't_ be left where they are. usb_put_hcd can be called an arbitrarily large number of times (provided it's balanced by an equal number of calls to usb_get_hcd) while the driver is still running. We can't have it setting the driver data to NULL. The only reason it has worked up until now is that there hasn't been any usb_get_hcd! But the patch adds one, and it is used in a few places. In principle the call in usb_create_hcd could stay where it is. But it would need to get undone somehow -- where should that happen? Maybe it would be best to precede this patch with another one that moves all those set_drvdata calls into the individual drivers and out of the core. Alan Stern ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
