[BUG] usbmsc: GET MAX LUN / MS-RESET EP0 stall in composite mode — wIndex checked against compile-time USBMSC_INTERFACEID instead of dynamic devinfo.ifnobase

[ricardgb]

Description

On a composite USB device that includes USBMSC (tested: CDC-ACM + CDC-NCM + USBMSC on
RP2350 / Raspberry Pi Pico 2 W), the Mass-Storage class control requests GET MAX LUN and
Bulk-Only Mass Storage Reset are answered with an EP0 STALL instead of the expected
response. macOS retries GET MAX LUN ~6 times over ~4 s and then, critically, reads a
garbage LUN count off the failed control transfer and probes phantom LUNs — after which
the drive never mounts. Linux tolerates the stall (assumes a single LUN) but the stall is
still wrong and observable.

This is not rp23xx/rp2040-specific — it is a generic bug in drivers/usbdev/usbmsc.c
that affects any composite configuration where the USBMSC interface number is not zero.

Root cause

usbmsc_setup() in drivers/usbdev/usbmsc.c validates the target interface of the
class/interface requests by comparing the request's wIndex against the compile-time
constant USBMSC_INTERFACEID:

#define USBMSC_INTERFACEID (CONFIG_USBMSC_IFNOBASE + 0)   /* usbmsc.h, == 0 by default */

But in composite mode the USBMSC interface number is assigned dynamically by the
composite core and stored in priv->devinfo.ifnobase. The configuration descriptor is built
from that dynamic value:

/* usbmsc_desc.c */
dest->ifno = devinfo->ifnobase;   /* interface descriptor advertises the real ifno */

So the host correctly directs GET MAX LUN / MS-RESET / GET&SET-INTERFACE to
wIndex == devinfo.ifnobase (interface 4 in my composite layout), but usbmsc_setup()
checks index != USBMSC_INTERFACEID (4 != 0) → ret = -EDOM → the USB driver stalls EP0.

Four comparisons in usbmsc_setup() are affected (SET_INTERFACE, GET_INTERFACE, MSRESET,
GETMAXLUN); all use USBMSC_INTERFACEID where they should use priv->devinfo.ifnobase.

In the standalone (non-composite) case ifnobase == CONFIG_USBMSC_IFNOBASE, so the two are
equal and the bug is invisible — which is why it has gone unnoticed.

Fix

-                if (index != USBMSC_INTERFACEID)
+                if (index != priv->devinfo.ifnobase)

applied to the MSRESET and GETMAXLUN handlers (and the matching == test in the
GET/SET_INTERFACE handlers). Full diff below.

Reproduction and validation (RP2350, Raspberry Pi Pico 2 W, silicon; Linux host, usbmon)

Composite layout places USBMSC at interface 4. Forcing a fresh SCSI probe on Linux
(echo 3-4:1.4 > /sys/bus/usb/drivers/usb-storage/unbind, then bind) and capturing usbmon:

Before the fix — GET MAX LUN stalls:

S Ci:3:007:0 s a1 fe 0000 0004 0001 1 <     # GET MAX LUN, bmRequestType a1, wIndex=4
C Ci:3:007:0 -32 0                           # -EPIPE / EP0 STALL, 0 bytes

After the fix — GET MAX LUN succeeds:

S Ci:3:010:0 s a1 fe 0000 0004 0001 1 <
C Ci:3:010:0 0 1 = 00                         # 1 byte returned, value 0x00 = 1 LUN

No regression: the FAT drive still mounts/reads, CDC-NCM and CDC-ACM are unaffected, and
cold re-enumeration is clean.

macOS impact (the motivating symptom)

On macOS the composite's network + serial come up but no disk device is ever created.
The kernel log shows GET MAX LUN stalling (endpoint 0x00: status 0xe0005000 (pipe stalled))
6×, then Max LUNs reported as 28 with 0xe0005000 — macOS reads a junk LUN count from the
stalled transfer — after which a bulk-IN babble error on 0x87 right after READ CAPACITY
sends IOUSBMassStorageDriver into a reset/retry loop that gives up. The babble does not
reproduce on Linux (Linux never mis-reads the LUN count). The working hypothesis is that the
babble is downstream of the phantom-LUN probing caused by the GET MAX LUN stall; a Mac
re-test of the fixed image is in progress. Either way the GET MAX LUN stall is a real,
independently-confirmed bug and the correct first fix.

Related

Same driver family and hardware as #19434 (rp2040/rp23xx cold-plug pull-up loss). This one
is in the generic drivers/usbdev/usbmsc.c layer rather than the arch USB driver.

Environment

• NuttX board branch tracking recent master; drivers/usbdev/usbmsc.c, usbmsc_desc.c,
  usbmsc.h.
• RP2350, Raspberry Pi Pico 2 W, composite CDC-ACM + CDC-NCM + USBMSC (USBMSC at interface 4).
• Hosts: Linux (usbmon/sg_raw, reproduced + fix-validated), macOS (motivating symptom).

Disclosure

This investigation, root-cause analysis, and the tested fix were performed by an AI agent
(Claude Code), operated and directed by the submitter, and the results were reviewed by the
submitter before posting. Happy to provide the full usbmon captures, the macOS kernel-log
excerpts, or test any proposed alternative fix on hardware.

[ricardgb]

Patch (diff)

diff --git a/drivers/usbdev/usbmsc.c b/drivers/usbdev/usbmsc.c
index bfac6ff03f..bae9bc2f99 100644
--- a/drivers/usbdev/usbmsc.c
+++ b/drivers/usbdev/usbmsc.c
@@ -741,7 +741,7 @@ static int usbmsc_setup(FAR struct usbdevclass_driver_s *driver,
             if (ctrl->type == USB_REQ_RECIPIENT_INTERFACE)
               {
                 if (priv->config == USBMSC_CONFIGID &&
-                    index == USBMSC_INTERFACEID &&
+                    index == priv->devinfo.ifnobase &&
                     value == USBMSC_ALTINTERFACEID)
                   {
                     /* Signal to instantiate the interface change */
@@ -764,7 +764,7 @@ static int usbmsc_setup(FAR struct usbdevclass_driver_s *driver,
             if (ctrl->type == (USB_DIR_IN | USB_REQ_RECIPIENT_INTERFACE) &&
                 priv->config == USBMSC_CONFIGIDNONE)
               {
-                if (index != USBMSC_INTERFACEID)
+                if (index != priv->devinfo.ifnobase)
                   {
                     ret = -EDOM;
                   }
@@ -805,7 +805,7 @@ static int usbmsc_setup(FAR struct usbdevclass_driver_s *driver,
               {
                 /* Only one interface is supported */
 
-                if (index != USBMSC_INTERFACEID)
+                if (index != priv->devinfo.ifnobase)
                   {
                     usbtrace(TRACE_CLSERROR(USBMSC_TRACEERR_MSRESETNDX),
                              index);
@@ -836,7 +836,7 @@ static int usbmsc_setup(FAR struct usbdevclass_driver_s *driver,
               {
                 /* Only one interface is supported */
 
-                if (index != USBMSC_INTERFACEID)
+                if (index != priv->devinfo.ifnobase)
                   {
                     usbtrace(TRACE_CLSERROR(USBMSC_TRACEERR_GETMAXLUNNDX),
                              index);

[ricardgb]

This investigation is still ongoing. There are still issues when identifying scsi drives on osx and windows.

[ricardgb]

Update: fix confirmed on macOS + two more composite-USBMSC bugs found beneath it

The devinfo.ifnobase fix above is confirmed working on macOS — the stalled GET MAX
LUN (and the "Max LUNs reported as 28" garbage read) is gone from the kernel log.

However, the disk still does not mount on macOS, and peeling that onion exposed two more
generic composite-mode bugs in drivers/usbdev/usbmsc* (plus an arch crash under
investigation). Posting them here since they are all in the same probe path and were masked
by this issue's bug; happy to split into separate issues if preferred.

Bug 2: usbmsc_deferredresponse() is a compile-time no-op in composite mode

The entire body of usbmsc_deferredresponse() (drivers/usbdev/usbmsc.c) is wrapped in
#ifndef CONFIG_USBMSC_COMPOSITE. The deferred EP0 status-stage responses for
Bulk-Only Mass Storage Reset and SET_INTERFACE are made through this function by the
SCSI worker thread — so in composite mode the MSRESET status stage is never sent and
the host's BOT reset recovery times out. macOS log:

endpoint 0x87: status 0xe0005000 (pipe stalled)
endpoint 0x00: status 0xe00002d6 (timeout)        <- MSRESET never answered
USB device ... BOT reset completed with kIOReturnTimeout
IOUSBMassStorageDriver: ... usb reset ...          <- full device reset, probe loop, gives up

(Before the ifnobase fix this path was unreachable — MSRESET was stalled by the
wrong-interface check — which is presumably why it was never seen.)

Fix: compile the body in composite mode as well. EP_SUBMIT(dev->ep0, ctrlreq) is correct
there for these class requests (equivalent to composite_ep0submit() for anything but
SETCONFIGURATION), and additionally the worker must NOT send the deferred response for
USBMSC_EVENT_CFGCHANGE in composite mode — the composite driver already answers
SETCONFIGURATION itself (that is exactly what the composite_ep0submit() filter exists
for), and a duplicate ZLP would corrupt EP0.

Bug 3: gratuitous bulk-IN STALL when the host allocation exceeds the response (Hi > Di)

For any Data-In command whose response is shorter than the host's requested transfer
length, usbmsc_cmdfinishstate() (drivers/usbdev/usbmsc_scsi.c) submits the short
response and then also stalls the bulk-IN endpoint because residue > 0. The stall is
permitted by BOT 6.7.2, but it is unnecessary — the short packet has already terminated
the host's data phase — and it is harmful in practice: macOS answers any bulk-IN halt
during device probing with the full BOT-reset sequence (which then ran into bug 2 above).
Linux is only unaffected because its SCSI probe happens not to issue Hi > Di transfers;
it can be reproduced on Linux trivially:

$ sudo sg_raw -r 192 /dev/sg0 1a 00 3f 00 c0 00     # MODE SENSE(6), alloc 0xC0
# usbmon: 16-byte short data-in, then CSW read STALLed (-EPIPE),
#         clear-halt, CSW retry succeeds with dCSWDataResidue=0xB0

CONFIG_USBMSC_NOT_STALL_BULKEP exists as a config-level workaround for exactly this
area (it suppresses the stall but also fakes the MODE SENSE length and zeroes the
residue, i.e. it lies in the CSW).

Fix: in usbmsc_cmdfinishstate(), only stall when the data phase was not terminated —
i.e. when no response data was submitted at all (the request is submitted with
USBDEV_REQFLAGS_NULLPKT, so a submitted response always ends in a short packet or ZLP).
When the short response was sent, proceed directly to the CSW and report the residue in
dCSWDataResidue, which is the BOT-correct behavior. NOT_STALL_BULKEP then becomes
unnecessary for correctness.

Under investigation: the BOT reset crashes the firmware (RP2350)

With the two bugs above still in place, SWD inspection of the wedged device (Pico 2 W,
plugged into the macOS host, after the probe loop gave up) found core 0 in ARM lockup
(pc=0xEFFFFFFE, CFSR=0x00080001 = instruction-access violation escalated to HardFault,
HFSR=FORCED), with the last received SETUP packet in DPSRAM being 21 ff 00 00 04 00 00 00
(Bulk-Only Mass Storage Reset). I.e. the repeated MSRESET/reset recovery sequence does not
just time out — it eventually takes a wild jump in the USB interrupt path and kills the
firmware until power-cycle (this is why the macOS log ends with SET_ADDRESS failures and
"disabling port"). Root-cause in progress with a debug probe; will report separately
(likely an rp23xx/rp2040 arch issue or a request-cancellation race, related to this
issue's driver family).

Status

• Fixes for bugs 2 and 3 are implemented and build clean; silicon validation (Linux
  usbmon + macOS mount test) is in progress and I will confirm results here.

Disclosure

As above: this investigation and the fixes were performed by an AI agent (Claude Code),
operated and directed by the submitter, and reviewed by the submitter before posting.

[ricardgb]

Validation results (silicon, RP2350 / Pico 2 W, Linux host)

Both fixes from the previous comment are now implemented and validated on hardware
(composite CDC-ACM + CDC-NCM + USBMSC, USBMSC at interface 4, usbmon captures):

Bug 2 (deferred response no-op) — FIXED, validated: Bulk-Only Mass Storage Reset now
completes with a proper status stage instead of timing out. Before:
MSRESET: errno=110 (ETIMEDOUT) (raw usbfs control transfer). After: MSRESET: OK,
10/10 iterations, GET MAX LUN remains functional after each. Also exercised with MSRESET
arriving while a Data-In command's CSW is pending, plus an immediate USB bus reset after
it (mimicking macOS's recovery), 12 cycles: all clean.

Bug 3 (gratuitous Hi>Di stall) — FIXED, validated: exact macOS trigger
(sg_raw -r 192 ... 1a 00 3f 00 c0 00, MODE SENSE(6) alloc=0xC0):

Before: 16-byte short data, then CSW read STALLed (-EPIPE) → clear-halt → CSW retry.
After (wire trace): 16-byte short data, then the CSW immediately —
55534253 xx000000 b0000000 00 (dCSWDataResidue=0xB0, status good). Zero bulk-IN
stalls, zero clear-halts across the whole suite (MODE SENSE 6/10, INQUIRY alloc 255,
REQUEST SENSE alloc 252, READ CAPACITY exact-8).

No regressions: FAT drive mounts and full-reads, CDC-NCM and CDC-ACM unaffected, warm
reboots re-enumerate cleanly, and the GET MAX LUN fix from this issue still validates.

On the crash mentioned earlier: the ARM lockup (wild jump in the USB IRQ path during
the macOS stall→BOT-reset→device-reset loop) did NOT reproduce from Linux in 24 deliberate
race cycles (stall + MSRESET mid-flight + immediate bus reset) on either the unfixed or
fixed firmware — it appears to need a narrow timing window that macOS's exact sequence
hits. Since fixes 2+3 remove the entire triggering path (no stall → no BOT reset storm),
the practical exposure is gone, but the underlying arch-level fragility remains
un-root-caused; I'm leaving the evidence here (lockup registers, DPSRAM SETUP=MSRESET) in
case it rings a bell for the rp2040/rp23xx driver authors.

macOS mount test of the fixed image is next; will report the result here.

Disclosure

As above: investigation, fixes, and validation performed by an AI agent (Claude Code),
operated and directed by the submitter, reviewed before posting.

[ricardgb]

Bug 5 — the one that still broke macOS after the previous fixes: the rp2040/rp23xx DCD drops requests submitted while an endpoint is halted (the CSW-loss race)

macOS still failed to mount with fixes 1-3 applied. The failing command turned out to be
one the earlier validation never sent: macOS probes MODE SENSE(6) with PAGE CODE 0x00
(write-protect header sniff; the IOUSBMassStorageDriver RwC trace shows CDB 1A 00 00 00,
allocation length 4 and then 0xC0). usbmsc_modepage() only implements pages 0x08/0x3F,
so the command fails — which is fine and spec-legal: for a failed Hi>Di command with no
data, usbmsc_cmdfinishstate() halts the bulk-IN endpoint (BOT 6.7.2) and
usbmsc_cmdstatusstate() then submits the CSW (status = failed).

The bug: rp23xx_epsubmit() / rp2040_epsubmit() reject IN requests submitted while
the endpoint is halted (stalled && in -> abort with -EBUSY). The CSW is therefore
dropped on the floor. When the host clears the halt and reads the CSW, the endpoint NAKs
forever; macOS times out after 30 s and enters a Bulk-Only-reset/device-reset spiral that
ends with the port disabled ("persistent enumeration failures").

This is precisely the race documented for over a decade in the header comment of
drivers/usbdev/usbmsc_scsi.c (David Hewson's analysis): "the subsequent transfer for
the CSW would be dropped on the floor (by the epsubmit() function) if the end point was
still stalled". The USBMSC_STALL_RACEWAR sleep-workaround was active (these chips do not
declare CONFIG_ARCH_USBDEV_STALLQUEUE), but it only survives hosts that clear the halt
within its 100 ms sleep. Linux's usb-storage does; macOS does not — and Linux's SCSI probe
also never sends a failing MODE SENSE page (it uses 0x3F), which is why the earlier
validation passed while macOS kept failing.

Fix (both rp2040_usbdev.c and rp23xx_usbdev.c): implement stall queuing in the DCD

1. epsubmit(): while the endpoint is halted, requests are queued but the hardware is
   not armed (IN and OUT — arming an OUT endpoint rewrites the DPSRAM buffer-control
   word and would silently clear the STALL bit). The -EBUSY abort is removed.
2. epstall(stall): after applying the hardware stall, cancel in-flight IN requests —
   their armed buffer was just disarmed and would never complete.
3. epstall(resume): after clearing the halt (and resetting the data toggle), re-arm
   the head of the request queue — this delivers the queued CSW.
4. Buffer-status IRQ: ignore completions latched for transfers aborted by a halt.
5. arch/arm/Kconfig: RP2040/RP23XX now select ARCH_USBDEV_STALLQUEUE, which also
   retires the RACEWAR's two 100 ms sleeps per failed command.

The class driver is untouched by this fix (its behavior is BOT-correct).

Validation (silicon, RP2350 / Pico 2 W, composite ACM+NCM+MSC, Linux host)

An important subtlety: Linux cannot reproduce this bug via sg_raw/usb-storage, because
usb-storage clears the halt within microseconds — inside the RACEWAR's 100 ms window — so
the CSW submit finds the endpoint already resumed. (sg_raw -r 4 /dev/sgX 1a 00 00 00 04 00 on the broken firmware completes fine in 0.23 s, of which 0.2 s are the two RACEWAR
sleeps.) The repro needs macOS's timing over raw usbfs: CBW MODE SENSE(6) page 0x00
alloc 4 → data-IN stall → wait 1 s (past the RACEWAR window) → clear-halt → read CSW.

A/B on the same board, same script, same 1 s delay:

• Before (bugs 1-3 fixed, no stall queuing): data-IN EPIPE at +0.10 s (RACEWAR sleep
  visible), clear-halt OK, CSW read ETIMEDOUT — the CSW had been aborted with -EBUSY
  at submit time. This is the macOS failure exactly (its log then shows a 30 s bulk-IN
  timeout followed by the BOT-reset/device-reset spiral until the port is disabled).
• After (stall queuing): data-IN EPIPE immediately (RACEWAR retired), clear-halt OK,
  CSW delivered instantly: status=FAIL(1), dCSWDataResidue=4, tag correct.

Full macOS-equivalent probe replay over raw usbfs (TUR, INQUIRY ×2, MODE SENSE page 0
alloc 4 and 0xC0 with clear-halt recovery and CSW signature/tag/status/residue checks,
REQUEST SENSE, READ CAPACITY exact-8, MODE SENSE 0x3F control, START STOP UNIT ×2
variants, MSRESET + clear-halts mid-probe): 5 cycles, zero failures.

Regressions, all clean: page-0 MODE SENSE through usb-storage now returns CHECK
CONDITION / Illegal Request in 0.017 s (previously 0.23 s through the RACEWAR sleeps);
MODE SENSE 0x3F, INQUIRY 255, REQUEST SENSE 252, READ CAPACITY exact-8 all Good;
GET MAX LUN + MSRESET 10/10 via raw usbfs; FAT drive mounts and full-reads; CDC-NCM and
CDC-ACM up; warm reboots re-enumerate cleanly.

macOS mount retest is next; will report the result here.

Remaining loose end (honest)

In the macOS failure log there is also a ~1 s EP0 control-transfer timeout immediately
after the first bulk-IN stall, before the 30 s CSW timeout. Clear-halt is handled directly
in the USB IRQ and should be instant, so this is not fully explained by the CSW loss;
candidates are a SIE disturbance from writing buffer-control while the host is actively
IN-polling the endpoint, or the deferred MSRESET response racing a 1 s host deadline. If
it persists on the macOS retest with this fix it will be investigated separately.

Disclosure

As above: this investigation and the fixes were performed by an AI agent (Claude Code),
operated and directed by the submitter, and reviewed by the submitter before posting.

[ricardgb]

Bug 6 — GET STATUS is never answered by the rp2040/rp23xx DCD (found after the bug-5 fix still didn't satisfy macOS)

Status update on the macOS saga: the stall-queue fix (bug 5, previous comment) is real and
held up, but the macOS retest still failed — and the failure log isolated the remaining
piece, which turned out to be the "1 s EP0 timeout" loose end I flagged.

Symptom

With bug 5 fixed, the macOS probe reaches the (BOT-legal) bulk-IN halt for the failed
MODE SENSE(6) page-0 command. ~50 ms after the halt, macOS's storage stack issues
GetPipeStatus = GET STATUS (recipient: endpoint) on the halted pipe before deciding on
recovery. That control transfer times out after 1 s, macOS resets the device, and the
familiar spiral follows (fConsecutiveResetCount 1→3, SET_ADDRESS failures, port disabled
for "persistent enumeration failures").

Root cause (deterministic, code-level)

In both arch/arm/src/rp2040/rp2040_usbdev.c and arch/arm/src/rp23xx/rp23xx_usbdev.c,
the USB_REQ_GETSTATUS case in *_ep0setup() validates the request but never queues
the two-byte status response — for all three recipients (device, interface, endpoint).
EP0 therefore NAKs the host's data-IN stage forever and every GET STATUS times out. Linux
does not issue GET STATUS in normal enumeration or usb-storage operation, so the bug is
invisible there; any host (or userspace tool, e.g. lsusb -v device-status query) that
sends GET STATUS hangs for its control timeout.

Silicon proof (raw usbfs, RP2350, firmware with bugs 1-3+5 fixed but not this one):

GET_STATUS device:      errno=110(ETIMEDOUT) (1.54s)
GET_STATUS interface 4: errno=110(ETIMEDOUT) (1.54s)
GET_STATUS ep 0x87:     errno=110(ETIMEDOUT) (1.54s)
GET_STATUS ep 0x08:     errno=110(ETIMEDOUT) (1.54s)
GET_STATUS ep0:         errno=110(ETIMEDOUT) (1.54s)

Fix

Build and transmit the 2-byte status in the GETSTATUS handler: endpoint recipient reports
the halt bit from the endpoint state, device recipient reports self-powered, interface
reports zeros; the response is sent with *_epwrite(ep0, response, 2) and the status
stage (host's zero-length OUT) is armed by *_handle_zlp() exactly as for
class-dispatched IN transfers. Applied to both chips.

Validation (same board, fixed firmware)

• All five GET STATUS variants above now answer 2B 0000 in <1 ms; on a halted endpoint
  the response is 0100 (halt bit) and returns to 0000 after CLEAR FEATURE.
• Post-stall delay sweep replicating macOS's recovery order — data-IN stall →
  wait {0, 30, 50, 80, 150, 500, 1000} ms → GET STATUS(ep) (assert halted) → CLEAR
  FEATURE → GET STATUS (assert cleared) → CSW read (assert signature/tag/status/residue):
  all delays pass. (The 50 ms point is macOS's observed timing; the earlier bug-5
  validation used only a 1 s delay, which is why this hole survived it.)
• Full macOS-equivalent BOT probe replay ×5 cycles: zero failures.
• Regressions: failed-command CSW still delivered (bug-5 fix intact), MODE SENSE 0x3F /
  INQUIRY / REQUEST SENSE / READ CAPACITY good, GET MAX LUN + Bulk-Only reset 10/10, FAT
  drive mounts + full-reads, CDC-NCM and CDC-ACM functional, warm reboots re-enumerate.

macOS mount retest of this build is pending and I will report the result. Given that the
macOS failure log's three distinct signatures (LUN garbage, lost CSW, EP0 timeout) are now
each root-caused to a specific driver defect with silicon-validated fixes, this should be
the last layer — but that has been said before in this saga, so: pending confirmation.

For maintainers keeping score, the full stack found behind "macOS never mounts a NuttX
composite MSC" is now: (1) wIndex vs ifnobase in usbmsc_setup (composite-only), (2)
usbmsc_deferredresponse compiled out in composite mode, (3) gratuitous bulk-IN stall on
short-data Hi>Di, (5) IN requests submitted while an endpoint is halted are dropped by the
DCD (CSW loss; ARCH_USBDEV_STALLQUEUE now implemented), (6) GET STATUS never answered by
the DCD. ((4) is the still-open lockup, no longer reachable via this path.)

Disclosure

As above: this investigation and the fixes were performed by an AI agent (Claude Code),
operated and directed by the submitter, and reviewed by the submitter before posting.

[ricardgb]

macOS CONFIRMED: the mass-storage drive now mounts

Retest on the same macOS host (Apple Silicon, AppleT8132 XHCI) with the bug-5 + bug-6
fixes applied: the MSC volume now appears in Finder and mounts normally. The
enumerate → probe → reset-loop → "port disabled" failure is gone. The composite's
CDC-ACM and CDC-NCM functions continue to work alongside.

That closes the macOS side of this issue end-to-end. Final tally of distinct defects
found behind "macOS never mounts a NuttX composite MSC device", each root-caused,
fixed, and validated on RP2350 silicon (fixes mirrored to rp2040 where the code is
shared/ported):

1. usbmsc_setup() compares wIndex against the compile-time interface id instead of
   the composite-assigned devinfo.ifnobase → GET MAX LUN / MS-RESET / GET,SET-INTERFACE
   all EP0-stall in composite mode (macOS read a garbage LUN count off the stall).
2. usbmsc_deferredresponse() is compiled out in composite mode (body inside
   #ifndef CONFIG_USBMSC_COMPOSITE) → Bulk-Only Mass Storage Reset never gets its
   status stage → timeout.
3. Gratuitous bulk-IN stall on Hi>Di residue even though the short packet already
   terminated the data phase → needless BOT reset recovery on macOS.
4. (Open, unreachable via this path now:) ARM lockup observed once during the
   stall/reset storm; pc=0xEFFFFFFE, CFSR=0x00080001. Not reproducible from Linux in
   deliberate race testing; evidence preserved earlier in this thread.
5. rp2040/rp23xx DCD drops IN requests submitted while the endpoint is halted
   (David Hewson's CSW race, documented in usbmsc_scsi.c for over a decade) → the failed
   command's CSW is lost and the host times out waiting for it after Clear-Halt. Fixed by
   implementing stall queuing (ARCH_USBDEV_STALLQUEUE) in the DCD.
6. rp2040/rp23xx DCD never answers GET STATUS (any recipient) → macOS's
   GetPipeStatus on the halted pipe times out ~50 ms after the stall → reset spiral.

Sibling issue #19434 (SIE_CTRL.PULLUP_EN clobbered in usbdev_register → cold-plug
never enumerates) makes it seven distinct defects across
rp2040_usbdev.c / rp23xx_usbdev.c / usbmsc in this investigation arc.

A process note that may help others debugging similar reports: bugs 5 and 6 each
survived a Linux validation round because Linux's SCSI stack neither sends the failing
command (MODE SENSE page 0), nor GET STATUS, and clears halts within 100 µs-100 ms.
What finally worked was replaying the exact macOS command bytes AND timing (raw usbfs,
post-stall delay sweep 0-1000 ms in macOS's recovery order). Happy to share the test
scripts if useful.

I'll leave patches/PR logistics to the maintainers' preference as before — all fixes are
described precisely in this thread and are small.

Disclosure

As above: this investigation and the fixes were performed by an AI agent (Claude Code),
operated and directed by the submitter, and reviewed by the submitter before posting.

[ricardgb]

Follow-up with the captured macOS success log (same host, retest of the previous comment's confirmation):

20:46:24.778 AppleUSB20HubPort@01130000: enumerated 0x0000/0000/1010 (Composite device / 4) at 12 Mbps
20:46:25.903 AppleUSBIORequest::complete: device 4 endpoint 0x87: status 0xe0005000 (pipe stalled): 0 bytes transferred
20:46:25.904 AppleUSBIORequest::complete: device 4 endpoint 0x87: status 0xe0005000 (pipe stalled): 0 bytes transferred
20:46:25.905 AppleUSBIORequest::complete: device 4 endpoint 0x87: status 0xe0005000 (pipe stalled): 0 bytes transferred

Those three bulk-IN stalls are the expected, BOT-legal halts for the failed MODE SENSE
page-0 probes — and this time recovery just works: GET STATUS answered, halt cleared,
failed CSW delivered, probe continues. The entire kernel log for the plug-in is 23 lines:
no EP0 timeouts, no fConsecutiveResetCount, no device resets, no port disable.
(For contrast, the failure logs earlier in this thread ran to hundreds of lines of reset
spirals ending in "persistent enumeration failures".)

/dev/disk4 (external, physical):
   0:                            PROVISION              *32.8 KB    disk4

Drive mounted. Closing the loop on the macOS side of this issue.

Disclosure: as above — investigation and fixes by an AI agent (Claude Code), operated,
directed, and reviewed by the submitter.