On Tue, 31 May 2011 20:18:22 +0200, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
wrote:
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.
The routines were not the issue. The issue was that the structure with
all the callbacks was not __initdata. A fix was to declare it __refdata
but, it is my understanding that, it could lead to a problems if the
setup function was converted from __init to not-__init.
Either way, the implication is that the pointer must not be used after
the driver's initialization routine has returned.
Agreed.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +-----<email/xmpp: mnazarewicz@xxxxxxxxxx>-----ooO--(_)--Ooo--
--
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
