On Tue, 31 May 2011, Sebastian Andrzej Siewior wrote: > Michal Nazarewicz wrote: > >> * Call this in your gadget driver's module initialization function, > >> * to tell the underlying usb controller driver about your driver. > >> - * The @bind() function will be called to bind it to a gadget before > >> this > >> - * registration call returns. It's expected that the @bind() > >> function will > >> - * be in init sections. > >> + * The @driver->bind() function will be called to bind it to a gadget > >> before > >> + * this registration call returns. It's expected that the > >> @driver->bind() > >> + * function will be in init sections. > >> */ > >> int usb_gadget_probe_driver(struct usb_gadget_driver *driver, > >> int (*bind)(struct usb_gadget *)); > >> +int usb_gadget_register_driver(struct usb_gadget_driver *driver); > > > > Wasn't the whole point of introducing usb_gadget_probe_driver() and > > removing bind callback to avoid problems with section mismatches? > > Adding it back the way it was will bring all those warnings back. > > I've been looking at b0fca50f5 and I don't see how this fixes the issue. > It makes the warning go way but that is it. The point is that ->bind() > points to something that will be discarded after the driver is loaded. > This is also the case with ->probe() in struct pci_dev for instance[0]. > Nobody removed the callback there. > > So if you call usb_gadget_probe_driver() at post init time and > composite_bind() is __init then it points to the function which is already > discarded. It looks like the section-mismatch problem was solved incorrectly. Instead of getting passed as an argument, the pointer to the bind routine should have been left in the table and instead, the routines should be marked with __devinit instead of __init. Either way, the implication is that the pointer must not be used after the driver's initialization routine has returned. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
