From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: kieran.bingham@ideasonboard.com
Cc: linux-usb@vger.kernel.org, Felipe Balbi <balbi@kernel.org>,
Joel Pepper <joel.pepper@rwth-aachen.de>,
Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Subject: [3/8] usb: gadget: uvc: configfs: Allocate groups dynamically
Date: Thu, 02 Aug 2018 00:37:13 +0300 [thread overview]
Message-ID: <7269586.OUnpxaZDRU@avalon> (raw)
Hi Kieran,
On Wednesday, 1 August 2018 12:58:40 EEST Kieran Bingham wrote:
> On 01/08/18 01:29, Laurent Pinchart wrote:
> > The UVC configfs implementation creates all groups as global static
> > variables. This prevents creationg of multiple UVC function instances,
>
> /creationg/creation/
>
> > as they would all require their own configfs group instances.
> >
> > Fix this by allocating all groups dynamically. To avoid duplicating code
> > around, extend the config_item_type structure with group name and
> > children, and implement helper functions to create children
> > automatically for most groups.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> I'm struggling to see what paths free all of the dynamically created
> children in this patch.
>
> Is this already supported by the config_group framework?
>
> I see a reference to config_group_put(&opts->func_inst.group); in one
> error path - but that's about it.
>
> Am I missing something nice and obvious? (or is it already handled by
> framework code not in this patch)
>
>
> In fact, I can't see how it could be handled by core - as the children
> are added to a new structure you have created.
>
> I'll let you look into this :)
I did, for a whole day :-S It wasn't easy as the configfs documentation is
quite terse, and doesn't clearly explain when and how references should be
acquired and released. I'll post a v2 shortly.
> > ---
> >
> > drivers/usb/gadget/function/f_uvc.c | 8 +-
> > drivers/usb/gadget/function/uvc_configfs.c | 480 ++++++++++++++----------
> > 2 files changed, 282 insertions(+), 206 deletions(-)
[snip]
> > diff --git a/drivers/usb/gadget/function/uvc_configfs.c
> > b/drivers/usb/gadget/function/uvc_configfs.c index
> > dbc95c9558de..e019ea317c7a 100644
> > --- a/drivers/usb/gadget/function/uvc_configfs.c
> > +++ b/drivers/usb/gadget/function/uvc_configfs.c
[snip]
> > -static struct config_group uvcg_terminal_grp;
> > -
> > -static const struct config_item_type uvcg_terminal_grp_type = {
> > - .ct_owner = THIS_MODULE,
> > +static const struct uvcg_config_group_type uvcg_terminal_grp_type = {
> > + .type = {
> > + .ct_owner = THIS_MODULE,
> > + },
> > + .name = "terminal",
> > + .children = (const struct uvcg_config_group_type*[]) {
>
> Is this cast really needed? Or is it just to constify the array ?
It's needed to make the expression within the curly braces an array that is
then turned into a pointer to initialize the children field, which is defined
as
const struct uvcg_config_group_type **children;
Without that you would get the following compilation errors.
drivers/usb/gadget/function/uvc_configfs.c:557:2: error: braces around scalar
initializer [-Werror]
drivers/usb/gadget/function/uvc_configfs.c:557:2: error: (near initialization
for ‘uvcg_terminal_grp_type.children’) [-Werror]
drivers/usb/gadget/function/uvc_configfs.c:558:3: error: initialization from
incompatible pointer type [-Werror]
drivers/usb/gadget/function/uvc_configfs.c:558:3: error: (near initialization
for ‘uvcg_terminal_grp_type.children’) [-Werror]
drivers/usb/gadget/function/uvc_configfs.c:559:3: error: excess elements in
scalar initializer [-Werror]
drivers/usb/gadget/function/uvc_configfs.c:559:3: error: (near initialization
for ‘uvcg_terminal_grp_type.children’) [-Werror]
drivers/usb/gadget/function/uvc_configfs.c:560:3: error: excess elements in
scalar initializer [-Werror]
drivers/usb/gadget/function/uvc_configfs.c:560:3: error: (near initialization
for ‘uvcg_terminal_grp_type.children’) [-Werror]
Such a syntax removes the need to declare the array externally to
uvcg_terminal_grp_type as
static const struct uvcg_config_group_type *uvcg_terminal_grp_children[] = {
&uvcg_camera_grp_type,
&uvcg_output_grp_type,
NULL,
};
static const struct uvcg_config_group_type uvcg_terminal_grp_type = {
.type = {
.ct_owner = THIS_MODULE,
},
.name = "terminal",
.children = uvcg_terminal_grp_children,
};
> > + &uvcg_camera_grp_type,
> > + &uvcg_output_grp_type,
> > + NULL,
> > + },
> > };
[snip]
next reply other threads:[~2018-08-01 21:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-01 21:37 Laurent Pinchart [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-08-01 9:58 [3/8] usb: gadget: uvc: configfs: Allocate groups dynamically Kieran Bingham
2018-08-01 0:29 Laurent Pinchart
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=7269586.OUnpxaZDRU@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=andrzej.p@samsung.com \
--cc=balbi@kernel.org \
--cc=joel.pepper@rwth-aachen.de \
--cc=kieran.bingham@ideasonboard.com \
--cc=linux-usb@vger.kernel.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.