Yifan-Liu1 commented on code in PR #21443:
URL: https://github.com/apache/nuttx/pull/21443#discussion_r4477238898
##########
drivers/usbhost/usbhost_composite.c:
##########
@@ -312,23 +300,59 @@ static int usbhost_copyinterface(uint8_t ifno, FAR const
uint8_t *configdesc,
return -EINVAL;
}
- /* Is this an interface descriptor? */
+ if (desc->type != USB_DESC_TYPE_INTERFACE)
+ {
+ offset += len;
+ continue;
+ }
+
+ ifdesc = (FAR struct usb_ifdesc_s *)&configdesc[offset];
+ if (ifdesc->ifno != ifno)
Review Comment:
Good catch, thanks. You are right - copying every alternate setting moves
the zero-endpoint alt 0 of the data interface into the synthesized descriptor,
and both drivers took the data interface only once, so the bulk endpoints of
alt 1 were dropped.
Fixed in ee2018c, following your suggestion:
if ((found & USBHOST_DATAIF_FOUND) == 0 || ifdesc->ifno == priv->dataif)
so `currif` is set again on the alt 1 descriptor and its endpoints are
collected. The commit message of the composite change now explains why the two
class drivers have to move with it.
My testing only covered the camera, so this would have gone unnoticed
without your report - much appreciated. The CDC/ACM and FT232R data paths could
not be exercised on real hardware here; the change only widens the interface
match, and a device whose first matching descriptor already carries the
endpoints behaves as before. Please take another look when you get a chance.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
