[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1704121026010.2070-100000@iolanthe.rowland.org>
Date: Wed, 12 Apr 2017 10:30:02 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Felipe Balbi <balbi@...nel.org>
cc: Greg KH <greg@...ah.com>, Roger Quadros <rogerq@...com>,
<vivek.gautam@...eaurora.org>,
USB list <linux-usb@...r.kernel.org>,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same
gadget device
On Wed, 12 Apr 2017, Felipe Balbi wrote:
> >> Maybe... But I can't shake the feeling that Greg KH would strongly
> >> disagree. Hasn't he said, many times in the past, that any dynamically
> >> allocated device structure _must_ have a real release routine?
> >> usb_udc_nop_release() doesn't qualify.
> >
> > Aw, I wanted to publically yell at someone like the kernel documentation
> > says I am allowed to do so if anyone does such a foolish thing :)
>
> heh, except that we're not dynamically allocating struct device at all
> :-) Here's what we have for most UDCs (net2280.c included):
>
> struct my_udc {
> struct gadget gadget;
> [...]
> };
>
> probe()
> {
> struct my_udc *u;
>
> u = kzalloc(sizeof(*u), GFP_KERNEL);
> [...]
> return 0;
> }
Allow me to point out that the struct device is embedded inside the
struct gadget (actually struct usb_gadget) embedded inside the struct
my_udc, which _is_ dynamically allocated. Therefore the struct device
is located in dynamically allocated memory.
> Now, if this kzalloc() would be replaced with devm_kzalloc() wouldn't
> this result on a functionally equivalent execution to the patch I
> proposed above?
It would, and it would be equally wrong.
Alan Stern
Powered by blists - more mailing lists