* Re: [PATCH net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Russell King (Oracle) @ 2026-01-24 0:16 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Konrad Dybcio, linux-arm-kernel,
linux-arm-msm, linux-phy, linux-stm32, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <20260124000409.36nsxlvkde4zpddk@skbuf>
On Sat, Jan 24, 2026 at 02:04:09AM +0200, Vladimir Oltean wrote:
> On Fri, Jan 23, 2026 at 11:13:26AM +0000, Russell King (Oracle) wrote:
> > According to patchwork, this doesn't apply to net-next. That's odd,
> > it was generated on last night's net next, and although there has been
> > further work, it rebases cleanly on top of this morning's. How can
> > these changes:
> >
> > drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 6 +++++-
> > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++++++++++----
> > 2 files changed, 21 insertions(+), 5 deletions(-)
> >
> > which happened in net-next overnight result in this change in patch 1:
> >
> > drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > failing to apply?
> >
> > No, patchwork is clearly wrong.
>
> Conflicts with commit dc6597fab3e3 ("net: stmmac: dwmac-imx: keep
> preamble before sfd on i.MX8MP"), merged in the meantime.
>
> In include/linux/stmmac.h (your commit "net: stmmac: add stmmac core
> serdes support" adds a "struct phy;" line, but that other commit
> modifies the context by inserting:
>
> #define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD BIT(14)
>
> (the last stmmac flag in your context, at patch generation time, was:
> #define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(13)
> )
I still maintain that this is silly - to mark all patches as such
and without any details about the problem applying the patches is
not helpful.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Vladimir Oltean @ 2026-01-24 0:04 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Konrad Dybcio, linux-arm-kernel,
linux-arm-msm, linux-phy, linux-stm32, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <aXNX1oi7nWLcPK28@shell.armlinux.org.uk>
On Fri, Jan 23, 2026 at 11:13:26AM +0000, Russell King (Oracle) wrote:
> According to patchwork, this doesn't apply to net-next. That's odd,
> it was generated on last night's net next, and although there has been
> further work, it rebases cleanly on top of this morning's. How can
> these changes:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 6 +++++-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++++++++++----
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> which happened in net-next overnight result in this change in patch 1:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> failing to apply?
>
> No, patchwork is clearly wrong.
Conflicts with commit dc6597fab3e3 ("net: stmmac: dwmac-imx: keep
preamble before sfd on i.MX8MP"), merged in the meantime.
In include/linux/stmmac.h (your commit "net: stmmac: add stmmac core
serdes support" adds a "struct phy;" line, but that other commit
modifies the context by inserting:
#define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD BIT(14)
(the last stmmac flag in your context, at patch generation time, was:
#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(13)
)
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: google: fix build dependency for Google Tensor USB PHY
From: Roy Luo @ 2026-01-23 23:51 UTC (permalink / raw)
To: André Draszik
Cc: Vinod Koul, Neil Armstrong, Peter Griffin, Tudor Ambarus,
Joy Chakraborty, Naveen Kumar, linux-phy, linux-kernel,
linux-arm-kernel, linux-samsung-soc, kernel test robot
In-Reply-To: <f956ccd3f5f694de7a634819da3f790a8dce132b.camel@linaro.org>
On Thu, Jan 22, 2026 at 10:28 PM André Draszik <andre.draszik@linaro.org> wrote:
>
> Hi Roy,
>
> On Thu, 2026-01-22 at 11:00 -0800, Roy Luo wrote:
> > On Thu, Jan 22, 2026 at 2:39 AM André Draszik <andre.draszik@linaro.org> wrote:
> > >
> > > Hi Roy,
> > >
> > > On Wed, 2026-01-21 at 22:21 +0000, Roy Luo wrote:
> > > > The Google Tensor USB PHY driver uses the Type-C switch framework to
> > > > handle orientation changes. However, the Kconfig did not specify a
> > > > dependency on the TYPEC framework, leading to undefined reference
> > > > errors when building for architectures or configurations where
> > > > CONFIG_TYPEC is disabled or configured as a module.
> > > >
> > > > Add 'depends on TYPEC' to the PHY_GOOGLE_USB entry to ensure all
> > > > required symbols are available during linking.
> > > >
> > > > Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
> > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > Closes: https://lore.kernel.org/oe-kbuild-all/202601210825.ELrpQeED-lkp@intel.com/
> > > > Signed-off-by: Roy Luo <royluo@google.com>
> > > > ---
> > > > drivers/phy/Kconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > > > index 142e7b0ef2efb9209781800ee47b820a91b115ae..5531ff31d8156cb164c32e3e52d4a57b26a62d8d 100644
> > > > --- a/drivers/phy/Kconfig
> > > > +++ b/drivers/phy/Kconfig
> > > > @@ -49,6 +49,7 @@ config GENERIC_PHY_MIPI_DPHY
> > > >
> > > > config PHY_GOOGLE_USB
> > > > tristate "Google Tensor SoC USB PHY driver"
> > > > + depends on TYPEC
> > >
> > > Can you make this
> > >
> > > depends on TYPEC || COMPILE_TEST
> > >
> > > to allow some better test coverage?
> > >
> > > Cheers,
> > > Andre
> >
> > Hi Andre,
> >
> > Whether to add COMPILE_TEST for build coverage was discussed in
> > another thread [1]. My takeaway from that discussion is that
> > COMPILE_TEST is intended to substitute for ARCH_XXX in build
> > testing and should not be used without it. Once ARCH_GOOGLE is
> > present, we can add "depends on (ARCH_GOOGLE || COMPILTE_TEST)".
>
> COMPILE_TEST is not limited to ARCH_xxx. It allows drivers to be
> compile tested even if the current build doesn't enable whatever
> option (like TYPEC).
>
> See also https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#compile-testing
"If a config symbol has a dependency, but the code controlled by the
config symbol can still be compiled if the dependency is not met",
TYPEC doesn't fall into this category as it's mandatory for compiling
PHY_GOOGLE_USB.
With "depends on TYPEC || COMPILE_TEST", this very build error
would resurface when TYPEC=n, COMPILE_TEST=y and
PHY_GOOGLE_USB=y. Please let me know if I missed anything.
Thanks,
Roy
>
> Cheers,
> Andre'
>
>
> >
> > [1] https://lore.kernel.org/all/CA+zupgwgfKwPYqj8G2tNf4pEXNEWA+vL2WYJPhJ16xExgko7Dw@mail.gmail.com/
> >
> > Regards,
> > Roy
--
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-23 21:32 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: <aXN5BFXMshnhwBQ7@oss.qualcomm.com>
On Fri, Jan 23, 2026 at 07:05:00PM +0530, Mohd Ayaan Anwar wrote:
> 4. Switching from 1G to 2.5G - similar issues + a NULL pointer
> dereference. I am checking on the reason for it.
For the NULL pointer dereference, this is a bit weird, and may help to
point towards the issue.
> [ 1235.996004] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
> [ 1240.517716] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
> [ 1240.529470] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
> [ 1240.537642] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
> [ 1240.546702] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
> [ 1240.555441] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
> [ 1240.880168] Code: d63f0020 f9400e60 b4000040 f900081f (f9000ad3)
This code line disassembles to:
0: d63f0020 blr x1
4: f9400e60 ldr x0, [x19, #24]
8: b4000040 cbz x0, 10 <.text+0x10>
c: f900081f str xzr, [x0, #16]
10: f9000ad3 str x19, [x22, #16]
which, after comparing with my disassembly, the blr x1 is the call to
pcs_disable() inside phylink_pcs_disable() in this code:
if (pcs_changed) {
phylink_pcs_disable(pl->pcs);
if (pl->pcs)
pl->pcs->phylink = NULL;
pcs->phylink = pl;
and the failing store is the one for that last line of C code - in
other words, pcs = NULL.
This means that mac_select_pcs() returned NULL when being asked
"which PCS should be used for 2500base-X" ?
This suggests that the SerDes detection of support for 2500BASE-X
isn't working, meaning that stmmac_mac_select_pcs() ends up returning
NULL, rather than &priv->integrated_pcs->pcs.
That would only happen if:
/* Only allow 2500Base-X if the SerDes has support. */
ret = dwmac_serdes_validate(priv, PHY_INTERFACE_MODE_2500BASEX);
if (ret == 0)
__set_bit(PHY_INTERFACE_MODE_2500BASEX,
spcs->pcs.supported_interfaces);
fails, meaning we don't set that interface mode for the PCS.
dwmac_serdes_validate() calls phy_validate() for PHY_MODE_ETHERNET
with the PHY interface mode as the sub mode.
Patch 3 adds the required methods to phy-qcom-sgmii-eth.c to allow
phy_validate() to indicate whether this is supported or not:
.validate = qcom_dwmac_sgmii_phy_validate,
and its implementation is:
int ret = qcom_dwmac_sgmii_phy_speed(mode, submode);
return ret < 0 ? ret : 0;
where qcom_dwmac_sgmii_phy_speed() is:
if (mode != PHY_MODE_ETHERNET)
return -EINVAL;
if (submode == PHY_INTERFACE_MODE_SGMII ||
submode == PHY_INTERFACE_MODE_1000BASEX)
return SPEED_1000;
if (submode == PHY_INTERFACE_MODE_2500BASEX)
return SPEED_2500;
return -EINVAL;
So, this should be returning a positive integer (SPEED_2500), which
should cause phy_validate(serdes, PHY_MODE_ETHERNET,
PHY_INTERFACE_MODE_2500BASEX, NULL) to return success (zero). That
should result in PHY_INTERFACE_MODE_2500BASEX being set in
spcs->pcs.supported_interfaces, and thus &priv->integrated_pcs->pcs
being returned for PHY_INTERFACE_MODE_2500BASEX.
Is the particular hardware you're running this oopsing test on not
using a SerDes PHY? If that's the case, how does it switch between
2.5Gbps and 1Gbps data rate on the SerDes?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Russell King (Oracle) @ 2026-01-23 17:26 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: <aXN5BFXMshnhwBQ7@oss.qualcomm.com>
On Fri, Jan 23, 2026 at 07:05:00PM +0530, Mohd Ayaan Anwar wrote:
> Hello Russell,
> On Fri, Jan 23, 2026 at 09:52:00AM +0000, Russell King (Oracle) wrote:
> > This is the v1 submission: if it doesn't get tested but review goes
> > well, it'll end up in net-next and mainline without testing on the
> > affected hardware!
> >
> > Mentioned previously, I've been trying to sort out the PCS support in
> > stmmac, and this series represents the current state of play.
> >
> > Previous posted patches centred around merely getting autonegotiation
> > to be configured correctly, to a point where the manual configuration
> > can be removed from the qcom-ethqos driver. The qcom-ethqos driver
> > uses both SGMII and 2500BASE-X, manually configuring the dwmac's
> > integrated PCS appropriately.
> >
>
> Thank you for CC'ing me on this series. Sorry, but I have been M.I.A.
> for the past couple of months due to some health issues, which caused a
> backlog at work that I had to power through. I haven't been able to
> monitor the mailing list for stmmac patches.
Sorry to hear that, but if it's any consolation, you're not alone. On
new year's eve, I had three teeth extracted, including one that was
laying horizontally in the palate of the mouth buried in bone, and
needed in bone graft (modern bone grafts are quite different from what
you'd expect btw.) It's been quite sore/painful as it heals.
> I tested v1 last night and just picked up v2. Here are my observations
> and logs (phylink logs are enabled). I haven't had time to debug the
> issues, but they are not seen on the net-next tree. One thing that I
> remember from our last discussion is the need to test with comma
> detection enabled; I will test that next.
>
> Tested on the QCS9100 Ride R3 board with 2X AQR115C PHYs. I have one
> more board that I can test next week (IQ8275, which has a single
> QCA8081 PHY, but that is limited to 2.5G because the PHY switches its
> mode according to the speed).
Thanks for testing!
Given the results you've given, my suggestion would be that the
following patches are probably the most risky:
Patch 2 "net: stmmac: qcom-ethqos: convert to set_clk_tx_rate() method"
This changes the way the clock is configured. It would be worth
testing that and giving a tested-by for the first two patches if
that's successful.
Patch 6 "net: stmmac: qcom-ethqos: convert to dwmac generic SerDes
support"
This changes how the SerDes is handled, which is a significant change.
It's possible that the PHY calibration needs some other state to be
appropriately configured, and that's not happening in the same order.
Either of these two would account for what appears to be an unstable
SerDes link.
As for the NULL pointer deref, I'll look at that in a bit (waiting
for a build to complete so I can hopefully pinpoint where the oops
is happening.)
--
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
* [PATCH v4 3/3] dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
From: Charan Pedumuru @ 2026-01-23 15:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
In-Reply-To: <20260123-ti-phy-v4-0-b557e2c46e6f@gmail.com>
Convert TI OMAP Control PHY binding to DT schema.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../bindings/phy/ti,control-phy-otghs.yaml | 99 ++++++++++++++++++++++
Documentation/devicetree/bindings/phy/ti-phy.txt | 98 ---------------------
2 files changed, 99 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..4ecb1611ee65
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml
@@ -0,0 +1,99 @@
+# 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:
+ - Roger Quadros <rogerq@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: "^phy@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - ti,control-phy-otghs
+ - ti,control-phy-pcie
+ - ti,control-phy-pipe3
+ - ti,control-phy-usb2
+ - ti,control-phy-usb2-am437
+ - ti,control-phy-usb2-dra7
+
+ reg:
+ minItems: 1
+ maxItems: 3
+
+ reg-names:
+ minItems: 1
+ maxItems: 3
+ 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
+ then:
+ properties:
+ reg:
+ minItems: 3
+
+ reg-names:
+ items:
+ - const: power
+ - const: pcie_pcs
+ - const: control_sma
+
+ - 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:
+ - |
+ phy@4a00233c {
+ 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 related
* [PATCH v4 2/3] dt-bindings: phy: ti,phy-usb3: convert to DT schema
From: Charan Pedumuru @ 2026-01-23 15:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
In-Reply-To: <20260123-ti-phy-v4-0-b557e2c46e6f@gmail.com>
Convert TI PIPE3 PHY binding to DT schema.
Changes during conversion:
- Define a new pattern 'pcie-phy' 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 | 138 +++++++++++++++++++++
1 file changed, 138 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..84f538aa587c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
@@ -0,0 +1,138 @@
+# 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:
+ - Roger Quadros <rogerq@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: "^(pcie-phy|usb3-phy|phy)@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - ti,omap-usb3
+ - ti,phy-pipe3-pcie
+ - ti,phy-pipe3-sata
+ - ti,phy-usb3
+
+ reg:
+ minItems: 2
+ maxItems: 3
+
+ reg-names:
+ 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
+ maxItems: 1
+ items:
+ items:
+ - description: Phandle to the system control module
+ - description: Register offset controlling PHY power
+
+ syscon-pllreset:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+ items:
+ items:
+ - description: Phandle to the system control module
+ - description: Register offset of CTRL_CORE_SMA_SW_0
+
+ syscon-pcs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+ items:
+ items:
+ - description: Phandle to the system control module
+ - description: Register offset for PCS delay programming
+
+ ctrl-module:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle of control module for PHY power on.
+ deprecated: true
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,phy-pipe3-sata
+ then:
+ properties:
+ syscon-pllreset: true
+ else:
+ properties:
+ syscon-pllreset: false
+
+required:
+ - reg
+ - compatible
+ - reg-names
+ - "#phy-cells"
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ /* TI PIPE3 USB3 PHY */
+ usb3-phy@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 related
* [PATCH v4 1/3] arm: dts: ti: omap: align node patterns with established convention
From: Charan Pedumuru @ 2026-01-23 15:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
In-Reply-To: <20260123-ti-phy-v4-0-b557e2c46e6f@gmail.com>
Update OMAP DTS node patterns to match established conventions.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 4 ++--
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 ++--
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
index c9282f57ffa5..ed206eb84d02 100644
--- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
@@ -328,7 +328,7 @@ ocp2scp@0 {
ranges = <0 0 0x8000>;
reg = <0x0 0x20>;
- pcie1_phy: pciephy@4000 {
+ pcie1_phy: pcie-phy@4000 {
compatible = "ti,phy-pipe3-pcie";
reg = <0x4000 0x80>, /* phy_rx */
<0x4400 0x64>; /* phy_tx */
@@ -348,7 +348,7 @@ pcie1_phy: pciephy@4000 {
#phy-cells = <0>;
};
- pcie2_phy: pciephy@5000 {
+ pcie2_phy: pcie-phy@5000 {
compatible = "ti,phy-pipe3-pcie";
reg = <0x5000 0x80>, /* phy_rx */
<0x5400 0x64>; /* phy_tx */
diff --git a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
index 4ee53dfb71b4..d8b16cbe6c35 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
@@ -72,13 +72,13 @@ scm_conf: scm_conf@0 {
#size-cells = <1>;
};
- omap_control_usb2phy: control-phy@300 {
+ omap_control_usb2phy: phy@300 {
compatible = "ti,control-phy-usb2";
reg = <0x300 0x4>;
reg-names = "power";
};
- omap_control_usbotg: control-phy@33c {
+ omap_control_usbotg: phy@33c {
compatible = "ti,control-phy-otghs";
reg = <0x33c 0x4>;
reg-names = "otghs_control";
diff --git a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
index 9f6100c7c34d..5c94db589dd1 100644
--- a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
@@ -472,7 +472,7 @@ usb2_phy: usb2phy@4000 {
#phy-cells = <0>;
};
- usb3_phy: usb3phy@4400 {
+ usb3_phy: usb3-phy@4400 {
compatible = "ti,omap-usb3";
reg = <0x4400 0x80>,
<0x4800 0x64>,
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v4 0/3] dt-bindings: phy: Convert TI OMAP control and PIPE3 PHY to DT schema
From: Charan Pedumuru @ 2026-01-23 15:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
This series converts the old text-based DeviceTree bindings for TI OMAP
Control PHY and TI PIPE3 PHY to modern JSON-schema (YAML) format.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Changes in v4:
- ti,phy-usb3: Limit phandle arrays for optional properties to one entry.
- ti,phy-usb3: Use lowercase hex for reg values in examples.
- Link to v3: https://lore.kernel.org/r/20260122-ti-phy-v3-0-751619729433@gmail.com
Changes in v3:
- Change maintainer to "Roger Quadros" for both YAML files.
- dts: Split node pattern updates into a separate patch and align node
naming with standard conventions.
- ti,phy-usb3: Update node pattern to follow standard conventions.
- ti,phy-usb3: Refine the reg-names property and add constraints for
optional phandle-array properties.
- ti,phy-usb3: Redefine "syscon-pllreset" dependency on the compatible
"ti,phy-pipe3-sata" in a correct format.
- ti,control-phy-otghs: Update node pattern and adjust maxItems for reg
and reg-names.
- ti,control-phy-otghs: Fix the conditional handling for the
ti,control-phy-pcie compatible.
- Link to v2: https://lore.kernel.org/r/20260107-ti-phy-v2-0-a1ec27401fff@gmail.com
Changes in v2:
- ti,control-phy-otghs: Update commit message to reflect the latest
binding changes.
- ti,phy-usb3: Drop the obsolete "id" property from the schema.
- Both bindings: Update maintainers list, modify node pattern and improve
node descriptions for clarity.
- ti,phy-usb3: Introduce new YAML schema with properly defined optional
properties for the PIPE3 PHY.
- Link to v1: https://lore.kernel.org/r/20260103-ti-phy-v1-1-8c3f5e2cbd63@gmail.com
---
Charan Pedumuru (3):
arm: dts: ti: omap: align node patterns with established convention
dt-bindings: phy: ti,phy-usb3: convert to DT schema
dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
.../bindings/phy/ti,control-phy-otghs.yaml | 99 +++++++++++++++
.../devicetree/bindings/phy/ti,phy-usb3.yaml | 138 +++++++++++++++++++++
Documentation/devicetree/bindings/phy/ti-phy.txt | 98 ---------------
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 2 +-
6 files changed, 242 insertions(+), 103 deletions(-)
---
base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8
change-id: 20251231-ti-phy-58bb9e38cfc9
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 8/9] arm64: dts: renesas: ulcb: ulcb-kf: Describe PCIe/USB3.0 clock generator
From: Marek Vasut @ 2026-01-23 15:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <CAMuHMdV7UPWCqj4A6097KKT+Es2Zz_mPeJoyJd5qDMudrNx_5A@mail.gmail.com>
On 1/23/26 2:37 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> Thanks for your patch!
>
> On Sun, 18 Jan 2026 at 14:51, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
>> Describe the 9FGV0841 PCIe and USB3.0 clock generator present on ULCB
>> board. The clock generator supplies 100 MHz differential clock for both
>> PCIe ports, the USB 3.0 PHY and SATA.
>>
>> SATA is not yet described in the ULCB DT, therefore the connection to
>> this clock generator is not described here either.
>>
>> The H3 ULCB schematic does describe connection from output DIF7 to
>> USB3S1_CLK_*, but these signals do not exist on the SoC, therefore
>> this connection is also not described.
>
> That is the case because the first ULCB came with R-Car H3 ES1.0,
> which did have two USB3 channels. R-Car H3 ES2.0, M3-W, M3-W+,
> and M3-N have only a single USB3 channel.
>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-devel for v6.21.
Thank you
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 9/9] arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator
From: Geert Uytterhoeven @ 2026-01-23 13:39 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260118135038.8033-10-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Describe the 9FGV0841 PCIe and USB3.0 clock generator present on Ebisu
> board. The clock generator supplies 100 MHz differential clock for both
> PCIe slot and BT/WLAN expansion port, as well as for the USB 3.0 PHY.
>
> This configuration is valid for SW49 in OFF position, which means the
> PCIe signals are routed to the PCIe slot and U11 9FGV0841 PCIe clock
> generator output 3 supplies clock to the PCIe slot.
>
> In case the SW49 is set to ON position, which means the PCIe signals
> are routed to the EX BT/WLAN expansion port, and U11 9FGV0841 PCIe
> clock generator output 4 supplies clock to the port and &pciec0_rp
> clocks should be changed to "clocks = <&pcie_usb_clk 4>;". Once the
> BT/WLAN port is tested, this can be implemented using a DTO. Until
> then, assume SW49 is set to OFF position.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
> --- a/arch/arm64/boot/dts/renesas/ebisu.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ebisu.dtsi
> @@ -578,12 +591,30 @@ &ohci0 {
>
> &pcie_bus_clk {
> clock-frequency = <100000000>;
I will drop the clock-frequency while applying, as there is no point
in changing it in a disabled node.
> + status = "disabled";
> };
> @@ -871,7 +902,19 @@ &usb2_phy0 {
> status = "okay";
> };
>
> +&usb3_phy0 {
> + clocks = <&pcie_usb_clk 6>;
> + status = "okay";
> +};
> +
> +&usb3s0_clk {
> + clock-frequency = <100000000>;
Likewise.
> + status = "disabled";
> +};
> +
> &usb3_peri0 {
> + phys = <&usb3_phy0>;
> + phy-names = "usb";
> companion = <&xhci0>;
> status = "okay";
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 8/9] arm64: dts: renesas: ulcb: ulcb-kf: Describe PCIe/USB3.0 clock generator
From: Geert Uytterhoeven @ 2026-01-23 13:37 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260118135038.8033-9-marek.vasut+renesas@mailbox.org>
Hi Marek,
Thanks for your patch!
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Describe the 9FGV0841 PCIe and USB3.0 clock generator present on ULCB
> board. The clock generator supplies 100 MHz differential clock for both
> PCIe ports, the USB 3.0 PHY and SATA.
>
> SATA is not yet described in the ULCB DT, therefore the connection to
> this clock generator is not described here either.
>
> The H3 ULCB schematic does describe connection from output DIF7 to
> USB3S1_CLK_*, but these signals do not exist on the SoC, therefore
> this connection is also not described.
That is the case because the first ULCB came with R-Car H3 ES1.0,
which did have two USB3 channels. R-Car H3 ES2.0, M3-W, M3-W+,
and M3-N have only a single USB3 channel.
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
> --- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> @@ -352,19 +352,30 @@ &ohci0 {
>
> &pcie_bus_clk {
> clock-frequency = <100000000>;
I will drop the clock-frequency while applying, as there is no point
in changing it in a disabled node.
> + status = "disabled";
> };
>
> @@ -475,6 +486,16 @@ &usb2_phy0 {
> status = "okay";
> };
>
> +&usb3_phy0 {
> + clocks = <&cpg CPG_MOD 328>, <&pcie_usb_clk 6>, <&usb_extal_clk>;
> + status = "okay";
> +};
> +
> +&usb3s0_clk {
> + clock-frequency = <100000000>;
Likewise.
> + status = "disabled";
> +};
> +
> &xhci0 {
> status = "okay";
> };
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 net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Mohd Ayaan Anwar @ 2026-01-23 13:35 UTC (permalink / raw)
To: Russell King (Oracle)
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: <aXNEwBW3OA1xLEUj@shell.armlinux.org.uk>
Hello Russell,
On Fri, Jan 23, 2026 at 09:52:00AM +0000, Russell King (Oracle) wrote:
> This is the v1 submission: if it doesn't get tested but review goes
> well, it'll end up in net-next and mainline without testing on the
> affected hardware!
>
> Mentioned previously, I've been trying to sort out the PCS support in
> stmmac, and this series represents the current state of play.
>
> Previous posted patches centred around merely getting autonegotiation
> to be configured correctly, to a point where the manual configuration
> can be removed from the qcom-ethqos driver. The qcom-ethqos driver
> uses both SGMII and 2500BASE-X, manually configuring the dwmac's
> integrated PCS appropriately.
>
Thank you for CC'ing me on this series. Sorry, but I have been M.I.A.
for the past couple of months due to some health issues, which caused a
backlog at work that I had to power through. I haven't been able to
monitor the mailing list for stmmac patches.
I tested v1 last night and just picked up v2. Here are my observations
and logs (phylink logs are enabled). I haven't had time to debug the
issues, but they are not seen on the net-next tree. One thing that I
remember from our last discussion is the need to test with comma
detection enabled; I will test that next.
Tested on the QCS9100 Ride R3 board with 2X AQR115C PHYs. I have one
more board that I can test next week (IQ8275, which has a single
QCA8081 PHY, but that is limited to 2.5G because the PHY switches its
mode according to the speed).
1. Boot up at 2.5G: Continous TX timeouts keep issuing a reset,
resulting in a broken data path.
[ 7.492567] qcom-ethqos 23040000.ethernet: User ID: 0x20, Synopsys ID: 0x52
[ 7.492576] qcom-ethqos 23040000.ethernet: DWMAC4/5
[ 7.492601] qcom-ethqos 23040000.ethernet: Using 36/40 bits DMA host/device width
[ 9.556835] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 9.566440] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 9.577175] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=333)
[ 9.586679] qcom-ethqos 23040000.ethernet eth1: phy: 2500base-x setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 9.615015] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 9.622371] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 9.631155] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 9.637701] qcom-ethqos 23040000.ethernet eth1: configuring for phy/2500base-x link mode
[ 9.646026] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 9.654175] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 9.663212] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 9.671797] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/2500base-x/none adv=00000000,00000000,00000000,00000000 pause=00
[ 9.695529] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 14.219898] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
[ 14.231487] qcom-ethqos 23040000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off
[ 26.308402] qcom-ethqos 23040000.ethernet eth1: NETDEV WATCHDOG: CPU: 0: transmit queue 3 timed out 5512 ms
[ 26.319068] qcom-ethqos 23040000.ethernet eth1: Reset adapter.
[ 26.328258] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 26.885477] qcom-ethqos 23040000.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter
[ 26.893552] qcom-ethqos 23040000.ethernet eth1: failed to kill vid 0081/0
[ 26.900711] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 26.908972] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 26.917145] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 26.925232] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 27.836839] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 27.846435] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 27.857175] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=333)
[ 27.866659] qcom-ethqos 23040000.ethernet eth1: phy: 2500base-x setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 27.892561] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 27.899700] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 27.908831] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 27.915373] qcom-ethqos 23040000.ethernet eth1: configuring for phy/2500base-x link mode
[ 27.923697] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 27.931850] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 27.940894] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 27.949481] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/2500base-x/none adv=00000000,00000000,00000000,00000000 pause=00
[ 27.965702] 8021q: adding VLAN 0 to HW filter on device eth1
[ 27.971735] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 32.552893] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
[ 32.564571] qcom-ethqos 23040000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off
[ 44.292394] qcom-ethqos 23040000.ethernet eth1: NETDEV WATCHDOG: CPU: 0: transmit queue 2 timed out 5548 ms
[ 44.293874] qcom-ethqos 23040000.ethernet eth1: Reset adapter.
[ 44.295010] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 44.846480] qcom-ethqos 23040000.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter
[ 44.846503] qcom-ethqos 23040000.ethernet eth1: failed to kill vid 0081/0
[ 44.846652] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 44.847116] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 44.847529] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 44.847965] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 45.752841] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 45.752865] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 45.752875] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=333)
[ 45.752881] qcom-ethqos 23040000.ethernet eth1: phy: 2500base-x setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 45.764640] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 45.764958] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 45.765223] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 45.765228] qcom-ethqos 23040000.ethernet eth1: configuring for phy/2500base-x link mode
[ 45.765232] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 45.765236] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 45.765240] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 45.765243] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/2500base-x/none adv=00000000,00000000,00000000,00000000 pause=00
[ 45.775210] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 45.776826] 8021q: adding VLAN 0 to HW filter on device eth1
[ 50.455049] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
[ 50.457389] qcom-ethqos 23040000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off
2. Boot up at 1G: link state is flapping + the same TX timeout issue as
above. Also, a warning due to qcom-ethqos toggling ANE. For the link
state flapping issue, the MAC/IOMACRO configuration looks fine to me, do
we need to handle something in the PHY?
<Console gets flooded due to the flapping of the link state>
[ 34.444213] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 34.444229] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 34.444257] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 34.444262] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 34.444818] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 34.444832] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 34.444862] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 34.444867] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 34.445124] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041000
[ 34.445154] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 34.445426] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 34.445439] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 34.445480] qcom-ethqos 23040000.ethernet eth1: Link is Down
[ 34.445509] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 34.449951] qcom-ethqos 23040000.ethernet: PCS ANE process completed
[ 34.449957] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 34.449966] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 40.476697] qcom-ethqos 23040000.ethernet eth1: NETDEV WATCHDOG: CPU: 0: transmit queue 2 timed out 5004 ms
[ 40.477296] qcom-ethqos 23040000.ethernet eth1: Reset adapter.
[ 40.479898] qcom-ethqos 23040000.ethernet eth1: phy link down sgmii/Unknown/Unknown/none/off/nolpi
[ 40.517655] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 40.518174] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 40.518623] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 40.518986] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 41.405148] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 41.405175] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 41.405185] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=340)
[ 41.405192] qcom-ethqos 23040000.ethernet eth1: phy: sgmii setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 41.416920] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 41.417226] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 41.418826] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 41.418832] qcom-ethqos 23040000.ethernet eth1: configuring for phy/sgmii link mode
[ 41.418836] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/sgmii
[ 41.418842] qcom-ethqos 23040000.ethernet eth1: interface sgmii inband modes: pcs=03 phy=03
[ 41.418846] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/sgmii
[ 41.418849] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/sgmii/none adv=00000000,00000000,00000000,00000000 pause=00
[ 41.425947] 8021q: adding VLAN 0 to HW filter on device eth1
[ 41.432191] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 44.979659] qcom-ethqos 23040000.ethernet eth1: phy link up sgmii/1Gbps/Full/none/off/nolpi
[ 44.982047] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041000
[ 44.982092] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 45.019087] qcom-ethqos 23040000.ethernet: PCS ANE process completed
[ 45.019101] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 45.019120] qcom-ethqos 23040000.ethernet eth1: pcs link up
3. Switching from 2.5G to 1G: similar continuous Tx timeouts, warning
due to ANE.
[ 97.318077] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 97.877280] qcom-ethqos 23040000.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter
[ 97.877309] qcom-ethqos 23040000.ethernet eth1: failed to kill vid 0081/0
[ 97.877507] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 97.878080] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 97.878530] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 97.879004] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 98.784839] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 98.784865] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 98.784876] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=333)
[ 98.784883] qcom-ethqos 23040000.ethernet eth1: phy: 2500base-x setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 98.796612] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 98.796912] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 98.798518] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 98.798522] qcom-ethqos 23040000.ethernet eth1: configuring for phy/2500base-x link mode
[ 98.798526] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 98.798530] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 98.798534] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 98.798537] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/2500base-x/none adv=00000000,00000000,00000000,00000000 pause=00
[ 98.802000] 8021q: adding VLAN 0 to HW filter on device eth1
[ 98.808472] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 102.180528] qcom-ethqos 23040000.ethernet eth1: phy link up sgmii/1Gbps/Full/none/off/nolpi
[ 102.182972] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/sgmii
[ 102.182986] qcom-ethqos 23040000.ethernet eth1: interface sgmii inband modes: pcs=03 phy=03
[ 102.182994] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/sgmii
[ 102.183000] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/sgmii/none adv=00000000,00000000,00000000,00000000 pause=00
[ 102.186901] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 102.186913] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 102.186952] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 102.186955] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 102.187089] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 102.187092] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 102.187123] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 102.187126] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 102.187169] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041000
[ 102.187175] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 102.187178] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 102.187206] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 102.187213] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 102.187217] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 102.187218] qcom-ethqos 23040000.ethernet eth1: Link is Down
[ 102.187273] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 102.220947] qcom-ethqos 23040000.ethernet: PCS ANE process completed
[ 102.220958] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 102.220972] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 114.309051] qcom-ethqos 23040000.ethernet eth1: NETDEV WATCHDOG: CPU: 2: transmit queue 3 timed out 5588 ms
[ 114.309141] qcom-ethqos 23040000.ethernet eth1: Reset adapter.
4. Switching from 1G to 2.5G - similar issues + a NULL pointer
dereference. I am checking on the reason for it.
[ 1235.996004] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 1240.517716] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
[ 1240.529470] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 1240.537642] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 1240.546702] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 1240.555441] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
[ 1240.564481] Mem abort info:
[ 1240.567377] ESR = 0x0000000096000044
[ 1240.571242] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1240.576720] SET = 0, FnV = 0
[ 1240.579874] EA = 0, S1PTW = 0
[ 1240.583123] FSC = 0x04: level 0 translation fault
[ 1240.588162] Data abort info:
[ 1240.591149] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
[ 1240.596799] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[ 1240.602007] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1240.607483] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000137f96000
[ 1240.614107] [0000000000000010] pgd=0000000000000000, p4d=0000000000000000
[ 1240.621093] Internal error: Oops: 0000000096000044 [#1] SMP
[ 1240.626910] Modules linked in: --
[ 1240.737142] CPU: 1 UID: 0 PID: 55 Comm: kworker/u33:0 Not tainted 6.19.0-rc5-00581-g73cb8467a63e #1 PREEMPT
[ 1240.747223] Hardware name: Qualcomm Technologies, Inc. Lemans Ride Rev3 (DT)
[ 1240.754461] Workqueue: events_power_efficient phylink_resolve
[ 1240.760368] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1240.767509] pc : phylink_major_config+0x408/0x948
[ 1240.772340] lr : phylink_major_config+0x3fc/0x948
[ 1240.777167] sp : ffff800080353c60
[ 1240.780568] x29: ffff800080353cb0 x28: ffffb305068a8a00 x27: ffffb305068a8000
[ 1240.787894] x26: ffff000080092100 x25: 0000000000000000 x24: 0000000000000000
[ 1240.795219] x23: 0000000000000001 x22: 0000000000000000 x21: ffffb3050555b3d0
[ 1240.802544] x20: ffff800080353d10 x19: ffff0000b6059400 x18: 00000000ffffffff
[ 1240.809870] x17: 74756f2f79687020 x16: ffffb305045e4f18 x15: 6769666e6f632072
[ 1240.817195] x14: 6f6a616d203a3168 x13: 782d657361623030 x12: ffffb305068c6a98
[ 1240.824521] x11: 0000000000000583 x10: 0000000000000018 x9 : ffffb305068c6a98
[ 1240.831849] x8 : 0000000100006583 x7 : 0000000000000000 x6 : ffff00008083cc40
[ 1240.839174] x5 : ffff00008083cc40 x4 : 0000000000000001 x3 : 0000000000000001
[ 1240.846498] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000b269e5a8
[ 1240.853824] Call trace:
[ 1240.856339] phylink_major_config+0x408/0x948 (P)
[ 1240.861167] phylink_resolve+0x294/0x6e4
[ 1240.865196] process_one_work+0x148/0x28c
[ 1240.869316] worker_thread+0x2d8/0x3d8
[ 1240.873171] kthread+0x134/0x208
[ 1240.876490] ret_from_fork+0x10/0x20
[ 1240.880168] Code: d63f0020 f9400e60 b4000040 f900081f (f9000ad3)
[ 1240.886423] ---[ end trace 0000000000000000 ]---
That's all I have right now. I will try to test out with comma detection
enabled and share the results in a day or so.
Ayaan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 7/9] arm64: dts: renesas: salvator-common: Describe PCIe/USB3.0 clock generator
From: Geert Uytterhoeven @ 2026-01-23 13:34 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260118135038.8033-8-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Describe the 9FGV0841 PCIe and USB3.0 clock generator present on both
> Salvator-X and Salvator-XS boards. The clock generator supplies 100 MHz
> differential clock for both PCIe ports, as well as for the USB 3.0 PHY.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -641,16 +654,27 @@ &ohci1 {
>
> &pcie_bus_clk {
> clock-frequency = <100000000>;
I will drop the clock-frequency while applying, as there is no point
in changing it in a disabled node.
> + status = "disabled";
> };
> @@ -1038,11 +1062,13 @@ &usb3_peri0 {
> };
>
> &usb3_phy0 {
> + clocks = <&cpg CPG_MOD 328>, <&pcie_usb_clk 6>, <&usb_extal_clk>;
> status = "okay";
> };
>
> &usb3s0_clk {
> clock-frequency = <100000000>;
Likewise.
> + status = "disabled";
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/9] arm64: dts: renesas: r8a77990: Add USB 3.0 PHY and USB3S0 clock nodes
From: Geert Uytterhoeven @ 2026-01-23 13:32 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260118135038.8033-7-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add USB 3.0 PHY and PHY clock node for R8877990 E3 . The PHY node is
> different in that it does not have control registers and extal clock,
> which are not routed to the SoC pads on E3, therefore describe the
> PHY as usb-nop-xceiv simple PHY. Add USB3S0 clock pad fixed-clock
> node, the frequency has to be overridden at board level.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> V2: Describe PHY as usb-nop-xceiv and update commit message
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/9] arm64: dts: renesas: r8a77990: Describe PCIe root port
From: Geert Uytterhoeven @ 2026-01-23 13:31 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260118135038.8033-6-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add node which describes the root port in the PCIe controller DT node.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 4/9] arm64: dts: renesas: r8a77965: Describe PCIe root ports
From: Geert Uytterhoeven @ 2026-01-23 13:31 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260118135038.8033-5-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add nodes which describe the root ports in the PCIe controller DT nodes.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 3/9] arm64: dts: renesas: r8a77961: Describe PCIe root ports
From: Geert Uytterhoeven @ 2026-01-23 13:30 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260118135038.8033-4-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add nodes which describe the root ports in the PCIe controller DT nodes.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/9] arm64: dts: renesas: r8a77960: Describe PCIe root ports
From: Geert Uytterhoeven @ 2026-01-23 13:29 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260118135038.8033-3-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add nodes which describe the root ports in the PCIe controller DT nodes.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/9] arm64: dts: renesas: r8a77951: Describe PCIe root ports
From: Geert Uytterhoeven @ 2026-01-23 13:29 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260118135038.8033-2-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add nodes which describe the root ports in the PCIe controller DT nodes.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
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 v3 2/3] dt-bindings: phy: ti,phy-usb3: convert to DT schema
From: Charan Pedumuru @ 2026-01-23 13:12 UTC (permalink / raw)
To: Rob Herring
Cc: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Conor Dooley,
Kishon Vijay Abraham I, Aaro Koskinen, Andreas Kemnade,
Kevin Hilman, Roger Quadros, Tony Lindgren, Roger Quadros,
linux-phy, devicetree, linux-kernel, linux-omap
In-Reply-To: <20260122233309.GA3730160-robh@kernel.org>
On 23-01-2026 05:03, Rob Herring wrote:
> On Thu, Jan 22, 2026 at 05:52:58PM +0000, Charan Pedumuru wrote:
>> Convert TI PIPE3 PHY binding to DT schema.
>> Changes during conversion:
>> - Define a new pattern 'pcie-phy' 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 | 135 +++++++++++++++++++++
>> 1 file changed, 135 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..605f12f0f79a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
>> @@ -0,0 +1,135 @@
>> +# 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:
>> + - Roger Quadros <rogerq@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: "^(pcie-phy|usb3-phy|phy)@[0-9a-f]+$"
>> +
>> + compatible:
>> + enum:
>> + - ti,omap-usb3
>> + - ti,phy-pipe3-pcie
>> + - ti,phy-pipe3-sata
>> + - ti,phy-usb3
>> +
>> + reg:
>> + minItems: 2
>> + maxItems: 3
>> +
>> + reg-names:
>> + 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
>> + items:
>> + items:
>> + - description: Phandle to the system control module
>> + - description: Register offset controlling PHY power
>
> This allows N entries of 2 cells each. You need either:
>
> items:
> - items:
> - description: ...
> - description: ...
>
> (the hyphen is important!)
>
> Or:
>
> maxItems: 1
> items:
> items:
> - description: ...
> - description: ...
Okay, I will use the above format in the next revision.
>
>> +
>> + syscon-pllreset:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + items:
>> + - description: Phandle to the system control module
>> + - description: Register offset of CTRL_CORE_SMA_SW_0
>> +
>> + syscon-pcs:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + items:
>> + - description: Phandle to the system control module
>> + - description: Register offset for PCS delay programming
>> +
>> + ctrl-module:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Phandle of control module for PHY power on.
>> + deprecated: true
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: ti,phy-pipe3-sata
>> + then:
>> + properties:
>> + syscon-pllreset: true
>> + else:
>> + properties:
>> + syscon-pllreset: false
>> +
>> +required:
>> + - reg
>> + - compatible
>> + - reg-names
>> + - "#phy-cells"
>> + - clocks
>> + - clock-names
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + /* TI PIPE3 USB3 PHY */
>> + usb3-phy@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 */
>
> Use lowercase hex.
Sure.
>
>> + 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
>>
--
Best Regards,
Charan.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy] phy: enter drivers/phy/Makefile even without CONFIG_GENERIC_PHY
From: Venkat Rao Bagalkote @ 2026-01-23 13:01 UTC (permalink / raw)
To: Vladimir Oltean, linux-phy, Vinod Koul, Neil Armstrong
Cc: netdev, Paolo Abeni, Bjørn Mork, linux-kernel,
Christophe Leroy (CS GROUP)
In-Reply-To: <20260123110600.3118561-1-vladimir.oltean@nxp.com>
On 23/01/26 4:36 pm, Vladimir Oltean wrote:
> Kconfig option CONFIG_PHY_COMMON_PROPS, which builds
> drivers/phy/phy-common-props.c, was intended to be selectable
> independently of CONFIG_GENERIC_PHY. Yet it lives in drivers/phy/, which
> is entered by the Makefile only if CONFIG_GENERIC_PHY is set.
>
> Allow the Makefile to enter one level deeper, but stop at drivers/phy/
> if CONFIG_GENERIC_PHY is unselected (i.e. do not enter vendor folders).
> The other stuff from drivers/phy/Makefile except for CONFIG_PHY_COMMON_PROPS,
> like CONFIG_PHY_NXP_PTN3222, all depends on CONFIG_GENERIC_PHY.
>
> Fixes: e7556b59ba65 ("phy: add phy_get_rx_polarity() and phy_get_tx_polarity()")
> Closes: https://lore.kernel.org/lkml/43ea0202-891d-4582-980b-5cb557b41114@linux.ibm.com/
> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Debugged-by: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> ---
> drivers/Makefile | 2 +-
> drivers/phy/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index ccc05f1eae3e..53fbd2e0acdd 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -10,7 +10,7 @@ obj-y += cache/
> obj-y += irqchip/
> obj-y += bus/
>
> -obj-$(CONFIG_GENERIC_PHY) += phy/
> +obj-y += phy/
>
> # GPIO must come after pinctrl as gpios may need to mux pins etc
> obj-$(CONFIG_PINCTRL) += pinctrl/
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 30b150d68de7..93715ea0d010 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -15,7 +15,7 @@ obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
> obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
> obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
> -obj-y += allwinner/ \
> +obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
> amlogic/ \
> broadcom/ \
> cadence/ \
--
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-23 11:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Konrad Dybcio, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <aXNEwBW3OA1xLEUj@shell.armlinux.org.uk>
According to patchwork, this doesn't apply to net-next. That's odd,
it was generated on last night's net next, and although there has been
further work, it rebases cleanly on top of this morning's. How can
these changes:
drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 6 +++++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++++++++++----
2 files changed, 21 insertions(+), 5 deletions(-)
which happened in net-next overnight result in this change in patch 1:
drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 3 ---
1 file changed, 3 deletions(-)
failing to apply?
No, patchwork is clearly wrong.
On Fri, Jan 23, 2026 at 09:52:00AM +0000, Russell King (Oracle) wrote:
> This is the v1 submission: if it doesn't get tested but review goes
> well, it'll end up in net-next and mainline without testing on the
> affected hardware!
>
> Mentioned previously, I've been trying to sort out the PCS support in
> stmmac, and this series represents the current state of play.
>
> Previous posted patches centred around merely getting autonegotiation
> to be configured correctly, to a point where the manual configuration
> can be removed from the qcom-ethqos driver. The qcom-ethqos driver
> uses both SGMII and 2500BASE-X, manually configuring the dwmac's
> integrated PCS appropriately.
>
> This *untested* series attempts to take this further. The patches:
>
> - clean up qcom-ethqos only-written mac_base member.
> - convert qcom-ethqos to use the set_clk_tx_rate() method for setting
> the link clock rate.
> - add support for phy_set_mode_ext() to the qcom "SGMII" ethernet
> SerDes driver (which is really only what it needs. Note that
> phy_set_mode_ext() is an expected call to be made, where as
> phy_set_speed() is optional and not. See PHY documentation.)
> - add platform-glue independent SerDes support to the stmmac core
> driver. Currently, only qcom-ethqos will make use of this, and
> I suspect as we haven't had this, it's going to be difficult to
> convert other platform glue to use this - but had this existed
> earlier, we could've pushed people to use PHY to abstract some
> of the platform glue differences. Adding it now makes it available
> for future platform glue.
> - convert qcom-ethqos to use this core SerDes support.
> - arrange for stmmac_pcs.c to supply the phy_intf_sel field value
> if the integrated PCS will be used. (PHY_INTF_SEL_SGMII requires
> the integrated PCS rather than an external PCS.)
> - add BASE-X support to the integrated PCS driver, and use it for
> BASE-X modes. This fully supports in-band mode, including reading
> the link partner advertisement.
> - add in-band support for SGMII, reading the state from the RGSMII
> status field.
>
> As we leave qcom-ethqos' manual configuration of the PCS in place at
> the moment, the last patch adds reporting of any changes in its
> configuration that the qcom-ethqos driver does beyond what phylink
> requested, thus providing a path to debug and eventually remove
> qcom-ethqos' manual configuration.
>
> One patch is not included in this set - which adds a phy_intf_sel
> value for external PCS (using PHY_INTF_SEL_GMII_MII). I believe all
> external PCS use this mode when connected to a MAC capable of up to
> 2.5G. However, no platform glue that provides the mac_select_pcs()
> method also provide the set_phy_intf_sel() method, so we can safely
> ignore this for now.
>
> I would like to get this into net-next before the next merge window,
> so testing would be appreciated. If there are issues with these patches
> applied, please check whether the issue exists without these patches
> and only report regressions caused by this patch set. For example,
> I'm aware that qcom-ethqos has issues with 10Mbps mode due to an AQR
> PHY being insanely provisioned to use SGMII in 1000M mode but with
> rate matching with 10M media. This is not an issue that is relevant
> to this patch series, but a problem with the PHY provisioning.
>
> rfc->v1:
> - fix SGMII link status
> - avoid calling phy_get_mode() if PHY is null
> v2:
> - fix further AI review bot dribble that could've been raised on
> the rfc version but wasn't.
>
> drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
> drivers/net/ethernet/stmicro/stmmac/common.h | 1 -
> .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 74 ++-----
> drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 12 +-
> .../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 11 +-
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 10 +-
> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 10 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 69 +++++--
> drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c | 222 +++++++++++++++++++--
> drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h | 53 ++---
> .../net/ethernet/stmicro/stmmac/stmmac_serdes.c | 111 +++++++++++
> .../net/ethernet/stmicro/stmmac/stmmac_serdes.h | 16 ++
> drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 43 ++++
> include/linux/stmmac.h | 2 +
> 14 files changed, 491 insertions(+), 145 deletions(-)
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
>
--
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 phy] phy: enter drivers/phy/Makefile even without CONFIG_GENERIC_PHY
From: Christophe Leroy (CS GROUP) @ 2026-01-23 11:09 UTC (permalink / raw)
To: Vladimir Oltean, linux-phy, Vinod Koul, Neil Armstrong
Cc: netdev, Paolo Abeni, Bjørn Mork, linux-kernel,
Venkat Rao Bagalkote
In-Reply-To: <20260123110600.3118561-1-vladimir.oltean@nxp.com>
Le 23/01/2026 à 12:06, Vladimir Oltean a écrit :
> Kconfig option CONFIG_PHY_COMMON_PROPS, which builds
> drivers/phy/phy-common-props.c, was intended to be selectable
> independently of CONFIG_GENERIC_PHY. Yet it lives in drivers/phy/, which
> is entered by the Makefile only if CONFIG_GENERIC_PHY is set.
>
> Allow the Makefile to enter one level deeper, but stop at drivers/phy/
> if CONFIG_GENERIC_PHY is unselected (i.e. do not enter vendor folders).
> The other stuff from drivers/phy/Makefile except for CONFIG_PHY_COMMON_PROPS,
> like CONFIG_PHY_NXP_PTN3222, all depends on CONFIG_GENERIC_PHY.
>
> Fixes: e7556b59ba65 ("phy: add phy_get_rx_polarity() and phy_get_tx_polarity()")
> Closes: https://lore.kernel.org/lkml/43ea0202-891d-4582-980b-5cb557b41114@linux.ibm.com/
> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Debugged-by: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> ---
> drivers/Makefile | 2 +-
> drivers/phy/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index ccc05f1eae3e..53fbd2e0acdd 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -10,7 +10,7 @@ obj-y += cache/
> obj-y += irqchip/
> obj-y += bus/
>
> -obj-$(CONFIG_GENERIC_PHY) += phy/
> +obj-y += phy/
>
> # GPIO must come after pinctrl as gpios may need to mux pins etc
> obj-$(CONFIG_PINCTRL) += pinctrl/
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 30b150d68de7..93715ea0d010 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -15,7 +15,7 @@ obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
> obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
> obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
> -obj-y += allwinner/ \
> +obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
> amlogic/ \
> broadcom/ \
> cadence/ \
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [next-20260122] Build failure on IBM Power Server
From: Vladimir Oltean @ 2026-01-23 11:07 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Venkat Rao Bagalkote, Randy Dunlap, Madhavan Srinivasan, broonie,
Linux Next Mailing List, Maxime Chevallier, Jakub Kicinski, LKML,
linuxppc-dev, netdev@vger.kernel.org, Vinod Koul, linux-phy
In-Reply-To: <2b41debd-9a05-4707-b270-a8fa3dd7768c@kernel.org>
On Fri, Jan 23, 2026 at 11:52:45AM +0100, Christophe Leroy (CS GROUP) wrote:
> Le 23/01/2026 à 11:39, Vladimir Oltean a écrit :
> > On Fri, Jan 23, 2026 at 10:52:49AM +0100, Christophe Leroy (CS GROUP) wrote:
> > > +Vladimir, Maxime, Jakub and netdev
> > >
> > > Le 23/01/2026 à 10:11, Venkat Rao Bagalkote a écrit :
> > > >
> > > > On 23/01/26 1:17 pm, Randy Dunlap wrote:
> > > > >
> > > > > On 1/22/26 8:15 PM, Venkat Rao Bagalkote wrote:
> > > > > > Greetings!!
> > > > > >
> > > > > > IBM CI has reported build failure of 20260122 on IBM Power server.
> > > > > >
> > > > > >
> > > > > > Error:
> > > > > >
> > > > > >
> > > > > > ERROR: modpost: "phy_get_rx_polarity" [drivers/net/phy/
> > > > > > air_en8811h.ko] undefined!
> > > > > > ERROR: modpost: "phy_get_tx_polarity" [drivers/net/phy/
> > > > > > air_en8811h.ko] undefined!
> > > > > > make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> > > > > > make[1]: *** [/home/upstreamci/linux/Makefile:2040: modpost] Error 2
> > > > > > make: *** [Makefile:248: __sub-make] Error 2
> > >
> > > Thanks for the config file.
> > >
> > > The probleme is because allthough CONFIG_PHY_COMMON_PROPS is selected,
> > > drivers/phy/phy-common-props.o is not built because CONFIG_GENERIC_PHY
> > > is not selected.
> > >
> > > Likely comes from commit 66d8a334b57e ("net: phy: air_en8811h: deprecate
> > > "airoha,pnswap-rx" and "airoha,pnswap-tx"")
> > >
> > > Christophe
> >
> > The intention was for drivers/phy/phy-common-props.o to be
> > buildable/usable without CONFIG_GENERIC_PHY.
> >
> > Does this help?
>
> Yes it fixes the build for me.
>
> Christophe
Patch sent:
https://lore.kernel.org/linux-phy/20260123110600.3118561-1-vladimir.oltean@nxp.com/
--
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