jerpelea opened a new pull request, #19663: URL: https://github.com/apache/nuttx/pull/19663
## Summary rp2040_update_buffer_control() / rp23xx_update_buffer_control() re-arm an endpoint buffer by setting the AVAILABLE bit in the buffer-control word, which lives in DPSRAM. When a buffer is re-armed from the completion path (rp2040_usbintr_buffstat / rp23xx_usbintr_buffstat), that runs right after the handler clears the endpoint's bit in BUFF_STATUS, which lives in the USB controller register block — a different peripheral region. The bus fabric may reorder those two stores. If the controller observes the AVAILABLE re-arm before the BUFF_STATUS clear lands, it can transmit the next IN packet and latch its completion in BUFF_STATUS before the clear arrives; the late clear then wipes that just-set completion bit. The lost completion edge stops all further buffer interrupts for the endpoint, so the class driver's write-complete callback never runs and TX wedges permanently. The fix adds a UP_DMB() at the top of the AVAILABLE re-arm so the preceding BUFF_STATUS clear is ordered ahead of it. (Non-SMP builds reduce spin_lock_irqsave to a barrier-free up_irq_save, so nothing else orders these two stores.) This is the hardware-ordering issue tracked in #19472. The recently merged #19470 fixed the cdcncm-layer write-buffer handling; this is the companion controller-level fix it referenced, needed for full TX stability on RP2350 under maximal IN density. Includes: https://github.com/apache/nuttx/pull/19378 https://github.com/apache/nuttx/pull/19450 https://github.com/apache/nuttx/pull/19452 ## Impact RELEASE ## Testing CI -- 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]
