From: Pavel Machek <pavel@nabladev.com>
To: Claudiu Beznea <claudiu.beznea@kernel.org>
Cc: yoshihiro.shimoda.uh@renesas.com, vkoul@kernel.org,
neil.armstrong@linaro.org, geert+renesas@glider.be,
magnus.damm@gmail.com, prabhakar.mahadev-lad.rj@bp.renesas.com,
linux-renesas-soc@vger.kernel.org, linux-phy@lists.infradead.org,
linux-kernel@vger.kernel.org,
Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>,
stable@vger.kernel.org, Pavel Machek <pavel@nabladev.com>,
Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Subject: Re: [PATCH] phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context
Date: Thu, 14 May 2026 23:18:44 +0200 [thread overview]
Message-ID: <agY8NAyCcHkhBvBv@duo.ucw.cz> (raw)
In-Reply-To: <20260514111300.2152386-1-claudiu.beznea@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2597 bytes --]
Hi!
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The OTG PHY initialization sequence needs to wait for 20 ms at a specific
> step, as described in commit 72c0339c115b ("phy: renesas:
> rcar-gen3-usb2: follow the hardware manual procedure").
>
> Commit 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware
> registers and driver data") tried to address various problems in the
> rcar-gen3-usb2 driver and converted the mutex protecting HW register
> accesses to a spin lock, leaving, however, a long delay in the critical
> section protected by the spin lock. This may become a problem,
> especially on RT kernels.
>
> To address this, release the spin lock before sleeping for 20 ms as
> required by the HW manual and reacquire it afterwards. To avoid other
> threads entering the critical section and configuring the HW while the
> software is waiting for the OTG initialization to complete, introduce the
> otg_initializing variable alongside the otg_init_done completion. Any
> other thread trying to configure the HW while the OTG PHY initialization
> is in progress waits for the completion instead of immediately returning
> errors to PHY users. The IRQs were also disabled while waiting for the OTG
> PHY initialization to complete, as the interrupt handler may also apply HW
> settings.
Just... there has to be a better way.
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +static int rcar_gen3_phy_wait_otg_init(struct rcar_gen3_chan *channel,
> + unsigned long *flags)
> +{
> + unsigned long timeout = msecs_to_jiffies(25);
> + unsigned long ret = 1;
> +
> + lockdep_assert_held(&channel->lock);
> +
> + /*
> + * The OTG can be initialized only once and needs to release the lock
> + * and wait for 20 ms due to hardware constraints. Wait for the OTG PHY
> + * initialization to complete if another PHY executes configuration
> + * code while the OTG PHY is waiting. This avoids returning failures to
> + * PHY users.
> + */
> + if (READ_ONCE(channel->otg_initializing)) {
> + spin_unlock_irqrestore(&channel->lock, *flags);
This is not nice, passing flags between functions like this is a red flag.
You are only accessing otg_initializing under the spinlock. That means
that READ_ONCE is reduntant.
But AFAICT spinlock is only held over this function to protect
channel->otg_initializing access. I suspect correct answer here is
getting rid of spinlock over this function, and using
test_bit(BIT_INITIALIZING, ...) or something similar.
Best regards,
Pavel
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-05-14 21:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 11:13 [PATCH] phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context Claudiu Beznea
2026-05-14 18:52 ` sashiko-bot
2026-05-14 21:18 ` Pavel Machek [this message]
2026-05-15 9:47 ` David Laight
2026-05-15 14:37 ` Claudiu Beznea
2026-05-15 14:14 ` Claudiu Beznea
2026-05-15 15:01 ` sashiko review: " Claudiu Beznea
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=agY8NAyCcHkhBvBv@duo.ucw.cz \
--to=pavel@nabladev.com \
--cc=claudiu.beznea.uj@bp.renesas.com \
--cc=claudiu.beznea@kernel.org \
--cc=geert+renesas@glider.be \
--cc=iwamatsu@nigauri.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=neil.armstrong@linaro.org \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=stable@vger.kernel.org \
--cc=vkoul@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox