Hi Dan,
Before I go through your questions point by point, I want to flag something that affects the confidence of the whole patch.
My rationale for hardcoding fixed sizes per request type (GetHubDescriptor/GetHubStatus/GetPortStatus) was based on reasoning from rh_call_control() alone, without checking how the actual Project Ara module-side firmware behaves. I went and found the firmware at github.com/projectara/, and the relevant file at github.com/projectara/nuttx/blob/master/nuttx/drivers/greybus/usb.c, gb_usb_hub_control(). It doesn't support the assumption I was making. The module allocates its own response buffer purely from wLength and passes wLength straight through to the hardware call:
response = gb_operation_alloc_response(operation, sizeof(*response) + wLength); ... status = device_usb_hcd_hub_control(usbdev, typeReq, wValue, wIndex, (char*) response->buf, wLength);
So it's deferential to wLength on both ends. I don't see evidence here that the module would ever send back more data than wLength implied, which was the scenario I described as the "impact" of the original FIXME.
Given that, and given this driver has been unreachable at runtime for 11 years per commit a96493560cd1, I'd rather get your read on whether this is worth pursuing further before I go answer the rest of your review and send a v2. Happy to keep digging if you think it's still worthwhile, or fine leaving the FIXME as-is otherwise.
Thanks, Aditya