| Message ID | 1616464217-2650-1-git-send-email-wcheng@codeaurora.org |
|---|---|
| State | New |
| Headers | show |
| Series | usb: gadget: Stall OS descriptor request for unsupported functions | expand |
Hi Wesley, On Mon, Mar 22, 2021 at 06:50:17PM -0700, Wesley Cheng wrote: > From: Chandana Kishori Chiluveru <cchiluve@codeaurora.org> > > Hosts which request "OS descriptors" from gadgets do so during > the enumeration phase and before the configuration is set with > SET_CONFIGURATION. Composite driver supports OS descriptor > handling in composite_setup function. This requires to pass > signature field, vendor code, compatibleID and subCompatibleID > from user space. > > For USB compositions that contain functions which don't implement os > descriptors, Windows is sending vendor specific requests for os > descriptors and composite driver handling this request with invalid > data. With this invalid info host resetting the bus and never > selecting the configuration and leading enumeration issue. > > Fix this by bailing out from the OS descriptor setup request > handling if the functions does not have OS descriptors compatibleID. > > Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org> > Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> > --- > drivers/usb/gadget/composite.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c > index 72a9797..473edda6 100644 > --- a/drivers/usb/gadget/composite.c > +++ b/drivers/usb/gadget/composite.c > @@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) > buf[6] = w_index; > /* Number of ext compat interfaces */ > count = count_ext_compat(os_desc_cfg); > + /* > + * Bailout if device does not > + * have ext_compat interfaces. > + */ > + if (count == 0) > + break; > buf[8] = count; > count *= 24; /* 24 B/ext compat desc */ > count += 16; /* header */ Do we still need this fix? IIRC we had this change in our downstream kernel to fix the case when dynamically re-configuring ConfigFS, i.e. changing the composition of functions wherein none of the interfaces support OS Descriptors, so this causes count_ext_compat() to return 0 and results in the issue described in $SUBJECT. But I think this is more of a problem of an improperly configured ConfigFS gadget. If userspace instead removes the config from the gadget's os_desc subdirectory that should cause cdev->os_desc_config to be set to NULL and hence composite_setup() should never enter this handling at all, right? Jack
On 3/22/2021 11:25 PM, Jack Pham wrote: > Hi Wesley, > > On Mon, Mar 22, 2021 at 06:50:17PM -0700, Wesley Cheng wrote: >> From: Chandana Kishori Chiluveru <cchiluve@codeaurora.org> >> >> Hosts which request "OS descriptors" from gadgets do so during >> the enumeration phase and before the configuration is set with >> SET_CONFIGURATION. Composite driver supports OS descriptor >> handling in composite_setup function. This requires to pass >> signature field, vendor code, compatibleID and subCompatibleID >> from user space. >> >> For USB compositions that contain functions which don't implement os >> descriptors, Windows is sending vendor specific requests for os >> descriptors and composite driver handling this request with invalid >> data. With this invalid info host resetting the bus and never >> selecting the configuration and leading enumeration issue. >> >> Fix this by bailing out from the OS descriptor setup request >> handling if the functions does not have OS descriptors compatibleID. >> >> Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org> >> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> >> --- >> drivers/usb/gadget/composite.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c >> index 72a9797..473edda6 100644 >> --- a/drivers/usb/gadget/composite.c >> +++ b/drivers/usb/gadget/composite.c >> @@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) >> buf[6] = w_index; >> /* Number of ext compat interfaces */ >> count = count_ext_compat(os_desc_cfg); >> + /* >> + * Bailout if device does not >> + * have ext_compat interfaces. >> + */ >> + if (count == 0) >> + break; >> buf[8] = count; >> count *= 24; /* 24 B/ext compat desc */ >> count += 16; /* header */ > > Do we still need this fix? IIRC we had this change in our downstream > kernel to fix the case when dynamically re-configuring ConfigFS, i.e. > changing the composition of functions wherein none of the interfaces > support OS Descriptors, so this causes count_ext_compat() to return > 0 and results in the issue described in $SUBJECT. > Hi Jack, You're correct. We can address this as well in the userspace perspective. > But I think this is more of a problem of an improperly configured > ConfigFS gadget. If userspace instead removes the config from the > gadget's os_desc subdirectory that should cause cdev->os_desc_config to > be set to NULL and hence composite_setup() should never enter this > handling at all, right? Sure, I'll go with fixing it in the userspace, since the support to stall the OS desc is already present in the composite driver as you mentioned. Thanks for the input. Thanks Wesley Cheng
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index 72a9797..473edda6 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) buf[6] = w_index; /* Number of ext compat interfaces */ count = count_ext_compat(os_desc_cfg); + /* + * Bailout if device does not + * have ext_compat interfaces. + */ + if (count == 0) + break; buf[8] = count; count *= 24; /* 24 B/ext compat desc */ count += 16; /* header */