[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdVDK0W0T3=+2c1E6wtwy5JTUemTGYyj3PFuVUhK++AzrA@mail.gmail.com>
Date: Tue, 3 May 2022 17:27:08 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Felipe Balbi <balbi@...nel.org>,
Greg KH <gregkh@...uxfoundation.org>,
USB mailing list <linux-usb@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
Subject: Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
Hi Alan,
On Tue, May 3, 2022 at 5:14 PM Alan Stern <stern@...land.harvard.edu> wrote:
> On Tue, May 03, 2022 at 12:14:30PM +0200, Geert Uytterhoeven wrote:
> > On Sat, 23 Apr 2022, Alan Stern wrote:
> > > This patch adds a "gadget" bus and uses it for registering gadgets and
> > > their drivers. From now on, bindings will be managed by the driver
> > > core rather than through ad-hoc manipulations in the UDC core.
> > >
> > > As part of this change, the driver_pending_list is removed. The UDC
> > > core won't need to keep track of unbound drivers for later binding,
> > > because the driver core handles all of that for us.
> > >
> > > However, we do need one new feature: a way to prevent gadget drivers
> > > from being bound to more than one gadget at a time. The existing code
> > > does this automatically, but the driver core doesn't -- it's perfectly
> > > happy to bind a single driver to all the matching devices on the bus.
> > > The patch adds a new bitflag to the usb_gadget_driver structure for
> > > this purpose.
> > >
> > > A nice side effect of this change is a reduction in the total lines of
> > > code, since now the driver core will do part of the work that the UDC
> > > used to do.
> > >
> > > A possible future patch could add udc devices to the gadget bus, say
> > > as a separate device type.
> > >
> > > Signed-off-by: Alan Stern <stern@...land.harvard.edu>
> >
> > Thanks for your patch, which is now commit fc274c1e997314bf ("USB:
> > gadget: Add a new bus for gadgets") in usb-next.
> >
> > This patch cause a regression on the Renesas Salvator-XS development
> > board, as R-Car H3 has multiple USB gadget devices:
>
> Then these gadgets ought to have distinct names in order to avoid the
> conflict below:
>
> > sysfs: cannot create duplicate filename '/bus/gadget/devices/gadget'
> > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.18.0-rc1-arm64-renesas-00074-gfc274c1e9973 #1587
> > Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
> > Call trace:
> > dump_backtrace+0xcc/0xd8
> > show_stack+0x14/0x30
> > dump_stack_lvl+0x88/0xb0
> > dump_stack+0x14/0x2c
> > sysfs_warn_dup+0x60/0x78
> > sysfs_do_create_link_sd.isra.0+0xe4/0xf0
> > sysfs_create_link+0x20/0x40
> > bus_add_device+0x64/0x110
> > device_add+0x31c/0x850
> > usb_add_gadget+0x124/0x1a0
> > usb_add_gadget_udc_release+0x1c/0x50
> > usb_add_gadget_udc+0x10/0x18
> > renesas_usb3_probe+0x450/0x728
> ...
>
> Having three gadget devices, all named "gadget", doesn't seem like a
> good idea.
I'm not so sure where these names are coming from.
`git grep '"gadget"'` points to the following likely targets:
drivers/usb/gadget/udc/core.c: dev_set_name(&gadget->dev, "gadget");
drivers/usb/renesas_usbhs/mod_gadget.c: gpriv->mod.name = "gadget";
Changing both names reveals the problem is actually caused by
the former ;-)
> This doesn't seem like it should be too hard to fix, although I'm not
> at all familiar with the renesas-usb3 driver. Do you know who maintains
> that driver? Is it you?
Adding Shimoda-san to CC (but he's enjoying Golden Week).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists