From: Felipe Balbi <balbi@kernel.org>
To: Greg KH <greg@kroah.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Roger Quadros <rogerq@ti.com>,
vivek.gautam@codeaurora.org, USB list <linux-usb@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device
Date: Wed, 12 Apr 2017 10:33:34 +0300 [thread overview]
Message-ID: <87fuheaxm9.fsf@linux.intel.com> (raw)
In-Reply-To: <20170412064550.GA6143@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]
Hi,
Greg KH <greg@kroah.com> writes:
>> 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;
>> }
>>
>> 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?
>>
>> Iff we change struct gadget to contain a struct device *dev instead of a
>> struct device dev, then sure, we will need to cope with proper
>> ->release() implementations.
>>
>> As it is, it brings nothing to the table, IMO.
>
> You always have to have a release function for a kobject, no matter
> where it is, as it is being reference counted. To not do so, is a huge
> indication of a problem in the design.
okay, this goes all the way back to when Dave B wrote the API, it has
always had empty ->release() functions (not all UDCs, though). I'll make
sure to review all of this for v4.13.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-04-12 7:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-03 12:20 [PATCH v3 0/3] usb: dwc3: dual-role support Roger Quadros
2017-04-03 12:20 ` [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device Roger Quadros
2017-04-03 14:19 ` Alan Stern
2017-04-04 7:47 ` Felipe Balbi
2017-04-04 14:17 ` Alan Stern
2017-04-05 8:34 ` Felipe Balbi
2017-04-05 14:12 ` Alan Stern
2017-04-10 10:05 ` Felipe Balbi
2017-04-10 15:17 ` Alan Stern
2017-04-11 7:34 ` Felipe Balbi
2017-04-11 14:12 ` Alan Stern
2017-04-11 14:19 ` Greg KH
2017-04-12 6:01 ` Felipe Balbi
2017-04-12 6:45 ` Greg KH
2017-04-12 7:33 ` Felipe Balbi [this message]
2017-04-12 14:30 ` Alan Stern
2017-04-03 12:20 ` [PATCH v3 2/3] usb: dwc3: make role-switching work with debugfs/mode Roger Quadros
2017-04-03 12:20 ` [PATCH v3 3/3] usb: dwc3: Add dual-role support Roger Quadros
2017-04-03 19:21 ` kbuild test robot
2017-04-04 7:42 ` Roger Quadros
2017-04-04 7:46 ` [PATCH v4 " Roger Quadros
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fuheaxm9.fsf@linux.intel.com \
--to=balbi@kernel.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rogerq@ti.com \
--cc=stern@rowland.harvard.edu \
--cc=vivek.gautam@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.