All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josua Mayer <josua@solid-run.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>
Cc: Ioana Ciornei <ioana.ciornei@nxp.com>,
	Vinod Koul <vkoul@kernel.org>,
	Kishon Vijay Abraham I <kishon@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 phy 15/16] phy: lynx-28g: truly power the lanes up or down
Date: Wed, 24 Sep 2025 10:09:26 +0000	[thread overview]
Message-ID: <e04dd32d-801b-4019-aa2f-95bf8973c566@solid-run.com> (raw)
In-Reply-To: <20250923194445.454442-16-vladimir.oltean@nxp.com>

Am 23.09.25 um 21:44 schrieb Vladimir Oltean:
> The current procedure for power_off() and power_on() is the same as the
> one used for major lane reconfiguration, aka halting.
>
> But one would expect that a powered off lane causes the CDR (clock and
> data recovery) loop of the link partner to lose lock onto its RX stream
> (which suggests there are no longer any bit transitions => the channel
> is inactive). However, this does not take place (the CDR lock is still
> there), so a halted lane is still active.
>
> Implement the procedure mentioned in the block guide for powering down
> a lane, and then back on.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v1->v2: slight commit message reword
>
>  drivers/phy/freescale/phy-fsl-lynx-28g.c | 78 ++++++++++++++++++------
>  1 file changed, 60 insertions(+), 18 deletions(-)
cut
> +static int lynx_28g_power_off(struct phy *phy)
> +{
> +	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
> +	u32 trstctl, rrstctl;
> +
> +	if (!lane->powered_up)
> +		return 0;
> +
> +	/* Issue a stop request */
> +	lynx_28g_lane_rmw(lane, LNaTRSTCTL, LNaTRSTCTL_STP_REQ,
> +			  LNaTRSTCTL_STP_REQ);
> +	lynx_28g_lane_rmw(lane, LNaRRSTCTL, LNaRRSTCTL_STP_REQ,
> +			  LNaRRSTCTL_STP_REQ);
> +
> +	/* Wait until the stop process is complete */
> +	do {
> +		trstctl = lynx_28g_lane_read(lane, LNaTRSTCTL);
> +		rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
> +	} while ((trstctl & LNaTRSTCTL_STP_REQ) ||
> +		 (rrstctl & LNaRRSTCTL_STP_REQ));

Unbounded loop, perhaps use timeout.

This can fail on unbalanced calls as you discovered,
but also e.g. when a pll is unstable.

See below for when this came up previously:

https://lore.kernel.org/all/20240218-lynx28g-infinite-loop-v1-1-59cc5cef8367@solid-run.com/

-- 
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: Josua Mayer <josua@solid-run.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>
Cc: Ioana Ciornei <ioana.ciornei@nxp.com>,
	Vinod Koul <vkoul@kernel.org>,
	Kishon Vijay Abraham I <kishon@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 phy 15/16] phy: lynx-28g: truly power the lanes up or down
Date: Wed, 24 Sep 2025 10:09:26 +0000	[thread overview]
Message-ID: <e04dd32d-801b-4019-aa2f-95bf8973c566@solid-run.com> (raw)
In-Reply-To: <20250923194445.454442-16-vladimir.oltean@nxp.com>

Am 23.09.25 um 21:44 schrieb Vladimir Oltean:
> The current procedure for power_off() and power_on() is the same as the
> one used for major lane reconfiguration, aka halting.
>
> But one would expect that a powered off lane causes the CDR (clock and
> data recovery) loop of the link partner to lose lock onto its RX stream
> (which suggests there are no longer any bit transitions => the channel
> is inactive). However, this does not take place (the CDR lock is still
> there), so a halted lane is still active.
>
> Implement the procedure mentioned in the block guide for powering down
> a lane, and then back on.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v1->v2: slight commit message reword
>
>  drivers/phy/freescale/phy-fsl-lynx-28g.c | 78 ++++++++++++++++++------
>  1 file changed, 60 insertions(+), 18 deletions(-)
cut
> +static int lynx_28g_power_off(struct phy *phy)
> +{
> +	struct lynx_28g_lane *lane = phy_get_drvdata(phy);
> +	u32 trstctl, rrstctl;
> +
> +	if (!lane->powered_up)
> +		return 0;
> +
> +	/* Issue a stop request */
> +	lynx_28g_lane_rmw(lane, LNaTRSTCTL, LNaTRSTCTL_STP_REQ,
> +			  LNaTRSTCTL_STP_REQ);
> +	lynx_28g_lane_rmw(lane, LNaRRSTCTL, LNaRRSTCTL_STP_REQ,
> +			  LNaRRSTCTL_STP_REQ);
> +
> +	/* Wait until the stop process is complete */
> +	do {
> +		trstctl = lynx_28g_lane_read(lane, LNaTRSTCTL);
> +		rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
> +	} while ((trstctl & LNaTRSTCTL_STP_REQ) ||
> +		 (rrstctl & LNaRRSTCTL_STP_REQ));

Unbounded loop, perhaps use timeout.

This can fail on unbalanced calls as you discovered,
but also e.g. when a pll is unstable.

See below for when this came up previously:

https://lore.kernel.org/all/20240218-lynx28g-infinite-loop-v1-1-59cc5cef8367@solid-run.com/


  reply	other threads:[~2025-09-24 10:09 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-23 19:44 [PATCH v2 phy 00/16] Lynx 28G improvements part 1 Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 01/16] phy: lynx-28g: remove LYNX_28G_ prefix from register names Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 02/16] phy: lynx-28g: don't concatenate lynx_28g_lane_rmw() argument "reg" with "val" and "mask" Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 03/16] phy: lynx-28g: use FIELD_GET() and FIELD_PREP() Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 04/16] phy: lynx-28g: convert iowrite32() calls with magic values to macros Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 05/16] phy: lynx-28g: restructure protocol configuration register accesses Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 06/16] phy: lynx-28g: make lynx_28g_set_lane_mode() more systematic Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 07/16] phy: lynx-28g: refactor lane->interface to lane->mode Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 08/16] phy: lynx-28g: distinguish between 10GBASE-R and USXGMII Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 09/16] phy: lynx-28g: configure more equalization params for 1GbE and 10GbE Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 10/16] phy: lynx-28g: use "dev" argument more in lynx_28g_probe() Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 11/16] phy: lynx-28g: improve lynx_28g_probe() sequence Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 12/16] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 20:37   ` Rob Herring (Arm)
2025-09-23 20:37     ` Rob Herring (Arm)
2025-09-23 20:57     ` Vladimir Oltean
2025-09-23 20:57       ` Vladimir Oltean
2025-09-24 13:54   ` Rob Herring
2025-09-24 13:54     ` Rob Herring
2025-09-24 15:45     ` Vladimir Oltean
2025-09-24 15:45       ` Vladimir Oltean
2025-09-24 15:56       ` Josua Mayer
2025-09-24 15:56         ` Josua Mayer
2025-09-25  8:03         ` Vladimir Oltean
2025-09-25  8:03           ` Vladimir Oltean
2025-09-25 13:05       ` Rob Herring
2025-09-25 13:05         ` Rob Herring
2025-09-23 19:44 ` [PATCH v2 phy 13/16] phy: lynx-28g: probe on per-SoC and per-instance compatible strings Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 14/16] phy: lynx-28g: add support for 25GBASER Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 15/16] phy: lynx-28g: truly power the lanes up or down Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean
2025-09-24 10:09   ` Josua Mayer [this message]
2025-09-24 10:09     ` Josua Mayer
2025-09-24 13:06     ` Vladimir Oltean
2025-09-24 13:06       ` Vladimir Oltean
2025-09-24 15:57       ` Josua Mayer
2025-09-24 15:57         ` Josua Mayer
2025-09-23 19:44 ` [PATCH v2 phy 16/16] phy: lynx-28g: implement phy_exit() operation Vladimir Oltean
2025-09-23 19:44   ` Vladimir Oltean

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=e04dd32d-801b-4019-aa2f-95bf8973c566@solid-run.com \
    --to=josua@solid-run.com \
    --cc=ioana.ciornei@nxp.com \
    --cc=kishon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=vkoul@kernel.org \
    --cc=vladimir.oltean@nxp.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 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.