* Re: [PATCH v5 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Geert Uytterhoeven @ 2026-01-20 9:35 UTC (permalink / raw)
To: Josua Mayer
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Yazan Shhady, Jon Nettleton, Mikhail Anikin, linux-can, linux-phy,
linux-kernel, linux-omap, linux-i2c, linux-mmc, devicetree,
linux-renesas-soc
In-Reply-To: <20260118-rz-sdio-mux-v5-1-3c37e8872683@solid-run.com>
Hi Josua,
On Sun, 18 Jan 2026 at 11:29, Josua Mayer <josua@solid-run.com> wrote:
> Rename the temporary devm_mux_state_get_optional function to avoid
> conflict with upcoming implementation in multiplexer subsystem.
>
> Acked-by: Vinod Koul <vkoul@kernel.org>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
My
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
on v3 is still valid.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Dmitry Baryshkov @ 2026-01-20 9:28 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable, Abel Vesa
In-Reply-To: <8c63a77c-1676-461a-bfcf-55202e723718@oss.qualcomm.com>
On Tue, Jan 20, 2026 at 03:56:10PM +0800, Yongxing Mou wrote:
>
>
> On 1/20/2026 11:12 AM, Dmitry Baryshkov wrote:
> > On Tue, Jan 20, 2026 at 10:43:46AM +0800, Yongxing Mou wrote:
> > >
> > >
> > > On 1/19/2026 8:55 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Jan 19, 2026 at 08:37:20PM +0800, Yongxing Mou wrote:
> > > > > Currently, the LeMans/Monaco devices and their derivative platforms
> > > > > operate in DP mode rather than eDP mode. Per the PHY HPG, the Swing and
> > > > > Emphasis settings need to be corrected to the proper values.
> > > >
> > > > No, they need to be configured dynamically. I wrote earlier that the
> > > > driver needs refactoring.
> > > >
> > > Hi, Dmitry. I plan to submit them in this order: this patch → LDO patch →
> > > refactor.
> > > Since the refactor involves more platforms and may take some time, I’d like
> > > to get this patch merged first.
> >
> > This patch is incorrect. It trades working on some platforms (DP) vs
> > working of someo ther platforms (eDP). I don't think it is a proper fix
> > for any problem.
> >
> Got it.. will post refactor series.
Thanks! I don't see a good way to fix your issue without restructuring
the driver.
Note, the driver has to support both older DT (which used separate -edp
and -dp compats) and the current one.
> > > > >
> > > > > This will help achieve successful link training on some dongles.
> > > > >
> > > > > Cc: stable@vger.kernel.org
> > > > > Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
> > > > > Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> > > > > Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> > > > > ---
> > > > > Changes in v2:
> > > > > - Separate the LDO change out.[Konrad][Dmitry]
> > > > > - Modify the commit message.[Dmitry]
> > > > > - Link to v1: https://lore.kernel.org/r/20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com
> > > > > ---
> > > > > drivers/phy/qualcomm/phy-qcom-edp.c | 23 ++++++++++++++++++++++-
> > > > > 1 file changed, 22 insertions(+), 1 deletion(-)
> > > > >
> > > >
> > >
> > >
> > > --
> > > linux-phy mailing list
> > > linux-phy@lists.infradead.org
> > > https://lists.infradead.org/mailman/listinfo/linux-phy
> >
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Vladimir Oltean @ 2026-01-20 8:42 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <aW8M9ZiiftGBQIRM@shell.armlinux.org.uk>
On Tue, Jan 20, 2026 at 05:04:53AM +0000, Russell King (Oracle) wrote:
> On Mon, Jan 19, 2026 at 11:21:25AM -0800, Jakub Kicinski wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> >
> > For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> > ---
> > net: stmmac: add stmmac core serdes support
> >
> > This commit adds SerDes PHY support to the stmmac core driver, moving it
> > from platform glue into the integrated PCS driver. The SerDes is managed
> > through phy_init/phy_exit for lifecycle and phy_power_on/phy_power_off
> > for the power state.
> >
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > > index 2f826fe7229b..4d1902f3a58f 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> >
> > [ ... ]
> >
> > > static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
> > > {
> > > struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> > > + struct stmmac_priv *priv = spcs->priv;
> > > + int ret;
> > >
> > > - stmmac_mac_irq_modify(spcs->priv, 0, spcs->int_mask);
> > > + ret = dwmac_serdes_power_on(priv);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (spcs->interface != PHY_INTERFACE_MODE_NA) {
> > > + ret = dwmac_serdes_set_mode(priv, spcs->interface);
> > > + if (ret)
> > > + return ret;
> > ^^^^^^^^^^
> >
> > If dwmac_serdes_set_mode() fails here, doesn't this leave the SerDes in
> > a powered-on state? dwmac_serdes_power_on() succeeded at this point but
> > there's no corresponding dwmac_serdes_power_off() call before returning
> > the error.
> >
> > Looking at phylink_major_config(), it appears to discard the return
> > value from phylink_pcs_enable(), so the caller won't know to call
> > pcs_disable() to clean up the power state.
>
> This AI analysis is incorrect.
>
> By the time phylink_pcs_enable() has been called, the PCS is already
> plumbed in to phylink. It _will_ have phylink_pcs_disable() called on
> it at some point in the future, either by having the PCS displaced
> by another in a subsequent phylink_major_config(), or by a driver
> calling phylink_stop().
>
> If we clean up here, then we will call dwmac_serdes_power_off() twice.
>
> Yes, it's not "nice" but that's the way phylink is right now, and
> without reworking phylink to record that pcs_enable() has failed
> to avoid a subsequent pcs_disable(), and to stop the major config
> (which then potentially causes a whole bunch of other issues). I
> don't even want to think about that horrid scenario at the moment.
More to the point, if dwmac_integrated_pcs_enable() fails at
dwmac_serdes_power_on() (thus, the SerDes is _not_ powered on), by your
own admission of this PCS calling convention, sooner or later
dwmac_integrated_pcs_disable() -> dwmac_serdes_power_off() will still be
called, leading to a negative phy->power_count.
That is to say, if the model is "irrespective of whether pcs_enable()
succeeds or fails mid way, pcs_disable is called anyway()", then these
methods are not prepared to handle that reliably.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Vladimir Oltean @ 2026-01-20 8:18 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <aW8M9ZiiftGBQIRM@shell.armlinux.org.uk>
On Tue, Jan 20, 2026 at 05:04:53AM +0000, Russell King (Oracle) wrote:
> On Mon, Jan 19, 2026 at 11:21:25AM -0800, Jakub Kicinski wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> >
> > For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> > ---
> > net: stmmac: add stmmac core serdes support
> >
> > This commit adds SerDes PHY support to the stmmac core driver, moving it
> > from platform glue into the integrated PCS driver. The SerDes is managed
> > through phy_init/phy_exit for lifecycle and phy_power_on/phy_power_off
> > for the power state.
> >
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > > index 2f826fe7229b..4d1902f3a58f 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> >
> > [ ... ]
> >
> > > static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
> > > {
> > > struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> > > + struct stmmac_priv *priv = spcs->priv;
> > > + int ret;
> > >
> > > - stmmac_mac_irq_modify(spcs->priv, 0, spcs->int_mask);
> > > + ret = dwmac_serdes_power_on(priv);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (spcs->interface != PHY_INTERFACE_MODE_NA) {
> > > + ret = dwmac_serdes_set_mode(priv, spcs->interface);
> > > + if (ret)
> > > + return ret;
> > ^^^^^^^^^^
> >
> > If dwmac_serdes_set_mode() fails here, doesn't this leave the SerDes in
> > a powered-on state? dwmac_serdes_power_on() succeeded at this point but
> > there's no corresponding dwmac_serdes_power_off() call before returning
> > the error.
> >
> > Looking at phylink_major_config(), it appears to discard the return
> > value from phylink_pcs_enable(), so the caller won't know to call
> > pcs_disable() to clean up the power state.
>
> This AI analysis is incorrect.
>
> By the time phylink_pcs_enable() has been called, the PCS is already
> plumbed in to phylink. It _will_ have phylink_pcs_disable() called on
> it at some point in the future, either by having the PCS displaced
> by another in a subsequent phylink_major_config(), or by a driver
> calling phylink_stop().
>
> If we clean up here, then we will call dwmac_serdes_power_off() twice.
>
> Yes, it's not "nice" but that's the way phylink is right now, and
> without reworking phylink to record that pcs_enable() has failed
> to avoid a subsequent pcs_disable(), and to stop the major config
> (which then potentially causes a whole bunch of other issues). I
> don't even want to think about that horrid scenario at the moment.
Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
after calling pcs_disable(), though?
I had to deal with the same issue when preparing patches that integrate
SerDes support into the Lynx PCS.
I had these patches (please pardon the unadapted commit messages for the
present situation):
-- >8 --
Subject: [PATCH] net: phylink: handle return code from phylink_pcs_enable()
I am trying to make phylink_pcs_ops :: pcs_enable() something that is
handled sufficiently carefully by phylink, such that we can expect that
when we return an error code here, no other phylink_pcs_ops call is
being made. This way, the API can be considered sufficiently reliable to
allocate memory in pcs_enable() which is freed in pcs_disable().
Currently this does not take place. The pcs_enable() method has an int
return code, which is ignored. If the PCS returns an error, the
initialization of the phylink instance is not stopped, but continues on
like a train, most likely triggering faults somewhere else.
Like this:
$ ip link set endpmac2 up
fsl_dpaa2_eth dpni.1 endpmac2: configuring for c73/10gbase-kr link mode
fsl_dpaa2_eth dpni.1 endpmac2: pcs_enable() failed: -ENOMEM // added by me
Unable to handle kernel paging request at virtual address fffffffffffffff4
Call trace:
mtip_backplane_get_state+0x34/0x2b4
lynx_pcs_get_state+0x30/0x180
phylink_resolve+0x2c0/0x764
process_scheduled_works+0x228/0x330
worker_thread+0x28c/0x450
Do a minimal handling of the error by clearing pl->pcs, so that we lose
access to its ops, and thus are unable to call anything else (which
would be invalid anyway).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/phy/phylink.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 32ffa4f9e5b2..a8459116b701 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1315,8 +1315,15 @@ static void phylink_major_config(struct phylink *pl, bool restart,
}
}
- if (pl->pcs_state == PCS_STATE_STARTING || pcs_changed)
- phylink_pcs_enable(pl->pcs);
+ if (pl->pcs_state == PCS_STATE_STARTING || pcs_changed) {
+ err = phylink_pcs_enable(pl->pcs);
+ if (err < 0) {
+ phylink_err(pl, "pcs_enable() failed: %pe\n",
+ ERR_PTR(err));
+ pl->pcs = NULL;
+ return;
+ }
+ }
err = phylink_pcs_config(pl->pcs, pl->pcs_neg_mode, state,
!!(pl->link_config.pause & MLO_PAUSE_AN));
-- >8 --
-- >8 --
Subject: [PATCH] net: phylink: suppress pcs->ops->pcs_get_state() calls after
phylink_stop()
I am attempting to make phylink_pcs_ops :: pcs_disable() treated
sufficiently carefully by phylink so as to be able to free memory
allocations from this PCS callback, and do not suffer from faults
attempting to access that memory later from other phylink_pcs callbacks.
Currently, nothing prevents this situation from happening:
$ ip link set endpmac2 up
$ ip link set endpmac2 down
$ ethtool endpmac2
Unable to handle kernel paging request at virtual address 0000100000000034
Call trace:
__mutex_lock+0xb8/0x574
__mutex_lock_slowpath+0x14/0x20
mutex_lock+0x24/0x58
mtip_backplane_get_state+0x44/0x24c
lynx_pcs_get_state+0x30/0x180
phylink_ethtool_ksettings_get+0x178/0x218
dpaa2_eth_get_link_ksettings+0x54/0xa4
__ethtool_get_link_ksettings+0x68/0xa8
linkmodes_prepare_data+0x44/0xc4
ethnl_default_doit+0x118/0x39c
genl_rcv_msg+0x29c/0x314
netlink_rcv_skb+0x11c/0x134
genl_rcv+0x34/0x4c
However, the case where "ethtool endpmac2" is executed as the first
thing (before the interface is brought up) does not crash. What's
different is that second situation is that phylink_major_config() did
not run yet, so pl->pcs is still NULL inside phylink_mac_pcs_get_state().
In plain English, "as long as the PCS is disabled, the link is naturally
down, no need to ask".
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/phy/phylink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index a8459116b701..f78d0e0f7cfb 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -2527,6 +2527,7 @@ void phylink_stop(struct phylink *pl)
pl->pcs_state = PCS_STATE_DOWN;
phylink_pcs_disable(pl->pcs);
+ pl->pcs = NULL;
}
EXPORT_SYMBOL_GPL(phylink_stop);
-- >8 --
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Yongxing Mou @ 2026-01-20 7:56 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable, Abel Vesa
In-Reply-To: <5ytgf7saw6yfvqzqmy4gtjygo4cx52vomi7mwswc7hgedzz3rb@eiqxiqs2cjmb>
On 1/20/2026 11:12 AM, Dmitry Baryshkov wrote:
> On Tue, Jan 20, 2026 at 10:43:46AM +0800, Yongxing Mou wrote:
>>
>>
>> On 1/19/2026 8:55 PM, Dmitry Baryshkov wrote:
>>> On Mon, Jan 19, 2026 at 08:37:20PM +0800, Yongxing Mou wrote:
>>>> Currently, the LeMans/Monaco devices and their derivative platforms
>>>> operate in DP mode rather than eDP mode. Per the PHY HPG, the Swing and
>>>> Emphasis settings need to be corrected to the proper values.
>>>
>>> No, they need to be configured dynamically. I wrote earlier that the
>>> driver needs refactoring.
>>>
>> Hi, Dmitry. I plan to submit them in this order: this patch → LDO patch →
>> refactor.
>> Since the refactor involves more platforms and may take some time, I’d like
>> to get this patch merged first.
>
> This patch is incorrect. It trades working on some platforms (DP) vs
> working of someo ther platforms (eDP). I don't think it is a proper fix
> for any problem.
>
Got it.. will post refactor series.
>>>>
>>>> This will help achieve successful link training on some dongles.
>>>>
>>>> Cc: stable@vger.kernel.org
>>>> Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
>>>> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>> Changes in v2:
>>>> - Separate the LDO change out.[Konrad][Dmitry]
>>>> - Modify the commit message.[Dmitry]
>>>> - Link to v1: https://lore.kernel.org/r/20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com
>>>> ---
>>>> drivers/phy/qualcomm/phy-qcom-edp.c | 23 ++++++++++++++++++++++-
>>>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>>>
>>>
>>
>>
>> --
>> linux-phy mailing list
>> linux-phy@lists.infradead.org
>> https://lists.infradead.org/mailman/listinfo/linux-phy
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/4] Add USB support for Canaan K230
From: Greg KH @ 2026-01-20 6:06 UTC (permalink / raw)
To: Jiayu Du
Cc: vkoul, conor, neil.armstrong, robh, krzk+dt, pjw, palmer, aou,
alex, linux-phy, linux-usb, devicetree, linux-riscv, linux-kernel
In-Reply-To: <aW5WyizgDyQJaKLQ@duge-virtual-machine>
On Tue, Jan 20, 2026 at 12:07:38AM +0800, Jiayu Du wrote:
> On Mon, Jan 19, 2026 at 05:38:31PM +0800, Jiayu Du wrote:
>
> This is series is the RESEND of the series here[1]. I resend it
> because I mistakenly sent the wrong USBPHY driver code.
>
> Link: https://lore.kernel.org/all/20260119093836.316007-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
> ]
>
I have no idea which is which anymore, sorry. Please send out a v4 so
we know which to look at.
confused,
greg k-h
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Russell King (Oracle) @ 2026-01-20 5:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: linux-phy, davem, maxime.chevallier, alexandre.torgue, mohd.anwar,
neil.armstrong, hkallweit1, mcoquelin.stm32, netdev, edumazet,
linux-arm-msm, linux-arm-kernel, vkoul, andrew, pabeni,
andrew+netdev, linux-stm32
In-Reply-To: <20260119192125.1245102-1-kuba@kernel.org>
On Mon, Jan 19, 2026 at 11:21:25AM -0800, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> net: stmmac: add stmmac core serdes support
>
> This commit adds SerDes PHY support to the stmmac core driver, moving it
> from platform glue into the integrated PCS driver. The SerDes is managed
> through phy_init/phy_exit for lifecycle and phy_power_on/phy_power_off
> for the power state.
>
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > index 2f826fe7229b..4d1902f3a58f 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
>
> [ ... ]
>
> > static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
> > {
> > struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> > + struct stmmac_priv *priv = spcs->priv;
> > + int ret;
> >
> > - stmmac_mac_irq_modify(spcs->priv, 0, spcs->int_mask);
> > + ret = dwmac_serdes_power_on(priv);
> > + if (ret)
> > + return ret;
> > +
> > + if (spcs->interface != PHY_INTERFACE_MODE_NA) {
> > + ret = dwmac_serdes_set_mode(priv, spcs->interface);
> > + if (ret)
> > + return ret;
> ^^^^^^^^^^
>
> If dwmac_serdes_set_mode() fails here, doesn't this leave the SerDes in
> a powered-on state? dwmac_serdes_power_on() succeeded at this point but
> there's no corresponding dwmac_serdes_power_off() call before returning
> the error.
>
> Looking at phylink_major_config(), it appears to discard the return
> value from phylink_pcs_enable(), so the caller won't know to call
> pcs_disable() to clean up the power state.
This AI analysis is incorrect.
By the time phylink_pcs_enable() has been called, the PCS is already
plumbed in to phylink. It _will_ have phylink_pcs_disable() called on
it at some point in the future, either by having the PCS displaced
by another in a subsequent phylink_major_config(), or by a driver
calling phylink_stop().
If we clean up here, then we will call dwmac_serdes_power_off() twice.
Yes, it's not "nice" but that's the way phylink is right now, and
without reworking phylink to record that pcs_enable() has failed
to avoid a subsequent pcs_disable(), and to stop the major config
(which then potentially causes a whole bunch of other issues). I
don't even want to think about that horrid scenario at the moment.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Dmitry Baryshkov @ 2026-01-20 3:12 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable, Abel Vesa
In-Reply-To: <749e716e-a6cb-4adb-8ffc-0d6f4c6d56c4@oss.qualcomm.com>
On Tue, Jan 20, 2026 at 10:43:46AM +0800, Yongxing Mou wrote:
>
>
> On 1/19/2026 8:55 PM, Dmitry Baryshkov wrote:
> > On Mon, Jan 19, 2026 at 08:37:20PM +0800, Yongxing Mou wrote:
> > > Currently, the LeMans/Monaco devices and their derivative platforms
> > > operate in DP mode rather than eDP mode. Per the PHY HPG, the Swing and
> > > Emphasis settings need to be corrected to the proper values.
> >
> > No, they need to be configured dynamically. I wrote earlier that the
> > driver needs refactoring.
> >
> Hi, Dmitry. I plan to submit them in this order: this patch → LDO patch →
> refactor.
> Since the refactor involves more platforms and may take some time, I’d like
> to get this patch merged first.
This patch is incorrect. It trades working on some platforms (DP) vs
working of someo ther platforms (eDP). I don't think it is a proper fix
for any problem.
> > >
> > > This will help achieve successful link training on some dongles.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
> > > Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> > > Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> > > ---
> > > Changes in v2:
> > > - Separate the LDO change out.[Konrad][Dmitry]
> > > - Modify the commit message.[Dmitry]
> > > - Link to v1: https://lore.kernel.org/r/20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com
> > > ---
> > > drivers/phy/qualcomm/phy-qcom-edp.c | 23 ++++++++++++++++++++++-
> > > 1 file changed, 22 insertions(+), 1 deletion(-)
> > >
> >
>
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Yongxing Mou @ 2026-01-20 2:43 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable, Abel Vesa
In-Reply-To: <47skckagggxijdhinmmibtrd3dydixtj6pccrgjwyczs7bj2te@2rq2iprmzvyf>
On 1/19/2026 8:55 PM, Dmitry Baryshkov wrote:
> On Mon, Jan 19, 2026 at 08:37:20PM +0800, Yongxing Mou wrote:
>> Currently, the LeMans/Monaco devices and their derivative platforms
>> operate in DP mode rather than eDP mode. Per the PHY HPG, the Swing and
>> Emphasis settings need to be corrected to the proper values.
>
> No, they need to be configured dynamically. I wrote earlier that the
> driver needs refactoring.
>
Hi, Dmitry. I plan to submit them in this order: this patch → LDO patch
→ refactor.
Since the refactor involves more platforms and may take some time, I’d
like to get this patch merged first.
>>
>> This will help achieve successful link training on some dongles.
>>
>> Cc: stable@vger.kernel.org
>> Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
>> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Separate the LDO change out.[Konrad][Dmitry]
>> - Modify the commit message.[Dmitry]
>> - Link to v1: https://lore.kernel.org/r/20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com
>> ---
>> drivers/phy/qualcomm/phy-qcom-edp.c | 23 ++++++++++++++++++++++-
>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,12/14] net: stmmac: add support for reading inband SGMII status
From: Jakub Kicinski @ 2026-01-19 19:21 UTC (permalink / raw)
To: rmk+kernel
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <E1vhoSr-00000005H2N-2H2L@rmk-PC.armlinux.org.uk>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: stmmac: add support for reading inband SGMII status
This patch adds support for reading link status, speed, and duplex for
SGMII links from the RGSMII status register. New fields are added to
stmmac_pcs_info and stmmac_pcs structures for the register offset and mask.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> index 73fc56ce5e55..9dd7e78cfbc4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
[ ... ]
> @@ -111,7 +121,37 @@ static void dwmac_integrated_pcs_get_state(struct phylink_pcs *pcs,
>
> phylink_mii_c22_pcs_decode_state(state, neg_mode, status, lpa);
> } else {
> - state->link = false;
> + rgsmii = field_get(spcs->rgsmii_status_mask,
> + readl(spcs->rgsmii));
^^^^
When dwmac1000_pcs_init() or dwmac4_pcs_init() is used, the pcs_info
structures do not initialize the new rgsmii_offset and rgsmii_status_mask
fields. For example, dwmac4_pcs_info in dwmac4_core.c only sets:
static const struct stmmac_pcs_info dwmac4_pcs_info = {
.pcs_offset = GMAC_PCS_BASE,
.int_mask = GMAC_INT_PCS_LINK | GMAC_INT_PCS_ANE,
};
This leaves rgsmii_status_mask implicitly zero. Calling field_get() with a
mask of zero violates its API contract (mask must be non-zero) and results
in undefined behavior from __ffs(0).
Should the existing dwmac1000_pcs_info and dwmac4_pcs_info structures be
updated to provide proper values for the new fields? Or should there be a
guard check before calling field_get() when rgsmii_status_mask is zero?
> +
> + state->link = status & BMSR_LSTATUS &&
> + rgsmii & GMAC_RGSMIII_LNKSTS;
[ ... ]
> @@ -205,6 +245,8 @@ int stmmac_integrated_pcs_init(struct stmmac_priv *priv,
>
> spcs->priv = priv;
> spcs->base = priv->ioaddr + pcs_info->pcs_offset;
> + spcs->rgsmii = priv->ioaddr + pcs_info->rgsmii_offset;
> + spcs->rgsmii_status_mask = pcs_info->rgsmii_status_mask;
The values are copied from pcs_info here, but dwmac1000_pcs_info and
dwmac4_pcs_info do not initialize these fields.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> index a7c71f40f952..f9e7a7ed840b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> @@ -29,12 +29,16 @@ struct stmmac_priv;
>
> struct stmmac_pcs_info {
> unsigned int pcs_offset;
> + unsigned int rgsmii_offset;
> + u32 rgsmii_status_mask;
> u32 int_mask;
> };
These new fields need to be initialized by all users of stmmac_pcs_info.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Jakub Kicinski @ 2026-01-19 19:21 UTC (permalink / raw)
To: rmk+kernel
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <E1vhoSH-00000005H1f-2cq9@rmk-PC.armlinux.org.uk>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: stmmac: add stmmac core serdes support
This commit adds SerDes PHY support to the stmmac core driver, moving it
from platform glue into the integrated PCS driver. The SerDes is managed
through phy_init/phy_exit for lifecycle and phy_power_on/phy_power_off
for the power state.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> index 2f826fe7229b..4d1902f3a58f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
[ ... ]
> static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
> {
> struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> + struct stmmac_priv *priv = spcs->priv;
> + int ret;
>
> - stmmac_mac_irq_modify(spcs->priv, 0, spcs->int_mask);
> + ret = dwmac_serdes_power_on(priv);
> + if (ret)
> + return ret;
> +
> + if (spcs->interface != PHY_INTERFACE_MODE_NA) {
> + ret = dwmac_serdes_set_mode(priv, spcs->interface);
> + if (ret)
> + return ret;
^^^^^^^^^^
If dwmac_serdes_set_mode() fails here, doesn't this leave the SerDes in
a powered-on state? dwmac_serdes_power_on() succeeded at this point but
there's no corresponding dwmac_serdes_power_off() call before returning
the error.
Looking at phylink_major_config(), it appears to discard the return
value from phylink_pcs_enable(), so the caller won't know to call
pcs_disable() to clean up the power state.
Should this be something like:
if (spcs->interface != PHY_INTERFACE_MODE_NA) {
ret = dwmac_serdes_set_mode(priv, spcs->interface);
if (ret) {
dwmac_serdes_power_off(priv);
return ret;
}
}
> + }
> +
> + stmmac_mac_irq_modify(priv, 0, spcs->int_mask);
>
> return 0;
> }
[ ... ]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/4] Add USB support for Canaan K230
From: Jiayu Du @ 2026-01-19 16:07 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex, linux-phy,
linux-usb, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20260119093836.316007-1-jiayu.riscv@isrc.iscas.ac.cn>
On Mon, Jan 19, 2026 at 05:38:31PM +0800, Jiayu Du wrote:
This is series is the RESEND of the series here[1]. I resend it
because I mistakenly sent the wrong USBPHY driver code.
Link: https://lore.kernel.org/all/20260119093836.316007-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 00/11] Describe PCIe/USB3.0 clock generator on R-Car Gen3
From: Geert Uytterhoeven @ 2026-01-19 15:58 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <2b6f19f3-aaf9-4fb7-bef7-f38e19f94351@mailbox.org>
Hi Marek,
On Sun, 18 Jan 2026 at 14:54, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 1/13/26 3:19 PM, Geert Uytterhoeven wrote:
> > I do not know what is the actual issue. Adding debug prints to
> > rs9_suspend() and rs9_resume() shows these functions are not called,
> > while adding 'status = "disabled"' to the renesas,9fgv0841 clock node
> > in arch/arm64/boot/dts/renesas/salvator-common.dtsi does fix the issue.
> >
> > Perhaps you have pending patches for the rs9 or PCIe drivers?
> > Do you have a clue?
> I believe this one should address the problem:
>
> [PATCH] clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841
>
> https://lore.kernel.org/linux-clk/20260118025756.96377-1-marek.vasut+renesas@mailbox.org/
Yes it does, thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on Purwa
From: Konrad Dybcio @ 2026-01-19 15:14 UTC (permalink / raw)
To: Krzysztof Kozlowski, Konrad Dybcio, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, YijieYang
In-Reply-To: <8ea2358b-00e9-44b2-acce-777863e8688e@kernel.org>
On 1/19/26 3:50 PM, Krzysztof Kozlowski wrote:
> On 19/01/2026 12:48, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> Neither of the two Gen4x4 PHYs found on Purwa supports bifurcation.
>> The PHY is however physically laid out as if it were to, since there
>> are two separate ports (A/B).
>>
>> Split out a new if-then block to un-require the bifurcation register
>> handle to squash this warning:
>>
>> purwa-iot-evk.dtb: phy@1bd4000 (qcom,x1p42100-qmp-gen4x4-pcie-phy): 'qcom,4ln-config-sel' is a required property
>
> Warning does not exist in the kernel, so please do not reference it.
Only because no Purwa-based device enables it, so I think it's valid
If you really want to, I can resend with that mention removed
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on Purwa
From: Krzysztof Kozlowski @ 2026-01-19 14:50 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, YijieYang,
Konrad Dybcio
In-Reply-To: <20260119-topic-purwa_phy_shutup_warning-v1-1-997a692b31c6@oss.qualcomm.com>
On 19/01/2026 12:48, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Neither of the two Gen4x4 PHYs found on Purwa supports bifurcation.
> The PHY is however physically laid out as if it were to, since there
> are two separate ports (A/B).
>
> Split out a new if-then block to un-require the bifurcation register
> handle to squash this warning:
>
> purwa-iot-evk.dtb: phy@1bd4000 (qcom,x1p42100-qmp-gen4x4-pcie-phy): 'qcom,4ln-config-sel' is a required property
Warning does not exist in the kernel, so please do not reference it.
>
> Fixes: 2e1ffd4c1805 ("dt-bindings: phy: qcom,qmp-pcie: Add X1P42100 PCIe Gen4x4 PHY")
> Reported-by: Rob Herring <robh@kernel.org>
> Closes: https://lore.kernel.org/linux-arm-msm/176857775469.1631885.16133311938753588148.robh@kernel.org/
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> index 3a35120a77ec..431e8cb5df84 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> @@ -136,13 +136,22 @@ allOf:
> items:
> - description: port a
> - description: port b
> - required:
> - - qcom,4ln-config-sel
> else:
> properties:
> reg:
> maxItems: 1
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,sc8280xp-qmp-gen3x4-pcie-phy
> + - qcom,x1e80100-qmp-gen4x4-pcie-phy
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/5] phy: tegra: xusb: Fix ordering issue when switching roles on USB2 ports
From: Jon Hunter @ 2026-01-19 14:31 UTC (permalink / raw)
To: Diogo Ivo, Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <64c02ad1-9aac-488b-a846-fcb59ffd3f54@tecnico.ulisboa.pt>
On 15/01/2026 11:06, Diogo Ivo wrote:
> Hi Jonathan,
>
> On 1/13/26 11:56, Jon Hunter wrote:
>>
>> On 04/12/2025 21:27, Diogo Ivo wrote:
>>> The current implementation of USB2 role switching on Tegra relies on
>>> whichever the previous USB controller driver was using the PHY to first
>>> "yield" it back to USB_ROLE_NONE before the next controller configures
>>> it for the new role. However, no mechanism to guarantee this ordering
>>> was implemented, and currently, in the general case, the configuration
>>> functions tegra_xhci_id_work() and tegra_xudc_usb_role_sw_work() end up
>>> running in the same order regardless of the transition being HOST-
>>> >DEVICE
>>> or DEVICE->HOST, leading to one of these transitions ending up in a
>>> non-working state due to the new configuration being clobbered by the
>>> previous controller driver setting USB_ROLE_NONE after the fact.
>>>
>>> Fix this by introducing a helper that waits for the USB2 port’s current
>>> role to become USB_ROLE_NONE and add it in the configuration functions
>>> above before setting the role to either USB_ROLE_HOST or
>>> USB_ROLE_DEVICE. The specific parameters of the helper function are
>>> choices that seem reasonable in my testing and have no other basis.
>>
>> This is no information here about why 6 * 50/60us is deemed to be
>> sufficient? May be it is, but a comment would be nice.
>
> I missed this review comment and I'm not sure what you mean here. Do you
> want me to comment on the commit message on how I chose these
> parameters? If so it's as stated in the current message, I simply tested
> with these parameters and it worked and I really have no better basis
> for choosing them. If you mean adding a comment in the code I can do
> that for v2.
Yes please be explicit about how you arrived at these numbers. Ie. based
upon your testing on what platform, etc.
Thanks
Jon
--
nvpublic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 14/14] net: stmmac: report PCS configuration changes
From: Russell King (Oracle) @ 2026-01-19 14:27 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Maxime Chevallier, Maxime Coquelin, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <E1vhoT1-00000005H2a-3EnB@rmk-PC.armlinux.org.uk>
On Mon, Jan 19, 2026 at 12:34:47PM +0000, Russell King (Oracle) wrote:
> Report if/when qcom-ethqos changes the PCS configuration. With phylink
> now setting the PCS configuration, there should be no need for drivers
> to change this.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> index f9e7a7ed840b..6a1e30b10740 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> @@ -71,6 +71,7 @@ static inline void dwmac_ctrl_ane(void __iomem *ioaddr, u32 reg, bool ane,
> bool srgmi_ral)
> {
> u32 value = readl(ioaddr + GMAC_AN_CTRL(reg));
> + u32 old = value, diff;
>
> /* Enable and restart the Auto-Negotiation */
> if (ane)
> @@ -84,6 +85,20 @@ static inline void dwmac_ctrl_ane(void __iomem *ioaddr, u32 reg, bool ane,
> if (srgmi_ral)
> value |= GMAC_AN_CTRL_SGMRAL;
>
> + diff = old ^ value;
> + if (diff & ~GMAC_AN_CTRL_RAN) {
> + pr_warn("dwmac: PCS configuration changed from phylink by glue, please report: 0x%08x -> 0x%08x\n",
> + old & ~GMAC_AN_CTRL_RAN, value & ~GMAC_AN_CTRL_RAN);
> +#define REPORT_BIT(x) \
> + if (diff & GMAC_AN_CTRL_##x) \
> + pr_warn("dwmac: %8s %u -> %u\n", #x, \
> + !!(old & GMAC_AN_CTRL_##x), \
> + !!(value & GMAC_AN_CTRL_##x))
> + REPORT_BIT(ANE);
> + REPORT_BIT(SGMRAL);
> +#undef REPORT_BIT
I notice in patchwork, checkpatch doesn't like the "if" starting the in
the macro definition. While that would be true of definitions in kernel
header files which can be used anwhere, for such a simple limited usage
here, wrapping the thing in do { } while(0) is needless baggage, over-
complicates the code, and makes it less readable. So, IMHO, checkpatch
is wrong.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 03/14] phy: qcom-sgmii-eth: add .set_mode() and .validate() methods
From: Bartosz Golaszewski @ 2026-01-19 14:00 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Maxime Chevallier, Maxime Coquelin, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul, Andrew Lunn,
Heiner Kallweit
In-Reply-To: <E1vhoS7-00000005H1T-1dXt@rmk-PC.armlinux.org.uk>
On Mon, 19 Jan 2026 13:33:51 +0100, "Russell King (Oracle)"
<rmk+kernel@armlinux.org.uk> said:
> qcom-sgmii-eth is an Ethernet SerDes supporting only Ethernet mode
> using SGMII, 1000BASE-X and 2500BASE-X.
>
> Add an implementation of the .set_mode() method, which can be used
> instead of or as well as the .set_speed() method. The Ethernet
> interface modes mentioned above all have a fixed data rate, so
> setting the mode is sufficient to fully specify the operating
> parameters.
>
> Add an implementation of the .validate() method, which will be
> necessary to allow discovery of the SerDes capabilities for platform
> independent SerDes support in the stmmac network driver.
>
> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 02/14] net: stmmac: qcom-ethqos: convert to set_clk_tx_rate() method
From: Bartosz Golaszewski @ 2026-01-19 14:00 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Maxime Chevallier, Maxime Coquelin, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul, Andrew Lunn,
Heiner Kallweit
In-Reply-To: <E1vhoS2-00000005H1N-12dx@rmk-PC.armlinux.org.uk>
On Mon, 19 Jan 2026 13:33:46 +0100, "Russell King (Oracle)"
<rmk+kernel@armlinux.org.uk> said:
> Set the RGMII link clock using the set_clk_tx_rate() method rather than
> coding it into the .fix_mac_speed() method. This simplifies ethqos's
> ethqos_fix_mac_speed().
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 01/14] net: stmmac: qcom-ethqos: remove mac_base
From: Bartosz Golaszewski @ 2026-01-19 13:59 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Maxime Chevallier, Maxime Coquelin, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul, Andrew Lunn,
Heiner Kallweit
In-Reply-To: <E1vhoRx-00000005H1H-0YoL@rmk-PC.armlinux.org.uk>
On Mon, 19 Jan 2026 13:33:41 +0100, "Russell King (Oracle)"
<rmk+kernel@armlinux.org.uk> said:
> In commit 9b443e58a896 ("net: stmmac: qcom-ethqos: remove MAC_CTRL_REG
> modification"), ethqos->mac_base is only written, never read. Let's
> remove it.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index 0826a7bd32ff..869f924f3cde 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -100,7 +100,6 @@ struct ethqos_emac_driver_data {
> struct qcom_ethqos {
> struct platform_device *pdev;
> void __iomem *rgmii_base;
> - void __iomem *mac_base;
> int (*configure_func)(struct qcom_ethqos *ethqos, int speed);
>
> unsigned int link_clk_rate;
> @@ -772,8 +771,6 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> return dev_err_probe(dev, PTR_ERR(ethqos->rgmii_base),
> "Failed to map rgmii resource\n");
>
> - ethqos->mac_base = stmmac_res.addr;
> -
> data = of_device_get_match_data(dev);
> ethqos->por = data->por;
> ethqos->num_por = data->num_por;
> --
> 2.47.3
>
>
>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 11/14] net: stmmac: add struct stmmac_pcs_info
From: Maxime Chevallier @ 2026-01-19 13:23 UTC (permalink / raw)
To: Russell King (Oracle), Andrew Lunn, Heiner Kallweit
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Maxime Coquelin, Mohd Ayaan Anwar, Neil Armstrong,
netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <E1vhoSm-00000005H2F-1mve@rmk-PC.armlinux.org.uk>
On 19/01/2026 13:34, Russell King (Oracle) wrote:
> We need to describe one more register (offset and field bitmask) to
> the PCS code. Move the existing PCS offset and interrupt enable bits
> to a new struct and pass that in to stmmac_integrated_pcs_init().
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 10/14] net: stmmac: use integrated PCS for BASE-X modes
From: Maxime Chevallier @ 2026-01-19 13:20 UTC (permalink / raw)
To: Russell King (Oracle), Andrew Lunn, Heiner Kallweit
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Maxime Coquelin, Mohd Ayaan Anwar, Neil Armstrong,
netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <E1vhoSh-00000005H29-1LYk@rmk-PC.armlinux.org.uk>
On 19/01/2026 13:34, Russell King (Oracle) wrote:
> dwmac-qcom-ethqos supports SGMII and 2500BASE-X using the integrated
> PCS, so we need to expand the PCS support to include support for
> BASE-X modes.
>
> Add support to the prereset configuration to detect 2500BASE-X, and
> arrange for stmmac_mac_select_pcs() to return the integrated PCS if
> its supported_interfaces bitmap reports support for the interface mode.
>
> This results in priv->hw->pcs now being write-only, so remove it.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Dmitry Baryshkov @ 2026-01-19 12:55 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable, Abel Vesa
In-Reply-To: <20260119-klm_dpphy-v2-1-52252190940b@oss.qualcomm.com>
On Mon, Jan 19, 2026 at 08:37:20PM +0800, Yongxing Mou wrote:
> Currently, the LeMans/Monaco devices and their derivative platforms
> operate in DP mode rather than eDP mode. Per the PHY HPG, the Swing and
> Emphasis settings need to be corrected to the proper values.
No, they need to be configured dynamically. I wrote earlier that the
driver needs refactoring.
>
> This will help achieve successful link training on some dongles.
>
> Cc: stable@vger.kernel.org
> Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
> Changes in v2:
> - Separate the LDO change out.[Konrad][Dmitry]
> - Modify the commit message.[Dmitry]
> - Link to v1: https://lore.kernel.org/r/20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH net-next 14/14] net: stmmac: report PCS configuration changes
From: Russell King (Oracle) @ 2026-01-19 12:34 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Maxime Chevallier, Maxime Coquelin, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <aW4kakF3Ly7VaxN6@shell.armlinux.org.uk>
Report if/when qcom-ethqos changes the PCS configuration. With phylink
now setting the PCS configuration, there should be no need for drivers
to change this.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
index f9e7a7ed840b..6a1e30b10740 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
@@ -71,6 +71,7 @@ static inline void dwmac_ctrl_ane(void __iomem *ioaddr, u32 reg, bool ane,
bool srgmi_ral)
{
u32 value = readl(ioaddr + GMAC_AN_CTRL(reg));
+ u32 old = value, diff;
/* Enable and restart the Auto-Negotiation */
if (ane)
@@ -84,6 +85,20 @@ static inline void dwmac_ctrl_ane(void __iomem *ioaddr, u32 reg, bool ane,
if (srgmi_ral)
value |= GMAC_AN_CTRL_SGMRAL;
+ diff = old ^ value;
+ if (diff & ~GMAC_AN_CTRL_RAN) {
+ pr_warn("dwmac: PCS configuration changed from phylink by glue, please report: 0x%08x -> 0x%08x\n",
+ old & ~GMAC_AN_CTRL_RAN, value & ~GMAC_AN_CTRL_RAN);
+#define REPORT_BIT(x) \
+ if (diff & GMAC_AN_CTRL_##x) \
+ pr_warn("dwmac: %8s %u -> %u\n", #x, \
+ !!(old & GMAC_AN_CTRL_##x), \
+ !!(value & GMAC_AN_CTRL_##x))
+ REPORT_BIT(ANE);
+ REPORT_BIT(SGMRAL);
+#undef REPORT_BIT
+ }
+
writel(value, ioaddr + GMAC_AN_CTRL(reg));
}
#endif /* __STMMAC_PCS_H__ */
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next 13/14] net: stmmac: configure SGMII AN control according to phylink
From: Russell King (Oracle) @ 2026-01-19 12:34 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Maxime Chevallier, Maxime Coquelin, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <aW4kakF3Ly7VaxN6@shell.armlinux.org.uk>
Provide phylink with the integrated PCS autonegotiation capabilities,
and configure the PCS's AN settings according to phylink's requested
requirements.
This may cause regressions.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../net/ethernet/stmicro/stmmac/stmmac_pcs.c | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
index 9dd7e78cfbc4..0426f608ebdf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
@@ -65,7 +65,8 @@ static int dwmac_integrated_pcs_validate(struct phylink_pcs *pcs,
static unsigned int dwmac_integrated_pcs_inband_caps(struct phylink_pcs *pcs,
phy_interface_t interface)
{
- if (phy_interface_mode_is_8023z(interface))
+ if (phy_interface_mode_is_8023z(interface) ||
+ interface == PHY_INTERFACE_MODE_SGMII)
return LINK_INBAND_ENABLE | LINK_INBAND_DISABLE;
return 0;
@@ -162,8 +163,9 @@ static int dwmac_integrated_pcs_config(struct phylink_pcs *pcs,
bool permit_pause_to_mac)
{
struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
- bool changed = false, ane = true;
- u32 adv;
+ void __iomem *an_control = spcs->base + GMAC_AN_CTRL(0);
+ bool changed = false;
+ u32 adv, ctrl;
int ret;
if (spcs->interface != interface) {
@@ -180,12 +182,16 @@ static int dwmac_integrated_pcs_config(struct phylink_pcs *pcs,
if (readl(spcs->base + GMAC_ANE_ADV) != adv)
changed = true;
writel(adv, spcs->base + GMAC_ANE_ADV);
-
- ane = neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED;
}
- dwmac_ctrl_ane(spcs->base, 0, ane,
- spcs->priv->hw->reverse_sgmii_enable);
+ ctrl = readl(an_control) & ~(GMAC_AN_CTRL_ANE | GMAC_AN_CTRL_SGMRAL);
+ if (spcs->priv->hw->reverse_sgmii_enable)
+ ctrl |= GMAC_AN_CTRL_SGMRAL | GMAC_AN_CTRL_ANE;
+ else if (neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED)
+ ctrl |= GMAC_AN_CTRL_ANE;
+ else
+ ctrl |= GMAC_AN_CTRL_SGMRAL;
+ writel(ctrl, an_control);
return changed;
}
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox