* Re: [PATCH 0/4] Serdes: s32g: Add support for serdes subsystem
From: Vincent Guittot @ 2026-01-29 13:26 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: vkoul, neil.armstrong, krzk+dt, conor+dt, ciprianmarian.costea,
s32, p.zabel, ghennadi.procopciuc, Ionut.Vicovan, linux-phy,
devicetree, linux-kernel, linux-arm-kernel, netdev, Frank.li
In-Reply-To: <aXtUNxEmxcvuNj6J@shell.armlinux.org.uk>
On Thu, 29 Jan 2026 at 13:36, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> Please drop these addresses from future patch series:
Yes, will dorp for next version
>
> alexandru-catalin.ionita@nxp.com
> host nxp-com.mail.protection.outlook.com [2a01:111:f403:ca09::7]
> SMTP error from remote mail server after RCPT TO:<alexandru-catalin.ionita@n
> xp.com>:
> 550 5.4.1 Recipient address rejected: Access denied. For more information se
> e https://aka.ms/EXOSmtpErrors [AM4PEPF00027A62.eurprd04.prod.outlook.com 2026-0
> 1-29T12:31:01.197Z 08DE5971FB66165F]
> bogdan-gabriel.roman@nxp.com
> host nxp-com.mail.protection.outlook.com [2a01:111:f403:ca09::6]
> SMTP error from remote mail server after RCPT TO:<bogdan-gabriel.roman@nxp.c
> om>:
> 550 5.4.1 Recipient address rejected: Access denied. For more information se
> e https://aka.ms/EXOSmtpErrors [AM3PEPF0000A798.eurprd04.prod.outlook.com 2026-0
> 1-29T12:31:00.781Z 08DE596525364766]
>
> --
> 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 2/4] phy: s32g: Add serdes subsystem phy
From: Vincent Guittot @ 2026-01-29 13:36 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Simon Horman, vkoul, neil.armstrong, krzk+dt, conor+dt,
ciprianmarian.costea, s32, p.zabel, ghennadi.procopciuc,
bogdan-gabriel.roman, Ionut.Vicovan, alexandru-catalin.ionita,
linux-phy, devicetree, linux-kernel, linux-arm-kernel, netdev,
Frank.li
In-Reply-To: <aXtfVUb0eLwP4R28@shell.armlinux.org.uk>
On Thu, 29 Jan 2026 at 14:23, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Thu, Jan 29, 2026 at 02:01:13PM +0100, Vincent Guittot wrote:
> > yes, the usual pattern is :
> > - phy_set_mode_ext()
> > - then phy_power_on()
> > but I can add an additional check
>
> Please read Documentation/driver-api/phy/phy.rst section "Order of API
> calls" which suggests phy_set_mode_ext() after phy_power_on().
Fair enough.
That being said, all pcie drivers that use phy_set_mode_ext(), call
it before phy_power_on()
>
> Having different requirements for different SerDes PHYs quickly becomes
> annoying for users of the SerDes PHYs.
>
> E.g. I'm trying to add SerDes PHY support to stmmac, which is used
> across different platforms. Having all SerDes PHY drivers behave the
> same as far as their PHY API calls are concerned means that the whole
> point of having an abstracted interface is maintained. Otherwise, it's
> completely pointless.
>
> --
> 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 3/4] phy: s32g: Add serdes xpcs subsystem
From: Vincent Guittot @ 2026-01-29 13:45 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: vkoul, neil.armstrong, krzk+dt, conor+dt, ciprianmarian.costea,
s32, p.zabel, ghennadi.procopciuc, bogdan-gabriel.roman,
Ionut.Vicovan, alexandru-catalin.ionita, linux-phy, devicetree,
linux-kernel, linux-arm-kernel, netdev, Frank.li
In-Reply-To: <aXtS-Yan4HkXZlDD@shell.armlinux.org.uk>
On Thu, 29 Jan 2026 at 13:30, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Mon, Jan 26, 2026 at 10:21:58AM +0100, Vincent Guittot wrote:
> > s32g SoC family includes 2 serdes subsystems which are made of one PCIe
> > controller, 2 XPCS and one Phy. The Phy got 2 lanes that can be configure
> > to output PCIe lanes and/or SGMII.
> >
> > Add XPCS and SGMII support.
> >
> > Co-developed-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> > Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> > Co-developed-by: Alexandru-Catalin Ionita <alexandru-catalin.ionita@nxp.com>
> > Signed-off-by: Alexandru-Catalin Ionita <alexandru-catalin.ionita@nxp.com>
> > Co-developed-by: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> > Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> > Co-developed-by: Ionut Vicovan <Ionut.Vicovan@nxp.com>
> > Signed-off-by: Ionut Vicovan <Ionut.Vicovan@nxp.com>
> > Co-developed-by: Bogdan Roman <bogdan-gabriel.roman@nxp.com>
> > Signed-off-by: Bogdan Roman <bogdan-gabriel.roman@nxp.com>
> > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>
> I'm not doing a full review for this patch yet.
>
> > +/*
> > + * Note: This function should be compatible with phylink.
> > + * That means it should only modify link, duplex, speed
> > + * an_complete, pause.
> > + */
> > +static int s32g_xpcs_get_state(struct s32g_xpcs *xpcs,
> > + struct phylink_link_state *state)
> > +{
> > + struct device *dev = xpcs->dev;
> > + unsigned int mii_ctrl, val, ss;
> > + bool ss6, ss13, an_enabled, intr_en;
> > +
> > + mii_ctrl = s32g_xpcs_read(xpcs, SR_MII_CTRL);
> > + an_enabled = !!(mii_ctrl & AN_ENABLE);
> > + intr_en = !!(s32g_xpcs_read(xpcs, VR_MII_AN_CTRL) & MII_AN_INTR_EN);
> > +
> > + /* Check this important condition */
> > + if (an_enabled && !intr_en) {
> > + dev_err(dev, "Invalid SGMII AN config interrupt is disabled\n");
> > + return -EINVAL;
> > + }
>
> This isn't an interrupt handler. Phylink calls it from the state
> resolver, which _may_ be triggered by an interrupt handler, but will
> also be called at other times.
>
> > +
> > + if (an_enabled) {
> > + /* MLO_AN_INBAND */
> > + state->speed = SPEED_UNKNOWN;
> > + state->link = 0;
> > + state->duplex = DUPLEX_UNKNOWN;
> > + state->an_complete = 0;
> > + state->pause = MLO_PAUSE_NONE;
>
> Have you looked at the initial state that phylink sets up before
> calling the .pcs_get_state() method? See phylink_mac_pcs_get_state().
okay, I'm going to have a look
>
> speed/duplex/pause/an_complete are already setup like that for you if
> autoneg is enabled. link is the only member you'd need to touch.
Okay
>
> > + val = s32g_xpcs_read(xpcs, VR_MII_AN_INTR_STS);
> > +
> > + /* Interrupt is raised with each SGMII AN that is in cases
> > + * Link down - Every SGMII link timer expire
> > + * Link up - Once before link goes up
> > + * So either linkup or raised interrupt mean AN was completed
> > + */
> > + if ((val & CL37_ANCMPLT_INTR) || (val & CL37_ANSGM_STS_LINK)) {
> > + state->an_complete = 1;
> > + if (val & CL37_ANSGM_STS_LINK)
> > + state->link = 1;
> > + else
> > + return 0;
> > + if (val & CL37_ANSGM_STS_DUPLEX)
> > + state->duplex = DUPLEX_FULL;
> > + else
> > + state->duplex = DUPLEX_HALF;
> > + ss = FIELD_GET(CL37_ANSGM_STS_SPEED_MASK, val);
> > + } else {
> > + return 0;
> > + }
> > +
> > + } else {
> > + /* MLO_AN_FIXED, MLO_AN_PHY */
>
> This function won't be called in those modes, so this is a misleading
> comment. It can be called in MLO_AN_INBAND but when autoneg is disabled.
Okay
>
> > + val = s32g_xpcs_read(xpcs, SR_MII_STS);
> > + state->link = !!(val & LINK_STS);
> > + state->an_complete = 0;
> > + state->pause = MLO_PAUSE_NONE;
> > +
> > + if (mii_ctrl & DUPLEX_MODE)
> > + state->duplex = DUPLEX_FULL;
> > + else
> > + state->duplex = DUPLEX_HALF;
> > +
> > + /*
> > + * Build similar value as CL37_ANSGM_STS_SPEED with
> > + * SS6 and SS13 of SR_MII_CTRL:
> > + * - 0 for 10 Mbps
> > + * - 1 for 100 Mbps
> > + * - 2 for 1000 Mbps
> > + */
> > + ss6 = !!(mii_ctrl & SS6);
> > + ss13 = !!(mii_ctrl & SS13);
> > + ss = ss6 << 1 | ss13;
> > + }
> > +
> > + switch (ss) {
> > + case CL37_ANSGM_10MBPS:
> > + state->speed = SPEED_10;
> > + break;
> > + case CL37_ANSGM_100MBPS:
> > + state->speed = SPEED_100;
> > + break;
> > + case CL37_ANSGM_1000MBPS:
> > + state->speed = SPEED_1000;
> > + break;
> > + default:
> > + dev_err(dev, "Failed to interpret the value of SR_MII_CTRL\n");
> > + break;
> > + }
> > +
> > + val = s32g_xpcs_read(xpcs, VR_MII_DIG_CTRL1);
> > + if ((val & EN_2_5G_MODE) && state->speed == SPEED_1000)
> > + state->speed = SPEED_2500;
> > +
> > + /* Cover SGMII AN inability to distigunish between 1G and 2.5G */
> > + if ((val & EN_2_5G_MODE) &&
> > + state->speed != SPEED_2500 && an_enabled) {
> > + dev_err(dev, "Speed not supported in SGMII AN mode\n");
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int s32g_xpcs_config_an(struct s32g_xpcs *xpcs,
> > + const struct phylink_link_state state)
> > +{
> > + bool an_enabled = false;
> > +
> > + an_enabled = linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
> > + state.advertising);
> > + if (!an_enabled)
> > + return 0;
>
> Don't check the autoneg bit. This is the media-side autoneg, not
> the PCS autoneg.
Okay
>
> > +
> > + s32g_xpcs_write_bits(xpcs, VR_MII_DIG_CTRL1,
> > + CL37_TMR_OVRRIDE, CL37_TMR_OVRRIDE);
> > +
> > + s32g_xpcs_write_bits(xpcs, VR_MII_AN_CTRL,
> > + PCS_MODE_MASK | MII_AN_INTR_EN,
> > + FIELD_PREP(PCS_MODE_MASK, PCS_MODE_SGMII) | MII_AN_INTR_EN);
> > + /* Enable SGMII AN */
> > + s32g_xpcs_write_bits(xpcs, SR_MII_CTRL, AN_ENABLE, AN_ENABLE);
> > + /* Enable SGMII AUTO SW */
> > + s32g_xpcs_write_bits(xpcs, VR_MII_DIG_CTRL1,
> > + MAC_AUTO_SW, MAC_AUTO_SW);
> > +
> > + return 0;
> > +}
> > +
> > +static int s32g_xpcs_config(struct s32g_xpcs *xpcs,
> > + const struct phylink_link_state state)
> > +{
> > + struct device *dev = xpcs->dev;
> > + unsigned int val = 0, duplex = 0;
> > + int ret = 0;
> > + int speed = state.speed;
> > + bool an_enabled;
> > +
> > + /* Configure adaptive MII width */
> > + s32g_xpcs_write_bits(xpcs, VR_MII_AN_CTRL, MII_CTRL, 0);
> > +
> > + an_enabled = !!(s32g_xpcs_read(xpcs, SR_MII_CTRL) & AN_ENABLE);
> > +
> > + dev_dbg(dev, "xpcs_%d: speed=%u duplex=%d an=%d\n", xpcs->id,
> > + speed, state.duplex, an_enabled);
> > +
> > + if (an_enabled) {
> > + switch (speed) {
> > + case SPEED_10:
> > + case SPEED_100:
> > + case SPEED_1000:
> > + s32g_xpcs_write(xpcs, VR_MII_LINK_TIMER_CTRL, 0x2faf);
> > + break;
> > + case SPEED_2500:
> > + s32g_xpcs_write(xpcs, VR_MII_LINK_TIMER_CTRL, 0x7a1);
> > + s32g_xpcs_write_bits(xpcs, VR_MII_DIG_CTRL1, MAC_AUTO_SW, 0);
>
> Configuring the link timer _after_ the link has already come up looks
> completely wrong to me... this should be done when .pcs_config() detects
> that the PHY interface mode has changed.
Okay
>
> > + break;
> > + default:
> > + dev_err(dev, "Speed not recognized. Can't setup xpcs\n");
> > + return -EINVAL;
> > + }
> > +
> > + s32g_xpcs_write_bits(xpcs, SR_MII_CTRL, RESTART_AN, RESTART_AN);
>
> As this is called from the .pcs_link_up() method, expect the link to
> go bouncey bouncy bouncy if you restart AN _after_ the link has
> come up.
>
> > +
> > + ret = s32g_xpcs_wait_an_done(xpcs);
> > + if (ret)
> > + dev_warn(dev, "AN did not finish for XPCS%d", xpcs->id);
> > +
> > + /* Clear the AN CMPL intr */
> > + s32g_xpcs_write_bits(xpcs, VR_MII_AN_INTR_STS, CL37_ANCMPLT_INTR, 0);
> > + } else {
> > + s32g_xpcs_write_bits(xpcs, SR_MII_CTRL, AN_ENABLE, 0);
> > + s32g_xpcs_write_bits(xpcs, VR_MII_AN_CTRL, MII_AN_INTR_EN, 0);
> > +
> > + switch (speed) {
> > + case SPEED_10:
> > + break;
> > + case SPEED_100:
> > + val = SS13;
> > + break;
> > + case SPEED_1000:
> > + val = SS6;
> > + break;
> > + case SPEED_2500:
> > + val = SS6;
> > + break;
> > + default:
> > + dev_err(dev, "Speed not supported\n");
> > + break;
> > + }
> > +
> > + if (state.duplex == DUPLEX_FULL)
> > + duplex = DUPLEX_MODE;
> > +
> > + s32g_xpcs_write_bits(xpcs, SR_MII_CTRL, DUPLEX_MODE, duplex);
> > +
> > + if (speed == SPEED_2500) {
> > + ret = s32g_serdes_bifurcation_pll_transit(xpcs, XPCS_PLLB);
> > + if (ret)
> > + dev_err(dev, "Switch to PLLB failed\n");
> > + } else {
> > + ret = s32g_serdes_bifurcation_pll_transit(xpcs, XPCS_PLLA);
> > + if (ret)
> > + dev_err(dev, "Switch to PLLA failed\n");
> > + }
> > +
> > + s32g_xpcs_write_bits(xpcs, SR_MII_CTRL, SS6 | SS13, val);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * phylink_pcs_ops fops
>
> They are not "fops" which commonly refers to struct file_operations
>
> > + */
> > +
> > +static void s32cc_phylink_pcs_get_state(struct phylink_pcs *pcs, unsigned int neg_mode,
> > + struct phylink_link_state *state)
> > +{
> > + struct s32g_xpcs *xpcs = phylink_pcs_to_s32g_xpcs(pcs);
> > +
> > + s32g_xpcs_get_state(xpcs, state);
> > +}
>
> Seems to me a pointless wrapper.
okay
>
> > +
> > +static int s32cc_phylink_pcs_config(struct phylink_pcs *pcs,
> > + unsigned int neg_mode,
> > + phy_interface_t interface,
> > + const unsigned long *advertising,
> > + bool permit_pause_to_mac)
> > +{
> > + struct s32g_xpcs *xpcs = phylink_pcs_to_s32g_xpcs(pcs);
> > + struct phylink_link_state state = { 0 };
> > +
> > + if (!(neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED))
> > + return 0;
> > +
> > + linkmode_copy(state.advertising, advertising);
> > +
> > + return s32g_xpcs_config_an(xpcs, state);
>
> Given this is the only callsite for this function, and the only thing
> you pass is the advertising mask, why pass a struct phylink_link_state
> rather than the advertising mask?
fair enough
>
> > +}
> > +
> > +static void s32cc_phylink_pcs_restart_an(struct phylink_pcs *pcs)
> > +{
> > + /* Not yet */
> > +}
> > +
> > +static void s32cc_phylink_pcs_link_up(struct phylink_pcs *pcs,
> > + unsigned int neg_mode,
> > + phy_interface_t interface, int speed,
> > + int duplex)
> > +{
> > + struct s32g_xpcs *xpcs = phylink_pcs_to_s32g_xpcs(pcs);
> > + struct phylink_link_state state = { 0 };
> > +
> > + state.speed = speed;
> > + state.duplex = duplex;
> > + state.an_complete = false;
>
> an_complete is never an "input" to drivers. It's a state from PCS
> drivers back to phylink. Also, s32g_xpcs_config never looks at this.
>
> > +
> > + s32g_xpcs_config(xpcs, state);
>
> Again, the only things that this function uses are the speed and
> duplex, so why wrap them up into a struct?
will clean this
>
> > +}
> > +
> > +static const struct phylink_pcs_ops s32cc_phylink_pcs_ops = {
> > + .pcs_get_state = s32cc_phylink_pcs_get_state,
> > + .pcs_config = s32cc_phylink_pcs_config,
> > + .pcs_an_restart = s32cc_phylink_pcs_restart_an,
> > + .pcs_link_up = s32cc_phylink_pcs_link_up,
> > +};
>
> Please implement .pcs_inband_caps. As you don't support disabling
> inband for SGMII, that means you can't support MLO_AN_PHY mode
> reliably.
okay
>
> Also note that there are PHYs out there that do _not_ provide SGMII
> inband, which means if you have it enabled, and you're relying on it
> to complete, you won't be able to interface with those PHYs. There's
> such a PHY on a SFP module.
>
> If this driver is purely for a network PCS, then please locate it in
> drivers/net/pcs.
That was an one open point for me because the content of this file is
only called by
drivers/phy/freescale/phy-nxp-s32g-xpcs.c
So locating both in the same place looked reasonable but I can but
files in different dir
>
> I'm pretty sure there's other stuff I've missed as far as the phylink
> API goes, so please expect further review once you've addressed the
> comments above.
Thanks
>
> --
> 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 2/4] phy: s32g: Add serdes subsystem phy
From: Russell King (Oracle) @ 2026-01-29 13:51 UTC (permalink / raw)
To: Vincent Guittot, vkoul, neil.armstrong
Cc: Simon Horman, krzk+dt, conor+dt, ciprianmarian.costea, s32,
p.zabel, ghennadi.procopciuc, Ionut.Vicovan, linux-phy,
devicetree, linux-kernel, linux-arm-kernel, netdev, Frank.li
In-Reply-To: <CAKfTPtCiJcNOdoddZN5N1dKHXfUJBe0=zeWfZ5uENoXDvbMnpQ@mail.gmail.com>
On Thu, Jan 29, 2026 at 02:36:01PM +0100, Vincent Guittot wrote:
> On Thu, 29 Jan 2026 at 14:23, Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> >
> > On Thu, Jan 29, 2026 at 02:01:13PM +0100, Vincent Guittot wrote:
> > > yes, the usual pattern is :
> > > - phy_set_mode_ext()
> > > - then phy_power_on()
> > > but I can add an additional check
> >
> > Please read Documentation/driver-api/phy/phy.rst section "Order of API
> > calls" which suggests phy_set_mode_ext() after phy_power_on().
>
> Fair enough.
> That being said, all pcie drivers that use phy_set_mode_ext(), call
> it before phy_power_on()
It looks like many ethernet drivers do the same, so I think maybe the
generic PHY documentation is incorrect or misleading, or is expressing
a preference that almost no one follows. Something for the generic PHY
maintainers to look at and/or comment on.
--
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 2/4] phy: s32g: Add serdes subsystem phy
From: Vinod Koul @ 2026-01-29 14:30 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vincent Guittot, neil.armstrong, Simon Horman, krzk+dt, conor+dt,
ciprianmarian.costea, s32, p.zabel, ghennadi.procopciuc,
Ionut.Vicovan, linux-phy, devicetree, linux-kernel,
linux-arm-kernel, netdev, Frank.li
In-Reply-To: <aXtl6eQ8zD_olTdc@shell.armlinux.org.uk>
On 29-01-26, 13:51, Russell King (Oracle) wrote:
> On Thu, Jan 29, 2026 at 02:36:01PM +0100, Vincent Guittot wrote:
> > On Thu, 29 Jan 2026 at 14:23, Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Thu, Jan 29, 2026 at 02:01:13PM +0100, Vincent Guittot wrote:
> > > > yes, the usual pattern is :
> > > > - phy_set_mode_ext()
> > > > - then phy_power_on()
> > > > but I can add an additional check
> > >
> > > Please read Documentation/driver-api/phy/phy.rst section "Order of API
> > > calls" which suggests phy_set_mode_ext() after phy_power_on().
> >
> > Fair enough.
> > That being said, all pcie drivers that use phy_set_mode_ext(), call
> > it before phy_power_on()
>
> It looks like many ethernet drivers do the same, so I think maybe the
> generic PHY documentation is incorrect or misleading, or is expressing
> a preference that almost no one follows. Something for the generic PHY
> maintainers to look at and/or comment on.
I would feel it makes sense to configure the mode first and then power
the phy up. As commented above yes it looks like apart from one tegra
driver rest seem to do it this way.
Lets update the documentation
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/4] phy: s32g: Add serdes subsystem phy
From: Russell King (Oracle) @ 2026-01-29 14:36 UTC (permalink / raw)
To: Vinod Koul
Cc: Vincent Guittot, neil.armstrong, Simon Horman, krzk+dt, conor+dt,
ciprianmarian.costea, s32, p.zabel, ghennadi.procopciuc,
Ionut.Vicovan, linux-phy, devicetree, linux-kernel,
linux-arm-kernel, netdev, Frank.li
In-Reply-To: <aXtvDn_-pCuKPrnf@vaman>
On Thu, Jan 29, 2026 at 08:00:38PM +0530, Vinod Koul wrote:
> On 29-01-26, 13:51, Russell King (Oracle) wrote:
> > On Thu, Jan 29, 2026 at 02:36:01PM +0100, Vincent Guittot wrote:
> > > On Thu, 29 Jan 2026 at 14:23, Russell King (Oracle)
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > On Thu, Jan 29, 2026 at 02:01:13PM +0100, Vincent Guittot wrote:
> > > > > yes, the usual pattern is :
> > > > > - phy_set_mode_ext()
> > > > > - then phy_power_on()
> > > > > but I can add an additional check
> > > >
> > > > Please read Documentation/driver-api/phy/phy.rst section "Order of API
> > > > calls" which suggests phy_set_mode_ext() after phy_power_on().
> > >
> > > Fair enough.
> > > That being said, all pcie drivers that use phy_set_mode_ext(), call
> > > it before phy_power_on()
> >
> > It looks like many ethernet drivers do the same, so I think maybe the
> > generic PHY documentation is incorrect or misleading, or is expressing
> > a preference that almost no one follows. Something for the generic PHY
> > maintainers to look at and/or comment on.
>
> I would feel it makes sense to configure the mode first and then power
> the phy up. As commented above yes it looks like apart from one tegra
> driver rest seem to do it this way.
>
> Lets update the documentation
Please also indicate in the documentation whether changing the submode
of the serdes (particularly for ethernet) is permitted without doing a
phy_power_down()..phy_power_up() dance around the phy_set_mode_ext()
call.
Thanks.
--
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 v7 2/7] mux: Add helper functions for getting optional and selected mux-state
From: Ulf Hansson @ 2026-01-29 16:06 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, 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: <20260128-rz-sdio-mux-v7-2-92ebb6da0df8@solid-run.com>
On Wed, 28 Jan 2026 at 15:46, Josua Mayer <josua@solid-run.com> wrote:
>
> In-tree phy-can-transceiver driver has already implemented a local
> version of devm_mux_state_get_optional.
>
> The omap-i2c driver gets and selects an optional mux in its probe
> function without using any helper.
>
> Add new helper functions covering both aforementioned use-cases:
>
> - mux_control_get_optional:
> Get a mux-control if specified in dt, return NULL otherwise.
> - devm_mux_state_get_optional:
> Get a mux-state if specified in dt, return NULL otherwise.
> - devm_mux_state_get_selected:
> Get and select a mux-state specified in dt, return error otherwise.
> - devm_mux_state_get_optional_selected:
> Get and select a mux-state if specified in dt, return error or NULL.
>
> Existing mux_get helper function is changed to take an extra argument
> indicating whether the mux is optional.
> In this case no error is printed, and NULL returned in case of ENOENT.
>
> Calling code is adapted to handle NULL return case, and to pass optional
> argument as required.
>
> To support automatic deselect for _selected helper, a new structure is
> created storing an exit pointer similar to clock core which is called on
> release.
>
> To facilitate code sharing between optional/mandatory/selected helpers,
> a new internal helper function is added to handle quiet (optional) and
> verbose (mandatory) errors, as well as storing the correct callback for
> devm release: __devm_mux_state_get
>
> Due to this structure devm_mux_state_get_*_selected can no longer print
> a useful error message when select fails. Instead callers should print
> errors where needed.
>
> Commit e153fdea9db04 ("phy: can-transceiver: Re-instate "mux-states"
> property presence check") noted that "mux_get() always prints an error
> message in case of an error, including when the property is not present,
> confusing the user."
>
> The first error message covers the case that a mux name is not matched
> in dt. The second error message is based on of_parse_phandle_with_args
> return value.
>
> In optional case no error is printed and NULL is returned.
> This ensures that the new helper functions will not confuse the user
> either.
>
> With the addition of optional helper functions it became clear that
> drivers should compile and link even if CONFIG_MULTIPLEXER was not enabled.
> Add stubs for all symbols exported by mux core.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> drivers/mux/core.c | 178 ++++++++++++++++++++++++++++++++++++-------
> include/linux/mux/consumer.h | 108 +++++++++++++++++++++++++-
> 2 files changed, 253 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/mux/core.c b/drivers/mux/core.c
> index a3840fe0995f..b01ec126caaf 100644
> --- a/drivers/mux/core.c
> +++ b/drivers/mux/core.c
[...]
> static void devm_mux_state_release(struct device *dev, void *res)
> {
> - struct mux_state *mstate = *(struct mux_state **)res;
> + struct devm_mux_state_state *devm_state = res;
>
> - mux_state_put(mstate);
> + if (devm_state->exit)
> + devm_state->exit(devm_state->mstate);
> +
> + mux_state_put(devm_state->mstate);
> }
>
> /**
> - * devm_mux_state_get() - Get the mux-state for a device, with resource
> - * management.
> - * @dev: The device that needs a mux-control.
> - * @mux_name: The name identifying the mux-control.
> + * __devm_mux_state_get() - Get the optional mux-state for a device,
> + * with resource management.
> + * @dev: The device that needs a mux-state.
> + * @mux_name: The name identifying the mux-state.
> + * @optional: Whether to return NULL and silence errors when mux doesn't exist.
> + * @init: Optional function pointer for mux-state object initialisation.
> + * @exit: Optional function pointer for mux-state object cleanup on release.
> *
> * Return: Pointer to the mux-state, or an ERR_PTR with a negative errno.
> */
> -struct mux_state *devm_mux_state_get(struct device *dev,
> - const char *mux_name)
> +static struct mux_state *__devm_mux_state_get(struct device *dev, const char *mux_name,
> + bool optional,
> + int (*init)(struct mux_state *mstate),
> + int (*exit)(struct mux_state *mstate))
> {
> - struct mux_state **ptr, *mstate;
> + struct devm_mux_state_state *devm_state;
> + struct mux_state *mstate;
> + int ret;
>
> - ptr = devres_alloc(devm_mux_state_release, sizeof(*ptr), GFP_KERNEL);
> - if (!ptr)
> + devm_state = devres_alloc(devm_mux_state_release, sizeof(*devm_state), GFP_KERNEL);
> + if (!devm_state)
> return ERR_PTR(-ENOMEM);
>
> - mstate = mux_state_get(dev, mux_name);
> - if (IS_ERR(mstate)) {
> - devres_free(ptr);
> - return mstate;
> + mstate = mux_state_get(dev, mux_name, optional);
> + if (IS_ERR_OR_NULL(mstate)) {
> + ret = PTR_ERR(mstate);
Should this be PTR_ERR_OR_ZERO?
> + goto err_mux_state_get;
> }
>
> - *ptr = mstate;
> - devres_add(dev, ptr);
> + if (init) {
> + ret = init(mstate);
> + if (ret)
> + goto err_mux_state_init;
> + }
> +
> + devm_state->mstate = mstate;
> + devm_state->exit = exit;
> + devres_add(dev, devm_state);
>
> return mstate;
> +
> +err_mux_state_init:
> + mux_state_put(mstate);
> +err_mux_state_get:
> + devres_free(devm_state);
> + return ERR_PTR(ret);
If PTR_ERR_OR_ZERO is used above as I suggested, ret may be 0 here.
Then it is probably clearer to add a check if (!ret) and return NULL
explicitly for that case, I think.
[...]
Kind regards
Uffe
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux
From: Ulf Hansson @ 2026-01-29 16:15 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, 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: <20260128-rz-sdio-mux-v7-0-92ebb6da0df8@solid-run.com>
On Wed, 28 Jan 2026 at 15:46, Josua Mayer <josua@solid-run.com> wrote:
>
> Some Renesas SoC based boards mux SD and eMMC on a single sdio
> controller, exposing user control by dip switch and software control by
> gpio.
>
> Purpose is to simplify development and provisioning by selecting boot
> media at power-on, and again before starting linux.
>
> Add binding and driver support for linking a (gpio) mux to renesas sdio
> controller.
>
> Introduce generic helper functions for getting managed and selected
> mux-state objects, and switch i2c-omap and phy-can-transceiver drivers.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
This series needs to go together in some way. If you like, I can
funnel it via my mmc tree, unless someone (Wolfram for the i2c part?)
has objections to this of course.
Kind regards
Uffe
> ---
> Changes in v7:
> - picked up reviewed-tags
> - fix Kconfig change to add the missing prompt for CONFIG_MULTIPLEXER,
> and enable it by default when COMPILE_TEST is set.
> (Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>)
> - fix another kernel build robot warning: undocumented C struct member
> - Link to v6: https://lore.kernel.org/r/20260121-rz-sdio-mux-v6-0-38aa39527928@solid-run.com
>
> Changes in v6:
> - replaced /* with /** for devm_mux_state_state function description.
> - collected review tags.
> - fixed checkpatch warnings (space-before-tab, void-return).
> (Reported-by: Geert Uytterhoeven)
> - fixed use-after-free in mux core mux_get function.
> (Reported-by: Geert Uytterhoeven)
> - fix mux helper error path uninitialised return code variable.
> (Reported-by: kernel test robot <lkp@intel.com>)
> - Link to v5: https://lore.kernel.org/r/20260118-rz-sdio-mux-v5-0-3c37e8872683@solid-run.com
>
> Changes in v5:
> - implemented automatic mux deselect for devm_*_selected.
> (Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>)
> - because of semantic changes I dropped reviewed and acks from omap-i2c
> patch (Andreas Kemnade / Wolfram Sang).
> - fix invalid return value in void function for mux helper stubs
> (Reported-by: kernel test robot <lkp@intel.com>)
> - Link to v4: https://lore.kernel.org/r/20251229-rz-sdio-mux-v4-0-a023e55758fe@solid-run.com
>
> Changes in v4:
> - added MULTIPLEXER Kconfig help text.
> - removed "select MULTIPLEXER" from renesas sdhi Kconfig, as it is
> not required for all devices using this driver.
> - added stubs for all symbols exported by mux core.
> (Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>)
> - refactored mux core logic to silence ENOENT errors only on optional
> code paths, keeping error printing unchanged otherwise.
> (Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>)
> - picked up various reviewed- and acked-by tags
> - Link to v3: https://lore.kernel.org/r/20251210-rz-sdio-mux-v3-0-ca628db56d60@solid-run.com
>
> Changes in v3:
> - updated omap-i2c and phy-can-transceiver to use new helpers.
> - created generic helper functions for getting managed optional mux-state.
> (Reported-by: Rob Herring <robh@kernel.org>)
> - picked up binding ack by Rob Herring.
> - replaced use of "SDIO" with "SD/SDIO/eMMC" in binding document and
> commit descriptions.
> (Reported-by: Ulf Hansson <ulf.hansson@linaro.org>)
> - Link to v2: https://lore.kernel.org/r/20251201-rz-sdio-mux-v2-0-bcb581b88dd7@solid-run.com
>
> Changes in v2:
> - dropped mux-controller node from dt binding example
> (Reported-by: Conor Dooley <conor@kernel.org>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>)
> - Link to v1: https://lore.kernel.org/r/20251128-rz-sdio-mux-v1-0-1ede318d160f@solid-run.com
>
> ---
> Josua Mayer (7):
> phy: can-transceiver: rename temporary helper function to avoid conflict
> mux: Add helper functions for getting optional and selected mux-state
> mux: add help text for MULTIPLEXER config option
> phy: can-transceiver: drop temporary helper getting optional mux-state
> i2c: omap: switch to new generic helper for getting selected mux-state
> dt-bindings: mmc: renesas,sdhi: Add mux-states property
> mmc: host: renesas_sdhi_core: support selecting an optional mux
>
> .../devicetree/bindings/mmc/renesas,sdhi.yaml | 6 +
> drivers/i2c/busses/i2c-omap.c | 24 +--
> drivers/mmc/host/renesas_sdhi_core.c | 6 +
> drivers/mux/Kconfig | 8 +-
> drivers/mux/core.c | 178 +++++++++++++++++----
> drivers/phy/phy-can-transceiver.c | 10 --
> include/linux/mux/consumer.h | 108 ++++++++++++-
> 7 files changed, 277 insertions(+), 63 deletions(-)
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251128-rz-sdio-mux-acc5137f1618
>
> Best regards,
> --
> Josua Mayer <josua@solid-run.com>
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/4] phy: s32g: Add serdes xpcs subsystem
From: Simon Horman @ 2026-01-29 16:20 UTC (permalink / raw)
To: Vincent Guittot
Cc: vkoul, neil.armstrong, krzk+dt, conor+dt, ciprianmarian.costea,
s32, p.zabel, linux, ghennadi.procopciuc, bogdan-gabriel.roman,
Ionut.Vicovan, alexandru-catalin.ionita, linux-phy, devicetree,
linux-kernel, linux-arm-kernel, netdev, Frank.li
In-Reply-To: <CAKfTPtB8xDB8qYUZwGnH+h94ww3+gSyOuZ+RL+zOh5tYGuu_HQ@mail.gmail.com>
On Thu, Jan 29, 2026 at 02:24:15PM +0100, Vincent Guittot wrote:
> On Thu, 29 Jan 2026 at 12:59, Simon Horman <horms@kernel.org> wrote:
> >
> > On Mon, Jan 26, 2026 at 10:21:58AM +0100, Vincent Guittot wrote:
> >
> > ...
> >
> > > diff --git a/drivers/phy/freescale/phy-nxp-s32g-serdes.c b/drivers/phy/freescale/phy-nxp-s32g-serdes.c
> >
> > ...
> >
> > > +static void s32g_serdes_prepare_pma_mode5(struct s32g_serdes *serdes)
> > > +{
> > > + u32 val;
> > > + /* Configure TX_VBOOST_LVL and TX_TERM_CTRL */
> > > + val = readl(serdes->ctrl.ss_base + S32G_PCIE_PHY_EXT_MISC_CTRL_2);
> > > + val &= ~(EXT_TX_VBOOST_LVL_MASK | EXT_TX_TERM_CTRL_MASK);
> > > + val |= FIELD_PREP(EXT_TX_VBOOST_LVL_MASK, 0x3) |
> > > + FIELD_PREP(EXT_TX_TERM_CTRL_MASK, 0x4);
> > > + writel(val, serdes->ctrl.ss_base + S32G_PCIE_PHY_EXT_MISC_CTRL_2);
> >
> > This is part of an AI Generated review.
> > I have looked over it and I think it warrants investigation.
> > For information on how to reproduce locally, as I did, please see [1].
> >
> > The entire s32g_serdes_prepare_pma_mode5() function is ~70 lines of
> > magic numbers with zero explanation. These appear to be
> > hardware-specific PLL/PHY tuning parameters for 2.5G mode.
>
> Unfortunately there is no additional information in the reference
> manual other than
> *step 4:
> - Write 3h to EXT_TX_VBOOST_LVL.
> - Write 4h to EXT_TX_TERM_CTRL
Understood. Sometimes you have the play the hand you're dealt.
>
> >
> > Please consider using #defines, to give values names.
> >
> > ...
> >
> > > +static int s32g_serdes_init_clks(struct s32g_serdes *serdes)
> > > +{
> > > + struct s32g_serdes_ctrl *ctrl = &serdes->ctrl;
> > > + struct s32g_xpcs_ctrl *xpcs = &serdes->xpcs;
> > > + int ret, order[2], xpcs_id;
> > > + size_t i;
> > > +
> > > + switch (ctrl->ss_mode) {
> > > + case 0:
> > > + return 0;
> > > + case 1:
> > > + order[0] = 0;
> > > + order[1] = XPCS_DISABLED;
> > > + break;
> > > + case 2:
> > > + case 5:
> > > + order[0] = 1;
> > > + order[1] = XPCS_DISABLED;
> > > + break;
> > > + case 3:
> > > + order[0] = 1;
> > > + order[1] = 0;
> > > + break;
> > > + case 4:
> > > + order[0] = 0;
> > > + order[1] = 1;
> > > + break;
> > > + default:
> > > + return -EINVAL;
> >
> > AI review also flags that s32g_serdes_get_ctrl_resources() ensures that
> > ss_mode is <= 5. So this check is unnecessary.
>
> okay but providing a default seems a good practice
Yeah, I was of two minds about forwarding on this part of the report.
...
> > AI review also flags that s32g_xpcs_regmap_reg_read and
> > s32g_xpcs_regmap_reg_write do not protect against concurrent access.
>
> but regmap framework should
If it does, then I agree there is no problem here.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: phy: qcom-edp: Add reference clock for sa8775p eDP PHY
From: Rob Herring (Arm) @ 2026-01-29 16:53 UTC (permalink / raw)
To: Ritesh Kumar
Cc: quic_mahap, robin.clark, mripard, krzk+dt, dri-devel,
martin.petersen, tzimmermann, lumag, simona, linux-kernel,
maarten.lankhorst, sean, kishon, James.Bottomley, marijn.suijten,
devicetree, andersson, cros-qcom-dts-watchers, linux-scsi, vkoul,
mani, linux-arm-msm, linux-phy, quic_vproddut, abhinav.kumar,
conor+dt, konradybcio, freedreno, airlied
In-Reply-To: <20260128114853.2543416-2-quic_riteshk@quicinc.com>
On Wed, 28 Jan 2026 17:18:49 +0530, Ritesh Kumar wrote:
> The initial sa8775p eDP PHY binding contribution missed adding support for
> voting on the eDP reference clock. This went unnoticed because the UFS PHY
> driver happened to enable the same clock.
>
> After commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
> calls"), the eDP reference clock is no longer kept enabled, which results
> in the following PHY power-on failure:
>
> phy phy-aec2a00.phy.10: phy poweron failed --> -110
>
> To fix this, explicit voting for the eDP reference clock is required.
> This patch adds the eDP reference clock for sa8775p eDP PHY and updates
> the corresponding example node.
>
> Signed-off-by: Ritesh Kumar <quic_riteshk@quicinc.com>
> ---
> .../devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml | 6 ++++--
> Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml | 1 +
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 2/7] mux: Add helper functions for getting optional and selected mux-state
From: Geert Uytterhoeven @ 2026-01-29 16:13 UTC (permalink / raw)
To: Ulf Hansson
Cc: Josua Mayer, 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, 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, Dan Carpenter
In-Reply-To: <CAPDyKFrBuL+747QUJJUejtcvjm0V7Lt=vHwjvcMdCt_h4=sFwg@mail.gmail.com>
On Thu, 29 Jan 2026 at 17:06, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On Wed, 28 Jan 2026 at 15:46, Josua Mayer <josua@solid-run.com> wrote:
> >
> > In-tree phy-can-transceiver driver has already implemented a local
> > version of devm_mux_state_get_optional.
> >
> > The omap-i2c driver gets and selects an optional mux in its probe
> > function without using any helper.
> >
> > Add new helper functions covering both aforementioned use-cases:
> >
> > - mux_control_get_optional:
> > Get a mux-control if specified in dt, return NULL otherwise.
> > - devm_mux_state_get_optional:
> > Get a mux-state if specified in dt, return NULL otherwise.
> > - devm_mux_state_get_selected:
> > Get and select a mux-state specified in dt, return error otherwise.
> > - devm_mux_state_get_optional_selected:
> > Get and select a mux-state if specified in dt, return error or NULL.
> >
> > Existing mux_get helper function is changed to take an extra argument
> > indicating whether the mux is optional.
> > In this case no error is printed, and NULL returned in case of ENOENT.
> >
> > Calling code is adapted to handle NULL return case, and to pass optional
> > argument as required.
> >
> > To support automatic deselect for _selected helper, a new structure is
> > created storing an exit pointer similar to clock core which is called on
> > release.
> >
> > To facilitate code sharing between optional/mandatory/selected helpers,
> > a new internal helper function is added to handle quiet (optional) and
> > verbose (mandatory) errors, as well as storing the correct callback for
> > devm release: __devm_mux_state_get
> >
> > Due to this structure devm_mux_state_get_*_selected can no longer print
> > a useful error message when select fails. Instead callers should print
> > errors where needed.
> >
> > Commit e153fdea9db04 ("phy: can-transceiver: Re-instate "mux-states"
> > property presence check") noted that "mux_get() always prints an error
> > message in case of an error, including when the property is not present,
> > confusing the user."
> >
> > The first error message covers the case that a mux name is not matched
> > in dt. The second error message is based on of_parse_phandle_with_args
> > return value.
> >
> > In optional case no error is printed and NULL is returned.
> > This ensures that the new helper functions will not confuse the user
> > either.
> >
> > With the addition of optional helper functions it became clear that
> > drivers should compile and link even if CONFIG_MULTIPLEXER was not enabled.
> > Add stubs for all symbols exported by mux core.
> >
> > Signed-off-by: Josua Mayer <josua@solid-run.com>
> > ---
> > drivers/mux/core.c | 178 ++++++++++++++++++++++++++++++++++++-------
> > include/linux/mux/consumer.h | 108 +++++++++++++++++++++++++-
> > 2 files changed, 253 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/mux/core.c b/drivers/mux/core.c
> > index a3840fe0995f..b01ec126caaf 100644
> > --- a/drivers/mux/core.c
> > +++ b/drivers/mux/core.c
>
> [...]
>
> > static void devm_mux_state_release(struct device *dev, void *res)
> > {
> > - struct mux_state *mstate = *(struct mux_state **)res;
> > + struct devm_mux_state_state *devm_state = res;
> >
> > - mux_state_put(mstate);
> > + if (devm_state->exit)
> > + devm_state->exit(devm_state->mstate);
> > +
> > + mux_state_put(devm_state->mstate);
> > }
> >
> > /**
> > - * devm_mux_state_get() - Get the mux-state for a device, with resource
> > - * management.
> > - * @dev: The device that needs a mux-control.
> > - * @mux_name: The name identifying the mux-control.
> > + * __devm_mux_state_get() - Get the optional mux-state for a device,
> > + * with resource management.
> > + * @dev: The device that needs a mux-state.
> > + * @mux_name: The name identifying the mux-state.
> > + * @optional: Whether to return NULL and silence errors when mux doesn't exist.
> > + * @init: Optional function pointer for mux-state object initialisation.
> > + * @exit: Optional function pointer for mux-state object cleanup on release.
> > *
> > * Return: Pointer to the mux-state, or an ERR_PTR with a negative errno.
> > */
> > -struct mux_state *devm_mux_state_get(struct device *dev,
> > - const char *mux_name)
> > +static struct mux_state *__devm_mux_state_get(struct device *dev, const char *mux_name,
> > + bool optional,
> > + int (*init)(struct mux_state *mstate),
> > + int (*exit)(struct mux_state *mstate))
> > {
> > - struct mux_state **ptr, *mstate;
> > + struct devm_mux_state_state *devm_state;
> > + struct mux_state *mstate;
> > + int ret;
> >
> > - ptr = devres_alloc(devm_mux_state_release, sizeof(*ptr), GFP_KERNEL);
> > - if (!ptr)
> > + devm_state = devres_alloc(devm_mux_state_release, sizeof(*devm_state), GFP_KERNEL);
> > + if (!devm_state)
> > return ERR_PTR(-ENOMEM);
> >
> > - mstate = mux_state_get(dev, mux_name);
> > - if (IS_ERR(mstate)) {
> > - devres_free(ptr);
> > - return mstate;
> > + mstate = mux_state_get(dev, mux_name, optional);
> > + if (IS_ERR_OR_NULL(mstate)) {
> > + ret = PTR_ERR(mstate);
>
> Should this be PTR_ERR_OR_ZERO?
"mux_state_get() never returns NULL"
https://lore.kernel.org/202601221036.J0kR78Uw-lkp@intel.com
>
> > + goto err_mux_state_get;
> > }
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 v7 0/7] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux
From: Wolfram Sang @ 2026-01-29 18:14 UTC (permalink / raw)
To: Ulf Hansson
Cc: Josua Mayer, 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, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, 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: <CAPDyKFp9StNf1eLaSETxC72=7sXYBmGFmHnv0CXysUGcYma5VA@mail.gmail.com>
On Thu, Jan 29, 2026 at 05:15:06PM +0100, Ulf Hansson wrote:
> On Wed, 28 Jan 2026 at 15:46, Josua Mayer <josua@solid-run.com> wrote:
> >
> > Some Renesas SoC based boards mux SD and eMMC on a single sdio
> > controller, exposing user control by dip switch and software control by
> > gpio.
> >
> > Purpose is to simplify development and provisioning by selecting boot
> > media at power-on, and again before starting linux.
> >
> > Add binding and driver support for linking a (gpio) mux to renesas sdio
> > controller.
> >
> > Introduce generic helper functions for getting managed and selected
> > mux-state objects, and switch i2c-omap and phy-can-transceiver drivers.
> >
> > Signed-off-by: Josua Mayer <josua@solid-run.com>
>
> This series needs to go together in some way. If you like, I can
> funnel it via my mmc tree, unless someone (Wolfram for the i2c part?)
> has objections to this of course.
No objections, I even acked the I2C patch in a previous series. Since
the series changed because of some of my suggestions, I want to have
another look at it. But yes, your tree sounds very reasonable.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Russell King (Oracle) @ 2026-01-29 22:00 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Konrad Dybcio,
linux-arm-kernel, linux-arm-msm, linux-phy, linux-stm32,
Maxime Coquelin, Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <aXsLyb+x76/WaXcs@oss.qualcomm.com>
On Thu, Jan 29, 2026 at 12:57:05PM +0530, Mohd Ayaan Anwar wrote:
> I was thinking about the "good" sequence (i.e., the current net-next
> tree):
> -> phylink_up
> -> mac_link_up
> -> fix_mac_speed
> -> SerDes configured via phy_set_speed
> -> stmmac_pcs_ctrl_ane(priv, enable/disable, 0)
>
> Please let me know if you want me to try any other experiments.
> Maybe I need to do some more testing after playing around with the
> sequence followed by this series?
Given discussion elsewhere, it seems that the generic PHY maintainers
have come to the conclusion (at my request) that the documentation is
incorrect and needs to be changed:
Order of API calls
==================
The general order of calls should be::
[devm_][of_]phy_get()
phy_init()
phy_power_on()
[phy_set_mode[_ext]()]
...
phy_power_off()
phy_exit()
[[of_]phy_put()]
Essentially, most users of generic PHY do not follow this, but call
phy_set_mode[_ext]() before phy_power_on().
This will have implications for this patch series, particularly the
serdes related changes, and will make the update to qcom-sgmii-eth
more complex (as its current phy_power_on() implementation does
very little and isn't the reverse of phy_power_off().)
In the mean time, please test patch 2 to see whether that can be
merged.
I'm going to re-order some of the patches in this series to see what
else can be merged without depending on that and without affecting
dwmac-qcom-ethqos, and thus shrinking this series.
--
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 v7 2/7] mux: Add helper functions for getting optional and selected mux-state
From: Ulf Hansson @ 2026-01-30 10:28 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Josua Mayer, 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, 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, Dan Carpenter
In-Reply-To: <CAMuHMdXgLR9yeLa5JKNdAOtNEirJ8263bmn1zRNAnKnmf8F-Sg@mail.gmail.com>
On Thu, 29 Jan 2026 at 18:46, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Thu, 29 Jan 2026 at 17:06, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On Wed, 28 Jan 2026 at 15:46, Josua Mayer <josua@solid-run.com> wrote:
> > >
> > > In-tree phy-can-transceiver driver has already implemented a local
> > > version of devm_mux_state_get_optional.
> > >
> > > The omap-i2c driver gets and selects an optional mux in its probe
> > > function without using any helper.
> > >
> > > Add new helper functions covering both aforementioned use-cases:
> > >
> > > - mux_control_get_optional:
> > > Get a mux-control if specified in dt, return NULL otherwise.
> > > - devm_mux_state_get_optional:
> > > Get a mux-state if specified in dt, return NULL otherwise.
> > > - devm_mux_state_get_selected:
> > > Get and select a mux-state specified in dt, return error otherwise.
> > > - devm_mux_state_get_optional_selected:
> > > Get and select a mux-state if specified in dt, return error or NULL.
> > >
> > > Existing mux_get helper function is changed to take an extra argument
> > > indicating whether the mux is optional.
> > > In this case no error is printed, and NULL returned in case of ENOENT.
> > >
> > > Calling code is adapted to handle NULL return case, and to pass optional
> > > argument as required.
> > >
> > > To support automatic deselect for _selected helper, a new structure is
> > > created storing an exit pointer similar to clock core which is called on
> > > release.
> > >
> > > To facilitate code sharing between optional/mandatory/selected helpers,
> > > a new internal helper function is added to handle quiet (optional) and
> > > verbose (mandatory) errors, as well as storing the correct callback for
> > > devm release: __devm_mux_state_get
> > >
> > > Due to this structure devm_mux_state_get_*_selected can no longer print
> > > a useful error message when select fails. Instead callers should print
> > > errors where needed.
> > >
> > > Commit e153fdea9db04 ("phy: can-transceiver: Re-instate "mux-states"
> > > property presence check") noted that "mux_get() always prints an error
> > > message in case of an error, including when the property is not present,
> > > confusing the user."
> > >
> > > The first error message covers the case that a mux name is not matched
> > > in dt. The second error message is based on of_parse_phandle_with_args
> > > return value.
> > >
> > > In optional case no error is printed and NULL is returned.
> > > This ensures that the new helper functions will not confuse the user
> > > either.
> > >
> > > With the addition of optional helper functions it became clear that
> > > drivers should compile and link even if CONFIG_MULTIPLEXER was not enabled.
> > > Add stubs for all symbols exported by mux core.
> > >
> > > Signed-off-by: Josua Mayer <josua@solid-run.com>
> > > ---
> > > drivers/mux/core.c | 178 ++++++++++++++++++++++++++++++++++++-------
> > > include/linux/mux/consumer.h | 108 +++++++++++++++++++++++++-
> > > 2 files changed, 253 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/drivers/mux/core.c b/drivers/mux/core.c
> > > index a3840fe0995f..b01ec126caaf 100644
> > > --- a/drivers/mux/core.c
> > > +++ b/drivers/mux/core.c
> >
> > [...]
> >
> > > static void devm_mux_state_release(struct device *dev, void *res)
> > > {
> > > - struct mux_state *mstate = *(struct mux_state **)res;
> > > + struct devm_mux_state_state *devm_state = res;
> > >
> > > - mux_state_put(mstate);
> > > + if (devm_state->exit)
> > > + devm_state->exit(devm_state->mstate);
> > > +
> > > + mux_state_put(devm_state->mstate);
> > > }
> > >
> > > /**
> > > - * devm_mux_state_get() - Get the mux-state for a device, with resource
> > > - * management.
> > > - * @dev: The device that needs a mux-control.
> > > - * @mux_name: The name identifying the mux-control.
> > > + * __devm_mux_state_get() - Get the optional mux-state for a device,
> > > + * with resource management.
> > > + * @dev: The device that needs a mux-state.
> > > + * @mux_name: The name identifying the mux-state.
> > > + * @optional: Whether to return NULL and silence errors when mux doesn't exist.
> > > + * @init: Optional function pointer for mux-state object initialisation.
> > > + * @exit: Optional function pointer for mux-state object cleanup on release.
> > > *
> > > * Return: Pointer to the mux-state, or an ERR_PTR with a negative errno.
> > > */
> > > -struct mux_state *devm_mux_state_get(struct device *dev,
> > > - const char *mux_name)
> > > +static struct mux_state *__devm_mux_state_get(struct device *dev, const char *mux_name,
> > > + bool optional,
> > > + int (*init)(struct mux_state *mstate),
> > > + int (*exit)(struct mux_state *mstate))
> > > {
> > > - struct mux_state **ptr, *mstate;
> > > + struct devm_mux_state_state *devm_state;
> > > + struct mux_state *mstate;
> > > + int ret;
> > >
> > > - ptr = devres_alloc(devm_mux_state_release, sizeof(*ptr), GFP_KERNEL);
> > > - if (!ptr)
> > > + devm_state = devres_alloc(devm_mux_state_release, sizeof(*devm_state), GFP_KERNEL);
> > > + if (!devm_state)
> > > return ERR_PTR(-ENOMEM);
> > >
> > > - mstate = mux_state_get(dev, mux_name);
> > > - if (IS_ERR(mstate)) {
> > > - devres_free(ptr);
> > > - return mstate;
> > > + mstate = mux_state_get(dev, mux_name, optional);
> > > + if (IS_ERR_OR_NULL(mstate)) {
> > > + ret = PTR_ERR(mstate);
> >
> > Should this be PTR_ERR_OR_ZERO?
>
> "mux_state_get() never returns NULL"
> https://lore.kernel.org/202601221036.J0kR78Uw-lkp@intel.com
By looking at the code in mux_state_get() and mux_get() that $subject
patch changes, it intends to add a "bool optional" as in-parameter. If
it's set, it looks like the intent is to allow returning NULL, which
makes sense to me.
Anyway, there seems to be some additional smatch warnings to fix
before this is ready to go.
[...]
Kind regards
Uffe
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/4] phy: s32g: Add serdes subsystem phy
From: Russell King (Oracle) @ 2026-01-30 14:50 UTC (permalink / raw)
To: Vinod Koul
Cc: Vincent Guittot, neil.armstrong, Simon Horman, krzk+dt, conor+dt,
ciprianmarian.costea, s32, p.zabel, ghennadi.procopciuc,
Ionut.Vicovan, linux-phy, devicetree, linux-kernel,
linux-arm-kernel, netdev, Frank.li
In-Reply-To: <aXtwfj1vqB1cXKFM@shell.armlinux.org.uk>
On Thu, Jan 29, 2026 at 02:36:46PM +0000, Russell King (Oracle) wrote:
> On Thu, Jan 29, 2026 at 08:00:38PM +0530, Vinod Koul wrote:
> > On 29-01-26, 13:51, Russell King (Oracle) wrote:
> > > On Thu, Jan 29, 2026 at 02:36:01PM +0100, Vincent Guittot wrote:
> > > > On Thu, 29 Jan 2026 at 14:23, Russell King (Oracle)
> > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > On Thu, Jan 29, 2026 at 02:01:13PM +0100, Vincent Guittot wrote:
> > > > > > yes, the usual pattern is :
> > > > > > - phy_set_mode_ext()
> > > > > > - then phy_power_on()
> > > > > > but I can add an additional check
> > > > >
> > > > > Please read Documentation/driver-api/phy/phy.rst section "Order of API
> > > > > calls" which suggests phy_set_mode_ext() after phy_power_on().
> > > >
> > > > Fair enough.
> > > > That being said, all pcie drivers that use phy_set_mode_ext(), call
> > > > it before phy_power_on()
> > >
> > > It looks like many ethernet drivers do the same, so I think maybe the
> > > generic PHY documentation is incorrect or misleading, or is expressing
> > > a preference that almost no one follows. Something for the generic PHY
> > > maintainers to look at and/or comment on.
> >
> > I would feel it makes sense to configure the mode first and then power
> > the phy up. As commented above yes it looks like apart from one tegra
> > driver rest seem to do it this way.
> >
> > Lets update the documentation
>
> Please also indicate in the documentation whether changing the submode
> of the serdes (particularly for ethernet) is permitted without doing a
> phy_power_down()..phy_power_up() dance around the phy_set_mode_ext()
> call.
Maybe something like this, which simply alters the documentation to
indicate that phy_set_mode*() is permissible prior to phy_power_on(),
and should be used at that point where drivers know the mode which
will be used.
Leaving the existing phy_set_mode*() in the sequence also indicates
that it's permissible to call this while the PHY is still powered
on.
For drivers such as stmmac, it will be important that details such as
whether phy_est_mode*() can be called with the PHY powered on are
riveted down and not left up to the generic PHY driver author - without
that, generic PHYs basically aren't usable from SoC/platform
independent code, and stmmac has bazillions of platform specific glue
already because of (a) bad code structuring and (b) lack of
generalisation through standardised interfaces that abstract platform
differences.
I want to be able for core stmmac code, or even phylink code (which
is even more platform generic) to be able to make use of generic PHY
stuff, but if the calls that can be made into generic PHY are platform
dependent, that is a blocking issue against that, and makes me question
why we have the generic PHY subsystem... it's not very generic if it
exposes the differences of each implementation to users of its
interfaces.
I think generic PHY has had the idea that its interfaces will only be
used from platform specific code that knows about the behaviour of it's
generic PHY driver, but as can be seen above, this will not remain the
case given that we have hardware designs where the core of the driver
is one vendor's IP that gets re-used across many different platforms,
but the SerDes PHY is one of many other vendor's IP.
diff --git a/Documentation/driver-api/phy/phy.rst b/Documentation/driver-api/phy/phy.rst
index 719a2b3fd2ab..cf73e4fb0951 100644
--- a/Documentation/driver-api/phy/phy.rst
+++ b/Documentation/driver-api/phy/phy.rst
@@ -142,6 +142,7 @@ Order of API calls
[devm_][of_]phy_get()
phy_init()
+ [phy_set_mode[_ext]()]
phy_power_on()
[phy_set_mode[_ext]()]
...
@@ -154,7 +155,7 @@ but controllers should always call these functions to be compatible with other
PHYs. Some PHYs may require :c:func:`phy_set_mode <phy_set_mode_ext>`, while
others may use a default mode (typically configured via devicetree or other
firmware). For compatibility, you should always call this function if you know
-what mode you will be using. Generally, this function should be called after
+what mode you will be using. Generally, this function should be called before
:c:func:`phy_power_on`, although some PHY drivers may allow it at any time.
Releasing a reference to the PHY
--
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 related
* Re: [PATCH v2 1/6] dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE
From: Herbert Xu @ 2026-01-31 2:50 UTC (permalink / raw)
To: Luca Weiss
Cc: David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Alim Akhtar, Avri Altman, Bart Van Assche,
Vinod Koul, Neil Armstrong, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Krzysztof Kozlowski
In-Reply-To: <20260112-milos-ufs-v2-1-d3ce4f61f030@fairphone.com>
On Mon, Jan 12, 2026 at 02:53:14PM +0100, Luca Weiss wrote:
> Document the Inline Crypto Engine (ICE) on the Milos SoC.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
> 1 file changed, 1 insertion(+)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: tegra: xusb: fix wrong cleanup function in tegra_xusb_pad_init()
From: Salah Triki @ 2026-01-31 12:39 UTC (permalink / raw)
To: JC Kuo, Vinod Koul, Neil Armstrong, Thierry Reding,
Jonathan Hunter
Cc: linux-phy, linux-tegra, linux-kernel, Salah Triki
In `tegra_xusb_pad_init()`, the code currently calls `device_unregister()`
if `dev_set_name()` or `device_add()` fails. This is technically incorrect.
`device_unregister()` is a combination of `device_del()` and `put_device()`
Calling `device_del()` is only valid if the device has been successfully
added to the system via `device_add()`. If `device_add()` fails or has not
been called yet, we must only use `put_device()` to drop the reference
count initialized by `device_initialize()`.
Fix this by calling `put_device()` instead of `device_unregister()` in the
error path.
Fixes: 53d2a715c2403 ("phy: Add Tegra XUSB pad controller support")
Signed-off-by: Salah Triki <salah.triki@gmail.com>
---
drivers/phy/tegra/xusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
index c89df95aa6ca..2db5586401e5 100644
--- a/drivers/phy/tegra/xusb.c
+++ b/drivers/phy/tegra/xusb.c
@@ -180,7 +180,7 @@ int tegra_xusb_pad_init(struct tegra_xusb_pad *pad,
return 0;
unregister:
- device_unregister(&pad->dev);
+ put_device(&pad->dev);
return err;
}
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH] phy: fsl-imx8mq-usb: set usb phy to be wakeup capable
From: Xu Yang @ 2026-02-02 8:02 UTC (permalink / raw)
To: vkoul, neil.armstrong, Frank.Li, s.hauer, kernel, festevam,
jun.li, a.fatoum, franz.schnyder, stefano.radaelli21, linux-phy,
imx, linux-arm-kernel, linux-kernel
USB remote wakeup need its PHY power domain to be active,
so set PHY to be wakeup capable.
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 958d114b0c83..50b67f1e6a90 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -750,6 +750,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
"failed to get tca\n");
imx8m_get_phy_tuning_data(imx_phy);
+ device_set_wakeup_capable(dev, true);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH] phy: renesas: rcar-gen3-usb2: add regulator dependency
From: Arnd Bergmann @ 2026-02-02 9:51 UTC (permalink / raw)
To: Vinod Koul, Tommaso Merciai
Cc: Arnd Bergmann, Neil Armstrong, Biju Das, linux-phy, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The driver start registering a regulator, but can still be
enabled even when it is unable to call into the regulator
subsystem:
aarch64-linux-ld: drivers/phy/renesas/phy-rcar-gen3-usb2.o: in function `rcar_gen3_phy_usb2_probe':
phy-rcar-gen3-usb2.c:(.text+0x2884): undefined reference to `devm_regulator_register'
Add a Kconfig dependency to avoid this configuration.
Fixes: b6d7dd157763 ("phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/phy/renesas/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/renesas/Kconfig b/drivers/phy/renesas/Kconfig
index d217c630b2fd..90a9ca2db7fc 100644
--- a/drivers/phy/renesas/Kconfig
+++ b/drivers/phy/renesas/Kconfig
@@ -29,6 +29,7 @@ config PHY_RCAR_GEN3_USB2
depends on ARCH_RENESAS
depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in
depends on USB_SUPPORT
+ depends on REGULATOR
select GENERIC_PHY
select MULTIPLEXER
select USB_COMMON
--
2.39.5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH] phy: GOOGLE_USB: add TYPEC dependency
From: Arnd Bergmann @ 2026-02-02 9:56 UTC (permalink / raw)
To: Vinod Koul, Joy Chakraborty, Naveen Kumar, Roy Luo
Cc: Arnd Bergmann, Neil Armstrong, Alex Elder, Ivaylo Ivanov,
Dmitry Baryshkov, Inochi Amaoto, Sven Peter, Vladimir Oltean,
linux-phy, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
With CONFIG_TYPEC=m, this driver cannot be built-in:
arm-linux-gnueabi/bin/arm-linux-gnueabi-ld: drivers/phy/phy-google-usb.o: in function `google_usb_phy_remove':
phy-google-usb.c:(.text+0x24): undefined reference to `typec_switch_unregister'
Add CONFIG_TYPEC as a hard dependency here to force a clean build.
In theory, compile-testing with CONFIG_TYPEC=n would also work, but
that seems pointless.
Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/phy/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 142e7b0ef2ef..02467dfd4fb0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -50,6 +50,7 @@ config GENERIC_PHY_MIPI_DPHY
config PHY_GOOGLE_USB
tristate "Google Tensor SoC USB PHY driver"
select GENERIC_PHY
+ depends on TYPEC
help
Enable support for the USB PHY on Google Tensor SoCs, starting with
the G5 generation (Laguna). This driver provides the PHY interfaces
--
2.39.5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2 6/6] arm64: dts: qcom: milos-fairphone-fp6: Enable UFS
From: Abel Vesa @ 2026-02-02 10:02 UTC (permalink / raw)
To: Luca Weiss
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Alim Akhtar, Avri Altman,
Bart Van Assche, Vinod Koul, Neil Armstrong, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260112-milos-ufs-v2-6-d3ce4f61f030@fairphone.com>
On 26-01-12 14:53:19, Luca Weiss wrote:
> Configure and enable the nodes for UFS, so that we can access the
> internal storage.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Abel Vesa <abel.vesa@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 v5 0/4] Add USB support for Canaan K230
From: Jiayu Du @ 2026-02-02 11:31 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: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
On Wed, Jan 21, 2026 at 10:55:21PM +0800, Jiayu Du wrote:
> Add support for the USB PHY and DWC2 IP which is used by Canaan K230,
> and made relevant changes to the DTS.
>
> This series is based on the initial 100ask K230 DshanPi series [1] which
> is based on the clock and pinctrl series. Check the details in the link.
>
> Link: https://lore.kernel.org/all/20260115060801.16819-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
>
> Changes in v5:
> - Changed the year of Copyright to 2026.
> - Add blank line after the declaration of variables
> - Fix wrong alignment.
> - Link to v4: https://lore.kernel.org/all/20260120143243.71937-1-jiayu.riscv@isrc.iscas.ac.cn/
>
> Changes in v4:
> - Shrink reg length to match the address/size-cells in k230-usb-phy yaml.
> - Move all PHY instance creation and initialization from xlate to probe.
> - Modify xlate function to only perform index lookup for PHY instances.
> - Define all register base offsets macros at the top of file instead of
> hard-coding magic numbers directly in probe.
> - Link to v2: https://lore.kernel.org/all/20260115064223.21926-1-jiayu.riscv@isrc.iscas.ac.cn/
>
> Changes in v3:
> - Please ignore v3.
>
> Changes in v2:
> - Fold the child into the parent in dtsi.
> - Define one usbphy with phy-cells=1.
> - Delete the clock of the usbphy as it is not needed.
> - Link to v1: https://lore.kernel.org/all/20251230023725.15966-1-jiayu.riscv@isrc.iscas.ac.cn/
>
> Jiayu Du (4):
> dt-bindings: phy: Add Canaan K230 USB PHY
> dt-bindings: usb: dwc2: Add support for Canaan K230 SoC
> phy: usb: Add driver for Canaan K230 USB 2.0 PHY
> riscv: dts: canaan: Add syscon and USB nodes for K230
>
> .../bindings/phy/canaan,k230-usb-phy.yaml | 35 +++
> .../devicetree/bindings/usb/dwc2.yaml | 3 +
> .../boot/dts/canaan/k230-canmv-dshanpi.dts | 17 ++
> arch/riscv/boot/dts/canaan/k230.dtsi | 35 +++
> drivers/phy/Kconfig | 1 +
> drivers/phy/Makefile | 1 +
> drivers/phy/canaan/Kconfig | 14 +
> drivers/phy/canaan/Makefile | 2 +
> drivers/phy/canaan/phy-k230-usb.c | 284 ++++++++++++++++++
> 9 files changed, 392 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
> create mode 100644 drivers/phy/canaan/Kconfig
> create mode 100644 drivers/phy/canaan/Makefile
> create mode 100644 drivers/phy/canaan/phy-k230-usb.c
>
> --
> 2.52.0
>
Hello Vinod, could you please take a look at this patch? Thank you!
Regards,
Jiayu Du
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy 0/8] Lynx 28G improvements part 2
From: Vladimir Oltean @ 2026-02-02 15:03 UTC (permalink / raw)
To: linux-phy, Vinod Koul, Neil Armstrong
Cc: netdev, Ioana Ciornei, Kishon Vijay Abraham I, Josua Mayer,
linux-kernel
In-Reply-To: <20260114152111.625350-1-vladimir.oltean@nxp.com>
Hello PHY maintainers,
On Wed, Jan 14, 2026 at 05:21:03PM +0200, Vladimir Oltean wrote:
> This contains a number of changes deferred from part 1 (patches 1-6):
> https://lore.kernel.org/linux-phy/20251125114847.804961-1-vladimir.oltean@nxp.com/
>
> They are reworked in ways detailed in their individual change logs.
>
> I have a special request to linux-phy maintainers: after merging, please
> provide a stable branch/tag of this plus part 1, that can be pulled into
> netdev. It is needed because phy_exit() calls from consumers would
> compile but would cause a functionally broken link, so we need a linear
> git history to avoid (temporary) regressions.
Given how close to the merge window we are, I am dropping my special
request for a stable tag. But can you please take a look at this until
the merge window opens? It will simplify further development to have it
for v6.20 (or whatever next release number will be).
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: tegra: xusb: Remove unused powered_on variable
From: Jon Hunter @ 2026-02-02 15:33 UTC (permalink / raw)
To: JC Kuo, Vinod Koul, Thierry Reding; +Cc: linux-phy, linux-tegra, Jon Hunter
Commit bbf711682cd5 ("phy: tegra: xusb: Add Tegra186 support") added the
variable 'powered_on' to the structure 'tegra_xusb_usb2_lane' but it has
never been used. Therefore, remove this unused variable.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
drivers/phy/tegra/xusb.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
index d2b5f9565132..cd277d0ed9e1 100644
--- a/drivers/phy/tegra/xusb.h
+++ b/drivers/phy/tegra/xusb.h
@@ -69,7 +69,6 @@ struct tegra_xusb_usb2_lane {
struct tegra_xusb_lane base;
u32 hs_curr_level_offset;
- bool powered_on;
};
static inline struct tegra_xusb_usb2_lane *
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 0/8] phy: zynqmp: Perform complete initialization, including ILL calibration
From: Sean Anderson @ 2026-02-03 0:21 UTC (permalink / raw)
To: Laurent Pinchart, Vinod Koul, linux-phy
Cc: Krzysztof Wilczyński, Lorenzo Pieralisi, Radhey Shyam Pandey,
linux-kernel, Michal Simek, linux-arm-kernel, linux-pci,
Neil Armstrong, Rob Herring, Thippeswamy Havalige,
Manivannan Sadhasivam, Bjorn Helgaas, Sean Anderson, Conor Dooley,
Krzysztof Kozlowski, devicetree
This series completely initializes the GTRs in Linux, making all
bootloader initialization (as performed by init_serdes() in
psu_init_gpl.c) optional. This gives the following advantages:
- On some boards (mine) the reference clocks may not be configured in
SPL/FSBL. So ILL calibration will fail (and take a long time to do so)
unless we defer initialization to U-Boot/Linux where the phy driver
can request the clocks.
- If PCIe/SATA are not used in U-Boot, ILL calibration can be deferred
until Linux when it can be done it parallel with other initialization.
- We will have flexibility to switch between different configurations at
runtime. For example, this could allow supporting both SATA and PCIe M.2
cards with [1].
I have tested this series with DP, PCIe, SGMII, and SATA. USB3 is broken
on my dev board at the moment (independent of this series; need to
investigate) so I have not tested that. I have an equivalent set of
patches for U-Boot that I will try to post soon.
[1] https://lore.kernel.org/linux-pci/20260107-pci-m2-v5-0-8173d8a72641@oss.qualcomm.com/
Sean Anderson (8):
dt-bindings: pci: xilinx-nwl: Add resets
phy: zynqmp: Refactor bus width configuration into helper
phy: zynqmp: Refactor common phy initialization into a helper
phy: zynqmp: Calibrate ILL if necessary
phy: zynqmp: Initialize chicken bits
PCI: xilinx-nwl: Split phy_init from phy_power_on
PCI: xilinx-nwl: Reset the core during probe
arm64: zynqmp: Add PCIe resets
.../bindings/pci/xlnx,nwl-pcie.yaml | 17 +
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 +
drivers/pci/controller/pcie-xilinx-nwl.c | 255 +++++++--
drivers/phy/xilinx/phy-zynqmp.c | 487 +++++++++++++++++-
4 files changed, 713 insertions(+), 50 deletions(-)
--
2.35.1.1320.gc452695387.dirty
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
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