Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Dmitry Baryshkov @ 2026-01-16  8:41 UTC (permalink / raw)
  To: Yongxing Mou
  Cc: Konrad Dybcio, Vinod Koul, Neil Armstrong, linux-arm-msm,
	linux-phy, linux-kernel
In-Reply-To: <80411ac4-6143-4c2e-bc9e-20a734f15987@oss.qualcomm.com>

On Fri, Jan 16, 2026 at 04:18:43PM +0800, Yongxing Mou wrote:
> 
> 
> On 1/14/2026 2:55 AM, Dmitry Baryshkov wrote:
> > On Tue, Jan 13, 2026 at 08:04:06PM +0800, Yongxing Mou wrote:
> > > 
> > > 
> > > On 1/9/2026 5:58 PM, Konrad Dybcio wrote:
> > > > On 1/9/26 9:30 AM, Yongxing Mou wrote:
> > > > > Currently, the LeMans/Monaco DP PHY operates in DP mode rather than eDP
> > > > > mode. Per the PHY HPG, the Swing and Emphasis settings have been corrected
> > > > > to the appropriate DP-mode values.
> > > > > 
> > > > > Additionally, the HPG specifies that the LDO value should be set to 0 when
> > > > > in DP mode. These misconfigurations can lead to link training failures on
> > > > > certain dongles.
> > > > > 
> > > > > Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> > > > > ---
> > > > >    drivers/phy/qualcomm/phy-qcom-edp.c | 27 ++++++++++++++++++++++++---
> > > > >    1 file changed, 24 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
> > > > > index 13feab99feec..5b0d774bd715 100644
> > > > > --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> > > > > +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> > > > > @@ -122,6 +122,13 @@ static const u8 dp_swing_hbr_rbr[4][4] = {
> > > > >    	{ 0x1f, 0xff, 0xff, 0xff }
> > > > >    };
> > > > > +static const u8 dp_swing_hbr_rbr_v1[4][4] = {
> > > > > +	{ 0x07, 0x0f, 0x16, 0x1f },
> > > > > +	{ 0x11, 0x1e, 0x1f, 0xff },
> > > > > +	{ 0x16, 0x1f, 0xff, 0xff },
> > > > > +	{ 0x1f, 0xff, 0xff, 0xff }
> > > > > +};
> > > > 
> > > > For these platforms, I see 4 tables of settings:
> > > > 
> > > > (Low/High) Swing/Pre-em for (Low/High) HBR
> > > > 
> > > > None of them exactly match your change
> > > > 
> > > Emm, this table is in LeMans eDP HPG, here are 6 tables. 4 of them use for
> > > eDP mode and reset 2 tables used for DP mode. If my understanding is
> > > incorrect, please correct me. Thanks ~~~ > [...]
> > > > 
> > > > > -	ldo_config = edp->is_edp ? 0x0 : 0x1;
> > > > > +	ldo_config = !edp->is_edp ? 0x0 : 0x1;
> > > > 
> > > > You'll notice that this is further wrong, because for eDP, it should be
> > > > 0x81 at low-swing-high-HBR and 0xc1 at low-swing-low-HBR, and 0 at both
> > > > cases of high-swing
> > > > 
> > > > Please split the LDO change into a separate commit because it touches
> > > > more platforms
> > > > 
> > > > Konrad
> > > > 
> > > 
> > > Yes, you are right, here seems something not correct. i will separate this
> > > change into single one.Here are some parts I don't fully understand here.
> > > Could you please point it? How do we know whether it is in low‑swing or
> > > high‑swing. I didn’t see any logic in the current code that determines this.
> > > Also, the value in Hamoa seems not same with LeMans,it is 0x51 and 0x91.
> > > 
> > > While going through the Hamoa HPG, I noticed a potential issue.
> > > 
> > >   static struct qcom_edp_phy_cfg x1e80100_phy_cfg = {
> > > 	.aux_cfg = edp_phy_aux_cfg_v4,
> > > 	.vco_div_cfg = edp_phy_vco_div_cfg_v4,
> > > 	.swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,...It use
> > > dp_phy_swing_pre_emph_cfg not edp_phy_swing_pre_emph_cfg, but Hamoa really
> > > use edp-panel here.. so does this phy cfg correct here?
> > 
> > All PHYs should support eDP and DP modes, so most of the configuration
> > tables need to be updated/fixed. I tried going through all the tables,
> > but I never had time to do it in a sane and complete way. As you started
> > looking into it, would you please review programming for all chipsets
> > starting from SC8180X?
> > 
> I don't got the SC8180X PHY HPG permission now. once i got it, will check
> it's configuration and see what i can do. But first i want to correct the
> LeMans and Hamoa configuration and post the LDO change. Do you mean
> switching between the eDP and DP mode tables based on is_edp, instead of
> using a fixed table?

Based on the PHY being used in the eDP or DP modes (it is related but
not equivalent to the is_edp).

-- 
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] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Yongxing Mou @ 2026-01-16  8:18 UTC (permalink / raw)
  To: Dmitry Baryshkov
  Cc: Konrad Dybcio, Vinod Koul, Neil Armstrong, linux-arm-msm,
	linux-phy, linux-kernel
In-Reply-To: <ldl7floy6bi5d6svs45xsdgbgkgwxpvj4kuazzg3e6dxzm654l@l5pjud7mvcgu>



On 1/14/2026 2:55 AM, Dmitry Baryshkov wrote:
> On Tue, Jan 13, 2026 at 08:04:06PM +0800, Yongxing Mou wrote:
>>
>>
>> On 1/9/2026 5:58 PM, Konrad Dybcio wrote:
>>> On 1/9/26 9:30 AM, Yongxing Mou wrote:
>>>> Currently, the LeMans/Monaco DP PHY operates in DP mode rather than eDP
>>>> mode. Per the PHY HPG, the Swing and Emphasis settings have been corrected
>>>> to the appropriate DP-mode values.
>>>>
>>>> Additionally, the HPG specifies that the LDO value should be set to 0 when
>>>> in DP mode. These misconfigurations can lead to link training failures on
>>>> certain dongles.
>>>>
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>>    drivers/phy/qualcomm/phy-qcom-edp.c | 27 ++++++++++++++++++++++++---
>>>>    1 file changed, 24 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
>>>> index 13feab99feec..5b0d774bd715 100644
>>>> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
>>>> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
>>>> @@ -122,6 +122,13 @@ static const u8 dp_swing_hbr_rbr[4][4] = {
>>>>    	{ 0x1f, 0xff, 0xff, 0xff }
>>>>    };
>>>> +static const u8 dp_swing_hbr_rbr_v1[4][4] = {
>>>> +	{ 0x07, 0x0f, 0x16, 0x1f },
>>>> +	{ 0x11, 0x1e, 0x1f, 0xff },
>>>> +	{ 0x16, 0x1f, 0xff, 0xff },
>>>> +	{ 0x1f, 0xff, 0xff, 0xff }
>>>> +};
>>>
>>> For these platforms, I see 4 tables of settings:
>>>
>>> (Low/High) Swing/Pre-em for (Low/High) HBR
>>>
>>> None of them exactly match your change
>>>
>> Emm, this table is in LeMans eDP HPG, here are 6 tables. 4 of them use for
>> eDP mode and reset 2 tables used for DP mode. If my understanding is
>> incorrect, please correct me. Thanks ~~~ > [...]
>>>
>>>> -	ldo_config = edp->is_edp ? 0x0 : 0x1;
>>>> +	ldo_config = !edp->is_edp ? 0x0 : 0x1;
>>>
>>> You'll notice that this is further wrong, because for eDP, it should be
>>> 0x81 at low-swing-high-HBR and 0xc1 at low-swing-low-HBR, and 0 at both
>>> cases of high-swing
>>>
>>> Please split the LDO change into a separate commit because it touches
>>> more platforms
>>>
>>> Konrad
>>>
>>
>> Yes, you are right, here seems something not correct. i will separate this
>> change into single one.Here are some parts I don't fully understand here.
>> Could you please point it? How do we know whether it is in low‑swing or
>> high‑swing. I didn’t see any logic in the current code that determines this.
>> Also, the value in Hamoa seems not same with LeMans,it is 0x51 and 0x91.
>>
>> While going through the Hamoa HPG, I noticed a potential issue.
>>
>>   static struct qcom_edp_phy_cfg x1e80100_phy_cfg = {
>> 	.aux_cfg = edp_phy_aux_cfg_v4,
>> 	.vco_div_cfg = edp_phy_vco_div_cfg_v4,
>> 	.swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,...It use
>> dp_phy_swing_pre_emph_cfg not edp_phy_swing_pre_emph_cfg, but Hamoa really
>> use edp-panel here.. so does this phy cfg correct here?
> 
> All PHYs should support eDP and DP modes, so most of the configuration
> tables need to be updated/fixed. I tried going through all the tables,
> but I never had time to do it in a sane and complete way. As you started
> looking into it, would you please review programming for all chipsets
> starting from SC8180X?
> 
I don't got the SC8180X PHY HPG permission now. once i got it, will 
check it's configuration and see what i can do. But first i want to 
correct the LeMans and Hamoa configuration and post the LDO change. Do 
you mean switching between the eDP and DP mode tables based on is_edp, 
instead of using a fixed table?

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v3 net-next 05/10] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
From: Jakub Kicinski @ 2026-01-16  3:19 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Paolo Abeni, Bjørn Mork, netdev, devicetree, linux-phy,
	linux-kernel, linux-arm-kernel, linux-mediatek, Daniel Golle,
	Horatiu Vultur, Andrew Lunn, Heiner Kallweit, Russell King,
	David S. Miller, Eric Dumazet, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Neil Armstrong, Matthias Brugger,
	AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún,
	Lee Jones, Patrice Chotard, Vinod Koul
In-Reply-To: <20260115093928.hdqlxkt6bd5w4xud@skbuf>

On Thu, 15 Jan 2026 11:39:28 +0200 Vladimir Oltean wrote:
> > > Could you please share a stable branch/tag, so that we can pull patches
> > > 1-5 into the net-next tree from there?  
> > 
> > Vladimir, could you please re-post patches 1-5 after that Vinod shares
> > the above? So that we don't keep in PW the dangling (current) series.
> >  
> Vinod did share the PR:
> https://lore.kernel.org/netdev/aWeXvFcGNK5T6As9@vaman/

IIUC Paolo did not pull Vinod's PR, so pulled now, you can repost.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v3 net-next 00/10] PHY polarity inversion via generic device tree properties
From: Jakub Kicinski @ 2026-01-16  3:16 UTC (permalink / raw)
  To: Vinod Koul
  Cc: Vladimir Oltean, netdev, devicetree, linux-phy, linux-kernel,
	linux-arm-kernel, linux-mediatek, Daniel Golle, Horatiu Vultur,
	Bjørn Mork, Andrew Lunn, Heiner Kallweit, Russell King,
	David S. Miller, Eric Dumazet, Paolo Abeni, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Matthias Brugger, AngeloGioacchino Del Regno, Eric Woudstra,
	Marek Behún, Lee Jones, Patrice Chotard
In-Reply-To: <aWeXvFcGNK5T6As9@vaman>

On Wed, 14 Jan 2026 18:48:52 +0530 Vinod Koul wrote:
> Subject: Re: [PATCH v3 net-next 00/10] PHY polarity inversion via generic device tree properties

You can submit the PR in reply to the series, but please rewrite the
subject to a typical PR format. Patchwork does not register this reply
as a submission.

-- 
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-16  2:58 UTC (permalink / raw)
  To: rmk+kernel
  Cc: Jakub Kicinski, andrew+netdev, alexandre.torgue, hkallweit1,
	vkoul, mohd.anwar, konrad.dybcio, andrew, edumazet, netdev,
	linux-phy, davem, linux-arm-msm, neil.armstrong, linux-arm-kernel,
	pabeni, mcoquelin.stm32, linux-stm32
In-Reply-To: <E1vg4wc-00000003SGl-1dZi@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 commit adds support for reading link status, speed, and duplex for
SGMII links from the RGSMII status register.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> index 73fc56ce5e55..12fc5038d913 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c

[ ... ]

> @@ -97,7 +107,7 @@ static void dwmac_integrated_pcs_get_state(struct phylink_pcs *pcs,
>  					   struct phylink_link_state *state)
>  {
>  	struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> -	u32 status, lpa;
> +	u32 status, lpa, rgsmii;
>
>  	status = readl(spcs->base + GMAC_AN_STATUS);
>
> @@ -111,7 +121,35 @@ 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));
> +		state->link = !!(status & GMAC_RGSMIII_LNKSTS);
                            ^^^^^^

Should this be checking rgsmii instead of status here? The status
variable contains the GMAC_AN_STATUS register which is equivalent to
MII_BMSR according to the comment at line 7. In BMSR, the link status
bit is BMSR_LSTATUS (bit 2), not bit 3.

GMAC_RGSMIII_LNKSTS is defined as BIT(3), which is the correct bit
position for the RGSMII status register (matching GMAC_RGSMIIIS_LNKSTS
in dwmac1000.h), but it appears to be applied to the wrong register
variable.

The code later uses rgsmii correctly for speed and duplex extraction.
Was the intent to use rgsmii for the link status check as well?

> +
> +		if (state->link && neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED) {

[ ... ]

-- 
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-16  2:57 UTC (permalink / raw)
  To: rmk+kernel
  Cc: Jakub Kicinski, andrew+netdev, alexandre.torgue, hkallweit1,
	vkoul, mohd.anwar, konrad.dybcio, andrew, edumazet, netdev,
	linux-phy, davem, linux-arm-msm, neil.armstrong, linux-arm-kernel,
	pabeni, mcoquelin.stm32, linux-stm32
In-Reply-To: <E1vg4w2-00000003SG5-2FH5@rmk-PC.armlinux.org.uk>

I haven't investigated too closely if this is legit or too defensive
TBH but since I'm sending the second one I'll include this as well..

This is an AI-generated review of your patch.

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 field in
platform data is optional and NULL when not provided by platforms.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 24a2555ca329..6c515f9efbe7 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

[ ... ]

> @@ -3549,12 +3550,16 @@ static void stmmac_safety_feat_configuration(struct stmmac_priv *priv)
>
>  static void stmmac_clk_rx_i_require(struct stmmac_priv *priv)
>  {
> +	dwmac_serdes_power_on(priv);
> +	/* Only sets the SerDes mode if it wasn't already configured. */
> +	dwmac_serdes_init_mode(priv, priv->plat->phy_interface);

When priv->plat->serdes is NULL, dwmac_serdes_init_mode() will call
phy_get_mode(NULL). Unlike other phy_* functions (phy_power_on,
phy_power_off, phy_set_mode_ext, phy_init, phy_exit) which handle NULL
by returning early, phy_get_mode() is an inline that directly
dereferences the pointer:

    static inline enum phy_mode phy_get_mode(struct phy *phy)
    {
        return phy->attrs.mode;
    }

Can this NULL pointer dereference occur when a platform does not
populate plat->serdes? The call path stmmac_open() -> dwmac_serdes_init()
returns 0 (success) when serdes is NULL, allowing __stmmac_open() ->
stmmac_hw_setup() -> stmmac_clk_rx_i_require() to proceed.

> +	phylink_rx_clk_stop_block(priv->phylink);
>  }

[ ... ]

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c
> new file mode 100644
> index 000000000000..3003e1ae38d2
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c

[ ... ]

> +int dwmac_serdes_init(struct stmmac_priv *priv)
> +{
> +	size_t i;
> +	int ret;
> +
> +	if (!priv->plat->serdes)
> +		return 0;

This returns success when serdes is NULL...

[ ... ]

> +int dwmac_serdes_init_mode(struct stmmac_priv *priv, phy_interface_t interface)
> +{
> +	struct phy *serdes = priv->plat->serdes;
> +
> +	if (phy_get_mode(serdes) == PHY_MODE_ETHERNET)
                         ^^^^^^

...but dwmac_serdes_init_mode() has no NULL check before calling
phy_get_mode(), which will crash when serdes is NULL. Should this
function also check for NULL serdes before calling phy_get_mode()?

> +		return 0;
> +
> +	return dwmac_serdes_set_mode(priv, interface);
> +}

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* [PATCH v2 3/3] MAINTAINERS: Add ASPEED USB3 PHY driver
From: Ryan Chen @ 2026-01-16  2:53 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
  Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
	linux-kernel, Ryan Chen
In-Reply-To: <20260116-upstream_usb3phy-v2-0-0b0c9f3eb6f4@aspeedtech.com>

Add maintainer entry for ASPEED USB3 PHY driver.

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5b11839cba9d..ad1d12f346f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3894,6 +3894,14 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/usb/aspeed,ast2600-udc.yaml
 F:	drivers/usb/gadget/udc/aspeed_udc.c
 
+ASPEED USB3 PHY DRIVER
+M:	Ryan Chen <ryan_chen@aspeedtech.com>
+L:	linux-aspeed@lists.ozlabs.org (moderated for non-subscribers)
+L:	linux-phy@lists.infradead.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
+F:	drivers/phy/aspeed/phy-aspeed-usb3.c
+
 ASPEED VIDEO ENGINE DRIVER
 M:	Eddie James <eajames@linux.ibm.com>
 L:	linux-media@vger.kernel.org

-- 
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 v2 2/3] phy: add AST2700 usb3.2 phy driver
From: Ryan Chen @ 2026-01-16  2:53 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
  Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
	linux-kernel, Ryan Chen
In-Reply-To: <20260116-upstream_usb3phy-v2-0-0b0c9f3eb6f4@aspeedtech.com>

Add AST2700 USB3.2 PHY driver support.

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
 drivers/phy/aspeed/Kconfig           |  12 ++
 drivers/phy/aspeed/Makefile          |   2 +
 drivers/phy/aspeed/phy-aspeed-usb3.c | 236 +++++++++++++++++++++++++++++++++++
 3 files changed, 250 insertions(+)

diff --git a/drivers/phy/aspeed/Kconfig b/drivers/phy/aspeed/Kconfig
new file mode 100644
index 000000000000..72b4fc17a85e
--- /dev/null
+++ b/drivers/phy/aspeed/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+#
+# PHY drivers for ASPEED
+#
+
+config PHY_ASPEED_USB3
+	tristate "ASPEED USB3 PHY driver"
+	select GENERIC_PHY
+	depends on (ARCH_ASPEED || COMPILE_TEST)
+	help
+	  Enable driver support for Aspeed AST2700 USB3 PHY.
diff --git a/drivers/phy/aspeed/Makefile b/drivers/phy/aspeed/Makefile
new file mode 100644
index 000000000000..20b5ac7b7e64
--- /dev/null
+++ b/drivers/phy/aspeed/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_ASPEED_USB3_PHY)		+= phy-aspeed-usb3.o
diff --git a/drivers/phy/aspeed/phy-aspeed-usb3.c b/drivers/phy/aspeed/phy-aspeed-usb3.c
new file mode 100644
index 000000000000..872d2163fcf5
--- /dev/null
+++ b/drivers/phy/aspeed/phy-aspeed-usb3.c
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2026 Aspeed Technology Inc.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+
+#define PHY3S00		0x00
+#define PHY3S00_INIT_DONE		BIT(15)
+#define PHY3S00_SRAM_BYPASS		BIT(7)
+#define PHY3S00_SRAM_EXT_LOAD	BIT(6)
+#define PHY3S04		0x04
+#define PHY3C00		0x08
+#define PHY3C04		0x0C
+#define PHY3P00		0x10
+#define PHY3P00_RX_ADAPT_AFE_EN_G1	BIT(0)
+#define PHY3P00_RX_ADAPT_AFE_EN_G2	BIT(1)
+#define PHY3P00_RX_ADAPT_DFE_EN_G1	BIT(2)
+#define PHY3P00_RX_ADAPT_DFE_EN_G2	BIT(3)
+#define PHY3P00_RX_CDR_VCO_LOWFREQ_G1	BIT(4)
+#define PHY3P00_RX_CDR_VCO_LOWFREQ_G2	BIT(5)
+#define PHY3P00_RX_EQ_AFE_GAIN_G1	GENMASK(9, 6)
+#define PHY3P00_RX_EQ_AFE_GAIN_G2	GENMASK(13, 10)
+#define PHY3P00_RX_EQ_ATT_LVL_G1	GENMASK(16, 14)
+#define PHY3P00_RX_EQ_ATT_LVL_G2	GENMASK(19, 17)
+#define PHY3P00_RX_EQ_CTLE_BOOST_G1	GENMASK(24, 20)
+#define PHY3P00_RX_EQ_CTLE_BOOST_G2	GENMASK(29, 25)
+#define PHY3P00_RX_EQ_DELTA_IQ_G1_LO	GENMASK(31, 30)
+
+#define PHY3P04		0x14
+#define PHY3P04_RX_EQ_DELTA_IQ_G1_HI	GENMASK(1, 0)
+#define PHY3P04_RX_EQ_DELTA_IQ_G2	GENMASK(5, 2)
+#define PHY3P04_RX_EQ_DFE_TAP1_G1	GENMASK(13, 6)
+#define PHY3P04_RX_EQ_DFE_TAP1_G2	GENMASK(21, 14)
+#define PHY3P04_RX_LOS_LFPS_EN		BIT(22)
+#define PHY3P04_RX_LOS_THRESHOLD	GENMASK(25, 23)
+#define PHY3P04_RX_TERM_CTRL		GENMASK(28, 26)
+#define PHY3P04_TX_EQ_MAIN_G1_LO	GENMASK(31, 29)
+
+#define PHY3P08		0x18
+#define PHY3P08_TX_EQ_MAIN_G1_HI	GENMASK(1, 0)
+#define PHY3P08_TX_EQ_MAIN_G2		GENMASK(6, 2)
+#define PHY3P08_TX_EQ_OVRD		BIT(7)
+#define PHY3P08_TX_EQ_POST_G1		GENMASK(12, 9)
+#define PHY3P08_TX_EQ_POST_G2		GENMASK(16, 13)
+#define PHY3P08_TX_EQ_PRE_G1		GENMASK(20, 17)
+#define PHY3P08_TX_EQ_PRE_G2		GENMASK(24, 21)
+#define PHY3P08_TX_IBOOST_LVL		GENMASK(28, 25)
+#define PHY3P08_TX_TERM_CTRL		GENMASK(31, 29)
+
+#define PHY3P0C		0x1C
+#define PHY3P0C_TX_VBOOST_EN		BIT(0)
+
+#define PHY3CMD		0x40
+
+#define PHY3P_RX_EQ_CTLE_BOOST_G1_DEFAULT	0x7
+#define PHY3P_RX_EQ_CTLE_BOOST_G2_DEFAULT	0x7
+#define PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT	0x3
+#define PHY3P_RX_EQ_DELTA_IQ_G2_DEFAULT	0x5
+#define PHY3P_RX_LOS_THRESHOLD_DEFAULT		0x3
+#define PHY3P_RX_TERM_CTRL_DEFAULT		0x2
+#define PHY3P_TX_EQ_MAIN_G1_DEFAULT		0xa
+#define PHY3P_TX_EQ_MAIN_G2_DEFAULT		0x9
+#define PHY3P_TX_EQ_POST_G1_DEFAULT		0x4
+#define PHY3P_TX_EQ_POST_G2_DEFAULT		0x3
+#define PHY3P_TX_EQ_PRE_G2_DEFAULT		0x2
+#define PHY3P_TX_IBOOST_LVL_DEFAULT		0xf
+#define PHY3P_TX_TERM_CTRL_DEFAULT		0x2
+
+#define PHY3P00_DEFAULT ( \
+	PHY3P00_RX_ADAPT_AFE_EN_G1 | \
+	PHY3P00_RX_ADAPT_AFE_EN_G2 | \
+	PHY3P00_RX_ADAPT_DFE_EN_G1 | \
+	PHY3P00_RX_ADAPT_DFE_EN_G2 | \
+	FIELD_PREP(PHY3P00_RX_EQ_CTLE_BOOST_G1, PHY3P_RX_EQ_CTLE_BOOST_G1_DEFAULT) | \
+	FIELD_PREP(PHY3P00_RX_EQ_CTLE_BOOST_G2, PHY3P_RX_EQ_CTLE_BOOST_G2_DEFAULT) | \
+	FIELD_PREP(PHY3P00_RX_EQ_DELTA_IQ_G1_LO, \
+		   PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT & 0x3) \
+)
+
+#define PHY3P04_DEFAULT ( \
+	FIELD_PREP(PHY3P04_RX_EQ_DELTA_IQ_G1_HI, \
+		   PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT >> 2) | \
+	FIELD_PREP(PHY3P04_RX_EQ_DELTA_IQ_G2, PHY3P_RX_EQ_DELTA_IQ_G2_DEFAULT) | \
+	PHY3P04_RX_LOS_LFPS_EN | \
+	FIELD_PREP(PHY3P04_RX_LOS_THRESHOLD, PHY3P_RX_LOS_THRESHOLD_DEFAULT) | \
+	FIELD_PREP(PHY3P04_RX_TERM_CTRL, PHY3P_RX_TERM_CTRL_DEFAULT) | \
+	FIELD_PREP(PHY3P04_TX_EQ_MAIN_G1_LO, \
+		   PHY3P_TX_EQ_MAIN_G1_DEFAULT & 0x7) \
+)
+
+#define PHY3P08_DEFAULT ( \
+	FIELD_PREP(PHY3P08_TX_EQ_MAIN_G1_HI, PHY3P_TX_EQ_MAIN_G1_DEFAULT >> 3) | \
+	FIELD_PREP(PHY3P08_TX_EQ_MAIN_G2, PHY3P_TX_EQ_MAIN_G2_DEFAULT) | \
+	FIELD_PREP(PHY3P08_TX_EQ_POST_G1, PHY3P_TX_EQ_POST_G1_DEFAULT) | \
+	FIELD_PREP(PHY3P08_TX_EQ_POST_G2, PHY3P_TX_EQ_POST_G2_DEFAULT) | \
+	FIELD_PREP(PHY3P08_TX_EQ_PRE_G2, PHY3P_TX_EQ_PRE_G2_DEFAULT) | \
+	FIELD_PREP(PHY3P08_TX_IBOOST_LVL, PHY3P_TX_IBOOST_LVL_DEFAULT) | \
+	FIELD_PREP(PHY3P08_TX_TERM_CTRL, PHY3P_TX_TERM_CTRL_DEFAULT) \
+)
+
+#define PHY3P0C_DEFAULT \
+	PHY3P0C_TX_VBOOST_EN
+
+struct aspeed_usb3_phy {
+	void __iomem *regs;
+	struct reset_control *rst;
+	struct device *dev;
+	struct clk *clk;
+};
+
+static int aspeed_usb3_phy_init(struct phy *phy)
+{
+	struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
+	u32 val;
+	int ret;
+
+	ret = clk_prepare_enable(aspeed_phy->clk);
+	if (ret) {
+		dev_err(aspeed_phy->dev, "Failed to enable clock %d\n", ret);
+		return ret;
+	}
+
+	ret = reset_control_deassert(aspeed_phy->rst);
+	if (ret) {
+		clk_disable_unprepare(aspeed_phy->clk);
+		return ret;
+	}
+
+	/* Wait for USB3 PHY internal SRAM initialization done */
+	ret = readl_poll_timeout(aspeed_phy->regs + PHY3S00, val,
+				 val & PHY3S00_INIT_DONE,
+				 USEC_PER_MSEC, 10 * USEC_PER_MSEC);
+	if (ret) {
+		dev_err(aspeed_phy->dev, "SRAM init timeout\n");
+		goto err_assert_reset;
+	}
+
+	val = readl(aspeed_phy->regs + PHY3S00);
+	val |= PHY3S00_SRAM_BYPASS;
+	writel(val, aspeed_phy->regs + PHY3S00);
+
+	/* Set protocol1_ext signals as default PHY3 settings based on SNPS documents.
+	 * Including PCFGI[54]: protocol1_ext_rx_los_lfps_en for better compatibility
+	 */
+	writel(PHY3P00_DEFAULT, aspeed_phy->regs + PHY3P00);
+	writel(PHY3P04_DEFAULT, aspeed_phy->regs + PHY3P04);
+	writel(PHY3P08_DEFAULT, aspeed_phy->regs + PHY3P08);
+	writel(PHY3P0C_DEFAULT, aspeed_phy->regs + PHY3P0C);
+
+	return 0;
+
+err_assert_reset:
+	reset_control_assert(aspeed_phy->rst);
+	clk_disable_unprepare(aspeed_phy->clk);
+	return ret;
+}
+
+static int aspeed_usb3_phy_exit(struct phy *phy)
+{
+	struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
+
+	reset_control_assert(aspeed_phy->rst);
+	clk_disable_unprepare(aspeed_phy->clk);
+
+	return 0;
+}
+
+static const struct phy_ops aspeed_usb3_phy_ops = {
+	.init		= aspeed_usb3_phy_init,
+	.exit		= aspeed_usb3_phy_exit,
+	.owner		= THIS_MODULE,
+};
+
+static int aspeed_usb3_phy_probe(struct platform_device *pdev)
+{
+	struct aspeed_usb3_phy *aspeed_phy;
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct phy *phy;
+
+	aspeed_phy = devm_kzalloc(dev, sizeof(*aspeed_phy), GFP_KERNEL);
+	if (!aspeed_phy)
+		return -ENOMEM;
+
+	aspeed_phy->dev = dev;
+
+	aspeed_phy->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(aspeed_phy->clk))
+		return PTR_ERR(aspeed_phy->clk);
+
+	aspeed_phy->rst = devm_reset_control_get_exclusive(dev, NULL);
+	if (IS_ERR(aspeed_phy->rst))
+		return PTR_ERR(aspeed_phy->rst);
+
+	aspeed_phy->regs = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(aspeed_phy->regs))
+		return PTR_ERR(aspeed_phy->regs);
+
+	phy = devm_phy_create(dev, NULL, &aspeed_usb3_phy_ops);
+	if (IS_ERR(phy))
+		return PTR_ERR(phy);
+
+	phy_set_drvdata(phy, aspeed_phy);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id aspeed_usb3_phy_match_table[] = {
+	{
+		.compatible = "aspeed,ast2700-usb3-phy",
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, aspeed_usb3_phy_match_table);
+
+static struct platform_driver aspeed_usb3_phy_driver = {
+	.probe		= aspeed_usb3_phy_probe,
+	.driver		= {
+		.name	= KBUILD_MODNAME,
+		.of_match_table	= aspeed_usb3_phy_match_table,
+	},
+};
+module_platform_driver(aspeed_usb3_phy_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ASPEED USB3.0 PHY Driver");

-- 
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 v2 1/3] dt-bindings: phy: aspeed: Document AST2700 USB3.0 PHY
From: Ryan Chen @ 2026-01-16  2:53 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
  Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
	linux-kernel, Ryan Chen, Krzysztof Kozlowski
In-Reply-To: <20260116-upstream_usb3phy-v2-0-0b0c9f3eb6f4@aspeedtech.com>

Document AST2700 USB3.2 PHY. This IP is connected between
USB3 controller and PHY module.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
 .../bindings/phy/aspeed,ast2700-usb3-phy.yaml      | 48 ++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
new file mode 100644
index 000000000000..b83037aa0438
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/aspeed,ast2700-usb3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2700 USB 3.2 PHY
+
+maintainers:
+  - Ryan Chen <ryan_chen@aspeedtech.com>
+
+properties:
+  compatible:
+    const: aspeed,ast2700-usb3-phy
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  resets:
+    maxItems: 1
+
+  '#phy-cells':
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - resets
+  - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/aspeed,ast2700-scu.h>
+    #include <dt-bindings/reset/aspeed,ast2700-scu.h>
+
+    usb-phy@12010000 {
+        compatible = "aspeed,ast2700-usb3-phy";
+        reg = <0x12010000 0xc0>;
+        clocks = <&syscon0 SCU0_CLK_GATE_PORTAUSB2CLK>;
+        resets = <&syscon0 SCU0_RESET_PORTA_PHY3>;
+        #phy-cells = <0>;
+    };

-- 
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 v2 0/3] Add AST2700 USB3.2 PHY driver
From: Ryan Chen @ 2026-01-16  2:53 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
  Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
	linux-kernel, Ryan Chen, Krzysztof Kozlowski

Add AST2700 USB3.2 PHY support.
 - Supports Super Speed Plus Gen2x1 (10 Gbps), Super Speed (5 Gbps),
   High Speed (480 Mbps), Full Speed (12Mbps), and Low Speed (1.5 Mbps).

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
Changes in v2:
- aspeed,ast2700-usb3-phy.yaml
 - Drop clocks, resets descripton.
- Kconfig
 - add COMPILE_TEST, remove default n
- Link to v1: https://lore.kernel.org/r/20260114-upstream_usb3phy-v1-0-2e59590be2d7@aspeedtech.com

---
Ryan Chen (3):
      dt-bindings: phy: aspeed: Document AST2700 USB3.0 PHY
      phy: add AST2700 usb3.2 phy driver
      MAINTAINERS: Add ASPEED USB3 PHY driver

 .../bindings/phy/aspeed,ast2700-usb3-phy.yaml      |  48 +++++
 MAINTAINERS                                        |   8 +
 drivers/phy/aspeed/Kconfig                         |  12 ++
 drivers/phy/aspeed/Makefile                        |   2 +
 drivers/phy/aspeed/phy-aspeed-usb3.c               | 236 +++++++++++++++++++++
 5 files changed, 306 insertions(+)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20260112-upstream_usb3phy-7116f8dfe779

Best regards,
-- 
Ryan Chen <ryan_chen@aspeedtech.com>


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v8 04/10] spmi: Implement spmi_subdevice_alloc_and_add() and devm variant
From: Stephen Boyd @ 2026-01-16  2:08 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno, jic23
  Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
	neil.armstrong, sre, angelogioacchino.delregno, krzk,
	dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
	ivo.ivanov.ivanov1, abelvesa, luca.weiss, konrad.dybcio,
	mitltlatltl, krishna.kurapati, linux-arm-msm, linux-iio,
	linux-kernel, linux-phy, linux-pm, kernel, Jonathan Cameron
In-Reply-To: <20260114092742.13231-5-angelogioacchino.delregno@collabora.com>

Quoting AngeloGioacchino Del Regno (2026-01-14 03:27:36)
> Some devices connected over the SPMI bus may be big, in the sense
> that those may be a complex of devices managed by a single chip
> over the SPMI bus, reachable through a single SID.
> 
> Add new functions aimed at managing sub-devices of a SPMI device
> spmi_subdevice_alloc_and_add() and a spmi_subdevice_put_and_remove()
> for adding a new subdevice and removing it respectively, and also
> add their devm_* variants.
> 
> The need for such functions comes from the existence of those
> complex Power Management ICs (PMICs), which feature one or many
> sub-devices, in some cases with these being even addressable on
> the chip in form of SPMI register ranges.
> 
> Examples of those devices can be found in both Qualcomm platforms
> with their PMICs having PON, RTC, SDAM, GPIO controller, and other
> sub-devices, and in newer MediaTek platforms showing similar HW
> features and a similar layout with those also having many subdevs.
> 
> Also, instead of generally exporting symbols, export them with a
> new "SPMI" namespace: all users will have to import this namespace
> to make use of the newly introduced exports.
> 
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---

Acked-by: Stephen Boyd <sboyd@kernel.org>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v8 03/10] spmi: Remove unneeded goto in spmi_device_add() error path
From: Stephen Boyd @ 2026-01-16  2:03 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno, jic23
  Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
	neil.armstrong, sre, angelogioacchino.delregno, krzk,
	dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
	ivo.ivanov.ivanov1, abelvesa, luca.weiss, konrad.dybcio,
	mitltlatltl, krishna.kurapati, linux-arm-msm, linux-iio,
	linux-kernel, linux-phy, linux-pm, kernel
In-Reply-To: <20260114092742.13231-4-angelogioacchino.delregno@collabora.com>

Quoting AngeloGioacchino Del Regno (2026-01-14 03:27:35)
> If any error happens during device_add() just return inside of the
> conditional, as the goto path doesn't do anything else if not just
> returning.
> 
> While at it, to improve readability, also change this function to
> explicitly return 0 (for success) at the end.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---

Acked-by: Stephen Boyd <sboyd@kernel.org>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v8 02/10] spmi: Print error status with %pe format
From: Stephen Boyd @ 2026-01-16  2:03 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno, jic23
  Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
	neil.armstrong, sre, angelogioacchino.delregno, krzk,
	dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
	ivo.ivanov.ivanov1, abelvesa, luca.weiss, konrad.dybcio,
	mitltlatltl, krishna.kurapati, linux-arm-msm, linux-iio,
	linux-kernel, linux-phy, linux-pm, kernel
In-Reply-To: <20260114092742.13231-3-angelogioacchino.delregno@collabora.com>

Quoting AngeloGioacchino Del Regno (2026-01-14 03:27:34)
> Instead of printing just a number, use the %pe format for error
> status, increasing readability of error prints.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---

Acked-by: Stephen Boyd <sboyd@kernel.org>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v8 01/10] spmi: Remove redundant dev_name() print in spmi_device_add()
From: Stephen Boyd @ 2026-01-16  2:03 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno, jic23
  Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
	neil.armstrong, sre, angelogioacchino.delregno, krzk,
	dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
	ivo.ivanov.ivanov1, abelvesa, luca.weiss, konrad.dybcio,
	mitltlatltl, krishna.kurapati, linux-arm-msm, linux-iio,
	linux-kernel, linux-phy, linux-pm, kernel
In-Reply-To: <20260114092742.13231-2-angelogioacchino.delregno@collabora.com>

Quoting AngeloGioacchino Del Regno (2026-01-14 03:27:33)
> Function spmi_device_add() uses dev_{dbg,err}() for respectively
> debug and error prints, and passes the same device pointer as both
> the dev_{dbg,err}() parameters and to a dev_name() that is part of
> the actual message.
> This means that the device name gets printed twice!
> 
> Remove the redundant dev_name() from the messages.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---

Acked-by: Stephen Boyd <sboyd@kernel.org>

-- 
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: axiado: add Axiado eMMC PHY driver
From: kernel test robot @ 2026-01-15 22:22 UTC (permalink / raw)
  To: Tzu-Hao Wei, SriNavmani A, Prasad Bolisetty, Vinod Koul,
	Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley
  Cc: oe-kbuild-all, linux-phy, devicetree, linux-arm-kernel,
	linux-kernel, openbmc, Tzu-Hao Wei
In-Reply-To: <20260109-axiado-ax3000-add-emmc-phy-driver-support-v1-2-dd43459dbfea@axiado.com>

Hi Tzu-Hao,

kernel test robot noticed the following build errors:

[auto build test ERROR on f0b9d8eb98dfee8d00419aa07543bdc2c1a44fb1]

url:    https://github.com/intel-lab-lkp/linux/commits/Tzu-Hao-Wei/dt-bindings-phy-axiado-ax3000-emmc-phy-add-Axiado-eMMC-PHY/20260109-174938
base:   f0b9d8eb98dfee8d00419aa07543bdc2c1a44fb1
patch link:    https://lore.kernel.org/r/20260109-axiado-ax3000-add-emmc-phy-driver-support-v1-2-dd43459dbfea%40axiado.com
patch subject: [PATCH 2/4] phy: axiado: add Axiado eMMC PHY driver
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20260116/202601160610.y8FbB5x1-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260116/202601160610.y8FbB5x1-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601160610.y8FbB5x1-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/linux/swab.h:5,
                    from include/uapi/linux/byteorder/big_endian.h:14,
                    from include/linux/byteorder/big_endian.h:5,
                    from arch/m68k/include/uapi/asm/byteorder.h:5,
                    from include/asm-generic/bitops/le.h:6,
                    from arch/m68k/include/asm/bitops.h:569,
                    from include/linux/bitops.h:67,
                    from include/linux/thread_info.h:27,
                    from include/asm-generic/preempt.h:5,
                    from ./arch/m68k/include/generated/asm/preempt.h:1,
                    from include/linux/preempt.h:79,
                    from arch/m68k/include/asm/processor.h:11,
                    from include/linux/sched.h:13,
                    from include/linux/delay.h:13,
                    from drivers/phy/axiado/phy-axiado-emmc.c:11:
   drivers/phy/axiado/phy-axiado-emmc.c: In function 'axiado_emmc_phy_power_on':
>> drivers/phy/axiado/phy-axiado-emmc.c:69:34: error: implicit declaration of function 'FIELD_PREP' [-Wimplicit-function-declaration]
      69 | #define OTAP_SEL(x)             (FIELD_PREP(OTAP_SEL_MASK, x) | OTAPDLY_EN)
         |                                  ^~~~~~~~~~
   include/uapi/linux/swab.h:118:38: note: in definition of macro '__swab32'
     118 |         (__u32)(__builtin_constant_p(x) ?       \
         |                                      ^
   include/linux/byteorder/generic.h:88:21: note: in expansion of macro '__cpu_to_le32'
      88 | #define cpu_to_le32 __cpu_to_le32
         |                     ^~~~~~~~~~~~~
   arch/m68k/include/asm/io_mm.h:373:26: note: in expansion of macro 'out_le32'
     373 | #define writel(val,addr) out_le32((addr),(val))
         |                          ^~~~~~~~
   drivers/phy/axiado/phy-axiado-emmc.c:147:9: note: in expansion of macro 'writel'
     147 |         writel(val | OTAP_SEL(OTAP_DLY), ax_phy->reg_base + PHY_CTRL_2);
         |         ^~~~~~
   drivers/phy/axiado/phy-axiado-emmc.c:147:22: note: in expansion of macro 'OTAP_SEL'
     147 |         writel(val | OTAP_SEL(OTAP_DLY), ax_phy->reg_base + PHY_CTRL_2);
         |                      ^~~~~~~~


vim +/FIELD_PREP +69 drivers/phy/axiado/phy-axiado-emmc.c

  > 11	#include <linux/delay.h>
    12	#include <linux/io.h>
    13	#include <linux/iopoll.h>
    14	#include <linux/module.h>
    15	#include <linux/of.h>
    16	#include <linux/phy/phy.h>
    17	#include <linux/platform_device.h>
    18	
    19	/* Arasan eMMC 5.1 - PHY configuration registers */
    20	#define CAP_REG_IN_S1_LSB		0x00
    21	#define CAP_REG_IN_S1_MSB		0x04
    22	#define PHY_CTRL_1			0x38
    23	#define PHY_CTRL_2			0x3C
    24	#define PHY_CTRL_3			0x40
    25	#define STATUS				0x50
    26	
    27	#define DLL_ENBL	BIT(26)
    28	#define RTRIM_EN	BIT(21)
    29	#define PDB_ENBL	BIT(23)
    30	#define RETB_ENBL	BIT(1)
    31	
    32	#define REN_STRB	BIT(27)
    33	#define REN_CMD		BIT(12)
    34	#define REN_DAT0	BIT(13)
    35	#define REN_DAT1	BIT(14)
    36	#define REN_DAT2	BIT(15)
    37	#define REN_DAT3	BIT(16)
    38	#define REN_DAT4	BIT(17)
    39	#define REN_DAT5	BIT(18)
    40	#define REN_DAT6	BIT(19)
    41	#define REN_DAT7	BIT(20)
    42	#define REN_CMD_EN	(REN_CMD | REN_DAT0 | REN_DAT1 | REN_DAT2 | \
    43			REN_DAT3 | REN_DAT4 | REN_DAT5 | REN_DAT6 | REN_DAT7)
    44	
    45	/* Pull-UP Enable on CMD Line */
    46	#define PU_CMD		BIT(3)
    47	#define PU_DAT0		BIT(4)
    48	#define PU_DAT1		BIT(5)
    49	#define PU_DAT2		BIT(6)
    50	#define PU_DAT3		BIT(7)
    51	#define PU_DAT4		BIT(8)
    52	#define PU_DAT5		BIT(9)
    53	#define PU_DAT6		BIT(10)
    54	#define PU_DAT7		BIT(11)
    55	#define PU_CMD_EN (PU_CMD | PU_DAT0 | PU_DAT1 | PU_DAT2 | PU_DAT3 | \
    56			PU_DAT4 | PU_DAT5 | PU_DAT6 | PU_DAT7)
    57	
    58	/* Selection value for the optimum delay from 1-32 output tap lines */
    59	#define OTAP_DLY	0x02
    60	/* DLL charge pump current trim default [1000] */
    61	#define DLL_TRM_ICP	0x08
    62	/* Select the frequency range of DLL Operation */
    63	#define FRQ_SEL	0x01
    64	
    65	#define OTAP_SEL_MASK		GENMASK(10, 7)
    66	#define DLL_TRM_MASK		GENMASK(25, 22)
    67	#define DLL_FRQSEL_MASK		GENMASK(27, 25)
    68	
  > 69	#define OTAP_SEL(x)		(FIELD_PREP(OTAP_SEL_MASK, x) | OTAPDLY_EN)
    70	#define DLL_TRM(x)		(FIELD_PREP(DLL_TRM_MASK, x) | DLL_ENBL)
    71	#define DLL_FRQSEL(x)	FIELD_PREP(DLL_FRQSEL_MASK, x)
    72	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH 00/27] clk: remove deprecated API divider_round_rate() and friends
From: Dmitry Baryshkov @ 2026-01-15 21:05 UTC (permalink / raw)
  To: Michael Turquette, Stephen Boyd, Brian Masney
  Cc: linux-clk, linux-kernel, Chen Wang, Inochi Amaoto, sophgo,
	Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec, Samuel Holland,
	linux-arm-kernel, linux-sunxi, Alexandre Belloni, linux-rtc,
	Andreas Färber, Manivannan Sadhasivam, linux-actions,
	Keguang Zhang, linux-mips, Taichi Sugaya, Takao Orito,
	Jacky Huang, Shan-Chun Hung, Vladimir Zapolskiy,
	Piotr Wojtaszczyk, Bjorn Andersson, linux-arm-msm, Orson Zhai,
	Baolin Wang, Chunyan Zhang, Maxime Coquelin, Alexandre Torgue,
	linux-stm32, Michal Simek, Rob Clark, Dmitry Baryshkov,
	David Airlie, Simona Vetter, Abhinav Kumar, Jessica Zhang,
	Sean Paul, Marijn Suijten, dri-devel, freedreno, Vinod Koul,
	Neil Armstrong, linux-phy
In-Reply-To: <20260108-clk-divider-round-rate-v1-0-535a3ed73bf3@redhat.com>

On Thu, 08 Jan 2026 16:16:18 -0500, Brian Masney wrote:
> Here's a series that gets rid of the deprecated APIs
> divider_round_rate(), divider_round_rate_parent(), and
> divider_ro_round_rate_parent() since these functions are just wrappers
> for the determine_rate variant.
> 
> Note that when I converted some of these drivers from round_rate to
> determine_rate, this was mistakenly converted to the following in some
> cases:
> 
> [...]

Applied to msm-next, thanks!

[24/27] drm/msm/dsi_phy_14nm: convert from divider_round_rate() to divider_determine_rate()
        https://gitlab.freedesktop.org/lumag/msm/-/commit/1d232f793d4d

Best regards,
-- 
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 1/4] dt-bindings: phy: Add Canaan K230 USB PHY
From: Rob Herring (Arm) @ 2026-01-15 20:03 UTC (permalink / raw)
  To: Jiayu Du
  Cc: devicetree, vkoul, TroyMitchell988, linux-usb, conor, kingxukai,
	linux-riscv, alex, pjw, linux-kernel, krzk+dt, gaohan, cyy,
	gregkh, linux-phy, aou, neil.armstrong, conor+dt, palmer,
	18771902331
In-Reply-To: <20260115064223.21926-2-jiayu.riscv@isrc.iscas.ac.cn>


On Thu, 15 Jan 2026 14:42:19 +0800, Jiayu Du wrote:
> K230 SoC USB PHY requires configuring registers for control and
> configuration. Add USB phy bindings for K230 SoC.
> 
> Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
> ---
>  .../bindings/phy/canaan,k230-usb-phy.yaml     | 35 +++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
> 

Reviewed-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 phy 2/8] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation
From: Rob Herring (Arm) @ 2026-01-15 19:52 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: netdev, Kishon Vijay Abraham I, Vinod Koul, Krzysztof Kozlowski,
	linux-phy, Neil Armstrong, Josua Mayer, Conor Dooley,
	linux-kernel, devicetree, Ioana Ciornei
In-Reply-To: <20260114152111.625350-3-vladimir.oltean@nxp.com>


On Wed, 14 Jan 2026 17:21:05 +0200, Vladimir Oltean wrote:
> The 28G Lynx SerDes is instantiated 3 times in the NXP LX2160A SoC and
> twice in the NXP LX2162A. All these instances share the same register
> map, but the number of lanes and the protocols supported by each lane
> differs in a way that isn't detectable by the programming model.
> 
> Going by the generic "fsl,lynx-28g" compatible string and expecting all
> SerDes instantiations to use it was a mistake that needs to be fixed.
> 
> The two major options considered are
> (a) encode the SoC and the SerDes instance in the compatible string,
>     everything else is the responsibility of the driver to derive based
>     on this sufficient information
> (b) add sufficient device tree properties to describe the per-lane
>     differences, as well as the different lane count
> 
> Another important consideration is that any decision made here should
> be consistent with the decisions taken for the yet-to-be-introduced
> 10G Lynx SerDes (older generation for older SoCs), because of how
> similar they are.
> 
> I've seen option (b) at play in this unmerged patch set for the 10G Lynx
> here, and I didn't like it:
> https://lore.kernel.org/linux-phy/20230413160607.4128315-3-sean.anderson@seco.com/
> 
> This is because there, we have a higher degree of variability in the
> PCCR register values that need to be written per protocol. This makes
> that approach more drawn-out and more prone to errors, compared to (a)
> which is more succinct and obviously correct.
> 
> So I've chosen option (a) through elimination, and this also reflects
> how the SoC reference manual provides different tables with protocol
> combinations for each SerDes. NXP clearly documents these as not
> identical, and refers to them as such (SerDes 1, 2, etc).
> 
> The per-SoC compatible string is prepended to the "fsl,lynx-28g" generic
> compatible, which is left there for compatibility with old kernels. An
> exception would be LX2160A SerDes #3, which at the time of writing is
> not described in fsl-lx2160a.dtsi, and is a non-networking SerDes, so
> the existing Linux driver is useless for it. So there is no practical
> reason to put the "fsl,lynx-28g" fallback for "fsl,lx2160a-serdes3".
> 
> The specific compatible strings give us the opportunity to express more
> constraints in the schema that we weren't able to express before:
> - We allow #phy-cells in the top-level SerDes node only for
>   compatibility with old kernels that don't know how to translate
>   "phys = <&serdes_1_lane_a>" to a PHY. We don't need that feature for
>   the not-yet-introduced LX2160A SerDes #3, so make the presence of
>   #phy-cells at the top level be dependent on the presence of the
>   "fsl,lynx-28g" fallback compatible.
> - The modernization of the compatible string should come together with
>   per-lane OF nodes.
> - LX2162A SerDes 1 has fewer lanes than the others, and trying to use
>   lanes 0-3 would be a mistake that could be caught by the schema.
> 
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> part 1 -> part 2:
> - drop everything having to do with constraints (on #phy-cells,
>   #address-cells, #size-cells) based on new compatible strings.
> 
> Patch made its last appearance in v4 from part 1:
> https://lore.kernel.org/linux-phy/20251110092241.1306838-16-vladimir.oltean@nxp.com/
> 
> v3->v4:
> - OF nodes per lane broken out as a separate "[PATCH v4 phy 01/16]
>   dt-bindings: phy: lynx-28g: permit lane OF PHY providers"
> - rewritten commit message
> - s|"^phy@[0-9a-f]+$"|"^phy@[0-7]$"|g in patternProperties
> - define "#address-cells" and "#size-cells" as part of common
>   properties, only leave the part which marks them required in the allOf
>   constraints area
> v2->v3:
> - re-add "fsl,lynx-28g" as fallback compatible, and #phy-cells = <1> in
>   top-level "serdes" node
> - drop useless description texts
> - fix text formatting
> - schema is more lax to allow overlaying old and new required properties
> v1->v2:
> - drop the usage of "fsl,lynx-28g" as a fallback compatible
> - mark "fsl,lynx-28g" as deprecated
> - implement Josua's request for per-lane OF nodes for the new compatible
>   strings
> 
>  .../devicetree/bindings/phy/fsl,lynx-28g.yaml | 33 +++++++++++++++++--
>  1 file changed, 30 insertions(+), 3 deletions(-)
> 

Reviewed-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 net-next 05/14] net: stmmac: add stmmac core serdes support
From: Russell King (Oracle) @ 2026-01-15 15:15 UTC (permalink / raw)
  To: Maxime Chevallier
  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, Mohd Ayaan Anwar, Neil Armstrong, netdev,
	Paolo Abeni, Vinod Koul
In-Reply-To: <a91a0937-93cd-40f2-9759-8823fb08f48c@bootlin.com>

On Thu, Jan 15, 2026 at 03:48:40PM +0100, Maxime Chevallier wrote:
> Hi Russell,
> 
> On 14/01/2026 18:45, Russell King (Oracle) wrote:
> > Rather than having platform glue implement SerDes PHY support, add it
> > to the core driver, specifically to the stmmac integrated PCS driver
> > as the SerDes is connected to the integrated PCS.
> > 
> > Platforms using external PCS can also populate plat->serdes, and the
> > core driver will call phy_init() and phy_exit() when the administrative
> > state of the interface changes, but the other phy methods will not be
> > called.
> > 
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> 
> Unfortunately I have no way to test. But still,

I am hoping Mohd Ayaan Anwar will be able to do at least some testing
on the qcom-ethqos hardware.

-- 
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 2/2] dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
From: Rob Herring @ 2026-01-15 14:51 UTC (permalink / raw)
  To: Charan Pedumuru
  Cc: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Conor Dooley,
	Kishon Vijay Abraham I, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260107-ti-phy-v2-2-a1ec27401fff@gmail.com>

On Wed, Jan 07, 2026 at 04:11:16PM +0000, Charan Pedumuru wrote:
> Convert TI OMAP Control PHY binding to DT schema.
> Changes during conversion:
> - Define a new pattern 'control-phy' to match nodes defined in DT.
> 
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
> ---
>  .../bindings/phy/ti,control-phy-otghs.yaml         | 94 +++++++++++++++++++++
>  Documentation/devicetree/bindings/phy/ti-phy.txt   | 98 ----------------------
>  2 files changed, 94 insertions(+), 98 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml b/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml
> new file mode 100644
> index 000000000000..2c91609cac35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/ti,control-phy-otghs.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI OMAP Control PHY Module
> +
> +maintainers:
> +  - Kishon Vijay Abraham I <kishon@ti.com>
> +
> +description:
> +  The TI OMAP Control PHY module is a hardware block within the system
> +  control module (SCM) of Texas Instruments OMAP SoCs. It provides
> +  centralized control over power, configuration, and auxiliary features
> +  for multiple on-chip PHYs. This module is essential for proper PHY
> +  operation in power-constrained embedded systems.
> +
> +properties:
> +  $nodename:
> +    pattern: "^control-phy(@[0-9a-f]+)?$"

Drop. Non-standard.

> +
> +  compatible:
> +    enum:
> +      - ti,control-phy-otghs
> +      - ti,control-phy-usb2
> +      - ti,control-phy-pipe3
> +      - ti,control-phy-pcie
> +      - ti,control-phy-usb2-dra7
> +      - ti,control-phy-usb2-am437

Alphabetical order

> +
> +  reg:
> +    minItems: 1
> +    maxItems: 4

With the constraints below, there is no case that allows 4 entries.

> +
> +  reg-names:
> +    minItems: 1
> +    maxItems: 4
> +    items:
> +      enum: [otghs_control, power, pcie_pcs, control_sma]
> +
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - ti,control-phy-otghs
> +    then:
> +      properties:
> +        reg-names:
> +          const: otghs_control
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - ti,control-phy-pcie

There's no .dts with this compatible. Do you really need this 
compatible or can drop it?

> +    then:
> +      properties:
> +        reg-names:
> +          items:
> +            - enum: [power, pcie_pcs, control_sma]

It's really 1 entry of 3 possible names?

> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - ti,control-phy-usb2
> +              - ti,control-phy-usb2-dra7
> +              - ti,control-phy-usb2-am437
> +              - ti,control-phy-pipe3
> +    then:
> +      properties:
> +        reg-names:
> +          const: power
> +
> +required:
> +  - reg
> +  - compatible
> +  - reg-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    control-phy@4a00233c {

phy@...

> +        compatible = "ti,control-phy-otghs";
> +        reg = <0x4a00233c 0x4>;
> +        reg-names = "otghs_control";
> +    };
> +...
> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
> deleted file mode 100644
> index 7c7936b89f2c..000000000000
> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
> +++ /dev/null
> @@ -1,98 +0,0 @@
> -TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
> -
> -OMAP CONTROL PHY
> -
> -Required properties:
> - - compatible: Should be one of
> - "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
> - "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
> -                        e.g. USB2_PHY on OMAP5.
> - "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
> -                        e.g. USB3 PHY and SATA PHY on OMAP5.
> - "ti,control-phy-pcie" - for pcie to support external clock for pcie and to
> -			set PCS delay value.
> -			e.g. PCIE PHY in DRA7x
> - "ti,control-phy-usb2-dra7" - if it has power down register like USB2 PHY on
> -                        DRA7 platform.
> - "ti,control-phy-usb2-am437" - if it has power down register like USB2 PHY on
> -                        AM437 platform.
> - - reg : register ranges as listed in the reg-names property
> - - reg-names: "otghs_control" for control-phy-otghs
> -	      "power", "pcie_pcs" and "control_sma" for control-phy-pcie
> -	      "power" for all other types
> -
> -omap_control_usb: omap-control-usb@4a002300 {
> -        compatible = "ti,control-phy-otghs";
> -        reg = <0x4a00233c 0x4>;
> -        reg-names = "otghs_control";
> -};
> -
> -TI PIPE3 PHY
> -
> -Required properties:
> - - compatible: Should be "ti,phy-usb3", "ti,phy-pipe3-sata" or
> -   "ti,phy-pipe3-pcie. "ti,omap-usb3" is deprecated.
> - - reg : Address and length of the register set for the device.
> - - reg-names: The names of the register addresses corresponding to the registers
> -   filled in "reg".
> - - #phy-cells: determine the number of cells that should be given in the
> -   phandle while referencing this phy.
> - - clocks: a list of phandles and clock-specifier pairs, one for each entry in
> -   clock-names.
> - - clock-names: should include:
> -   * "wkupclk" - wakeup clock.
> -   * "sysclk" - system clock.
> -   * "refclk" - reference clock.
> -   * "dpll_ref" - external dpll ref clk
> -   * "dpll_ref_m2" - external dpll ref clk
> -   * "phy-div" - divider for apll
> -   * "div-clk" - apll clock
> -
> -Optional properties:
> - - id: If there are multiple instance of the same type, in order to
> -   differentiate between each instance "id" can be used (e.g., multi-lane PCIe
> -   PHY). If "id" is not provided, it is set to default value of '1'.
> - - syscon-pllreset: Handle to system control region that contains the
> -   CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
> -   register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
> - - syscon-pcs : phandle/offset pair. Phandle to the system control module and the
> -   register offset to write the PCS delay value.
> -
> -Deprecated properties:
> - - ctrl-module : phandle of the control module used by PHY driver to power on
> -   the PHY.
> -
> -Recommended properties:
> - - syscon-phy-power : phandle/offset pair. Phandle to the system control
> -   module and the register offset to power on/off the PHY.
> -
> -This is usually a subnode of ocp2scp to which it is connected.
> -
> -usb3phy@4a084400 {
> -	compatible = "ti,phy-usb3";
> -	reg = <0x4a084400 0x80>,
> -	      <0x4a084800 0x64>,
> -	      <0x4a084c00 0x40>;
> -	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
> -	ctrl-module = <&omap_control_usb>;
> -	#phy-cells = <0>;
> -	clocks = <&usb_phy_cm_clk32k>,
> -		 <&sys_clkin>,
> -		 <&usb_otg_ss_refclk960m>;
> -	clock-names =	"wkupclk",
> -			"sysclk",
> -			"refclk";
> -};
> -
> -sata_phy: phy@4a096000 {
> -	compatible = "ti,phy-pipe3-sata";
> -	reg = <0x4A096000 0x80>, /* phy_rx */
> -	      <0x4A096400 0x64>, /* phy_tx */
> -	      <0x4A096800 0x40>; /* pll_ctrl */
> -	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
> -	ctrl-module = <&omap_control_sata>;
> -	clocks = <&sys_clkin1>, <&sata_ref_clk>;
> -	clock-names = "sysclk", "refclk";
> -	syscon-pllreset = <&scm_conf 0x3fc>;
> -	#phy-cells = <0>;
> -};
> 
> -- 
> 2.52.0
> 

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH net-next 05/14] net: stmmac: add stmmac core serdes support
From: Maxime Chevallier @ 2026-01-15 14:48 UTC (permalink / raw)
  To: Russell King (Oracle), Andrew Lunn, Heiner Kallweit
  Cc: 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, Mohd Ayaan Anwar,
	Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <E1vg4w2-00000003SG5-2FH5@rmk-PC.armlinux.org.uk>

Hi Russell,

On 14/01/2026 18:45, Russell King (Oracle) wrote:
> Rather than having platform glue implement SerDes PHY support, add it
> to the core driver, specifically to the stmmac integrated PCS driver
> as the SerDes is connected to the integrated PCS.
> 
> Platforms using external PCS can also populate plat->serdes, and the
> core driver will call phy_init() and phy_exit() when the administrative
> state of the interface changes, but the other phy methods will not be
> called.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Unfortunately I have no way to test. But still,

Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Maxime

