From: Pavel Machek <pavel@nabladev.com>
To: Claudiu Beznea <claudiu.beznea+renesas@tuxon.dev>
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,
claudiu.beznea@tuxon.dev, 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 v5] phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context
Date: Tue, 8 Sep 2026 12:52:41 +0200 [thread overview]
Message-ID: <ap_o-T5GGMFGYZ4v@duo.ucw.cz> (raw)
In-Reply-To: <20260716183246.3183877-1-claudiu.beznea+renesas@tuxon.dev>
[-- Attachment #1.1: Type: text/plain, Size: 2992 bytes --]
Hi!
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> 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 wait
> queue. Any
This is quite complex. How is this solved in mainline?
> To avoid failures when multiple PHYs call struct
> phy_ops::rcar_gen3_phy_usb2_init() simultaneously, and the PHY responsible
> for initializing the OTG either fails or deinit quiqly and another PHY
> takes over the PHY init role), the code waiting for the
> channel->otg_init_done wait queue retries up to NUM_OF_PHYS times.
And more complexity.
Example of the code is quoted below, and we are returning EBUSY to
userspace if it tries to change role at the wrong time. Not great.
As far as I understand, the initialization on needs to be done
once. Instead of exposing /sys interfaces before hardware is ready,
and then doing complex dance when /sys is accessed, could we
initialize hardware in rcar_gen3_phy_usb2_probe or something?
Looking at the code:
/* If current and new mode is the same, this returns the error */
if (cur_mode == new_mode)
return -EINVAL;
this should probably just return success? (EINVAL is certainly wrong
error code here.)
Best regards,
Pavel
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -392,26 +408,58 @@ static ssize_t role_store(struct device *dev, struct device_attribute *attr,
> struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> bool is_b_device;
> enum phy_mode cur_mode, new_mode;
> + int retries = NUM_OF_PHYS;
> + unsigned long flags;
> + int ret = -EIO;
>
> - guard(spinlock_irqsave)(&ch->lock);
> + spin_lock_irqsave(&ch->lock, flags);
>
> - if (!ch->is_otg_channel || !rcar_gen3_is_any_otg_rphy_initialized(ch))
> - return -EIO;
> + if (!ch->is_otg_channel)
> + goto unlock;
> +
> + while (retries-- && ch->otg_initializing) {
> + spin_unlock_irqrestore(&ch->lock, flags);
> +
> + ret = wait_event_timeout(ch->otg_init_done, !ch->otg_initializing,
> + USB2_OTG_INIT_TIMEOUT);
> + ret = ret ? 0 : -ETIMEDOUT;
> + if (ret && !retries)
> + goto exit;
> +
> + spin_lock_irqsave(&ch->lock, flags);
> + }
> +
> + /* If another thread started a new initialization just return -EBUSY. */
> + if (ch->otg_initializing) {
> + ret = -EBUSY;
> + goto unlock;
...
> @@ -1007,6 +1226,7 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
> return ret;
>
> spin_lock_init(&channel->lock);
> + init_waitqueue_head(&channel->otg_init_done);
> for (i = 0; i < NUM_OF_PHYS; i++) {
> channel->rphys[i].phy = devm_phy_create(dev, NULL,
> channel->phy_data->phy_usb2_ops);
[-- 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-09-08 10:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 18:32 [PATCH v5] phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context Claudiu Beznea
2026-07-16 18:42 ` sashiko-bot
2026-08-10 13:01 ` Claudiu Beznea
2026-09-08 7:41 ` Manivannan Sadhasivam
2026-09-08 10:52 ` Pavel Machek [this message]
2026-09-11 16:16 ` claudiu beznea
2026-09-13 10:44 ` Vinod Koul
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=ap_o-T5GGMFGYZ4v@duo.ucw.cz \
--to=pavel@nabladev.com \
--cc=claudiu.beznea+renesas@tuxon.dev \
--cc=claudiu.beznea.uj@bp.renesas.com \
--cc=claudiu.beznea@tuxon.dev \
--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