arch/arm/rp2040: fix IN endpoint DPSRAM index for bare-eplog callers rp2040_allocep() indexes the endpoint's DPSRAM buffer/control registers via RP2040_DPINDEX(eplog) and RP2040_EPINDEX(eplog), both of which take the transfer direction from the direction bit of 'eplog' itself instead of trusting the explicit 'in' argument that is also passed to this function. This is harmless for callers that always encode the direction bit into 'eplog' (e.g. CDC/ACM's CDCACM_MKEPBULKIN()/MKEPINTIN(), which OR in USB_DIR_IN), since 'in' then always agrees with that bit. But drivers/usbdev/usbdev_fs.c (the generic ADB/fastboot class driver) calls DEV_ALLOCEP() with a bare endpoint number in 'eplog' (no direction bit) and passes the direction only via the separate 'in' parameter - matching this function's own "direction bit ignored" contract for 'eplog' (see its Input Parameters doc, and the pre-existing "Ignore any direction bits in the logical address" comment, both dating back to the original driver in b860e3c4ad3). For such a bare-number IN endpoint, USB_ISEPOUT(eplog) always evaluates true (the IN bit is never set on a plain number), so RP2040_DPINDEX(eplog) silently pointed the endpoint's buffer/control registers at its OUT slot instead of its IN slot. The real IN slot was left unconfigured, so the SIE responded to every IN token on that endpoint with a STALL - confirmed on real hardware via usbmon: 'C Bi:1:050:6 -32 0' (EPIPE) on every attempt, while the paired OUT endpoint (which "accidentally" resolved to the correct slot for the same reason) worked fine. Fix: normalize 'eplog' to agree with the explicit 'in' argument before it is used by RP2040_EPINDEX()/RP2040_DPINDEX(), so both macros keep their original, single-argument form and every use of eplog's direction bit below this point is consistent with 'in'. Existing 0x80-encoded callers (EP0, CDC/ACM) already agree with 'in' and are unaffected by the normalization. Also fix two pre-existing nxstyle violations in this same file (a misaligned comment block under USB_REQ_SYNCHFRAME, and a bare ';' body instead of empty braces on a while loop), both dating back to the original driver in b860e3c4ad3 as well; CI runs nxstyle on the whole file whenever it is touched. Assisted-by: OpenCode:claude-sonnet-5 Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOSs (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).
For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.
First time on NuttX? Read the Getting Started guide! If you don't have a board available, NuttX has its own simulator that you can run on terminal.
You can find the current NuttX documentation on the Documentation Page.
Alternatively, you can build the documentation yourself by following the Documentation Build Instructions.
The old NuttX documentation is still available in the Apache wiki.
NuttX supports a wide variety of platforms. See the full list on the Supported Platforms page.
If you wish to contribute to the NuttX project, read the Contributing guidelines for information on Git usage, coding standard, workflow and the NuttX principles.
The code in this repository is under either the Apache 2 license, or a license compatible with the Apache 2 license. See the License Page for more information.