On 20-07-31 10:12:48, Alan Stern wrote:
> On Fri, Jul 31, 2020 at 02:06:20PM +0000, Peter Chen wrote:
> > On 20-07-31 14:25:20, Greg Kroah-Hartman wrote:
> > > On Fri, Jul 31, 2020 at 12:11:32PM +0000, Peter Chen wrote:
> > >
> > > Grab a reference from somewhere else and do not give it up for a long
> > > time.
> > >
> >
> > So wait_for_completion_timeout is suitable? The similar use case is when
> > we open the file at the USB Drive at Windows, and we click "Eject", it
> > will say "The device is currently in use", and refuse our "Eject"
> > operation.
> >
> > When we try to remove the gadget, if the gadget is in use, we could
> > refuse the remove operation, reasonable?
>
> No, the real solution is to fix the UDC drivers. They need to allocate
> the gadget structure dynamically instead of reusing it. And they should
> have a real release routine that deallocates the gadget structure.
>
> Alan Stern
So, the basic routine should like below. I thought the usb_gadget should
be deallocated before the UDC driver remove itself (UDC device
is the parent of usb_gadget device), I may not need to wrong about it,
it is just a memory region, it could release later.
xxx_udc_release(struct device *gadget_dev)
{
struct usb_gadget *gadget = container_of(gadget_dev, struct
usb_gadget, dev);
kfree(gadget);
}
xxx_udc_probe(pdev)
{
udc_priv_data = kzalloc(sizeof(*udc_priv_data), GFP_KERNEL);
gadget = kzalloc(sizeof(struct usb_gadget), GFP_KERNEL);
udc_priv_data->gadget = gadget;
...
usb_add_gadget_udc_release(&pdev->dev, gadget, xxx_udc_release);
}
At xxx_udc_remove(pdev)
{
usb_del_gadget_udc(udc_priv_data->gadget);
/* need to never reference udc_priv_data->gadget any more */
udc_priv_data other deinit;
kfree(udc_priv_data);
}
Since all structures xxx_udc_release uses are common one, it could
replace usb_udc_nop_release at udc/core.c.
--
Thanks,
Peter Chen
