All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elvira Khabirova <lineprinter0@gmail.com>
To: Bin Liu <b-liu@ti.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Hubert Wiśniewski" <hubert.wisniewski.25632@gmail.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Elvira Khabirova" <lineprinter0@gmail.com>
Subject: [PATCH v4 0/2] usb: musb: gadget: don't flush a waiting RX packet
Date: Sat,  7 Nov 2026 23:19:02 +0100	[thread overview]
Message-ID: <20261107221904.82487-1-lineprinter0@gmail.com> (raw)

Since commit 3fc137386c46 ("usb: musb: Fix hardware lockup on first Rx
endpoint request"), musb_ep_restart() flushes the RX FIFO instead of
calling rxstate().

When using some functions with musb, for example, f_mass_storage
or f_acm, this code path will be used mid-communication, and it will
cause data loss.

Patch 2 fixes this in musb_ep_restart() and schedules a bh work item
instead of flushing and losing the data in the RX FIFO.

Patch 1 modifies the semantics of musb_ep.busy from a flag to a counter.
If usb_ep_dequeue() runs at the same time as another musb_g_giveback(),
`busy` could end up with a false 1; this would stall an endpoint.
I added this patch in the series as prep for patch 2, because patch 2
would otherwise add one more case where such a race is possible --
a musb_g_giveback() of a work item with a musb_g_giveback() of nuke().

v3 -> v4:
- Move musb_gadget_enable_rx_kicks() in musb_resume() to be
  after musb_enable_interrupts() and under musb->lock (addresses
  sashiko's "premature and unlocked rx_kick queueing in musb_resume()")

v2 -> v3:
- Added patch 1: `busy` is a counter now (addresses sashiko's
  "overlapping musb_g_giveback() calls wedge ep->busy" and
  the nuke() part of "race and ordering bug in musb_gadget_disable()
  for rx_kick")
- Schedule a kick on every OUT ep when resuming to avoid stalls when
  the USB session is preserved across suspend/resume
  (addresses sashiko's "lost rx_kick across system suspend and resume")

v1 -> v2:
- musb_g_rx_kick() does not re-queue itself when `busy` is set.
  Instead, musb_g_giveback() re-queues it when `rx_kick_deferred`.
  This new flag is set in three cases:
  1) `busy` is set inside musb_g_rx_kick()
  2) musb_gadget_queue() adds an RX request to an empty request queue
     and `busy` is set
  3) `busy` is set in the beginning of musb_g_rx() (addresses sashiko's
     "RX endpoint lockup after giveback in musb_g_rx_kick()",
     "softirq busy-loop and livelock in musb_g_rx_kick()", and
     "race and ordering bug in musb_gadget_disable() for rx_kick")
- musb_g_rx_kick checks musb->is_runtime_suspended now and exits early
  if the controller is suspended, and the work items are disabled
  during system suspend (addresses sashiko's
  "unushed rx_kick work in musb_suspend() accesses disabled MMIO")
- This time tested also on a Pine A64+ (Allwinner A64),
  which has both MUSB and 4 cores.

v3: https://lore.kernel.org/linux-usb/20261107173601.63095-1-lineprinter0@gmail.com/
v2: https://lore.kernel.org/linux-usb/20261107105505.6554-1-lineprinter0@gmail.com/
v1: https://lore.kernel.org/linux-usb/20261027202744.79556-1-lineprinter0@gmail.com/

Elvira Khabirova (2):
  usb: musb: gadget: count givebacks in busy
  usb: musb: gadget: don't flush a waiting RX packet when queueing a
    request

 drivers/usb/musb/musb_core.c   |   3 +
 drivers/usb/musb/musb_gadget.c | 128 ++++++++++++++++++++++++++++++---
 drivers/usb/musb/musb_gadget.h |  11 ++-
 3 files changed, 133 insertions(+), 9 deletions(-)


base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8
-- 
2.53.0


             reply	other threads:[~2026-11-07 22:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-07 22:19 Elvira Khabirova [this message]
2026-11-07 22:19 ` [PATCH v4 1/2] usb: musb: gadget: count givebacks in busy Elvira Khabirova
2026-11-07 22:35   ` sashiko-bot
2026-11-07 23:08     ` Elvira Khabirova
2026-11-07 22:19 ` [PATCH v4 2/2] usb: musb: gadget: don't flush a waiting RX packet when queueing a request Elvira Khabirova
2026-11-07 22:37   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261107221904.82487-1-lineprinter0@gmail.com \
    --to=lineprinter0@gmail.com \
    --cc=b-liu@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hubert.wisniewski.25632@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.