All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mario Behn" <mario.behn@gmail.com>
Cc: linux-usb@vger.kernel.org, linux-rt-devel@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: chipidea: udc: give up when the endpoint halt bit is not taken
Date: Mon, 09 Nov 2026 20:01:06 +0000	[thread overview]
Message-ID: <sashiko-outbox-205522@kernel.org> (raw)
In-Reply-To: <20261105205343.982465-1-mario.behn@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] usb: chipidea: udc: missing Fixes trailer for hw_ep_set_halt()
  hang fix
--

commit a303d4e574823163c056eaedbfb37d82c4fbaacb
Author: Mario Behn <mario.behn@gmail.com>

> usb: chipidea: udc: give up when the endpoint halt bit is not taken
>
> hw_ep_set_halt() writes the stall bit of an endpoint and loops until it
> reads back. On endpoint 0 the controller clears the stall bit itself when
> a SETUP packet arrives, so when one arrives while the driver stalls the
> endpoint the loop never ends. It runs in the UDC interrupt thread with the
> controller lock held, and the SETUP packet it is waiting out can only be
> consumed by that same thread.
>
> Seen on a Zynq-7000 (an ADALM-PLUTO class board, PREEMPT_RT) during the
> host RNDIS initialisation: the gadget stalls the GET_ENCAPSULATED_RESPONSE
> poll that has no answer yet, the stall is refused, the interrupt thread
> spins for a minute, RCU stalls and every other USB operation blocks on the
> lock. With a bounded loop the condition shows on 1 to 3 percent of boots
> and is harmless: the pending SETUP packet is handled next and the host
> repeats its poll.
>
> Retry for about a millisecond, then warn with the endpoint control and
> setup status registers and return -EBUSY. The callers already report a
> failed stall.
>
> A loop timeout for the same hang was proposed in 2021 (usb: chipidea: add
> loop timeout for hw_ep_set_halt(), Jeaho Hwang) and not applied.
>
> Signed-off-by: Mario Behn <mario.behn@gmail.com>

[Severity: Low]
This fixes the unbounded polling loop in hw_ep_set_halt() introduced with the
initial driver.  Should this include:

  Fixes: aa69a8093ff9 ("USB: gadget: MIPS ci13xxx_udc")

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105205343.982465-1-mario.behn@gmail.com?part=1

      reply	other threads:[~2026-11-09 20:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 20:53 [PATCH] usb: chipidea: udc: give up when the endpoint halt bit is not taken Mario Behn
2026-11-09 20:01 ` sashiko-bot [this message]

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=sashiko-outbox-205522@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=linux-usb@vger.kernel.org \
    --cc=mario.behn@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.