usb: gadget: Stall OS descriptor request for unsupported functions
PATCH 1/1 usb: gadget: Stall OS descriptor request for unsupported functions
From: Chandana Kishori Chiluveru <[email protected]>
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.
--- drivers/usb/gadget/composite.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/usb/gadget/composite.c +6 -0
@@ -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 */
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Hi Wesley,
Quoted 31 lines · Wesley Cheng
From: Chandana Kishori Chiluveru <[email protected]>
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 incomposite_setupfunction. 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 <[email protected]>Signed-off-by Wesley Cheng <[email protected]>--- drivers/usb/gadget/composite.c | 6 ++++++ 1 file changed, 6 insertions(+)drivers/usb/gadget/composite.c +0
-0@@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) buf[6 ] = w_index;/* Number of ext compat interfaces */
drivers/usb/gadget/composite.c composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) · line 1956
Quoted 10 lines
drivers/usb/gadget/composite.c +6
-0count =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
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Quoted 42 lines · Jack Pham
Hi Wesley,
Quoted 39 lines · Wesley Cheng
From: Chandana Kishori Chiluveru <[email protected]>
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 incomposite_setupfunction. 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 <[email protected]>Signed-off-by Wesley Cheng <[email protected]>--- drivers/usb/gadget/composite.c | 6 ++++++ 1 file changed, 6 insertions(+)drivers/usb/gadget/composite.c +6
-0@@ -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;
Quoted 9 lines
drivers/usb/gadget/composite.c composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) · line 1956
Quoted 2 lines
drivers/usb/gadget/composite.c +0
-0count *=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.
Quoted 5 lines
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_descsubdirectory that should causecdev->os_desc_configto be set to NULL and hencecomposite_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
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project