2022-02-14 10:38:28

by Jing Leng

[permalink] [raw]
Subject: [PATCH] usb: gadget: f_uvc: fix superspeedplus transfer

From: Jing Leng <[email protected]>

UVC driver doesn't set ssp_descriptors in struct usb_function,
If we use ssp UDC (e.g. cdnsp), UVC doesn't work.

Signed-off-by: Jing Leng <[email protected]>
---
drivers/usb/gadget/function/f_uvc.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c
index 71bb5e477dba..8fc9b035481e 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -478,6 +478,7 @@ uvc_copy_descriptors(struct uvc_device *uvc, enum usb_device_speed speed)
void *mem;

switch (speed) {
+ case USB_SPEED_SUPER_PLUS:
case USB_SPEED_SUPER:
uvc_control_desc = uvc->desc.ss_control;
uvc_streaming_cls = uvc->desc.ss_streaming;
@@ -521,7 +522,7 @@ uvc_copy_descriptors(struct uvc_device *uvc, enum usb_device_speed speed)
+ uvc_control_ep.bLength + uvc_control_cs_ep.bLength
+ uvc_streaming_intf_alt0.bLength;

- if (speed == USB_SPEED_SUPER) {
+ if (speed == USB_SPEED_SUPER || speed == USB_SPEED_SUPER_PLUS) {
bytes += uvc_ss_control_comp.bLength;
n_desc = 6;
} else {
@@ -565,7 +566,7 @@ uvc_copy_descriptors(struct uvc_device *uvc, enum usb_device_speed speed)
uvc_control_header->baInterfaceNr[0] = uvc->streaming_intf;

UVC_COPY_DESCRIPTOR(mem, dst, &uvc_control_ep);
- if (speed == USB_SPEED_SUPER)
+ if (speed == USB_SPEED_SUPER || speed == USB_SPEED_SUPER_PLUS)
UVC_COPY_DESCRIPTOR(mem, dst, &uvc_ss_control_comp);

UVC_COPY_DESCRIPTOR(mem, dst, &uvc_control_cs_ep);
@@ -727,6 +728,15 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f)
}
}

+ if (gadget_is_superspeed_plus(c->cdev->gadget)) {
+ f->ssp_descriptors = uvc_copy_descriptors(uvc, USB_SPEED_SUPER_PLUS);
+ if (IS_ERR(f->ssp_descriptors)) {
+ ret = PTR_ERR(f->ssp_descriptors);
+ f->ssp_descriptors = NULL;
+ goto error;
+ }
+ }
+
/* Preallocate control endpoint request. */
uvc->control_req = usb_ep_alloc_request(cdev->gadget->ep0, GFP_KERNEL);
uvc->control_buf = kmalloc(UVC_MAX_REQUEST_SIZE, GFP_KERNEL);
--
2.17.1


2022-02-14 11:46:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH] usb: gadget: f_uvc: fix superspeedplus transfer

On Mon, Feb 14, 2022 at 01:52:24PM +0800, [email protected] wrote:
> From: Jing Leng <[email protected]>
>
> UVC driver doesn't set ssp_descriptors in struct usb_function,
> If we use ssp UDC (e.g. cdnsp), UVC doesn't work.

I do not understand this text, sorry. Please try to reword it to have
more descriptions.

thanks,

greg k-h

2022-02-15 03:38:46

by Jing Leng

[permalink] [raw]
Subject: [PATCH v2] usb: gadget: f_uvc: fix superspeedplus transfer

From: Jing Leng <[email protected]>

UVC driver doesn't set ssp_descriptors in struct usb_function,
If UVC uses superspeedplus UDC (e.g. cdnsp), when
config_ep_by_speed_and_alt is called, the g->speed is
USB_SPEED_SUPER_PLUS, and f->ssp_descriptors is NULL,
So kernel will access NULL pointer of speed_desc.

Call trace:
config_ep_by_speed_and_alt+0x3c/0x2a0 [libcomposite]
uvc_function_set_alt+0xd4/0x2e8 [usb_f_uvc]
set_config.constprop.0+0x154/0x3a0 [libcomposite]
composite_setup+0x314/0xb44 [libcomposite]
configfs_composite_setup+0x84/0xb0 [libcomposite]
cdnsp_ep0_std_request+0x25c/0x470 [cdns3]
cdnsp_setup_analyze+0x94/0x25c [cdns3]
cdnsp_handle_event+0xe8/0x23c [cdns3]
cdnsp_thread_irq_handler+0x58/0xe8 [cdns3]
irq_thread_fn+0x2c/0xa0
irq_thread+0x164/0x280
kthread+0x128/0x134
ret_from_fork+0x10/0x40

