Implemented a bugfix for control transfer requests parsing (#218)

* No longer using request_value to get request type.

* Removal of shift.

* Fix GET/SET_DESCRIPTOR routing for class-defined descriptor types

When a host sends GET_DESCRIPTOR or SET_DESCRIPTOR with bmRequestType
set to STANDARD but requests a class-defined descriptor type (e.g. HID
Report 0x22 or Physical 0x23), the request must be routed to the class
layer rather than handled as a standard USB request.

Per USB HID 1.11 section 7.1.1, HID stacks legitimately issue
GET_DESCRIPTOR with bmRequestType=STANDARD | INTERFACE | IN for class
descriptors.  The previous fix (checking request_type != STANDARD) broke
this path: (0x81 & 0x60) == 0x00 was seen as standard and the request
would be stalled.

The new condition explicitly checks:
  1. request is GET_DESCRIPTOR or SET_DESCRIPTOR
  2. bmRequestType type field is STANDARD
  3. bDescriptorType (high byte of wValue) is in the USB-IF class-reserved
     range 0x21..0x2F

Requests with bmRequestType already set to CLASS or VENDOR, and standard
descriptors (bDescriptorType < 0x21, e.g. BOS 0x0F) or vendor descriptors
(>= 0x40), are left unchanged and follow their normal dispatch path.

Also fix (UINT) to (ULONG) cast, matching the declared type of request_type.

Suggested-by: ABOUSTM <https://github.com/ABOUSTM>

---------

Co-authored-by: Frédéric Desbiens <[email protected]>
Co-authored-by: Copilot <[email protected]>

0 files changed, 0 insertions, 0 deletions