All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>,
	 Neil Armstrong <neil.armstrong@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	 Maxime Chevallier <maxime.chevallier@bootlin.com>,
	linux-phy@lists.infradead.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	 Igor Paunovic <royalnet026@gmail.com>,
	kernel@collabora.com
Subject: Re: [PATCH] phy: rockchip: inno-usb2: ensure PHY is running when clock is requested
Date: Mon, 28 Sep 2026 20:00:24 +0200	[thread overview]
Message-ID: <arqnn8s5yFmZzQvG@venus> (raw)
In-Reply-To: <xnvakstneih6njyxfe27kdx54vy3zpnth24o4mjlzuoykb2pfh@np7dx62waujo>


[-- Attachment #1.1: Type: text/plain, Size: 3374 bytes --]

Hello Mani,

On Sat, Sep 26, 2026 at 04:50:07AM +0200, Manivannan Sadhasivam wrote:
> On Tue, Sep 08, 2026 at 06:07:42PM +0200, Sebastian Reichel wrote:
> > On RK3588 the OHCI controller registers can only be accessed when the
> > PHY's 480MHz clock is running. After system suspend the controller is
> > resumed before the PHY.
> 
> This statement is slightly confusing. There is no PM ops in this
> PHY driver.

I will take a closer look how it is powered off during suspend.
Generally I expect it to loose state in any case as the related
power domain should be disabled.

> > The controller requests the clock, which opens
> > the gate in the PHY's clock prepare function. But with the PHY suspended
> > this just results in a dead clock being routed. The OHCI driver will
> > then continue to access its registers resulting in a board hang.
> > 
> > Fix this by resuming the suspended PHY in the clock's prepare function,
> > so that the clock is really prepared once the function returns.
> > 
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > ---
> > This was noticed on RK3588 EVB1 when resuming from system suspend. This
> > is technically a fix, but its unclear when the bug was introduced and
> > system suspend is broken on RK3588 for quite a while and not just due
> > to this problem. So I think this fix can be merged the normal way via
> > linux-next.
> > ---
> >  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 37 +++++++++++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> > 
> > diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > index 7d8a533f24ae..07d400967def 100644
> > --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > @@ -332,6 +332,39 @@ rockchip_usb2phy_clk480m_clkout_ctl(struct clk_hw *hw, struct regmap **base,
> >  	}
> >  }
> >  
> > +static int rockchip_usb2phy_clk480m_leave_suspend(struct clk_hw *hw)
> > +{
> > +	struct rockchip_usb2phy *rphy = container_of(hw, struct rockchip_usb2phy, clk480m_hw);
> > +	bool relock = false;
> > +	int ret, i;
> > +
> > +	/* Limit to single port; it's unclear how multi-port should be handled */
> > +	if (rphy->phy_cfg->num_ports > 1)
> > +		return 0;
> > +
> > +	for (i = 0; i < rphy->phy_cfg->num_ports; i++) {
> > +		struct rockchip_usb2phy_port *rport = &rphy->ports[i];
> > +		const struct rockchip_usb2phy_port_cfg *port_cfg = rport->port_cfg;
> > +
> > +		if (!rport->phy || !port_cfg || !port_cfg->phy_sus.enable)
> > +			continue;
> > +		if (property_enabled(rphy->grf, &port_cfg->phy_sus)) {
> > +			property_enable(rphy->grf, &port_cfg->phy_sus,
> > +					false);
> > +			relock = true;
> > +		}
> > +	}
> > +
> > +	if (relock) {
> > +		ret = rockchip_usb2phy_reset(rphy);
> > +		if (ret)
> > +			return ret;
> > +		usleep_range(1500, 2000);
> > +	}
> > +
> 
> This looks like a duplication of rockchip_usb2phy_power_on(). So I'm assuming
> that phy_power_on() is not called by the OHCI driver before accessing the
> registers. So why don't you fix that instead?

I can look into it. My way of thinking was, that the clock should be
running independently of that when the clock has been requested via
common clock framework.

Greetings,

-- Sebastian

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>,
	 Neil Armstrong <neil.armstrong@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	 Maxime Chevallier <maxime.chevallier@bootlin.com>,
	linux-phy@lists.infradead.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	 Igor Paunovic <royalnet026@gmail.com>,
	kernel@collabora.com
Subject: Re: [PATCH] phy: rockchip: inno-usb2: ensure PHY is running when clock is requested
Date: Mon, 28 Sep 2026 20:00:24 +0200	[thread overview]
Message-ID: <arqnn8s5yFmZzQvG@venus> (raw)
In-Reply-To: <xnvakstneih6njyxfe27kdx54vy3zpnth24o4mjlzuoykb2pfh@np7dx62waujo>

[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]

Hello Mani,

On Sat, Sep 26, 2026 at 04:50:07AM +0200, Manivannan Sadhasivam wrote:
> On Tue, Sep 08, 2026 at 06:07:42PM +0200, Sebastian Reichel wrote:
> > On RK3588 the OHCI controller registers can only be accessed when the
> > PHY's 480MHz clock is running. After system suspend the controller is
> > resumed before the PHY.
> 
> This statement is slightly confusing. There is no PM ops in this
> PHY driver.

I will take a closer look how it is powered off during suspend.
Generally I expect it to loose state in any case as the related
power domain should be disabled.

> > The controller requests the clock, which opens
> > the gate in the PHY's clock prepare function. But with the PHY suspended
> > this just results in a dead clock being routed. The OHCI driver will
> > then continue to access its registers resulting in a board hang.
> > 
> > Fix this by resuming the suspended PHY in the clock's prepare function,
> > so that the clock is really prepared once the function returns.
> > 
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > ---
> > This was noticed on RK3588 EVB1 when resuming from system suspend. This
> > is technically a fix, but its unclear when the bug was introduced and
> > system suspend is broken on RK3588 for quite a while and not just due
> > to this problem. So I think this fix can be merged the normal way via
> > linux-next.
> > ---
> >  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 37 +++++++++++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> > 
> > diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > index 7d8a533f24ae..07d400967def 100644
> > --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > @@ -332,6 +332,39 @@ rockchip_usb2phy_clk480m_clkout_ctl(struct clk_hw *hw, struct regmap **base,
> >  	}
> >  }
> >  
> > +static int rockchip_usb2phy_clk480m_leave_suspend(struct clk_hw *hw)
> > +{
> > +	struct rockchip_usb2phy *rphy = container_of(hw, struct rockchip_usb2phy, clk480m_hw);
> > +	bool relock = false;
> > +	int ret, i;
> > +
> > +	/* Limit to single port; it's unclear how multi-port should be handled */
> > +	if (rphy->phy_cfg->num_ports > 1)
> > +		return 0;
> > +
> > +	for (i = 0; i < rphy->phy_cfg->num_ports; i++) {
> > +		struct rockchip_usb2phy_port *rport = &rphy->ports[i];
> > +		const struct rockchip_usb2phy_port_cfg *port_cfg = rport->port_cfg;
> > +
> > +		if (!rport->phy || !port_cfg || !port_cfg->phy_sus.enable)
> > +			continue;
> > +		if (property_enabled(rphy->grf, &port_cfg->phy_sus)) {
> > +			property_enable(rphy->grf, &port_cfg->phy_sus,
> > +					false);
> > +			relock = true;
> > +		}
> > +	}
> > +
> > +	if (relock) {
> > +		ret = rockchip_usb2phy_reset(rphy);
> > +		if (ret)
> > +			return ret;
> > +		usleep_range(1500, 2000);
> > +	}
> > +
> 
> This looks like a duplication of rockchip_usb2phy_power_on(). So I'm assuming
> that phy_power_on() is not called by the OHCI driver before accessing the
> registers. So why don't you fix that instead?

I can look into it. My way of thinking was, that the clock should be
running independently of that when the clock has been requested via
common clock framework.

Greetings,

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>,
	 Neil Armstrong <neil.armstrong@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	 Maxime Chevallier <maxime.chevallier@bootlin.com>,
	linux-phy@lists.infradead.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	 Igor Paunovic <royalnet026@gmail.com>,
	kernel@collabora.com
Subject: Re: [PATCH] phy: rockchip: inno-usb2: ensure PHY is running when clock is requested
Date: Mon, 28 Sep 2026 20:00:24 +0200	[thread overview]
Message-ID: <arqnn8s5yFmZzQvG@venus> (raw)
In-Reply-To: <xnvakstneih6njyxfe27kdx54vy3zpnth24o4mjlzuoykb2pfh@np7dx62waujo>


[-- Attachment #1.1: Type: text/plain, Size: 3374 bytes --]

Hello Mani,

On Sat, Sep 26, 2026 at 04:50:07AM +0200, Manivannan Sadhasivam wrote:
> On Tue, Sep 08, 2026 at 06:07:42PM +0200, Sebastian Reichel wrote:
> > On RK3588 the OHCI controller registers can only be accessed when the
> > PHY's 480MHz clock is running. After system suspend the controller is
> > resumed before the PHY.
> 
> This statement is slightly confusing. There is no PM ops in this
> PHY driver.

I will take a closer look how it is powered off during suspend.
Generally I expect it to loose state in any case as the related
power domain should be disabled.

> > The controller requests the clock, which opens
> > the gate in the PHY's clock prepare function. But with the PHY suspended
> > this just results in a dead clock being routed. The OHCI driver will
> > then continue to access its registers resulting in a board hang.
> > 
> > Fix this by resuming the suspended PHY in the clock's prepare function,
> > so that the clock is really prepared once the function returns.
> > 
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > ---
> > This was noticed on RK3588 EVB1 when resuming from system suspend. This
> > is technically a fix, but its unclear when the bug was introduced and
> > system suspend is broken on RK3588 for quite a while and not just due
> > to this problem. So I think this fix can be merged the normal way via
> > linux-next.
> > ---
> >  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 37 +++++++++++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> > 
> > diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > index 7d8a533f24ae..07d400967def 100644
> > --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > @@ -332,6 +332,39 @@ rockchip_usb2phy_clk480m_clkout_ctl(struct clk_hw *hw, struct regmap **base,
> >  	}
> >  }
> >  
> > +static int rockchip_usb2phy_clk480m_leave_suspend(struct clk_hw *hw)
> > +{
> > +	struct rockchip_usb2phy *rphy = container_of(hw, struct rockchip_usb2phy, clk480m_hw);
> > +	bool relock = false;
> > +	int ret, i;
> > +
> > +	/* Limit to single port; it's unclear how multi-port should be handled */
> > +	if (rphy->phy_cfg->num_ports > 1)
> > +		return 0;
> > +
> > +	for (i = 0; i < rphy->phy_cfg->num_ports; i++) {
> > +		struct rockchip_usb2phy_port *rport = &rphy->ports[i];
> > +		const struct rockchip_usb2phy_port_cfg *port_cfg = rport->port_cfg;
> > +
> > +		if (!rport->phy || !port_cfg || !port_cfg->phy_sus.enable)
> > +			continue;
> > +		if (property_enabled(rphy->grf, &port_cfg->phy_sus)) {
> > +			property_enable(rphy->grf, &port_cfg->phy_sus,
> > +					false);
> > +			relock = true;
> > +		}
> > +	}
> > +
> > +	if (relock) {
> > +		ret = rockchip_usb2phy_reset(rphy);
> > +		if (ret)
> > +			return ret;
> > +		usleep_range(1500, 2000);
> > +	}
> > +
> 
> This looks like a duplication of rockchip_usb2phy_power_on(). So I'm assuming
> that phy_power_on() is not called by the OHCI driver before accessing the
> registers. So why don't you fix that instead?

I can look into it. My way of thinking was, that the clock should be
running independently of that when the clock has been requested via
common clock framework.

Greetings,

-- Sebastian

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2026-09-28 18:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 16:07 [PATCH] phy: rockchip: inno-usb2: ensure PHY is running when clock is requested Sebastian Reichel
2026-09-08 16:07 ` Sebastian Reichel
2026-09-08 16:07 ` Sebastian Reichel
2026-09-08 16:20 ` sashiko-bot
2026-09-08 16:29 ` Igor Paunovic
2026-09-08 16:29   ` Igor Paunovic
2026-09-08 16:29   ` Igor Paunovic
2026-09-26  2:50 ` Manivannan Sadhasivam
2026-09-26  2:50   ` Manivannan Sadhasivam
2026-09-26  2:50   ` Manivannan Sadhasivam
2026-09-28 18:00   ` Sebastian Reichel [this message]
2026-09-28 18:00     ` Sebastian Reichel
2026-09-28 18:00     ` Sebastian Reichel
2026-09-29 14:44     ` Sebastian Reichel
2026-09-29 14:44       ` Sebastian Reichel
2026-09-29 14:44       ` Sebastian Reichel

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=arqnn8s5yFmZzQvG@venus \
    --to=sebastian.reichel@collabora.com \
    --cc=heiko@sntech.de \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mani@kernel.org \
    --cc=maxime.chevallier@bootlin.com \
    --cc=neil.armstrong@linaro.org \
    --cc=royalnet026@gmail.com \
    --cc=vkoul@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.