On Mon, Feb 14, 2022 at 10:32:23PM +0800, 3090101217@xxxxxxxxxx wrote: > From: Jing Leng <jleng@xxxxxxxxxxxxx> > > On page 362 of the USB3.2 specification ( > https://usb.org/sites/default/files/usb_32_20210125.zip), > The 'SuperSpeed Endpoint Companion Descriptor' shall only be returned > by Enhanced SuperSpeed devices that are operating at Gen X speed. > Each endpoint described in an interface is followed by a 'SuperSpeed > Endpoint Companion Descriptor'. > > If we use SuperSpeed UDC, host can't recognize the device if endpoint > doesn't have 'SuperSpeed Endpoint Companion Descriptor' followed. > > Currently in the uac2 driver code: > 1. ss_epout_desc_comp follows ss_epout_desc; > 2. ss_epin_fback_desc_comp follows ss_epin_fback_desc; > 3. ss_epin_desc_comp follows ss_epin_desc; > 4. Only ss_ep_int_desc endpoint doesn't have 'SuperSpeed Endpoint > Companion Descriptor' followed, so we should add it. > > Signed-off-by: Jing Leng <jleng@xxxxxxxxxxxxx> > --- > drivers/usb/gadget/function/f_uac2.c | 19 +++++++++++++++++-- > 1 file changed, 17 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/function/f_uac2.c b/drivers/usb/gadget/function/f_uac2.c > index 097a709549d6..a6fc492f9148 100644 > --- a/drivers/usb/gadget/function/f_uac2.c > +++ b/drivers/usb/gadget/function/f_uac2.c > @@ -282,6 +282,14 @@ static struct usb_endpoint_descriptor ss_ep_int_desc = { > .bInterval = 4, > }; > > +static struct usb_ss_ep_comp_descriptor ss_ep_int_desc_comp = { > + .bLength = sizeof(ss_ep_int_desc_comp), > + .bDescriptorType = USB_DT_SS_ENDPOINT_COMP, > + .bMaxBurst = 0, > + .bmAttributes = 0, > + .wBytesPerInterval = cpu_to_le16(6), > +}; > + > /* Audio Streaming OUT Interface - Alt0 */ > static struct usb_interface_descriptor std_as_out_if0_desc = { > .bLength = sizeof std_as_out_if0_desc, > @@ -595,7 +603,8 @@ static struct usb_descriptor_header *ss_audio_desc[] = { > (struct usb_descriptor_header *)&in_feature_unit_desc, > (struct usb_descriptor_header *)&io_out_ot_desc, > > - (struct usb_descriptor_header *)&ss_ep_int_desc, > + (struct usb_descriptor_header *)&ss_ep_int_desc, > + (struct usb_descriptor_header *)&ss_ep_int_desc_comp, > > (struct usb_descriptor_header *)&std_as_out_if0_desc, > (struct usb_descriptor_header *)&std_as_out_if1_desc, > @@ -657,6 +666,7 @@ static int set_ep_max_packet_size(const struct f_uac2_opts *uac2_opts, > > case USB_SPEED_HIGH: > case USB_SPEED_SUPER: > + case USB_SPEED_SUPER_PLUS: > max_size_ep = 1024; > factor = 8000; > break; > @@ -723,6 +733,7 @@ static void setup_headers(struct f_uac2_opts *opts, > struct usb_ss_ep_comp_descriptor *epout_desc_comp = NULL; > struct usb_ss_ep_comp_descriptor *epin_desc_comp = NULL; > struct usb_ss_ep_comp_descriptor *epin_fback_desc_comp = NULL; > + struct usb_ss_ep_comp_descriptor *ep_int_desc_comp = NULL; > struct usb_endpoint_descriptor *epout_desc; > struct usb_endpoint_descriptor *epin_desc; > struct usb_endpoint_descriptor *epin_fback_desc; > @@ -750,6 +761,7 @@ static void setup_headers(struct f_uac2_opts *opts, > epin_fback_desc = &ss_epin_fback_desc; > epin_fback_desc_comp = &ss_epin_fback_desc_comp; > ep_int_desc = &ss_ep_int_desc; > + ep_int_desc_comp = &ss_ep_int_desc_comp; > } > > i = 0; > @@ -778,8 +790,11 @@ static void setup_headers(struct f_uac2_opts *opts, > if (EPOUT_EN(opts)) > headers[i++] = USBDHDR(&io_out_ot_desc); > > - if (FUOUT_EN(opts) || FUIN_EN(opts)) > + if (FUOUT_EN(opts) || FUIN_EN(opts)) { > headers[i++] = USBDHDR(ep_int_desc); > + if (ep_int_desc_comp) > + headers[i++] = USBDHDR(ep_int_desc_comp); > + } > > if (EPOUT_EN(opts)) { > headers[i++] = USBDHDR(&std_as_out_if0_desc); > -- > 2.17.1 > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You sent multiple patches, yet no indication of which ones should be applied in which order. Greg could just guess, but if you are receiving this email, he guessed wrong and the patches didn't apply. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for a description of how to do this so that Greg has a chance to apply these correctly. - This looks like a new version of a previously submitted patch, but you did not list below the --- line any changes from the previous version. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what needs to be done here to properly describe this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