Signed-off-by: Jing Leng <[email protected]>
---
drivers/usb/gadget/function/f_uvc.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c
index 71bb5e477dba..8fc9b035481e 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -478,6 +478,7 @@ uvc_copy_descriptors(struct uvc_device *uvc, enum usb_device_speed speed)
void *mem;

switch (speed) {
+ case USB_SPEED_SUPER_PLUS:
case USB_SPEED_SUPER:
uvc_control_desc = uvc->desc.ss_control;
uvc_streaming_cls = uvc->desc.ss_streaming;
@@ -521,7 +522,7 @@ uvc_copy_descriptors(struct uvc_device *uvc, enum usb_device_speed speed)
+ uvc_control_ep.bLength + uvc_control_cs_ep.bLength
+ uvc_streaming_intf_alt0.bLength;

- if (speed == USB_SPEED_SUPER) {
+ if (speed == USB_SPEED_SUPER || speed == USB_SPEED_SUPER_PLUS) {
bytes += uvc_ss_control_comp.bLength;
n_desc = 6;
} else {
@@ -565,7 +566,7 @@ uvc_copy_descriptors(struct uvc_device *uvc, enum usb_device_speed speed)
uvc_control_header->baInterfaceNr[0] = uvc->streaming_intf;

UVC_COPY_DESCRIPTOR(mem, dst, &uvc_control_ep);
- if (speed == USB_SPEED_SUPER)
+ if (speed == USB_SPEED_SUPER || speed == USB_SPEED_SUPER_PLUS)
UVC_COPY_DESCRIPTOR(mem, dst, &uvc_ss_control_comp);

UVC_COPY_DESCRIPTOR(mem, dst, &uvc_control_cs_ep);
@@ -727,6 +728,15 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f)
}
}

+ if (gadget_is_superspeed_plus(c->cdev->gadget)) {
+ f->ssp_descriptors = uvc_copy_descriptors(uvc, USB_SPEED_SUPER_PLUS);
+ if (IS_ERR(f->ssp_descriptors)) {
+ ret = PTR_ERR(f->ssp_descriptors);
+ f->ssp_descriptors = NULL;
+ goto error;
+ }
+ }
+
/* Preallocate control endpoint request. */
uvc->control_req = usb_ep_alloc_request(cdev->gadget->ep0, GFP_KERNEL);
uvc->control_buf = kmalloc(UVC_MAX_REQUEST_SIZE, GFP_KERNEL);
--
2.17.1

2022-02-15 14:43:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v2] usb: gadget: f_uvc: fix superspeedplus transfer

On Tue, Feb 15, 2022 at 10:16:47AM +0800, [email protected] wrote:
> From: Jing Leng <[email protected]>
>
> UVC driver doesn't set ssp_descriptors in struct usb_function,
> If UVC uses superspeedplus UDC (e.g. cdnsp), when
> config_ep_by_speed_and_alt is called, the g->speed is
> USB_SPEED_SUPER_PLUS, and f->ssp_descriptors is NULL,
> So kernel will access NULL pointer of speed_desc.
>
> Call trace:
> config_ep_by_speed_and_alt+0x3c/0x2a0 [libcomposite]
> uvc_function_set_alt+0xd4/0x2e8 [usb_f_uvc]
> set_config.constprop.0+0x154/0x3a0 [libcomposite]
> composite_setup+0x314/0xb44 [libcomposite]
> configfs_composite_setup+0x84/0xb0 [libcomposite]
> cdnsp_ep0_std_request+0x25c/0x470 [cdns3]
> cdnsp_setup_analyze+0x94/0x25c [cdns3]
> cdnsp_handle_event+0xe8/0x23c [cdns3]
> cdnsp_thread_irq_handler+0x58/0xe8 [cdns3]
> irq_thread_fn+0x2c/0xa0
> irq_thread+0x164/0x280
> kthread+0x128/0x134
> ret_from_fork+0x10/0x40

What does "call trace" here mean? Is this an error? Something else?

>
> Signed-off-by: Jing Leng <[email protected]>
> ---
> drivers/usb/gadget/function/f_uvc.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)

You did not read the information that my bot told you to read, for how
to properly version your patches :(

Please go back and do so when you resend all of them.

Also this is not a patch series? Why not?

thanks,

greg k-h

2022-02-16 06:49:28

by Jing Leng

[permalink] [raw]
Subject: Re: [PATCH v2] usb: gadget: f_uvc: fix superspeedplus transfer

Hi Greg KH,

Sorry for the trouble, as a new contributor to kernel.
Although I have readed the document that how to submit patches,
I'm still missing some details.

> What does "call trace" here mean? Is this an error? Something else?
It is "call trace" when the kernel accessed NULL pointer and handed.

> You did not read the information that my bot told you to read, for how
> to properly version your patches :(
>
> Please go back and do so when you resend all of them.
>
> Also this is not a patch series? Why not?

I readed the bot told, but I still missed it.
The new patch only adds more detailed patch description.
So it is not a patch series.

thanks,

Jing Leng

2022-02-16 11:32:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v2] usb: gadget: f_uvc: fix superspeedplus transfer

On Wed, Feb 16, 2022 at 10:34:00AM +0800, 冷静 wrote:
> Hi Greg KH,
>
> Sorry for the trouble, as a new contributor to kernel.

That's fine, maybe get some more experience first before trying to add
new features? Try doing some coding style cleanups in drivers/staging/
or reviewing other people's code submissions first. That way you can
learn how things work easier.

> Although I have readed the document that how to submit patches,
> I'm still missing some details.
>
> > What does "call trace" here mean? Is this an error? Something else?
> It is "call trace" when the kernel accessed NULL pointer and handed.

I do not understand this, sorry.

> > You did not read the information that my bot told you to read, for how
> > to properly version your patches :(
> >
> > Please go back and do so when you resend all of them.
> >
> > Also this is not a patch series? Why not?
>
> I readed the bot told, but I still missed it.
> The new patch only adds more detailed patch description.
> So it is not a patch series.

I asked you to make it a patch series.

thanks,

greg k-h

2022-02-17 15:49:47

by Jing Leng

[permalink] [raw]
Subject: Re: [PATCH v2] usb: gadget: f_uvc: fix superspeedplus transfer

Hi Greg KH,

Sorry for the confusion.

I tested the feature on linux-5.10, it will cause Oops.
The Oops is as follows:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Mem abort info:
ESR = 0x96000005
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000005
CM = 0, WnR = 0
user pgtable: 4k pages, 39-bit VAs, pgdp=00000001b12cf000
[0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: ...
CPU: 0 PID: 619 Comm: irq/95-20200080 Tainted: G O 5.10.61 #2
Hardware name: Ambarella CV5 TIMN Board (DT)
pstate: 20c00085 (nzCv daIf +PAN +UAO -TCO BTYPE=--)
pc : config_ep_by_speed_and_alt+0x3c/0x2a0 [libcomposite]
lr : config_ep_by_speed+0x14/0x20 [libcomposite]
sp : ffffffc011dbbac0
x29: ffffffc011dbbac0 x28: 0000000000000001
x27: ffffff81b3eb1920 x26: 0000000000000000
x25: ffffff81b68085e8 x24: ffffff81b3ee4c00
x23: ffffff81b3d71c40 x22: 0000000000000000
x21: 0000000000000000 x20: ffffff81b68085e8
x19: ffffff81b6808000 x18: ffffffc091dbb737
x17: 0000000000000017 x16: 000000000000000a
x15: 0000000000000006 x14: ffffffc011dbb73f
x13: 0000000000000001 x12: ffffffc0109c97e8
x11: 0000000000000652 x10: 00000000000e5a65
x9 : ffffffc0109c97e8 x8 : 00000000fffff7ff
x7 : 00000000000017fd x6 : 0000000000000001
x5 : ffffff81fb5976a8 x4 : 0000000000000006
x3 : 0000000000000000 x2 : ffffff81b6838718
x1 : 0000000000000000 x0 : ffffff81b6838008
Call trace:
config_ep_by_speed_and_alt+0x3c/0x2a0 [libcomposite]
uvc_function_set_alt+0xd4/0x2e8 [usb_f_uvc]
set_config.constprop.0+0x154/0x3a0 [libcomposite]
composite_setup+0x314/0xb44 [libcomposite]
configfs_composite_setup+0x84/0xb0 [libcomposite]
cdnsp_ep0_std_request+0x25c/0x470 [cdns3]
cdnsp_setup_analyze+0x94/0x25c [cdns3]
cdnsp_handle_event+0xe8/0x23c [cdns3]
cdnsp_thread_irq_handler+0x58/0xe8 [cdns3]
irq_thread_fn+0x2c/0xa0
irq_thread+0x164/0x280
kthread+0x128/0x134
ret_from_fork+0x10/0x40
Code: 71000c9f 54000b60 f9400821 52800006 (f9400024)
---[ end trace 7d3065b8181de7a6 ]---
note: irq/95-20200080[619] exited with preempt_count 2
genirq: exiting task "irq/95-20200080" (619) is an active IRQ thread (irq 95)

But the Oops is fixed in the latest kernel by the following commit:
commit 16d42759207fc3d1bff7cfd330a08a225e470ba0
Author: Qihang Hu <[email protected]>
Date: Wed Nov 10 18:11:29 2021 +0800

usb: gadget: composite: Show warning if function driver's descriptors are incomplete.

There are some problems with my previous understanding,
so the patch is a feature but not a bug, I will modify the
title and description of the patch and resend it.

Thanks
Jing Leng