The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Felipe Balbi <balbi@kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	USB mailing list <linux-usb@vger.kernel.org>,
	linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
Date: Tue, 3 May 2022 10:54:10 -0400	[thread overview]
Message-ID: <YnFCEn45XwDWM/9Y@rowland.harvard.edu> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2205031209030.681336@ramsan.of.borg>

On Tue, May 03, 2022 at 12:14:30PM +0200, Geert Uytterhoeven wrote:
> 	Hi Alan,
> 
> 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@rowland.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.

> After boot-up, only one gadget device is visible:

Naturally, since the first registration succeeds and the later ones fail 
because they can't reuse the same name.

>     root@h3-salvator-xs:~# ls -l /sys/bus/gadget/devices/
>     total 0
>     lrwxrwxrwx 1 root root 0 Feb 14  2019 gadget -> ../../../devices/platform/soc/e659c000.usb/gadget
>     root@h3-salvator-xs:~#
> 
> Reverting this patch fixes the issue.

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?

Alan Stern

  reply	other threads:[~2022-05-03 14:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YjeEbHL8ITkW692W@rowland.harvard.edu>
     [not found] ` <YmKt3kH+85kjzdbL@kroah.com>
     [not found]   ` <YmSc29YZvxgT5fEJ@rowland.harvard.edu>
     [not found]     ` <YmSo6fU1FlNq8cOZ@rowland.harvard.edu>
     [not found]       ` <YmSpKpnWR8WWEk/p@rowland.harvard.edu>
     [not found]         ` <YmSpdxaDNeC2BBOf@rowland.harvard.edu>
2022-05-03 10:14           ` [PATCH 4/4] USB: gadget: Add a new bus for gadgets Geert Uytterhoeven
2022-05-03 14:54             ` Alan Stern [this message]
2022-05-03 15:27               ` Geert Uytterhoeven
2022-05-03 15:48                 ` Alan Stern
2022-05-04 14:40                   ` Greg KH
2022-05-07 15:36                   ` Alan Stern
2022-05-09  7:46                     ` Geert Uytterhoeven
2022-05-09 14:15                       ` Alan Stern
2022-05-09 14:42                         ` Geert Uytterhoeven
2022-05-09 15:05                           ` Alan Stern
2022-05-09 16:23                             ` Greg KH
2022-05-09 16:47                               ` Alan Stern
2022-05-10  7:52                                 ` Greg KH

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=YnFCEn45XwDWM/9Y@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=balbi@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox