* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
[not found] ` <YmSpdxaDNeC2BBOf@rowland.harvard.edu>
@ 2022-05-03 10:14 ` Geert Uytterhoeven
2022-05-03 14:54 ` Alan Stern
0 siblings, 1 reply; 13+ messages in thread
From: Geert Uytterhoeven @ 2022-05-03 10:14 UTC (permalink / raw)
To: Alan Stern
Cc: Felipe Balbi, Greg KH, USB mailing list, linux-renesas-soc, linux-kernel
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:
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
platform_probe+0x64/0xd0
really_probe+0x100/0x2a0
__driver_probe_device+0x74/0xd8
driver_probe_device+0x3c/0xe0
__driver_attach+0x80/0x110
bus_for_each_dev+0x6c/0xc0
driver_attach+0x20/0x28
bus_add_driver+0x138/0x1e0
driver_register+0x60/0x110
__platform_driver_register+0x24/0x30
renesas_usb3_driver_init+0x18/0x20
do_one_initcall+0x15c/0x31c
kernel_init_freeable+0x2f0/0x354
kernel_init+0x20/0x120
ret_from_fork+0x10/0x20
renesas_usb3: probe of ee020000.usb failed with error -17
...
renesas_usbhs: probe of e6590000.usb failed with error -17
After boot-up, only one gadget device is visible:
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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
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
2022-05-03 15:27 ` Geert Uytterhoeven
0 siblings, 1 reply; 13+ messages in thread
From: Alan Stern @ 2022-05-03 14:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Felipe Balbi, Greg KH, USB mailing list, linux-renesas-soc, linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
2022-05-03 14:54 ` Alan Stern
@ 2022-05-03 15:27 ` Geert Uytterhoeven
2022-05-03 15:48 ` Alan Stern
0 siblings, 1 reply; 13+ messages in thread
From: Geert Uytterhoeven @ 2022-05-03 15:27 UTC (permalink / raw)
To: Alan Stern
Cc: Felipe Balbi, Greg KH, USB mailing list, Linux-Renesas,
Linux Kernel Mailing List, Yoshihiro Shimoda
Hi Alan,
On Tue, May 3, 2022 at 5:14 PM Alan Stern <stern@rowland.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@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.
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@linux-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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
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
0 siblings, 2 replies; 13+ messages in thread
From: Alan Stern @ 2022-05-03 15:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Felipe Balbi, Greg KH, USB mailing list, Linux-Renesas,
Linux Kernel Mailing List, Yoshihiro Shimoda
On Tue, May 03, 2022 at 05:27:08PM +0200, Geert Uytterhoeven wrote:
> Hi Alan,
>
> On Tue, May 3, 2022 at 5:14 PM Alan Stern <stern@rowland.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@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.
>
> 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 ;-)
Ah, good.
One way to attack this would be to keep a static counter and dynamically
set the name to "gadget.%d" using the counter's value. Or keep a bitmap
of allocated gadget numbers and use the first available number.
Felipe, Greg, any opinions?
Ironically, the UDC driver itself provides a name in gadget->name. But
that string isn't unique either (in renesas-usb3, for instance, it is
always set to "renesas_usb3"), so it won't help solve this problem.
> > 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).
It looks like the problem has to be solved in the gadget core rather
than in the UDC driver. So we won't need to modify the driver after
all.
Alan Stern
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
2022-05-03 15:48 ` Alan Stern
@ 2022-05-04 14:40 ` Greg KH
2022-05-07 15:36 ` Alan Stern
1 sibling, 0 replies; 13+ messages in thread
From: Greg KH @ 2022-05-04 14:40 UTC (permalink / raw)
To: Alan Stern
Cc: Geert Uytterhoeven, Felipe Balbi, USB mailing list,
Linux-Renesas, Linux Kernel Mailing List, Yoshihiro Shimoda
On Tue, May 03, 2022 at 11:48:33AM -0400, Alan Stern wrote:
> On Tue, May 03, 2022 at 05:27:08PM +0200, Geert Uytterhoeven wrote:
> > Hi Alan,
> >
> > On Tue, May 3, 2022 at 5:14 PM Alan Stern <stern@rowland.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@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.
> >
> > 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 ;-)
>
> Ah, good.
>
> One way to attack this would be to keep a static counter and dynamically
> set the name to "gadget.%d" using the counter's value. Or keep a bitmap
> of allocated gadget numbers and use the first available number.
>
> Felipe, Greg, any opinions?
Just use an idr structure for the number, that's the simplest way to
track that.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
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
1 sibling, 1 reply; 13+ messages in thread
From: Alan Stern @ 2022-05-07 15:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Felipe Balbi, Greg KH, USB mailing list, Linux-Renesas,
Linux Kernel Mailing List, Yoshihiro Shimoda
On Tue, May 03, 2022 at 11:48:33AM -0400, Alan Stern wrote:
> On Tue, May 03, 2022 at 05:27:08PM +0200, Geert Uytterhoeven wrote:
> > Hi Alan,
> >
> > On Tue, May 3, 2022 at 5:14 PM Alan Stern <stern@rowland.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@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:
Geert:
Can you test the patch below? It ought to fix the problem (although it
might end up causing other problems down the line...)
Alan Stern
Index: usb-devel/drivers/usb/gadget/udc/core.c
===================================================================
--- usb-devel.orig/drivers/usb/gadget/udc/core.c
+++ usb-devel/drivers/usb/gadget/udc/core.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/device.h>
#include <linux/list.h>
+#include <linux/idr.h>
#include <linux/err.h>
#include <linux/dma-mapping.h>
#include <linux/sched/task_stack.h>
@@ -23,6 +24,8 @@
#include "trace.h"
+static DEFINE_IDA(gadget_id_numbers);
+
static struct bus_type gadget_bus_type;
/**
@@ -1248,7 +1251,6 @@ static void usb_udc_nop_release(struct d
void usb_initialize_gadget(struct device *parent, struct usb_gadget *gadget,
void (*release)(struct device *dev))
{
- dev_set_name(&gadget->dev, "gadget");
INIT_WORK(&gadget->work, usb_gadget_state_work);
gadget->dev.parent = parent;
@@ -1304,12 +1306,21 @@ int usb_add_gadget(struct usb_gadget *ga
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
udc->vbus = true;
+ ret = ida_alloc(&gadget_id_numbers, GFP_KERNEL);
+ if (ret < 0)
+ goto err_del_udc;
+ gadget->id_number = ret;
+ dev_set_name(&gadget->dev, "gadget.%d", ret);
+
ret = device_add(&gadget->dev);
if (ret)
- goto err_del_udc;
+ goto err_free_id;
return 0;
+ err_free_id:
+ ida_free(&gadget_id_numbers, gadget->id_number);
+
err_del_udc:
flush_work(&gadget->work);
device_del(&udc->dev);
@@ -1417,6 +1428,7 @@ void usb_del_gadget(struct usb_gadget *g
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
flush_work(&gadget->work);
device_del(&gadget->dev);
+ ida_free(&gadget_id_numbers, gadget->id_number);
device_unregister(&udc->dev);
}
EXPORT_SYMBOL_GPL(usb_del_gadget);
Index: usb-devel/include/linux/usb/gadget.h
===================================================================
--- usb-devel.orig/include/linux/usb/gadget.h
+++ usb-devel/include/linux/usb/gadget.h
@@ -386,6 +386,7 @@ struct usb_gadget_ops {
* @lpm_capable: If the gadget max_speed is FULL or HIGH, this flag
* indicates that it supports LPM as per the LPM ECN & errata.
* @irq: the interrupt number for device controller.
+ * @id_number: a unique ID number for ensuring that gadget names are distinct
*
* Gadgets have a mostly-portable "gadget driver" implementing device
* functions, handling all usb configurations and interfaces. Gadget
@@ -446,6 +447,7 @@ struct usb_gadget {
unsigned connected:1;
unsigned lpm_capable:1;
int irq;
+ int id_number;
};
#define work_to_gadget(w) (container_of((w), struct usb_gadget, work))
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
2022-05-07 15:36 ` Alan Stern
@ 2022-05-09 7:46 ` Geert Uytterhoeven
2022-05-09 14:15 ` Alan Stern
0 siblings, 1 reply; 13+ messages in thread
From: Geert Uytterhoeven @ 2022-05-09 7:46 UTC (permalink / raw)
To: Alan Stern
Cc: Felipe Balbi, Greg KH, USB mailing list, Linux-Renesas,
Linux Kernel Mailing List, Yoshihiro Shimoda
Hi Alan,
On Sat, May 7, 2022 at 5:36 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, May 03, 2022 at 11:48:33AM -0400, Alan Stern wrote:
> > On Tue, May 03, 2022 at 05:27:08PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, May 3, 2022 at 5:14 PM Alan Stern <stern@rowland.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@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:
>
> Geert:
>
> Can you test the patch below? It ought to fix the problem (although it
Thanks!
root@h3-salvator-xs:~# ls -l /sys/bus/gadget/devices/
total 0
lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.0 ->
../../../devices/platform/soc/e659c000.usb/gadget.0
lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.1 ->
../../../devices/platform/soc/ee020000.usb/gadget.1
lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.2 ->
../../../devices/platform/soc/e6590000.usb/gadget.2
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
LGTM, so
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> might end up causing other problems down the line...)
Can you please elaborate? I'm not too familiar with UBS gadgets.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
2022-05-09 7:46 ` Geert Uytterhoeven
@ 2022-05-09 14:15 ` Alan Stern
2022-05-09 14:42 ` Geert Uytterhoeven
0 siblings, 1 reply; 13+ messages in thread
From: Alan Stern @ 2022-05-09 14:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Felipe Balbi, Greg KH, USB mailing list, Linux-Renesas,
Linux Kernel Mailing List, Yoshihiro Shimoda
On Mon, May 09, 2022 at 09:46:25AM +0200, Geert Uytterhoeven wrote:
> > Geert:
> >
> > Can you test the patch below? It ought to fix the problem (although it
>
> Thanks!
>
> root@h3-salvator-xs:~# ls -l /sys/bus/gadget/devices/
> total 0
> lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.0 ->
> ../../../devices/platform/soc/e659c000.usb/gadget.0
> lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.1 ->
> ../../../devices/platform/soc/ee020000.usb/gadget.1
> lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.2 ->
> ../../../devices/platform/soc/e6590000.usb/gadget.2
>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> LGTM, so
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks!
> > might end up causing other problems down the line...)
>
> Can you please elaborate? I'm not too familiar with UBS gadgets.
I was concerned about the fact that changing the name of a file,
directory, or symbolic link in sysfs means changing a user API, and so
it might cause some existing programs to fail. That would be a
regression.
Perhaps the best way to work around the problem is to leave the name set
to "gadget" if the ID number is 0, while adding the ID number on to the
name if the value is > 0. What do you think?
Alan Stern
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
2022-05-09 14:15 ` Alan Stern
@ 2022-05-09 14:42 ` Geert Uytterhoeven
2022-05-09 15:05 ` Alan Stern
0 siblings, 1 reply; 13+ messages in thread
From: Geert Uytterhoeven @ 2022-05-09 14:42 UTC (permalink / raw)
To: Alan Stern
Cc: Felipe Balbi, Greg KH, USB mailing list, Linux-Renesas,
Linux Kernel Mailing List, Yoshihiro Shimoda
Hi Alan,
On Mon, May 9, 2022 at 4:15 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> On Mon, May 09, 2022 at 09:46:25AM +0200, Geert Uytterhoeven wrote:
> > > Geert:
> > >
> > > Can you test the patch below? It ought to fix the problem (although it
> >
> > Thanks!
> >
> > root@h3-salvator-xs:~# ls -l /sys/bus/gadget/devices/
> > total 0
> > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.0 ->
> > ../../../devices/platform/soc/e659c000.usb/gadget.0
> > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.1 ->
> > ../../../devices/platform/soc/ee020000.usb/gadget.1
> > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.2 ->
> > ../../../devices/platform/soc/e6590000.usb/gadget.2
> >
> > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > LGTM, so
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Thanks!
>
> > > might end up causing other problems down the line...)
> >
> > Can you please elaborate? I'm not too familiar with UBS gadgets.
>
> I was concerned about the fact that changing the name of a file,
> directory, or symbolic link in sysfs means changing a user API, and so
> it might cause some existing programs to fail. That would be a
> regression.
>
> Perhaps the best way to work around the problem is to leave the name set
> to "gadget" if the ID number is 0, while adding the ID number on to the
> name if the value is > 0. What do you think?
Oh, you mean the "gadget.N" subdirs, which are the targets of the
symlinks above? These were indeed named "gadget" before.
Would it be possible to append the ".N" suffixes only to the actual
symlinks, while keeping the target directory names unchanged?
E.g. /sys/bus/gadget/devices/gadget.0 ->
../../../devices/platform/soc/e659c000.usb/gadget
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
2022-05-09 14:42 ` Geert Uytterhoeven
@ 2022-05-09 15:05 ` Alan Stern
2022-05-09 16:23 ` Greg KH
0 siblings, 1 reply; 13+ messages in thread
From: Alan Stern @ 2022-05-09 15:05 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Felipe Balbi, Greg KH, USB mailing list, Linux-Renesas,
Linux Kernel Mailing List, Yoshihiro Shimoda
On Mon, May 09, 2022 at 04:42:01PM +0200, Geert Uytterhoeven wrote:
> Hi Alan,
>
> On Mon, May 9, 2022 at 4:15 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Mon, May 09, 2022 at 09:46:25AM +0200, Geert Uytterhoeven wrote:
> > > > Geert:
> > > >
> > > > Can you test the patch below? It ought to fix the problem (although it
> > >
> > > Thanks!
> > >
> > > root@h3-salvator-xs:~# ls -l /sys/bus/gadget/devices/
> > > total 0
> > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.0 ->
> > > ../../../devices/platform/soc/e659c000.usb/gadget.0
> > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.1 ->
> > > ../../../devices/platform/soc/ee020000.usb/gadget.1
> > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.2 ->
> > > ../../../devices/platform/soc/e6590000.usb/gadget.2
> > >
> > > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > >
> > > LGTM, so
> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Thanks!
> >
> > > > might end up causing other problems down the line...)
> > >
> > > Can you please elaborate? I'm not too familiar with UBS gadgets.
> >
> > I was concerned about the fact that changing the name of a file,
> > directory, or symbolic link in sysfs means changing a user API, and so
> > it might cause some existing programs to fail. That would be a
> > regression.
> >
> > Perhaps the best way to work around the problem is to leave the name set
> > to "gadget" if the ID number is 0, while adding the ID number on to the
> > name if the value is > 0. What do you think?
>
> Oh, you mean the "gadget.N" subdirs, which are the targets of the
> symlinks above? These were indeed named "gadget" before.
>
> Would it be possible to append the ".N" suffixes only to the actual
> symlinks, while keeping the target directory names unchanged?
> E.g. /sys/bus/gadget/devices/gadget.0 ->
> ../../../devices/platform/soc/e659c000.usb/gadget
No, it's not possible. Or at least, not without significant changes to
the driver core. Besides, people expect these names to be the same.
Alan Stern
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
2022-05-09 15:05 ` Alan Stern
@ 2022-05-09 16:23 ` Greg KH
2022-05-09 16:47 ` Alan Stern
0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2022-05-09 16:23 UTC (permalink / raw)
To: Alan Stern
Cc: Geert Uytterhoeven, Felipe Balbi, USB mailing list,
Linux-Renesas, Linux Kernel Mailing List, Yoshihiro Shimoda
On Mon, May 09, 2022 at 11:05:06AM -0400, Alan Stern wrote:
> On Mon, May 09, 2022 at 04:42:01PM +0200, Geert Uytterhoeven wrote:
> > Hi Alan,
> >
> > On Mon, May 9, 2022 at 4:15 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > > On Mon, May 09, 2022 at 09:46:25AM +0200, Geert Uytterhoeven wrote:
> > > > > Geert:
> > > > >
> > > > > Can you test the patch below? It ought to fix the problem (although it
> > > >
> > > > Thanks!
> > > >
> > > > root@h3-salvator-xs:~# ls -l /sys/bus/gadget/devices/
> > > > total 0
> > > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.0 ->
> > > > ../../../devices/platform/soc/e659c000.usb/gadget.0
> > > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.1 ->
> > > > ../../../devices/platform/soc/ee020000.usb/gadget.1
> > > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.2 ->
> > > > ../../../devices/platform/soc/e6590000.usb/gadget.2
> > > >
> > > > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > >
> > > > LGTM, so
> > > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > >
> > > Thanks!
> > >
> > > > > might end up causing other problems down the line...)
> > > >
> > > > Can you please elaborate? I'm not too familiar with UBS gadgets.
> > >
> > > I was concerned about the fact that changing the name of a file,
> > > directory, or symbolic link in sysfs means changing a user API, and so
> > > it might cause some existing programs to fail. That would be a
> > > regression.
> > >
> > > Perhaps the best way to work around the problem is to leave the name set
> > > to "gadget" if the ID number is 0, while adding the ID number on to the
> > > name if the value is > 0. What do you think?
> >
> > Oh, you mean the "gadget.N" subdirs, which are the targets of the
> > symlinks above? These were indeed named "gadget" before.
> >
> > Would it be possible to append the ".N" suffixes only to the actual
> > symlinks, while keeping the target directory names unchanged?
> > E.g. /sys/bus/gadget/devices/gadget.0 ->
> > ../../../devices/platform/soc/e659c000.usb/gadget
>
> No, it's not possible. Or at least, not without significant changes to
> the driver core. Besides, people expect these names to be the same.
It should always be ok to change the names of devices as those are not
going to be persistent / determinisitic. It's the attributes of devices
that are supposed to be used to determine those types of things.
So I think let's start out with the .N suffix for everything for now.
I'll be glad to submit the fixed patch to the Android kernel build
system to see what their testing comes back with to see if they happened
to make any name assumptions as that's the largest user of this
codebase.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
2022-05-09 16:23 ` Greg KH
@ 2022-05-09 16:47 ` Alan Stern
2022-05-10 7:52 ` Greg KH
0 siblings, 1 reply; 13+ messages in thread
From: Alan Stern @ 2022-05-09 16:47 UTC (permalink / raw)
To: Greg KH
Cc: Geert Uytterhoeven, Felipe Balbi, USB mailing list,
Linux-Renesas, Linux Kernel Mailing List, Yoshihiro Shimoda
On Mon, May 09, 2022 at 06:23:31PM +0200, Greg KH wrote:
> On Mon, May 09, 2022 at 11:05:06AM -0400, Alan Stern wrote:
> > On Mon, May 09, 2022 at 04:42:01PM +0200, Geert Uytterhoeven wrote:
> > > Hi Alan,
> > >
> > > On Mon, May 9, 2022 at 4:15 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > > > On Mon, May 09, 2022 at 09:46:25AM +0200, Geert Uytterhoeven wrote:
> > > > > > Geert:
> > > > > >
> > > > > > Can you test the patch below? It ought to fix the problem (although it
> > > > >
> > > > > Thanks!
> > > > >
> > > > > root@h3-salvator-xs:~# ls -l /sys/bus/gadget/devices/
> > > > > total 0
> > > > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.0 ->
> > > > > ../../../devices/platform/soc/e659c000.usb/gadget.0
> > > > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.1 ->
> > > > > ../../../devices/platform/soc/ee020000.usb/gadget.1
> > > > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.2 ->
> > > > > ../../../devices/platform/soc/e6590000.usb/gadget.2
> > > > >
> > > > > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > >
> > > > > LGTM, so
> > > > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > >
> > > > Thanks!
> > > >
> > > > > > might end up causing other problems down the line...)
> > > > >
> > > > > Can you please elaborate? I'm not too familiar with UBS gadgets.
> > > >
> > > > I was concerned about the fact that changing the name of a file,
> > > > directory, or symbolic link in sysfs means changing a user API, and so
> > > > it might cause some existing programs to fail. That would be a
> > > > regression.
> > > >
> > > > Perhaps the best way to work around the problem is to leave the name set
> > > > to "gadget" if the ID number is 0, while adding the ID number on to the
> > > > name if the value is > 0. What do you think?
> > >
> > > Oh, you mean the "gadget.N" subdirs, which are the targets of the
> > > symlinks above? These were indeed named "gadget" before.
> > >
> > > Would it be possible to append the ".N" suffixes only to the actual
> > > symlinks, while keeping the target directory names unchanged?
> > > E.g. /sys/bus/gadget/devices/gadget.0 ->
> > > ../../../devices/platform/soc/e659c000.usb/gadget
> >
> > No, it's not possible. Or at least, not without significant changes to
> > the driver core. Besides, people expect these names to be the same.
>
> It should always be ok to change the names of devices as those are not
> going to be persistent / determinisitic. It's the attributes of devices
> that are supposed to be used to determine those types of things.
>
> So I think let's start out with the .N suffix for everything for now.
> I'll be glad to submit the fixed patch to the Android kernel build
> system to see what their testing comes back with to see if they happened
> to make any name assumptions as that's the largest user of this
> codebase.
Okay. Do you need me to send it as a proper patch before you try it
out?
Alan Stern
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] USB: gadget: Add a new bus for gadgets
2022-05-09 16:47 ` Alan Stern
@ 2022-05-10 7:52 ` Greg KH
0 siblings, 0 replies; 13+ messages in thread
From: Greg KH @ 2022-05-10 7:52 UTC (permalink / raw)
To: Alan Stern
Cc: Geert Uytterhoeven, Felipe Balbi, USB mailing list,
Linux-Renesas, Linux Kernel Mailing List, Yoshihiro Shimoda
On Mon, May 09, 2022 at 12:47:19PM -0400, Alan Stern wrote:
> On Mon, May 09, 2022 at 06:23:31PM +0200, Greg KH wrote:
> > On Mon, May 09, 2022 at 11:05:06AM -0400, Alan Stern wrote:
> > > On Mon, May 09, 2022 at 04:42:01PM +0200, Geert Uytterhoeven wrote:
> > > > Hi Alan,
> > > >
> > > > On Mon, May 9, 2022 at 4:15 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > > > > On Mon, May 09, 2022 at 09:46:25AM +0200, Geert Uytterhoeven wrote:
> > > > > > > Geert:
> > > > > > >
> > > > > > > Can you test the patch below? It ought to fix the problem (although it
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > root@h3-salvator-xs:~# ls -l /sys/bus/gadget/devices/
> > > > > > total 0
> > > > > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.0 ->
> > > > > > ../../../devices/platform/soc/e659c000.usb/gadget.0
> > > > > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.1 ->
> > > > > > ../../../devices/platform/soc/ee020000.usb/gadget.1
> > > > > > lrwxrwxrwx 1 root root 0 Feb 14 2019 gadget.2 ->
> > > > > > ../../../devices/platform/soc/e6590000.usb/gadget.2
> > > > > >
> > > > > > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > > >
> > > > > > LGTM, so
> > > > > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > >
> > > > > Thanks!
> > > > >
> > > > > > > might end up causing other problems down the line...)
> > > > > >
> > > > > > Can you please elaborate? I'm not too familiar with UBS gadgets.
> > > > >
> > > > > I was concerned about the fact that changing the name of a file,
> > > > > directory, or symbolic link in sysfs means changing a user API, and so
> > > > > it might cause some existing programs to fail. That would be a
> > > > > regression.
> > > > >
> > > > > Perhaps the best way to work around the problem is to leave the name set
> > > > > to "gadget" if the ID number is 0, while adding the ID number on to the
> > > > > name if the value is > 0. What do you think?
> > > >
> > > > Oh, you mean the "gadget.N" subdirs, which are the targets of the
> > > > symlinks above? These were indeed named "gadget" before.
> > > >
> > > > Would it be possible to append the ".N" suffixes only to the actual
> > > > symlinks, while keeping the target directory names unchanged?
> > > > E.g. /sys/bus/gadget/devices/gadget.0 ->
> > > > ../../../devices/platform/soc/e659c000.usb/gadget
> > >
> > > No, it's not possible. Or at least, not without significant changes to
> > > the driver core. Besides, people expect these names to be the same.
> >
> > It should always be ok to change the names of devices as those are not
> > going to be persistent / determinisitic. It's the attributes of devices
> > that are supposed to be used to determine those types of things.
> >
> > So I think let's start out with the .N suffix for everything for now.
> > I'll be glad to submit the fixed patch to the Android kernel build
> > system to see what their testing comes back with to see if they happened
> > to make any name assumptions as that's the largest user of this
> > codebase.
>
> Okay. Do you need me to send it as a proper patch before you try it
> out?
Yes please.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-05-10 7:52 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).