> ---
>  drivers/net/ethernet/stmicro/stmmac/Makefile  |   2 +-
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c |  14 ++-
>  .../net/ethernet/stmicro/stmmac/stmmac_pcs.c  |  38 +++++-
>  .../net/ethernet/stmicro/stmmac/stmmac_pcs.h  |   1 +
>  .../ethernet/stmicro/stmmac/stmmac_serdes.c   | 111 ++++++++++++++++++
>  .../ethernet/stmicro/stmmac/stmmac_serdes.h   |  16 +++
>  include/linux/stmmac.h                        |   2 +
>  7 files changed, 180 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.h
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
> index c9263987ef8d..a3c2cd5d0c91 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
> @@ -7,7 +7,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o	\
>  	      dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o hwif.o \
>  	      stmmac_tc.o dwxgmac2_core.o dwxgmac2_dma.o dwxgmac2_descs.o \
>  	      stmmac_xdp.o stmmac_est.o stmmac_fpe.o stmmac_vlan.o \
> -	      stmmac_pcs.o $(stmmac-y)
> +	      stmmac_pcs.o stmmac_serdes.o $(stmmac-y)
>  
>  stmmac-$(CONFIG_STMMAC_SELFTESTS) += stmmac_selftests.o
>  
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 24a2555ca329..6c515f9efbe7 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -48,6 +48,7 @@
>  #include "stmmac_fpe.h"
>  #include "stmmac.h"
>  #include "stmmac_pcs.h"
> +#include "stmmac_serdes.h"
>  #include "stmmac_xdp.h"
>  #include <linux/reset.h>
>  #include <linux/of_mdio.h>
> @@ -3549,12 +3550,16 @@ static void stmmac_safety_feat_configuration(struct stmmac_priv *priv)
>  
>  static void stmmac_clk_rx_i_require(struct stmmac_priv *priv)
>  {
> +	dwmac_serdes_power_on(priv);
> +	/* Only sets the SerDes mode if it wasn't already configured. */
> +	dwmac_serdes_init_mode(priv, priv->plat->phy_interface);
>  	phylink_rx_clk_stop_block(priv->phylink);
>  }
>  
>  static void stmmac_clk_rx_i_release(struct stmmac_priv *priv)
>  {
>  	phylink_rx_clk_stop_unblock(priv->phylink);
> +	dwmac_serdes_power_off(priv);
>  }
>  
>  /**
> @@ -4152,10 +4157,14 @@ static int stmmac_open(struct net_device *dev)
>  	if (ret)
>  		goto err_runtime_pm;
>  
> -	ret = __stmmac_open(dev, dma_conf);
> +	ret = dwmac_serdes_init(priv);
>  	if (ret)
>  		goto err_disconnect_phy;
>  
> +	ret = __stmmac_open(dev, dma_conf);
> +	if (ret)
> +		goto err_serdes;
> +
>  	kfree(dma_conf);
>  
>  	/* We may have called phylink_speed_down before */
> @@ -4163,6 +4172,8 @@ static int stmmac_open(struct net_device *dev)
>  
>  	return ret;
>  
> +err_serdes:
> +	dwmac_serdes_exit(priv);
>  err_disconnect_phy:
>  	phylink_disconnect_phy(priv->phylink);
>  err_runtime_pm:
> @@ -4226,6 +4237,7 @@ static int stmmac_release(struct net_device *dev)
>  
>  	__stmmac_release(dev);
>  
> +	dwmac_serdes_exit(priv);
>  	phylink_disconnect_phy(priv->phylink);
>  	pm_runtime_put(priv->device);
>  
> 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
> @@ -1,12 +1,25 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  #include "stmmac.h"
>  #include "stmmac_pcs.h"
> +#include "stmmac_serdes.h"
>  
>  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;
> +	}
> +
> +	stmmac_mac_irq_modify(priv, 0, spcs->int_mask);
>  
>  	return 0;
>  }
> @@ -14,8 +27,11 @@ static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
>  static void dwmac_integrated_pcs_disable(struct phylink_pcs *pcs)
>  {
>  	struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> +	struct stmmac_priv *priv = spcs->priv;
>  
> -	stmmac_mac_irq_modify(spcs->priv, spcs->int_mask, 0);
> +	stmmac_mac_irq_modify(priv, spcs->int_mask, 0);
> +
> +	dwmac_serdes_power_off(priv);
>  }
>  
>  static void dwmac_integrated_pcs_get_state(struct phylink_pcs *pcs,
> @@ -32,6 +48,15 @@ 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);
> +	int ret;
> +
> +	if (spcs->interface != interface) {
> +		ret = dwmac_serdes_set_mode(spcs->priv, interface);
> +		if (ret)
> +			return ret;
> +
> +		spcs->interface = interface;
> +	}
>  
>  	dwmac_ctrl_ane(spcs->base, 0, 1, spcs->priv->hw->reverse_sgmii_enable);
>  
> @@ -71,6 +96,7 @@ int stmmac_integrated_pcs_init(struct stmmac_priv *priv, unsigned int offset,
>  			       u32 int_mask)
>  {
>  	struct stmmac_pcs *spcs;
> +	int ret;
>  
>  	spcs = devm_kzalloc(priv->device, sizeof(*spcs), GFP_KERNEL);
>  	if (!spcs)
> @@ -81,6 +107,14 @@ int stmmac_integrated_pcs_init(struct stmmac_priv *priv, unsigned int offset,
>  	spcs->int_mask = int_mask;
>  	spcs->pcs.ops = &dwmac_integrated_pcs_ops;
>  
> +	if (priv->plat->serdes) {
> +		ret = dwmac_serdes_validate(priv, PHY_INTERFACE_MODE_SGMII);
> +		if (ret)
> +			dev_warn(priv->device,
> +				 "serdes does not support SGMII: %pe\n",
> +				 ERR_PTR(ret));
> +	}
> +
>  	__set_bit(PHY_INTERFACE_MODE_SGMII, spcs->pcs.supported_interfaces);
>  
>  	priv->integrated_pcs = spcs;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> index c4e6b242d390..36bf75fdf478 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> @@ -53,6 +53,7 @@ struct stmmac_pcs {
>  	struct stmmac_priv *priv;
>  	void __iomem *base;
>  	u32 int_mask;
> +	phy_interface_t interface;
>  	struct phylink_pcs pcs;
>  };
>  
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c
> new file mode 100644
> index 000000000000..3003e1ae38d2
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c
> @@ -0,0 +1,111 @@
> +#include <linux/phy/phy.h>
> +
> +#include "stmmac.h"
> +#include "stmmac_serdes.h"
> +
> +static phy_interface_t dwmac_serdes_phy_modes[] = {
> +	PHY_INTERFACE_MODE_SGMII,
> +	PHY_INTERFACE_MODE_1000BASEX,
> +	PHY_INTERFACE_MODE_2500BASEX
> +};
> +
> +int dwmac_serdes_validate(struct stmmac_priv *priv, phy_interface_t interface)
> +{
> +	return phy_validate(priv->plat->serdes, PHY_MODE_ETHERNET, interface,
> +			    NULL);
> +}
> +
> +int dwmac_serdes_init(struct stmmac_priv *priv)
> +{
> +	size_t i;
> +	int ret;
> +
> +	if (!priv->plat->serdes)
> +		return 0;
> +
> +	/* Encourage good implementation of the SerDes PHY driver, so that
> +	 * we can discover which Ethernet modes the SerDes supports.
> +	 * Unfortunately, some implementations are noisy (bad), others
> +	 * require phy_set_speed() to select the correct speed first
> +	 * (which then reprograms the SerDes, negating the whole point of
> +	 * phy_validate().) Weed out these incompatible implementations.
> +	 */
> +	for (i = 0; i < ARRAY_SIZE(dwmac_serdes_phy_modes); i++) {
> +		ret = phy_validate(priv->plat->serdes, PHY_MODE_ETHERNET,
> +				   dwmac_serdes_phy_modes[i], NULL);
> +		if (ret == 0 || ret == -EOPNOTSUPP)
> +			break;
> +	}
> +
> +	if (ret == -EOPNOTSUPP)
> +		dev_warn(priv->device,
> +			 "SerDes driver does not implement phy_validate()\n");
> +	if (ret) {
> +		/* The SerDes PHY failed validation, refuse to use it. */
> +		dev_warn(priv->device,
> +			 "SerDes driver fails to validate SGMII, 1000BASE-X nor 2500BASE-X\n");
> +		return -EINVAL;
> +	}
> +
> +	ret = phy_init(priv->plat->serdes);
> +	if (ret)
> +		dev_err(priv->device, "failed to initialize SerDes: %pe\n",
> +			ERR_PTR(ret));
> +
> +	return ret;
> +}
> +
> +int dwmac_serdes_power_on(struct stmmac_priv *priv)
> +{
> +	int ret;
> +
> +	ret = phy_power_on(priv->plat->serdes);
> +	if (ret)
> +		dev_err(priv->device, "failed to power on SerDes: %pe\n",
> +			ERR_PTR(ret));
> +
> +	return ret;
> +}
> +
> +int dwmac_serdes_init_mode(struct stmmac_priv *priv, phy_interface_t interface)
> +{
> +	struct phy *serdes = priv->plat->serdes;
> +
> +	if (phy_get_mode(serdes) == PHY_MODE_ETHERNET)
> +		return 0;
> +
> +	return dwmac_serdes_set_mode(priv, interface);
> +}
> +
> +int dwmac_serdes_set_mode(struct stmmac_priv *priv, phy_interface_t interface)
> +{
> +	struct phy *serdes = priv->plat->serdes;
> +	int ret;
> +
> +	ret = phy_set_mode_ext(serdes, PHY_MODE_ETHERNET, interface);
> +	if (ret)
> +		dev_err(priv->device,
> +			"failed to set SerDes mode %s: %pe\n",
> +			phy_modes(interface), ERR_PTR(ret));
> +
> +	return ret;
> +}
> +
> +void dwmac_serdes_power_off(struct stmmac_priv *priv)
> +{
> +	int ret;
> +
> +	ret = phy_power_off(priv->plat->serdes);
> +	if (ret)
> +		dev_err(priv->device, "failed to power off SerDes: %pe\n",
> +			ERR_PTR(ret));
> +}
> +
> +void dwmac_serdes_exit(struct stmmac_priv *priv)
> +{
> +	int ret = phy_exit(priv->plat->serdes);
> +
> +	if (ret)
> +		dev_err(priv->device, "failed to shutdown SerDes: %pe\n",
> +			ERR_PTR(ret));
> +}
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.h
> new file mode 100644
> index 000000000000..a31e6c9e0570
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.h
> @@ -0,0 +1,16 @@
> +#ifndef STMMAC_SERDES_H
> +#define STMMAC_SERDES_H
> +
> +#include <linux/phy.h>
> +
> +struct stmmac_priv;
> +
> +int dwmac_serdes_validate(struct stmmac_priv *priv, phy_interface_t interface);
> +int dwmac_serdes_init(struct stmmac_priv *priv);
> +int dwmac_serdes_power_on(struct stmmac_priv *priv);
> +int dwmac_serdes_init_mode(struct stmmac_priv *priv, phy_interface_t interface);
> +int dwmac_serdes_set_mode(struct stmmac_priv *priv, phy_interface_t interface);
> +void dwmac_serdes_power_off(struct stmmac_priv *priv);
> +void dwmac_serdes_exit(struct stmmac_priv *priv);
> +
> +#endif
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index f1054b9c2d8a..4db506e5cf13 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -193,6 +193,7 @@ enum dwmac_core_type {
>  #define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(13)
>  
>  struct mac_device_info;
> +struct phy;
>  
>  struct plat_stmmacenet_data {
>  	enum dwmac_core_type core_type;
> @@ -222,6 +223,7 @@ struct plat_stmmacenet_data {
>  	 * that phylink uses.
>  	 */
>  	phy_interface_t phy_interface;
> +	struct phy *serdes;
>  	struct stmmac_mdio_bus_data *mdio_bus_data;
>  	struct device_node *phy_node;
>  	struct fwnode_handle *port_node;


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH net-next 04/14] net: stmmac: wrap phylink's rx_clk_stop functions
From: Maxime Chevallier @ 2026-01-15 14:47 UTC (permalink / raw)
  To: Russell King (Oracle), Andrew Lunn, Heiner Kallweit
  Cc: 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, Mohd Ayaan Anwar,
	Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <E1vg4vx-00000003SFz-1ldy@rmk-PC.armlinux.org.uk>

Hi Russell,

On 14/01/2026 18:45, Russell King (Oracle) wrote:
> With generic SerDes support, stmmac will need to do more work to ensure
> that clk_rx_i is running in all configurations. Rather than turn each
> site that calls phylink_rx_clk_stop_xxx() into a list of functions,
> move these to their own pair of functions so that they can be
> augmented at a single location.
> 
> 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 1/2] dt-bindings: phy: ti,phy-usb3: convert to DT schema
From: Rob Herring @ 2026-01-15 14:45 UTC (permalink / raw)
  To: Charan Pedumuru
  Cc: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Conor Dooley,
	Kishon Vijay Abraham I, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260107-ti-phy-v2-1-a1ec27401fff@gmail.com>

On Wed, Jan 07, 2026 at 04:11:15PM +0000, Charan Pedumuru wrote:
> Convert TI PIPE3 PHY binding to DT schema.
> Changes during conversion:
> - Define a new pattern 'pciephy' to match nodes defined in DT.
> - Drop obsolete "id" property from the schema.
> 
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
> ---
>  .../devicetree/bindings/phy/ti,phy-usb3.yaml       | 127 +++++++++++++++++++++
>  1 file changed, 127 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
> new file mode 100644
> index 000000000000..41b3828723ae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/ti,phy-usb3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI PIPE3 PHY Module
> +
> +maintainers:
> +  - Kishon Vijay Abraham I <kishon@ti.com>
> +
> +description:
> +  The TI PIPE3 PHY is a high-speed SerDes (Serializer/Deserializer)
> +  transceiver integrated in OMAP5, DRA7xx/AM57xx, and similar SoCs.
> +  It supports multiple protocols (USB3, SATA, PCIe) using the PIPE3
> +  interface standard, which defines a common physical layer for
> +  high-speed serial interfaces.
> +
> +properties:
> +  $nodename:
> +    pattern: "^(pciephy|usb3phy|phy)(@[0-9a-f]+)?$"

Again, don't define your own patterns. Either update the .dts files to 
use the established patterns (pcie-phy, usb3-phy, phy) or leave it 
undefined here.

Plus the unit-address is not optional as 'reg' is not optional...

> +
> +  compatible:
> +    enum:
> +      - ti,phy-usb3
> +      - ti,phy-pipe3-sata
> +      - ti,phy-pipe3-pcie
> +      - ti,omap-usb3

Alphabetical order please.

> +
> +  reg:
> +    minItems: 2
> +    maxItems: 3
> +
> +  reg-names:
> +    minItems: 2
> +    maxItems: 3
> +    items:
> +      enum:
> +        - phy_rx
> +        - phy_tx
> +        - pll_ctrl

Do this really need to be any order? Looks to me like this works for all 
users in tree:

minItems: 2
items:
  - const: phy_rx
  - const: phy_tx
  - const: pll_ctrl

> +
> +  "#phy-cells":
> +    const: 0
> +
> +  clocks:
> +    minItems: 2
> +    maxItems: 7
> +
> +  clock-names:
> +    minItems: 2
> +    maxItems: 7
> +    items:
> +      enum: [wkupclk, sysclk, refclk, dpll_ref,
> +             dpll_ref_m2, phy-div, div-clk]
> +
> +  syscon-phy-power:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description:
> +      Phandle/offset pair to system control module register for PHY
> +      power on/off.

Needs constrants on the size:

items:
  - items:
      - description: phandle to ...
      - description: offset of ...

> +
> +  syscon-pllreset:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description:
> +      Phandle/offset pair to CTRL_CORE_SMA_SW_0 register containing
> +      SATA_PLL_SOFT_RESET bit (SATA PHY only).

Same here.

> +
> +  syscon-pcs:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description:
> +      Phandle/offset pair to system control module for writing PCS delay value.

Same here.

> +
> +  ctrl-module:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      Phandle of control module for PHY power on.
> +    deprecated: true
> +
> +dependencies:
> +  syscon-pllreset:
> +    properties:
> +      compatible:
> +        contains:
> +          const: ti,phy-pipe3-sata

Usually we express this the other way around:

if:
  properties:
    compatible:
      contains:
        const: ti,phy-pipe3-sata
then:
  required:
    - syscon-pllreset
else:
  properties:
    syscon-pllreset: false

But that's slightly different as syscon-pllreset is optional for 
ti,phy-pipe3-sata in your case. Seems like it should be required if 
ti,phy-pipe3-sata?


> +
> +required:
> +  - reg
> +  - compatible
> +  - reg-names
> +  - "#phy-cells"
> +  - clocks
> +  - clock-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    /* TI PIPE3 USB3 PHY */
> +    usb3phy@4a084400 {
> +        compatible = "ti,phy-usb3";
> +        reg = <0x4a084400 0x80>,
> +              <0x4a084800 0x64>,
> +              <0x4a084c00 0x40>;
> +        reg-names = "phy_rx", "phy_tx", "pll_ctrl";
> +        #phy-cells = <0>;
> +        clocks = <&usb_phy_cm_clk32k>,
> +                 <&sys_clkin>,
> +                 <&usb_otg_ss_refclk960m>;
> +        clock-names = "wkupclk", "sysclk", "refclk";
> +        ctrl-module = <&omap_control_usb>;
> +    };
> +
> +  - |
> +    /* TI PIPE3 SATA PHY */
> +    phy@4a096000 {
> +        compatible = "ti,phy-pipe3-sata";
> +        reg = <0x4A096000 0x80>,  /* phy_rx */
> +              <0x4A096400 0x64>,  /* phy_tx */
> +              <0x4A096800 0x40>;  /* pll_ctrl */
> +        reg-names = "phy_rx", "phy_tx", "pll_ctrl";
> +        clocks = <&sys_clkin1>, <&sata_ref_clk>;
> +        clock-names = "sysclk", "refclk";
> +        syscon-pllreset = <&scm_conf 0x3fc>;
> +        #phy-cells = <0>;
> +    };
> +...
> 
> -- 
> 2.52.0
> 

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v2 3/4] phy: usb: Add driver for Canaan K230 USB 2.0 PHY
From: Jiayu Du @ 2026-01-15 14:35 UTC (permalink / raw)
  To: Vinod Koul
  Cc: conor, neil.armstrong, gregkh, robh, krzk+dt, conor+dt, pjw,
	palmer, aou, alex, 18771902331, cyy, TroyMitchell988, kingxukai,
	linux-phy, linux-usb, devicetree, linux-kernel, linux-riscv,
	gaohan
In-Reply-To: <aWjYHK1cTj8Dbz2B@vaman>

On Thu, Jan 15, 2026 at 05:35:48PM +0530, Vinod Koul wrote:
> On 15-01-26, 14:42, Jiayu Du wrote:
> 
> > +static struct phy *k230_usb_phy_xlate(struct device *dev,
> > +				      const struct of_phandle_args *args)
> > +{
> > +	struct k230_usb_phy_global *global = dev_get_drvdata(dev);
> > +	struct k230_usb_phy_instance *phy_inst;
> > +	struct phy *phy;
> > +
> > +	if (args->args[0] >= MAX_PHYS)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	phy_inst = devm_kzalloc(dev, sizeof(*phy_inst), GFP_KERNEL);
> > +	if (!phy_inst)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	phy_inst->global = global;
> > +	phy_inst->index = args->args[0];
> > +
> > +	phy = devm_phy_create(dev, NULL, &k230_usb_phy_ops);
> > +	if (IS_ERR(phy))
> > +		return ERR_PTR(PTR_ERR(phy));
> > +
> > +	phy_set_drvdata(phy, phy_inst);
> 
> This seems wrong place, why is this not done in the driver probe?

You are right, creating phy instances in the xlate function is not
the right place. I will move the allocation and devm_phy_creat to
the probe phase to create both instances.

> > +	global->reg_test_offset[0] = 0x70;
> > +	global->reg_ctl_offset[0] = 0xb0;
> > +	global->reg_test_offset[1] = 0x90;
> > +	global->reg_ctl_offset[1] = 0xb8;
> 
> Where are these magic values coming from?

These offsets are from K230 Technical Reference Manual section 12.6.4.2.
The TRM is here[1]. I will define them as macros with descriptive names.

Link:
https://kendryte-download.canaan-creative.com/developer/k230/HDK/K230%E7%A1%AC%E4%BB%B6%E6%96%87%E6%A1%A3/K230_Technical_Reference_Manual_V0.3.1_20241118.pdf[1]

I will send v2 with these changes soon.

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 25/27] phy: ti: phy-j721e-wiz: convert from divider_round_rate() to divider_determine_rate()
From: Brian Masney @ 2026-01-15 14:18 UTC (permalink / raw)
  To: Vinod Koul
  Cc: Michael Turquette, Stephen Boyd, linux-clk, linux-kernel,
	Neil Armstrong, linux-phy
In-Reply-To: <aWelbtaZjS4SZGQO@vaman>

Hi Vinod,

On Wed, Jan 14, 2026 at 07:47:18PM +0530, Vinod Koul wrote:
> On 08-01-26, 16:16, Brian Masney wrote:
> > The divider_round_rate() function is now deprecated, so let's migrate
> > to divider_determine_rate() instead so that this deprecated API can be
> > removed.
> > 
> > Note that when the main function itself was migrated to use
> > determine_rate, this was mistakenly converted to:
> > 
> >     req->rate = divider_round_rate(...)
> > 
> > This is invalid in the case when an error occurs since it can set the
> > rate to a negative value.
> 
> Acked-by: Vinod Koul <vkoul@kernel.org>

Thanks for the Acked-by.

However, this patch depends on this other series of mine that's merged
into your phy tree:

https://lore.kernel.org/linux-clk/176661322399.4169.14248756511703978007@lazor/

Stephen asked for an Acked-by for that series or an immutable branch.

This will allow us to remove round_rate from the clk core.

I also have a small series to post that's dependent on all of this that
lets us get rid of the noop determine_rate implementations that only
'return 0'. I haven't posted that because of the dependencies.

Brian


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox