* [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-03 21:06 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
For a long time, PCSs have been tightly coupled with their MACs. For
this reason, the MAC creates the "phy" or mdio device, and then passes
it to the PCS to initialize. This has a few disadvantages:
- Each MAC must re-implement the same steps to look up/create a PCS
- The PCS cannot use functions tied to device lifetime, such as devm_*.
- Generally, the PCS does not have easy access to its device tree node
This series adds a PCS subsystem which MDIO drivers can use to register
PCSs. It then converts the Lynx PCS library to use this subsystem.
Several (later) patches in this series cannot be applied until a stable
release has occured containing the dts updates. The DTS updates are
fairly straightforward (and should not affect existing systems), so I
encourage them to be applied, even if the rest of the series still needs
review.
Changes in v2:
- Add compatibles for qoriq-fman3-0-10g-2/3.dtsi as well
- Fix export of _pcs_get_by_fwnode
- Add device links to ensure correct probe/removal ordering
- Remove module_get/put, since this is ensured by the device_get/put
- Reorganize some of the control flow for legibility
- Add basic documentation
- Call mdio_device_register
- Squash in lynx parts of "use pcs_get_by_provider to get PCS"
- Rewrite probe/remove functions to use create/destroy. This lets us
convert existing drivers one at a time, instead of needing a flag day.
- Split off driver conversions into their own commits
- Reorder and rework commits for clarity
Sean Anderson (10):
arm64: dts: Add compatible strings for Lynx PCSs
powerpc: dts: Add compatible strings for Lynx PCSs
net: pcs: Add subsystem
net: pcs: lynx: Convert to an MDIO driver
net: enetc: Convert to use PCS subsystem
net: dsa: felix: Convert to use PCS driver
of: property: Add device link support for PCS
[DO NOT MERGE] net: dpaa: Convert to use PCS subsystem
[DO NOT MERGE] net: dpaa2: Convert to use PCS subsystem
[DO NOT MERGE] net: pcs: lynx: Remove non-device functionality
Vladimir Oltean (1):
net: dsa: ocelot: suppress PHY device scanning on the internal MDIO
bus
Documentation/networking/index.rst | 1 +
Documentation/networking/pcs.rst | 109 ++++++++
MAINTAINERS | 2 +
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 48 ++--
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 54 ++--
.../dts/freescale/qoriq-fman3-0-10g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-10g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-2.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-3.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-4.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-5.dtsi | 3 +-
.../fsl/qoriq-fman3-0-10g-0-best-effort.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi | 3 +-
.../fsl/qoriq-fman3-0-10g-1-best-effort.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi | 3 +-
drivers/net/dsa/ocelot/Kconfig | 2 +
drivers/net/dsa/ocelot/felix_vsc9959.c | 31 +--
drivers/net/dsa/ocelot/seville_vsc9953.c | 33 +--
drivers/net/ethernet/freescale/dpaa2/Kconfig | 1 +
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 43 +---
drivers/net/ethernet/freescale/enetc/Kconfig | 1 +
.../net/ethernet/freescale/enetc/enetc_pf.c | 23 +-
.../net/ethernet/freescale/fman/fman_memac.c | 118 +++------
drivers/net/pcs/Kconfig | 23 +-
drivers/net/pcs/Makefile | 2 +
drivers/net/pcs/core.c | 243 ++++++++++++++++++
drivers/net/pcs/pcs-lynx.c | 76 ++++--
drivers/of/property.c | 4 +
include/linux/pcs-lynx.h | 12 +-
include/linux/pcs.h | 111 ++++++++
include/linux/phylink.h | 5 +
49 files changed, 758 insertions(+), 268 deletions(-)
create mode 100644 Documentation/networking/pcs.rst
create mode 100644 drivers/net/pcs/core.c
create mode 100644 include/linux/pcs.h
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-03 21:06 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Sean Anderson, Vladimir Oltean, Jakub Kicinski, Paolo Abeni,
Vivien Didelot, devicetree, Claudiu Manoil, Rob Herring,
linux-arm-kernel, linuxppc-dev, linux-kernel, Li Yang,
Vladimir Oltean, Shawn Guo, David S . Miller
For a long time, PCSs have been tightly coupled with their MACs. For
this reason, the MAC creates the "phy" or mdio device, and then passes
it to the PCS to initialize. This has a few disadvantages:
- Each MAC must re-implement the same steps to look up/create a PCS
- The PCS cannot use functions tied to device lifetime, such as devm_*.
- Generally, the PCS does not have easy access to its device tree node
This series adds a PCS subsystem which MDIO drivers can use to register
PCSs. It then converts the Lynx PCS library to use this subsystem.
Several (later) patches in this series cannot be applied until a stable
release has occured containing the dts updates. The DTS updates are
fairly straightforward (and should not affect existing systems), so I
encourage them to be applied, even if the rest of the series still needs
review.
Changes in v2:
- Add compatibles for qoriq-fman3-0-10g-2/3.dtsi as well
- Fix export of _pcs_get_by_fwnode
- Add device links to ensure correct probe/removal ordering
- Remove module_get/put, since this is ensured by the device_get/put
- Reorganize some of the control flow for legibility
- Add basic documentation
- Call mdio_device_register
- Squash in lynx parts of "use pcs_get_by_provider to get PCS"
- Rewrite probe/remove functions to use create/destroy. This lets us
convert existing drivers one at a time, instead of needing a flag day.
- Split off driver conversions into their own commits
- Reorder and rework commits for clarity
Sean Anderson (10):
arm64: dts: Add compatible strings for Lynx PCSs
powerpc: dts: Add compatible strings for Lynx PCSs
net: pcs: Add subsystem
net: pcs: lynx: Convert to an MDIO driver
net: enetc: Convert to use PCS subsystem
net: dsa: felix: Convert to use PCS driver
of: property: Add device link support for PCS
[DO NOT MERGE] net: dpaa: Convert to use PCS subsystem
[DO NOT MERGE] net: dpaa2: Convert to use PCS subsystem
[DO NOT MERGE] net: pcs: lynx: Remove non-device functionality
Vladimir Oltean (1):
net: dsa: ocelot: suppress PHY device scanning on the internal MDIO
bus
Documentation/networking/index.rst | 1 +
Documentation/networking/pcs.rst | 109 ++++++++
MAINTAINERS | 2 +
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 48 ++--
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 54 ++--
.../dts/freescale/qoriq-fman3-0-10g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-10g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-2.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-3.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-4.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-5.dtsi | 3 +-
.../fsl/qoriq-fman3-0-10g-0-best-effort.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi | 3 +-
.../fsl/qoriq-fman3-0-10g-1-best-effort.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi | 3 +-
drivers/net/dsa/ocelot/Kconfig | 2 +
drivers/net/dsa/ocelot/felix_vsc9959.c | 31 +--
drivers/net/dsa/ocelot/seville_vsc9953.c | 33 +--
drivers/net/ethernet/freescale/dpaa2/Kconfig | 1 +
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 43 +---
drivers/net/ethernet/freescale/enetc/Kconfig | 1 +
.../net/ethernet/freescale/enetc/enetc_pf.c | 23 +-
.../net/ethernet/freescale/fman/fman_memac.c | 118 +++------
drivers/net/pcs/Kconfig | 23 +-
drivers/net/pcs/Makefile | 2 +
drivers/net/pcs/core.c | 243 ++++++++++++++++++
drivers/net/pcs/pcs-lynx.c | 76 ++++--
drivers/of/property.c | 4 +
include/linux/pcs-lynx.h | 12 +-
include/linux/pcs.h | 111 ++++++++
include/linux/phylink.h | 5 +
49 files changed, 758 insertions(+), 268 deletions(-)
create mode 100644 Documentation/networking/pcs.rst
create mode 100644 drivers/net/pcs/core.c
create mode 100644 include/linux/pcs.h
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-03 21:06 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
For a long time, PCSs have been tightly coupled with their MACs. For
this reason, the MAC creates the "phy" or mdio device, and then passes
it to the PCS to initialize. This has a few disadvantages:
- Each MAC must re-implement the same steps to look up/create a PCS
- The PCS cannot use functions tied to device lifetime, such as devm_*.
- Generally, the PCS does not have easy access to its device tree node
This series adds a PCS subsystem which MDIO drivers can use to register
PCSs. It then converts the Lynx PCS library to use this subsystem.
Several (later) patches in this series cannot be applied until a stable
release has occured containing the dts updates. The DTS updates are
fairly straightforward (and should not affect existing systems), so I
encourage them to be applied, even if the rest of the series still needs
review.
Changes in v2:
- Add compatibles for qoriq-fman3-0-10g-2/3.dtsi as well
- Fix export of _pcs_get_by_fwnode
- Add device links to ensure correct probe/removal ordering
- Remove module_get/put, since this is ensured by the device_get/put
- Reorganize some of the control flow for legibility
- Add basic documentation
- Call mdio_device_register
- Squash in lynx parts of "use pcs_get_by_provider to get PCS"
- Rewrite probe/remove functions to use create/destroy. This lets us
convert existing drivers one at a time, instead of needing a flag day.
- Split off driver conversions into their own commits
- Reorder and rework commits for clarity
Sean Anderson (10):
arm64: dts: Add compatible strings for Lynx PCSs
powerpc: dts: Add compatible strings for Lynx PCSs
net: pcs: Add subsystem
net: pcs: lynx: Convert to an MDIO driver
net: enetc: Convert to use PCS subsystem
net: dsa: felix: Convert to use PCS driver
of: property: Add device link support for PCS
[DO NOT MERGE] net: dpaa: Convert to use PCS subsystem
[DO NOT MERGE] net: dpaa2: Convert to use PCS subsystem
[DO NOT MERGE] net: pcs: lynx: Remove non-device functionality
Vladimir Oltean (1):
net: dsa: ocelot: suppress PHY device scanning on the internal MDIO
bus
Documentation/networking/index.rst | 1 +
Documentation/networking/pcs.rst | 109 ++++++++
MAINTAINERS | 2 +
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 48 ++--
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 54 ++--
.../dts/freescale/qoriq-fman3-0-10g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-10g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-2.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-3.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-4.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-5.dtsi | 3 +-
.../fsl/qoriq-fman3-0-10g-0-best-effort.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi | 3 +-
.../fsl/qoriq-fman3-0-10g-1-best-effort.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi | 3 +-
.../boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi | 3 +-
drivers/net/dsa/ocelot/Kconfig | 2 +
drivers/net/dsa/ocelot/felix_vsc9959.c | 31 +--
drivers/net/dsa/ocelot/seville_vsc9953.c | 33 +--
drivers/net/ethernet/freescale/dpaa2/Kconfig | 1 +
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 43 +---
drivers/net/ethernet/freescale/enetc/Kconfig | 1 +
.../net/ethernet/freescale/enetc/enetc_pf.c | 23 +-
.../net/ethernet/freescale/fman/fman_memac.c | 118 +++------
drivers/net/pcs/Kconfig | 23 +-
drivers/net/pcs/Makefile | 2 +
drivers/net/pcs/core.c | 243 ++++++++++++++++++
drivers/net/pcs/pcs-lynx.c | 76 ++++--
drivers/of/property.c | 4 +
include/linux/pcs-lynx.h | 12 +-
include/linux/pcs.h | 111 ++++++++
include/linux/phylink.h | 5 +
49 files changed, 758 insertions(+), 268 deletions(-)
create mode 100644 Documentation/networking/pcs.rst
create mode 100644 drivers/net/pcs/core.c
create mode 100644 include/linux/pcs.h
--
2.35.1.1320.gc452695387.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH net-next v2 01/11] arm64: dts: Add compatible strings for Lynx PCSs
2022-11-03 21:06 ` Sean Anderson
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson, Krzysztof Kozlowski, Li Yang,
Rob Herring, Shawn Guo, devicetree, linux-arm-kernel
This adds appropriate compatible strings for Lynx PCSs on arm64 QorIQ
platforms. This also changes the node name to avoid warnings from
ethernet-phy.yaml.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
(no changes since v1)
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 48 +++++++++++------
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 54 ++++++++++++-------
.../dts/freescale/qoriq-fman3-0-10g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-10g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-2.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-3.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-4.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-5.dtsi | 3 +-
10 files changed, 84 insertions(+), 42 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f1b9cc8714dc..148061b9828f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -552,7 +552,8 @@ pcs_mdio1: mdio@8c07000 {
#size-cells = <0>;
status = "disabled";
- pcs1: ethernet-phy@0 {
+ pcs1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -565,7 +566,8 @@ pcs_mdio2: mdio@8c0b000 {
#size-cells = <0>;
status = "disabled";
- pcs2: ethernet-phy@0 {
+ pcs2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -578,7 +580,8 @@ pcs_mdio3: mdio@8c0f000 {
#size-cells = <0>;
status = "disabled";
- pcs3: ethernet-phy@0 {
+ pcs3: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -591,7 +594,8 @@ pcs_mdio4: mdio@8c13000 {
#size-cells = <0>;
status = "disabled";
- pcs4: ethernet-phy@0 {
+ pcs4: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -604,7 +608,8 @@ pcs_mdio5: mdio@8c17000 {
#size-cells = <0>;
status = "disabled";
- pcs5: ethernet-phy@0 {
+ pcs5: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -617,7 +622,8 @@ pcs_mdio6: mdio@8c1b000 {
#size-cells = <0>;
status = "disabled";
- pcs6: ethernet-phy@0 {
+ pcs6: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -630,7 +636,8 @@ pcs_mdio7: mdio@8c1f000 {
#size-cells = <0>;
status = "disabled";
- pcs7: ethernet-phy@0 {
+ pcs7: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -643,7 +650,8 @@ pcs_mdio8: mdio@8c23000 {
#size-cells = <0>;
status = "disabled";
- pcs8: ethernet-phy@0 {
+ pcs8: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -656,7 +664,8 @@ pcs_mdio9: mdio@8c27000 {
#size-cells = <0>;
status = "disabled";
- pcs9: ethernet-phy@0 {
+ pcs9: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -669,7 +678,8 @@ pcs_mdio10: mdio@8c2b000 {
#size-cells = <0>;
status = "disabled";
- pcs10: ethernet-phy@0 {
+ pcs10: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -682,7 +692,8 @@ pcs_mdio11: mdio@8c2f000 {
#size-cells = <0>;
status = "disabled";
- pcs11: ethernet-phy@0 {
+ pcs11: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -695,7 +706,8 @@ pcs_mdio12: mdio@8c33000 {
#size-cells = <0>;
status = "disabled";
- pcs12: ethernet-phy@0 {
+ pcs12: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -708,7 +720,8 @@ pcs_mdio13: mdio@8c37000 {
#size-cells = <0>;
status = "disabled";
- pcs13: ethernet-phy@0 {
+ pcs13: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -721,7 +734,8 @@ pcs_mdio14: mdio@8c3b000 {
#size-cells = <0>;
status = "disabled";
- pcs14: ethernet-phy@0 {
+ pcs14: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -734,7 +748,8 @@ pcs_mdio15: mdio@8c3f000 {
#size-cells = <0>;
status = "disabled";
- pcs15: ethernet-phy@0 {
+ pcs15: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -747,7 +762,8 @@ pcs_mdio16: mdio@8c43000 {
#size-cells = <0>;
status = "disabled";
- pcs16: ethernet-phy@0 {
+ pcs16: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 6680fb2a6dc9..9315d4ed0454 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -1406,7 +1406,8 @@ pcs_mdio1: mdio@8c07000 {
#size-cells = <0>;
status = "disabled";
- pcs1: ethernet-phy@0 {
+ pcs1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1419,7 +1420,8 @@ pcs_mdio2: mdio@8c0b000 {
#size-cells = <0>;
status = "disabled";
- pcs2: ethernet-phy@0 {
+ pcs2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1432,7 +1434,8 @@ pcs_mdio3: mdio@8c0f000 {
#size-cells = <0>;
status = "disabled";
- pcs3: ethernet-phy@0 {
+ pcs3: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1445,7 +1448,8 @@ pcs_mdio4: mdio@8c13000 {
#size-cells = <0>;
status = "disabled";
- pcs4: ethernet-phy@0 {
+ pcs4: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1458,7 +1462,8 @@ pcs_mdio5: mdio@8c17000 {
#size-cells = <0>;
status = "disabled";
- pcs5: ethernet-phy@0 {
+ pcs5: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1471,7 +1476,8 @@ pcs_mdio6: mdio@8c1b000 {
#size-cells = <0>;
status = "disabled";
- pcs6: ethernet-phy@0 {
+ pcs6: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1484,7 +1490,8 @@ pcs_mdio7: mdio@8c1f000 {
#size-cells = <0>;
status = "disabled";
- pcs7: ethernet-phy@0 {
+ pcs7: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1497,7 +1504,8 @@ pcs_mdio8: mdio@8c23000 {
#size-cells = <0>;
status = "disabled";
- pcs8: ethernet-phy@0 {
+ pcs8: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1510,7 +1518,8 @@ pcs_mdio9: mdio@8c27000 {
#size-cells = <0>;
status = "disabled";
- pcs9: ethernet-phy@0 {
+ pcs9: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1523,7 +1532,8 @@ pcs_mdio10: mdio@8c2b000 {
#size-cells = <0>;
status = "disabled";
- pcs10: ethernet-phy@0 {
+ pcs10: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1536,7 +1546,8 @@ pcs_mdio11: mdio@8c2f000 {
#size-cells = <0>;
status = "disabled";
- pcs11: ethernet-phy@0 {
+ pcs11: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1549,7 +1560,8 @@ pcs_mdio12: mdio@8c33000 {
#size-cells = <0>;
status = "disabled";
- pcs12: ethernet-phy@0 {
+ pcs12: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1562,7 +1574,8 @@ pcs_mdio13: mdio@8c37000 {
#size-cells = <0>;
status = "disabled";
- pcs13: ethernet-phy@0 {
+ pcs13: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1575,7 +1588,8 @@ pcs_mdio14: mdio@8c3b000 {
#size-cells = <0>;
status = "disabled";
- pcs14: ethernet-phy@0 {
+ pcs14: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1588,7 +1602,8 @@ pcs_mdio15: mdio@8c3f000 {
#size-cells = <0>;
status = "disabled";
- pcs15: ethernet-phy@0 {
+ pcs15: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1601,7 +1616,8 @@ pcs_mdio16: mdio@8c43000 {
#size-cells = <0>;
status = "disabled";
- pcs16: ethernet-phy@0 {
+ pcs16: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1614,7 +1630,8 @@ pcs_mdio17: mdio@8c47000 {
#size-cells = <0>;
status = "disabled";
- pcs17: ethernet-phy@0 {
+ pcs17: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1627,7 +1644,8 @@ pcs_mdio18: mdio@8c4b000 {
#size-cells = <0>;
status = "disabled";
- pcs18: ethernet-phy@0 {
+ pcs18: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
index dbd2fc3ba790..4cf65e40126f 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
@@ -35,7 +35,8 @@ mdio@f1000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xf1000 0x1000>;
- pcsphy6: ethernet-phy@0 {
+ pcsphy6: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi
index 6fc5d2560057..de483c7e9ae0 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi
@@ -35,7 +35,8 @@ mdio@f3000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xf3000 0x1000>;
- pcsphy7: ethernet-phy@0 {
+ pcsphy7: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
index 4e02276fcf99..9c31b3b2292d 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
@@ -34,7 +34,8 @@ mdio@e1000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe1000 0x1000>;
- pcsphy0: ethernet-phy@0 {
+ pcsphy0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
index 0312fa43fa77..72dbb26c7fd4 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
@@ -34,7 +34,8 @@ mdio@e3000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe3000 0x1000>;
- pcsphy1: ethernet-phy@0 {
+ pcsphy1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
index af2df07971dd..e7aa07964d1c 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
@@ -34,7 +34,8 @@ mdio@e5000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe5000 0x1000>;
- pcsphy2: ethernet-phy@0 {
+ pcsphy2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
index 4ac98dc8b227..fb6b8d4eb786 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
@@ -34,7 +34,8 @@ mdio@e7000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe7000 0x1000>;
- pcsphy3: ethernet-phy@0 {
+ pcsphy3: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
index bd932d8b0160..1d9cc79bf7e2 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
@@ -34,7 +34,8 @@ mdio@e9000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe9000 0x1000>;
- pcsphy4: ethernet-phy@0 {
+ pcsphy4: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
index 7de1c5203f3e..b6151d6f6859 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
@@ -34,7 +34,8 @@ mdio@eb000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xeb000 0x1000>;
- pcsphy5: ethernet-phy@0 {
+ pcsphy5: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 01/11] arm64: dts: Add compatible strings for Lynx PCSs
@ 2022-11-03 21:06 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson, Krzysztof Kozlowski, Li Yang,
Rob Herring, Shawn Guo, devicetree, linux-arm-kernel
This adds appropriate compatible strings for Lynx PCSs on arm64 QorIQ
platforms. This also changes the node name to avoid warnings from
ethernet-phy.yaml.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
(no changes since v1)
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 48 +++++++++++------
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 54 ++++++++++++-------
.../dts/freescale/qoriq-fman3-0-10g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-10g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-0.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-1.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-2.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-3.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-4.dtsi | 3 +-
.../dts/freescale/qoriq-fman3-0-1g-5.dtsi | 3 +-
10 files changed, 84 insertions(+), 42 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f1b9cc8714dc..148061b9828f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -552,7 +552,8 @@ pcs_mdio1: mdio@8c07000 {
#size-cells = <0>;
status = "disabled";
- pcs1: ethernet-phy@0 {
+ pcs1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -565,7 +566,8 @@ pcs_mdio2: mdio@8c0b000 {
#size-cells = <0>;
status = "disabled";
- pcs2: ethernet-phy@0 {
+ pcs2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -578,7 +580,8 @@ pcs_mdio3: mdio@8c0f000 {
#size-cells = <0>;
status = "disabled";
- pcs3: ethernet-phy@0 {
+ pcs3: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -591,7 +594,8 @@ pcs_mdio4: mdio@8c13000 {
#size-cells = <0>;
status = "disabled";
- pcs4: ethernet-phy@0 {
+ pcs4: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -604,7 +608,8 @@ pcs_mdio5: mdio@8c17000 {
#size-cells = <0>;
status = "disabled";
- pcs5: ethernet-phy@0 {
+ pcs5: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -617,7 +622,8 @@ pcs_mdio6: mdio@8c1b000 {
#size-cells = <0>;
status = "disabled";
- pcs6: ethernet-phy@0 {
+ pcs6: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -630,7 +636,8 @@ pcs_mdio7: mdio@8c1f000 {
#size-cells = <0>;
status = "disabled";
- pcs7: ethernet-phy@0 {
+ pcs7: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -643,7 +650,8 @@ pcs_mdio8: mdio@8c23000 {
#size-cells = <0>;
status = "disabled";
- pcs8: ethernet-phy@0 {
+ pcs8: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -656,7 +664,8 @@ pcs_mdio9: mdio@8c27000 {
#size-cells = <0>;
status = "disabled";
- pcs9: ethernet-phy@0 {
+ pcs9: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -669,7 +678,8 @@ pcs_mdio10: mdio@8c2b000 {
#size-cells = <0>;
status = "disabled";
- pcs10: ethernet-phy@0 {
+ pcs10: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -682,7 +692,8 @@ pcs_mdio11: mdio@8c2f000 {
#size-cells = <0>;
status = "disabled";
- pcs11: ethernet-phy@0 {
+ pcs11: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -695,7 +706,8 @@ pcs_mdio12: mdio@8c33000 {
#size-cells = <0>;
status = "disabled";
- pcs12: ethernet-phy@0 {
+ pcs12: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -708,7 +720,8 @@ pcs_mdio13: mdio@8c37000 {
#size-cells = <0>;
status = "disabled";
- pcs13: ethernet-phy@0 {
+ pcs13: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -721,7 +734,8 @@ pcs_mdio14: mdio@8c3b000 {
#size-cells = <0>;
status = "disabled";
- pcs14: ethernet-phy@0 {
+ pcs14: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -734,7 +748,8 @@ pcs_mdio15: mdio@8c3f000 {
#size-cells = <0>;
status = "disabled";
- pcs15: ethernet-phy@0 {
+ pcs15: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -747,7 +762,8 @@ pcs_mdio16: mdio@8c43000 {
#size-cells = <0>;
status = "disabled";
- pcs16: ethernet-phy@0 {
+ pcs16: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 6680fb2a6dc9..9315d4ed0454 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -1406,7 +1406,8 @@ pcs_mdio1: mdio@8c07000 {
#size-cells = <0>;
status = "disabled";
- pcs1: ethernet-phy@0 {
+ pcs1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1419,7 +1420,8 @@ pcs_mdio2: mdio@8c0b000 {
#size-cells = <0>;
status = "disabled";
- pcs2: ethernet-phy@0 {
+ pcs2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1432,7 +1434,8 @@ pcs_mdio3: mdio@8c0f000 {
#size-cells = <0>;
status = "disabled";
- pcs3: ethernet-phy@0 {
+ pcs3: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1445,7 +1448,8 @@ pcs_mdio4: mdio@8c13000 {
#size-cells = <0>;
status = "disabled";
- pcs4: ethernet-phy@0 {
+ pcs4: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1458,7 +1462,8 @@ pcs_mdio5: mdio@8c17000 {
#size-cells = <0>;
status = "disabled";
- pcs5: ethernet-phy@0 {
+ pcs5: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1471,7 +1476,8 @@ pcs_mdio6: mdio@8c1b000 {
#size-cells = <0>;
status = "disabled";
- pcs6: ethernet-phy@0 {
+ pcs6: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1484,7 +1490,8 @@ pcs_mdio7: mdio@8c1f000 {
#size-cells = <0>;
status = "disabled";
- pcs7: ethernet-phy@0 {
+ pcs7: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1497,7 +1504,8 @@ pcs_mdio8: mdio@8c23000 {
#size-cells = <0>;
status = "disabled";
- pcs8: ethernet-phy@0 {
+ pcs8: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1510,7 +1518,8 @@ pcs_mdio9: mdio@8c27000 {
#size-cells = <0>;
status = "disabled";
- pcs9: ethernet-phy@0 {
+ pcs9: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1523,7 +1532,8 @@ pcs_mdio10: mdio@8c2b000 {
#size-cells = <0>;
status = "disabled";
- pcs10: ethernet-phy@0 {
+ pcs10: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1536,7 +1546,8 @@ pcs_mdio11: mdio@8c2f000 {
#size-cells = <0>;
status = "disabled";
- pcs11: ethernet-phy@0 {
+ pcs11: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1549,7 +1560,8 @@ pcs_mdio12: mdio@8c33000 {
#size-cells = <0>;
status = "disabled";
- pcs12: ethernet-phy@0 {
+ pcs12: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1562,7 +1574,8 @@ pcs_mdio13: mdio@8c37000 {
#size-cells = <0>;
status = "disabled";
- pcs13: ethernet-phy@0 {
+ pcs13: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1575,7 +1588,8 @@ pcs_mdio14: mdio@8c3b000 {
#size-cells = <0>;
status = "disabled";
- pcs14: ethernet-phy@0 {
+ pcs14: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1588,7 +1602,8 @@ pcs_mdio15: mdio@8c3f000 {
#size-cells = <0>;
status = "disabled";
- pcs15: ethernet-phy@0 {
+ pcs15: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1601,7 +1616,8 @@ pcs_mdio16: mdio@8c43000 {
#size-cells = <0>;
status = "disabled";
- pcs16: ethernet-phy@0 {
+ pcs16: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1614,7 +1630,8 @@ pcs_mdio17: mdio@8c47000 {
#size-cells = <0>;
status = "disabled";
- pcs17: ethernet-phy@0 {
+ pcs17: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -1627,7 +1644,8 @@ pcs_mdio18: mdio@8c4b000 {
#size-cells = <0>;
status = "disabled";
- pcs18: ethernet-phy@0 {
+ pcs18: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
index dbd2fc3ba790..4cf65e40126f 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-0.dtsi
@@ -35,7 +35,8 @@ mdio@f1000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xf1000 0x1000>;
- pcsphy6: ethernet-phy@0 {
+ pcsphy6: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi
index 6fc5d2560057..de483c7e9ae0 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-10g-1.dtsi
@@ -35,7 +35,8 @@ mdio@f3000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xf3000 0x1000>;
- pcsphy7: ethernet-phy@0 {
+ pcsphy7: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
index 4e02276fcf99..9c31b3b2292d 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-0.dtsi
@@ -34,7 +34,8 @@ mdio@e1000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe1000 0x1000>;
- pcsphy0: ethernet-phy@0 {
+ pcsphy0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
index 0312fa43fa77..72dbb26c7fd4 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-1.dtsi
@@ -34,7 +34,8 @@ mdio@e3000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe3000 0x1000>;
- pcsphy1: ethernet-phy@0 {
+ pcsphy1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
index af2df07971dd..e7aa07964d1c 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-2.dtsi
@@ -34,7 +34,8 @@ mdio@e5000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe5000 0x1000>;
- pcsphy2: ethernet-phy@0 {
+ pcsphy2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
index 4ac98dc8b227..fb6b8d4eb786 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-3.dtsi
@@ -34,7 +34,8 @@ mdio@e7000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe7000 0x1000>;
- pcsphy3: ethernet-phy@0 {
+ pcsphy3: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
index bd932d8b0160..1d9cc79bf7e2 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-4.dtsi
@@ -34,7 +34,8 @@ mdio@e9000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xe9000 0x1000>;
- pcsphy4: ethernet-phy@0 {
+ pcsphy4: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
index 7de1c5203f3e..b6151d6f6859 100644
--- a/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
+++ b/arch/arm64/boot/dts/freescale/qoriq-fman3-0-1g-5.dtsi
@@ -34,7 +34,8 @@ mdio@eb000 {
compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
reg = <0xeb000 0x1000>;
- pcsphy5: ethernet-phy@0 {
+ pcsphy5: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
--
2.35.1.1320.gc452695387.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 02/11] powerpc: dts: Add compatible strings for Lynx PCSs
2022-11-03 21:06 ` Sean Anderson
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson, Benjamin Herrenschmidt,
Krzysztof Kozlowski, Michael Ellerman, Paul Mackerras,
Rob Herring, devicetree, linuxppc-dev
This adds appropriate compatible strings for Lynx PCSs on PowerPC QorIQ
platforms. This also changes the node name to avoid warnings from
ethernet-phy.yaml.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
Changes in v2:
- Add compatibles for qoriq-fman3-0-10g-2/3.dtsi as well
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi | 3 ++-
20 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi
index 7e70977f282a..61d52044e7b4 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi
@@ -66,7 +66,8 @@ mdio@e1000 {
reg = <0xe1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy0: ethernet-phy@0 {
+ pcsphy0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
index 5f89f7c1761f..78d6e49655f4 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
@@ -70,7 +70,8 @@ mdio@f1000 {
reg = <0xf1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy6: ethernet-phy@0 {
+ pcsphy6: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi
index 71eb75e82c2e..5ffd1c2efaee 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi
@@ -73,7 +73,8 @@ mdio@e3000 {
reg = <0xe3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy1: ethernet-phy@0 {
+ pcsphy1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
index fb7032ddb7fc..e0325f09ce5f 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
@@ -70,7 +70,8 @@ mdio@f3000 {
reg = <0xf3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy7: ethernet-phy@0 {
+ pcsphy7: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi
index 6b3609574b0f..8e6f6c5f0f2e 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi
@@ -38,7 +38,8 @@ mdio@e1000 {
reg = <0xe1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy0: ethernet-phy@0 {
+ pcsphy0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi
index 28ed1a85a436..2cd3f0688cb1 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi
@@ -38,7 +38,8 @@ mdio@e3000 {
reg = <0xe3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy1: ethernet-phy@0 {
+ pcsphy1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi
index 1089d6861bfb..9f8c38a629cb 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi
@@ -62,7 +62,8 @@ mdio@e1000 {
reg = <0xe1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy0: ethernet-phy@0 {
+ pcsphy0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi
index a95bbb4fc827..248a57129d40 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi
@@ -69,7 +69,8 @@ mdio@e3000 {
reg = <0xe3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy1: ethernet-phy@0 {
+ pcsphy1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi
index 7d5af0147a25..73cef28db890 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi
@@ -69,7 +69,8 @@ mdio@e5000 {
reg = <0xe5000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy2: ethernet-phy@0 {
+ pcsphy2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi
index 61e5466ec854..4657b6a8fb78 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi
@@ -69,7 +69,8 @@ mdio@e7000 {
reg = <0xe7000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy3: ethernet-phy@0 {
+ pcsphy3: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi
index 3ba0cdafc069..ac322e5803c2 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi
@@ -62,7 +62,8 @@ mdio@e9000 {
reg = <0xe9000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy4: ethernet-phy@0 {
+ pcsphy4: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi
index 51748de0a289..68ffa2c65e03 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi
@@ -69,7 +69,8 @@ mdio@eb000 {
reg = <0xeb000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy5: ethernet-phy@0 {
+ pcsphy5: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi
index ee4f5170f632..caf28fcbd55c 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi
@@ -70,7 +70,8 @@ mdio@f1000 {
reg = <0xf1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy14: ethernet-phy@0 {
+ pcsphy14: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi
index 83d2e0ce8f7b..6128b9fb5381 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi
@@ -70,7 +70,8 @@ mdio@f3000 {
reg = <0xf3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy15: ethernet-phy@0 {
+ pcsphy15: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi
index 3132fc73f133..a7dffe6bbe5b 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi
@@ -62,7 +62,8 @@ mdio@e1000 {
reg = <0xe1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy8: ethernet-phy@0 {
+ pcsphy8: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi
index 75e904d96602..d0ad92f2ca2d 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi
@@ -69,7 +69,8 @@ mdio@e3000 {
reg = <0xe3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy9: ethernet-phy@0 {
+ pcsphy9: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi
index 69f2cc7b8f19..b4b893eead2a 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi
@@ -69,7 +69,8 @@ mdio@e5000 {
reg = <0xe5000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy10: ethernet-phy@0 {
+ pcsphy10: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi
index b3aaf01d7da0..6c15a6ff0926 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi
@@ -69,7 +69,8 @@ mdio@e7000 {
reg = <0xe7000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy11: ethernet-phy@0 {
+ pcsphy11: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi
index 18e020432807..14fa4d067ffd 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi
@@ -62,7 +62,8 @@ mdio@e9000 {
reg = <0xe9000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy12: ethernet-phy@0 {
+ pcsphy12: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi
index 55f329d13f19..64737187a577 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi
@@ -69,7 +69,8 @@ mdio@eb000 {
reg = <0xeb000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy13: ethernet-phy@0 {
+ pcsphy13: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 02/11] powerpc: dts: Add compatible strings for Lynx PCSs
@ 2022-11-03 21:06 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Andrew Lunn, Vladimir Oltean, Madalin Bucur, Sean Anderson,
linux-kernel, Eric Dumazet, Rob Herring, Paul Mackerras,
Krzysztof Kozlowski, Ioana Ciornei, Jakub Kicinski, Paolo Abeni,
linuxppc-dev, David S . Miller, devicetree
This adds appropriate compatible strings for Lynx PCSs on PowerPC QorIQ
platforms. This also changes the node name to avoid warnings from
ethernet-phy.yaml.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
Changes in v2:
- Add compatibles for qoriq-fman3-0-10g-2/3.dtsi as well
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi | 3 ++-
20 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi
index 7e70977f282a..61d52044e7b4 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi
@@ -66,7 +66,8 @@ mdio@e1000 {
reg = <0xe1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy0: ethernet-phy@0 {
+ pcsphy0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
index 5f89f7c1761f..78d6e49655f4 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
@@ -70,7 +70,8 @@ mdio@f1000 {
reg = <0xf1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy6: ethernet-phy@0 {
+ pcsphy6: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi
index 71eb75e82c2e..5ffd1c2efaee 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi
@@ -73,7 +73,8 @@ mdio@e3000 {
reg = <0xe3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy1: ethernet-phy@0 {
+ pcsphy1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
index fb7032ddb7fc..e0325f09ce5f 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
@@ -70,7 +70,8 @@ mdio@f3000 {
reg = <0xf3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy7: ethernet-phy@0 {
+ pcsphy7: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi
index 6b3609574b0f..8e6f6c5f0f2e 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi
@@ -38,7 +38,8 @@ mdio@e1000 {
reg = <0xe1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy0: ethernet-phy@0 {
+ pcsphy0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi
index 28ed1a85a436..2cd3f0688cb1 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi
@@ -38,7 +38,8 @@ mdio@e3000 {
reg = <0xe3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy1: ethernet-phy@0 {
+ pcsphy1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi
index 1089d6861bfb..9f8c38a629cb 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi
@@ -62,7 +62,8 @@ mdio@e1000 {
reg = <0xe1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy0: ethernet-phy@0 {
+ pcsphy0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi
index a95bbb4fc827..248a57129d40 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi
@@ -69,7 +69,8 @@ mdio@e3000 {
reg = <0xe3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy1: ethernet-phy@0 {
+ pcsphy1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi
index 7d5af0147a25..73cef28db890 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi
@@ -69,7 +69,8 @@ mdio@e5000 {
reg = <0xe5000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy2: ethernet-phy@0 {
+ pcsphy2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi
index 61e5466ec854..4657b6a8fb78 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi
@@ -69,7 +69,8 @@ mdio@e7000 {
reg = <0xe7000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy3: ethernet-phy@0 {
+ pcsphy3: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi
index 3ba0cdafc069..ac322e5803c2 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi
@@ -62,7 +62,8 @@ mdio@e9000 {
reg = <0xe9000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy4: ethernet-phy@0 {
+ pcsphy4: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi
index 51748de0a289..68ffa2c65e03 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi
@@ -69,7 +69,8 @@ mdio@eb000 {
reg = <0xeb000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy5: ethernet-phy@0 {
+ pcsphy5: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi
index ee4f5170f632..caf28fcbd55c 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi
@@ -70,7 +70,8 @@ mdio@f1000 {
reg = <0xf1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy14: ethernet-phy@0 {
+ pcsphy14: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi
index 83d2e0ce8f7b..6128b9fb5381 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi
@@ -70,7 +70,8 @@ mdio@f3000 {
reg = <0xf3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy15: ethernet-phy@0 {
+ pcsphy15: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi
index 3132fc73f133..a7dffe6bbe5b 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi
@@ -62,7 +62,8 @@ mdio@e1000 {
reg = <0xe1000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy8: ethernet-phy@0 {
+ pcsphy8: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi
index 75e904d96602..d0ad92f2ca2d 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi
@@ -69,7 +69,8 @@ mdio@e3000 {
reg = <0xe3000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy9: ethernet-phy@0 {
+ pcsphy9: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi
index 69f2cc7b8f19..b4b893eead2a 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi
@@ -69,7 +69,8 @@ mdio@e5000 {
reg = <0xe5000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy10: ethernet-phy@0 {
+ pcsphy10: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi
index b3aaf01d7da0..6c15a6ff0926 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi
@@ -69,7 +69,8 @@ mdio@e7000 {
reg = <0xe7000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy11: ethernet-phy@0 {
+ pcsphy11: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi
index 18e020432807..14fa4d067ffd 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi
@@ -62,7 +62,8 @@ mdio@e9000 {
reg = <0xe9000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy12: ethernet-phy@0 {
+ pcsphy12: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi
index 55f329d13f19..64737187a577 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi
@@ -69,7 +69,8 @@ mdio@eb000 {
reg = <0xeb000 0x1000>;
fsl,erratum-a011043; /* must ignore read errors */
- pcsphy13: ethernet-phy@0 {
+ pcsphy13: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0x0>;
};
};
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 03/11] net: dsa: ocelot: suppress PHY device scanning on the internal MDIO bus
2022-11-03 21:06 ` Sean Anderson
` (3 preceding siblings ...)
(?)
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Vladimir Oltean, Sean Anderson
From: Vladimir Oltean <vladimir.oltean@nxp.com>
This bus contains Lynx PCS devices, and if the lynx-pcs driver ever
decided to call mdio_device_register(), it would fail due to
mdiobus_scan() having created a dummy phydev for the same address
(the PCS responds to standard clause 22 PHY ID registers and can
therefore by autodetected by phylib which thinks it's a PHY).
On the Seville driver, things are a bit more complicated, since bus
creation is handled by mscc_miim_setup() and that is shared with the
dedicated mscc-miim driver. Suppress PHY scanning only for the Seville
internal MDIO bus rather than for the whole mscc-miim driver, since we
know that on NXP T1040, this bus only contains Lynx PCS devices.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
(no changes since v1)
drivers/net/dsa/ocelot/felix_vsc9959.c | 4 ++++
drivers/net/dsa/ocelot/seville_vsc9953.c | 6 +++++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c b/drivers/net/dsa/ocelot/felix_vsc9959.c
index 26a35ae322d1..ba893055b92d 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -990,6 +990,10 @@ static int vsc9959_mdio_bus_alloc(struct ocelot *ocelot)
bus->read = enetc_mdio_read;
bus->write = enetc_mdio_write;
bus->parent = dev;
+ /* Suppress PHY device creation in mdiobus_scan(),
+ * we have Lynx PCSs
+ */
+ bus->phy_mask = ~0;
mdio_priv = bus->priv;
mdio_priv->hw = hw;
/* This gets added to imdio_regs, which already maps addresses
diff --git a/drivers/net/dsa/ocelot/seville_vsc9953.c b/drivers/net/dsa/ocelot/seville_vsc9953.c
index 7af33b2c685d..1e1c6cd265fd 100644
--- a/drivers/net/dsa/ocelot/seville_vsc9953.c
+++ b/drivers/net/dsa/ocelot/seville_vsc9953.c
@@ -924,12 +924,16 @@ static int vsc9953_mdio_bus_alloc(struct ocelot *ocelot)
rc = mscc_miim_setup(dev, &bus, "VSC9953 internal MDIO bus",
ocelot->targets[GCB],
ocelot->map[GCB][GCB_MIIM_MII_STATUS & REG_MASK]);
-
if (rc) {
dev_err(dev, "failed to setup MDIO bus\n");
return rc;
}
+ /* Suppress PHY device creation in mdiobus_scan(),
+ * we have Lynx PCSs
+ */
+ bus->phy_mask = ~0;
+
/* Needed in order to initialize the bus mutex lock */
rc = devm_of_mdiobus_register(dev, bus, NULL);
if (rc < 0) {
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 04/11] net: pcs: Add subsystem
2022-11-03 21:06 ` Sean Anderson
` (4 preceding siblings ...)
(?)
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson
This adds support for getting PCS devices from the device tree. PCS
drivers must first register with phylink_register_pcs. After that, MAC
drivers may look up their PCS using phylink_get_pcs.
We use device links to ensure that PCS consumers are removed before
their PCSs. This will cause PCS consumers to be removed when their PCSs
go away. There is no way to avoid this without e.g. converting PCS
consumers to be composite devices. I think that approach adds
significant complexity, as PCS devices are unlikely to ever be remved.
Device links will not provide correct probe ordering when PCSs are
children of their consumers. In such cases, the PCS driver should set
suppress_bind_attrs to prevent incorrect removal order.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
This is adapted from [1], primarily incorporating the changes discussed
there. An example of this series done with composite devices may be
found at [2].
[1] https://lore.kernel.org/netdev/9f73bc4f-5f99-95f5-78fa-dac96f9e0146@seco.com/
[2] https://github.com/sean-anderson-seco/linux/tree/pcs_device
Changes in v2:
- Fix export of _pcs_get_by_fwnode
- Add device links to ensure correct probe/removal ordering
- Remove module_get/put, since this is ensured by the device_get/put
- Reorganize some of the control flow for legibility
- Add basic documentation
Documentation/networking/index.rst | 1 +
Documentation/networking/pcs.rst | 109 +++++++++++++
MAINTAINERS | 2 +
drivers/net/pcs/Kconfig | 12 ++
drivers/net/pcs/Makefile | 2 +
drivers/net/pcs/core.c | 243 +++++++++++++++++++++++++++++
include/linux/pcs.h | 111 +++++++++++++
include/linux/phylink.h | 5 +
8 files changed, 485 insertions(+)
create mode 100644 Documentation/networking/pcs.rst
create mode 100644 drivers/net/pcs/core.c
create mode 100644 include/linux/pcs.h
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 4f2d1f682a18..c37f94d9b24a 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -28,6 +28,7 @@ Contents:
page_pool
phy
sfp-phylink
+ pcs
alias
bridge
snmp_counter
diff --git a/Documentation/networking/pcs.rst b/Documentation/networking/pcs.rst
new file mode 100644
index 000000000000..3f3cafee1a88
--- /dev/null
+++ b/Documentation/networking/pcs.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+PCS Subsystem
+=============
+
+The PCS (Physical Coding Sublayer) subsystem handles the registration and lookup
+of PCS devices. These devices contain the upper sublayers of the Ethernet
+physical layer, generally handling framing, scrambling, and encoding tasks. PCS
+devices may also include PMA (Physical Medium Attachment) components. PCS
+devices transfer data between the Link-layer MAC device, and the rest of the
+physical layer, typically via a SerDes. The output of the SerDes may be
+connected more-or-less directly to the medium when using Fiber-optic or
+backplane connections (1000BASE-SX, 1000BASE-KX, etc). It may also communicate
+with a separate PHY (such as over SGMII) which handles the connection to the
+medium (such as 1000BASE-T).
+
+Looking up PCS Devices
+----------------------
+
+There are generally two ways to look up a PCS device. If the PCS device is
+internal to a larger device (such as a MAC or switch), and it does not share an
+implementation with an existing PCS, then it does not need to be registered with
+the PCS subsystem. Instead, you can populate a :c:type:`phylink_pcs`
+in your probe function. Otherwise, you must look up the PCS.
+
+If your device has a :c:type:`fwnode_handle`, you can add a PCS using the
+``pcs-handle`` property::
+
+ ethernet-controller {
+ // ...
+ pcs-handle = <&pcs>;
+ pcs-handle-names = "internal";
+ };
+
+Then, during your probe function, you can get the PCS using :c:func:`pcs_get`::
+
+ mac->pcs = pcs_get(dev, "internal");
+ if (IS_ERR(mac->pcs)) {
+ err = PTR_ERR(mac->pcs);
+ return dev_err_probe(dev, "Could not get PCS\n");
+ }
+
+If your device doesn't have a :c:type:`fwnode_handle`, you can get the PCS
+based on the providing device using :c:func:`pcs_get_by_dev`. Typically, you
+will create the device and bind your PCS driver to it before calling this
+function. This allows reuse of an existing PCS driver.
+
+Once you are done using the PCS, you must call :c:func:`pcs_put`.
+
+Using PCS Devices
+-----------------
+
+To select the PCS from a MAC driver, implement the ``mac_select_pcs`` callback
+of :c:type:`phylink_mac_ops`. In this example, the PCS is selected for SGMII
+and 1000BASE-X, and deselected for other interfaces::
+
+ static struct phylink_pcs *mac_select_pcs(struct phylink_config *config,
+ phy_interface_t iface)
+ {
+ struct mac *mac = config_to_mac(config);
+
+ switch (iface) {
+ case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
+ return mac->pcs;
+ default:
+ return NULL;
+ }
+ }
+
+To do the same from a DSA driver, implement the ``phylink_mac_select_pcs``
+callback of :c:type:`dsa_switch_ops`.
+
+Writing PCS Drivers
+-------------------
+
+To write a PCS driver, first implement :c:type:`phylink_pcs_ops`. Then,
+register your PCS in your probe function using :c:func:`pcs_register`. You must
+call :c:func:`pcs_unregister` from your remove function. You can avoid this step
+by registering with :c:func:`devm_pcs_unregister`.
+
+Normally, :ref:`device links <device_link>` will prevent improper ordering of
+device unbinding/removal. However, if your PCS device can be a child of its
+consumers (such as if it lives on an MDIO bus created by the MAC which uses the
+PCS), then no device link will be created. This is because children must be
+probed/removed after their parents, but a device link implies that the consumer
+must be probed after the provider. This contradiction is generally resolved by
+having the consumer probe the provider at an appropriate point in the consumer's
+probe function. However, the ``unbind`` device attribute can let userspace
+unbind the provider directly, bypassing this usual process. Therefore, PCS
+drivers in this situation, must set ``suppress_bind_attrs`` in their
+:c:type:`device_driver`.
+
+
+API Reference
+-------------
+
+.. kernel-doc:: include/linux/phylink.h
+ :identifiers: phylink_pcs phylink_pcs_ops
+
+.. kernel-doc:: include/linux/pcs.h
+ :internal:
+
+.. kernel-doc:: drivers/net/pcs/core.c
+ :export:
+
+.. kernel-doc:: drivers/net/pcs/core.c
+ :internal:
diff --git a/MAINTAINERS b/MAINTAINERS
index f99100cd37ce..bbea45c02e01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7705,6 +7705,7 @@ F: Documentation/ABI/testing/sysfs-class-net-phydev
F: Documentation/devicetree/bindings/net/ethernet-phy.yaml
F: Documentation/devicetree/bindings/net/mdio*
F: Documentation/devicetree/bindings/net/qca,ar803x.yaml
+F: Documentation/networking/pcs.rst
F: Documentation/networking/phy.rst
F: drivers/net/mdio/
F: drivers/net/mdio/acpi_mdio.c
@@ -7718,6 +7719,7 @@ F: include/linux/*mdio*.h
F: include/linux/mdio/*.h
F: include/linux/mii.h
F: include/linux/of_net.h
+F: include/linux/pcs.h
F: include/linux/phy.h
F: include/linux/phy_fixed.h
F: include/linux/platform_data/mdio-bcm-unimac.h
diff --git a/drivers/net/pcs/Kconfig b/drivers/net/pcs/Kconfig
index 6e7e6c346a3e..8d70fc52a803 100644
--- a/drivers/net/pcs/Kconfig
+++ b/drivers/net/pcs/Kconfig
@@ -5,6 +5,18 @@
menu "PCS device drivers"
+config PCS
+ bool "PCS subsystem"
+ help
+ This provides common helper functions for registering and looking up
+ Physical Coding Sublayer (PCS) devices. PCS devices translate between
+ different interface types. In some use cases, they may either
+ translate between different types of Medium-Independent Interfaces
+ (MIIs), such as translating GMII to SGMII. This allows using a fast
+ serial interface to talk to the phy which translates the MII to the
+ Medium-Dependent Interface. Alternatively, they may translate a MII
+ directly to an MDI, such as translating GMII to 1000Base-X.
+
config PCS_XPCS
tristate
select PHYLINK
diff --git a/drivers/net/pcs/Makefile b/drivers/net/pcs/Makefile
index 4c780d8f2e98..60cd32126d41 100644
--- a/drivers/net/pcs/Makefile
+++ b/drivers/net/pcs/Makefile
@@ -1,6 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
# Makefile for Linux PCS drivers
+obj-$(CONFIG_PCS) += core.o
+
pcs_xpcs-$(CONFIG_PCS_XPCS) := pcs-xpcs.o pcs-xpcs-nxp.o
obj-$(CONFIG_PCS_XPCS) += pcs_xpcs.o
diff --git a/drivers/net/pcs/core.c b/drivers/net/pcs/core.c
new file mode 100644
index 000000000000..be59afdac153
--- /dev/null
+++ b/drivers/net/pcs/core.c
@@ -0,0 +1,243 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Sean Anderson <sean.anderson@seco.com>
+ */
+
+#include <linux/fwnode.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
+#include <linux/notifier.h>
+#include <linux/pcs.h>
+#include <linux/phylink.h>
+#include <linux/property.h>
+
+static LIST_HEAD(pcs_devices);
+static DEFINE_MUTEX(pcs_mutex);
+
+/**
+ * pcs_register() - register a new PCS
+ * @pcs: the PCS to register
+ *
+ * Registers a new PCS which can be attached to a phylink.
+ *
+ * Return: 0 on success, or -errno on error
+ */
+int pcs_register(struct phylink_pcs *pcs)
+{
+ if (!pcs->dev || !pcs->ops)
+ return -EINVAL;
+ if (!pcs->ops->pcs_an_restart || !pcs->ops->pcs_config ||
+ !pcs->ops->pcs_get_state)
+ return -EINVAL;
+
+ INIT_LIST_HEAD(&pcs->list);
+ mutex_lock(&pcs_mutex);
+ list_add(&pcs->list, &pcs_devices);
+ mutex_unlock(&pcs_mutex);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pcs_register);
+
+/**
+ * pcs_unregister() - unregister a PCS
+ * @pcs: a PCS previously registered with pcs_register()
+ */
+void pcs_unregister(struct phylink_pcs *pcs)
+{
+ mutex_lock(&pcs_mutex);
+ list_del(&pcs->list);
+ mutex_unlock(&pcs_mutex);
+}
+EXPORT_SYMBOL_GPL(pcs_unregister);
+
+static void devm_pcs_release(struct device *dev, void *res)
+{
+ pcs_unregister(*(struct phylink_pcs **)res);
+}
+
+/**
+ * devm_pcs_register - resource managed pcs_register()
+ * @dev: device that is registering this PCS
+ * @pcs: the PCS to register
+ *
+ * Managed pcs_register(). For PCSs registered by this function,
+ * pcs_unregister() is automatically called on driver detach. See
+ * pcs_register() for more information.
+ *
+ * Return: 0 on success, or -errno on failure
+ */
+int devm_pcs_register(struct device *dev, struct phylink_pcs *pcs)
+{
+ struct phylink_pcs **pcsp;
+ int ret;
+
+ pcsp = devres_alloc(devm_pcs_release, sizeof(*pcsp),
+ GFP_KERNEL);
+ if (!pcsp)
+ return -ENOMEM;
+
+ ret = pcs_register(pcs);
+ if (ret) {
+ devres_free(pcsp);
+ return ret;
+ }
+
+ *pcsp = pcs;
+ devres_add(dev, pcsp);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(devm_pcs_register);
+
+/**
+ * _pcs_get_tail() - Look up and request a PCS
+ * @dev: The device requesting the PCS
+ * @fwnode: The PCS's fwnode
+ * @pcs_dev: The PCS's device
+ *
+ * Search PCSs registered with pcs_register() for one with a matching
+ * fwnode or device. Either @fwnode or @pcs_dev may be %NULL if matching
+ * against a fwnode or device is not desired (respectively).
+ *
+ * Once a PCS is found, perform common operations necessary when getting a PCS
+ * (increment reference counts, etc).
+ *
+ * Return: A PCS, or an error pointer on failure. If both @fwnode and @pcs_dev are
+ * * %NULL, returns %NULL to allow easier chaining.
+ */
+struct phylink_pcs *_pcs_get_tail(struct device *dev,
+ const struct fwnode_handle *fwnode,
+ const struct device *pcs_dev)
+{
+ struct phylink_pcs *pcs;
+
+ if (!fwnode && !pcs_dev)
+ return NULL;
+
+ /* We need to hold this until we get to device_link_add. Otherwise,
+ * someone could unbind the PCS driver.
+ */
+ mutex_lock(&pcs_mutex);
+ list_for_each_entry(pcs, &pcs_devices, list) {
+ if (pcs_dev && pcs->dev == pcs_dev)
+ goto found;
+ if (fwnode && pcs->dev->fwnode == fwnode)
+ goto found;
+ }
+ pcs = ERR_PTR(-EPROBE_DEFER);
+
+found:
+ pr_debug("looking for %pfwf or %s %s...%s found\n", fwnode,
+ dev ? dev_driver_string(dev) : "(null)",
+ dev ? dev_name(dev) : "(null)",
+ IS_ERR(pcs) ? " not" : "");
+ if (IS_ERR(pcs))
+ goto out;
+
+ get_device(pcs->dev);
+
+ /* If fwnode is present, this link should have already been created by
+ * of_fwnode_add_links. This will mainly fail if pcs->dev is a child of
+ * dev.
+ */
+ if (!device_link_add(dev, pcs->dev, DL_FLAG_STATELESS))
+ dev_dbg(dev, "failed to create device link to %s\n",
+ dev_name(pcs->dev));
+
+out:
+ mutex_unlock(&pcs_mutex);
+ return pcs;
+}
+EXPORT_SYMBOL_GPL(_pcs_get_tail);
+
+/**
+ * pcs_find_fwnode() - Find a PCS's fwnode
+ * @mac_node: The fwnode referencing the PCS
+ * @id: The name of the PCS to get. May be %NULL to get the first PCS.
+ * @optional: Whether the PCS is optional
+ *
+ * Find a PCS's fwnode, as referenced by @mac_node. This fwnode can later be
+ * used with _pcs_get_tail() to get the actual PCS. ``pcs-handle-names`` is
+ * used to match @id, then the fwnode is found using ``pcs-handle``.
+ *
+ * Return: %NULL if @optional is set and the PCS cannot be found. Otherwise,
+ * * returns a PCS if found or an error pointer on failure.
+ */
+static struct fwnode_handle *pcs_find_fwnode(const struct fwnode_handle *mac_node,
+ const char *id, bool optional)
+{
+ int index;
+ struct fwnode_handle *pcs_fwnode;
+
+ if (!mac_node)
+ return optional ? NULL : ERR_PTR(-ENODEV);
+
+ if (id)
+ index = fwnode_property_match_string(mac_node,
+ "pcs-handle-names", id);
+ else
+ index = 0;
+
+ if (index < 0) {
+ if (optional && (index == -EINVAL || index == -ENODATA))
+ return NULL;
+ return ERR_PTR(index);
+ }
+
+ /* First try pcs-handle, and if that doesn't work fall back to the
+ * (legacy) pcsphy-handle.
+ */
+ pcs_fwnode = fwnode_find_reference(mac_node, "pcs-handle", index);
+ if (PTR_ERR(pcs_fwnode) == -ENOENT)
+ pcs_fwnode = fwnode_find_reference(mac_node, "pcsphy-handle",
+ index);
+ if (optional && !id && PTR_ERR(pcs_fwnode) == -ENOENT)
+ return NULL;
+ return pcs_fwnode;
+}
+
+/**
+ * _pcs_get() - Get a PCS from a fwnode property
+ * @dev: The device to get a PCS for
+ * @fwnode: The fwnode to find the PCS with
+ * @id: The name of the PCS to get. May be %NULL to get the first PCS.
+ * @optional: Whether the PCS is optional
+ *
+ * Find a PCS referenced by @mac_node and return a reference to it. Every call
+ * to _pcs_get_by_fwnode() must be balanced with one to pcs_put().
+ *
+ * Return: a PCS if found, %NULL if not, or an error pointer on failure
+ */
+struct phylink_pcs *_pcs_get(struct device *dev, struct fwnode_handle *fwnode,
+ const char *id, bool optional)
+{
+ struct fwnode_handle *pcs_fwnode;
+ struct phylink_pcs *pcs;
+
+ pcs_fwnode = pcs_find_fwnode(fwnode, id, optional);
+ if (IS_ERR(pcs_fwnode))
+ return ERR_CAST(pcs_fwnode);
+
+ pcs = _pcs_get_tail(dev, pcs_fwnode, NULL);
+ fwnode_handle_put(pcs_fwnode);
+ return pcs;
+}
+EXPORT_SYMBOL_GPL(_pcs_get);
+
+/**
+ * pcs_put() - Release a previously-acquired PCS
+ * @dev: The device used to acquire the PCS
+ * @pcs: The PCS to put
+ *
+ * This frees resources associated with the PCS which were acquired when it was
+ * gotten.
+ */
+void pcs_put(struct device *dev, struct phylink_pcs *pcs)
+{
+ if (!pcs)
+ return;
+
+ device_link_remove(dev, pcs->dev);
+ put_device(pcs->dev);
+}
+EXPORT_SYMBOL_GPL(pcs_put);
diff --git a/include/linux/pcs.h b/include/linux/pcs.h
new file mode 100644
index 000000000000..41ea388ae3f7
--- /dev/null
+++ b/include/linux/pcs.h
@@ -0,0 +1,111 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2022 Sean Anderson <sean.anderson@seco.com>
+ */
+
+#ifndef _PCS_H
+#define _PCS_H
+
+#include <linux/property.h>
+
+struct phylink_pcs;
+
+int pcs_register(struct phylink_pcs *pcs);
+void pcs_unregister(struct phylink_pcs *pcs);
+int devm_pcs_register(struct device *dev, struct phylink_pcs *pcs);
+struct phylink_pcs *_pcs_get_tail(struct device *dev,
+ const struct fwnode_handle *fwnode,
+ const struct device *pcs_dev);
+struct phylink_pcs *_pcs_get(struct device *dev, struct fwnode_handle *fwnode,
+ const char *id, bool optional);
+void pcs_put(struct device *dev, struct phylink_pcs *pcs);
+
+/**
+ * pcs_get() - Get a PCS based on a fwnode
+ * @dev: The device requesting the PCS
+ * @id: The name of the PCS
+ *
+ * Find and get a PCS, as referenced by @dev's &struct fwnode_handle. See
+ * pcs_find_fwnode() for details. Each call to this function must be balanced
+ * with one to pcs_put().
+ *
+ * Return: A PCS on success, or an error pointer on failure
+ */
+static inline struct phylink_pcs *pcs_get(struct device *dev, const char *id)
+{
+ return _pcs_get(dev, dev_fwnode(dev), id, false);
+}
+
+/**
+ * pcs_get_optional() - Optionally get a PCS based on a fwnode
+ * @dev: The device requesting the PCS
+ * @id: The name of the PCS
+ *
+ * Optionally find and get a PCS, as referenced by @dev's &struct
+ * fwnode_handle. See pcs_find_fwnode() for details. Each call to this function
+ * must be balanced with one to pcs_put().
+ *
+ * Return: A PCS on success, %NULL if none was found, or an error pointer on
+ * * failure
+ */
+static inline struct phylink_pcs *pcs_get_optional(struct device *dev,
+ const char *id)
+{
+ return _pcs_get(dev, dev_fwnode(dev), id, true);
+}
+
+/**
+ * pcs_get_by_fwnode() - Get a PCS based on a fwnode
+ * @dev: The device requesting the PCS
+ * @fwnode: The &struct fwnode_handle referencing the PCS
+ * @id: The name of the PCS
+ *
+ * Find and get a PCS, as referenced by @fwnode. See pcs_find_fwnode() for
+ * details. Each call to this function must be balanced with one to pcs_put().
+ *
+ * Return: A PCS on success, or an error pointer on failure
+ */
+static inline struct phylink_pcs
+*pcs_get_by_fwnode(struct device *dev, struct fwnode_handle *fwnode,
+ const char *id)
+{
+ return _pcs_get(dev, fwnode, id, false);
+}
+
+/**
+ * pcs_get_by_fwnode_optional() - Optionally get a PCS based on a fwnode
+ * @dev: The device requesting the PCS
+ * @fwnode: The &struct fwnode_handle referencing the PCS
+ * @id: The name of the PCS
+ *
+ * Optionally find and get a PCS, as referenced by @fwnode. See
+ * pcs_find_fwnode() for details. Each call to this function must be balanced
+ * with one to pcs_put().
+ *
+ * Return: A PCS on success, %NULL if none was found, or an error pointer on
+ * * failure
+ */
+static inline struct phylink_pcs
+*pcs_get_by_fwnode_optional(struct device *dev, struct fwnode_handle *fwnode,
+ const char *id)
+{
+ return _pcs_get(dev, fwnode, id, true);
+}
+
+/**
+ * pcs_get_by_dev() - Get a PCS from its providing device
+ * @dev: The device requesting the PCS
+ * @pcs_dev: The device providing the PCS
+ *
+ * Get the first PCS registered by @pcs_dev. Each call to this function must be
+ * balanced with one to pcs_put().
+ *
+ * Return: A PCS on success, or an error pointer on failure
+ */
+static inline struct phylink_pcs *pcs_get_by_dev(struct device *dev,
+ const struct device *pcs_dev)
+{
+ return _pcs_get_tail(dev, NULL, pcs_dev);
+}
+
+#endif /* PCS_H */
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index 63800bf4a7ac..0edbf0d243e0 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -1,6 +1,7 @@
#ifndef NETDEV_PCS_H
#define NETDEV_PCS_H
+#include <linux/notifier.h>
#include <linux/phy.h>
#include <linux/spinlock.h>
#include <linux/workqueue.h>
@@ -432,13 +433,17 @@ struct phylink_pcs_ops;
/**
* struct phylink_pcs - PHYLINK PCS instance
+ * @dev: the device associated with this PCS
* @ops: a pointer to the &struct phylink_pcs_ops structure
+ * @list: internal list of PCS devices
* @poll: poll the PCS for link changes
*
* This structure is designed to be embedded within the PCS private data,
* and will be passed between phylink and the PCS.
*/
struct phylink_pcs {
+ struct list_head list;
+ struct device *dev;
const struct phylink_pcs_ops *ops;
bool poll;
};
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 05/11] net: pcs: lynx: Convert to an MDIO driver
2022-11-03 21:06 ` Sean Anderson
` (5 preceding siblings ...)
(?)
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson, Alexandre Belloni,
Claudiu Manoil, Florian Fainelli, UNGLinuxDriver, Vivien Didelot,
Vladimir Oltean
This partially converts the lynx PCS driver to a proper MDIO driver.
This allows using a more conventional driver lifecycle (e.g. with a
probe and remove). For compatibility with existing drivers, we retain
the old lynx_pcs_create/destroy functions. This may result in two
"drivers" attached to the same device (one real driver, and one attached
with lynx_pcs_create). However, this should not cause problems because
consumers will only use one or the other.
To assist in conversion of existing drivers to the PCS API, we provide a
lynx_pcs_create_on_bus function which will create an MDIO device on a
bus, bind our driver, and get the PCS. This should make it easy to
convert drivers which do not use devicetree.
Because this driver may be a direct child of its consumers (especially
when created with lynx_pcs_create_on_bus), we set suppress_bind_attrs.
This prevents userspace from causing a segfault by removing the PCS
before the consumer.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
Changes in v2:
- Call mdio_device_register
- Squash in lynx parts of "use pcs_get_by_provider to get PCS"
- Rewrite probe/remove functions to use create/destroy. This lets us
convert existing drivers one at a time, instead of needing a flag day.
drivers/net/pcs/Kconfig | 11 +++--
drivers/net/pcs/pcs-lynx.c | 83 +++++++++++++++++++++++++++++++++++---
include/linux/pcs-lynx.h | 7 +++-
3 files changed, 91 insertions(+), 10 deletions(-)
diff --git a/drivers/net/pcs/Kconfig b/drivers/net/pcs/Kconfig
index 8d70fc52a803..5e169e87db74 100644
--- a/drivers/net/pcs/Kconfig
+++ b/drivers/net/pcs/Kconfig
@@ -25,10 +25,15 @@ config PCS_XPCS
controllers.
config PCS_LYNX
- tristate
+ tristate "NXP Lynx PCS driver"
+ depends on PCS && MDIO_DEVICE
help
- This module provides helpers to phylink for managing the Lynx PCS
- which is part of the Layerscape and QorIQ Ethernet SERDES.
+ This module provides driver support for the PCSs in Lynx 10g and 28g
+ SerDes devices. These devices are present in NXP QorIQ SoCs,
+ including the Layerscape series.
+
+ If you want to use Ethernet on a QorIQ SoC, say "Y". If compiled as a
+ module, it will be called "pcs-lynx".
config PCS_RZN1_MIIC
tristate "Renesas RZ/N1 MII converter"
diff --git a/drivers/net/pcs/pcs-lynx.c b/drivers/net/pcs/pcs-lynx.c
index 7d5fc7f54b2f..3ea402049ef1 100644
--- a/drivers/net/pcs/pcs-lynx.c
+++ b/drivers/net/pcs/pcs-lynx.c
@@ -1,11 +1,14 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
-/* Copyright 2020 NXP
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2022 Sean Anderson <seanga2@gmail.com>
+ * Copyright 2020 NXP
* Lynx PCS MDIO helpers
*/
#include <linux/mdio.h>
-#include <linux/phylink.h>
+#include <linux/of.h>
+#include <linux/pcs.h>
#include <linux/pcs-lynx.h>
+#include <linux/phylink.h>
#define SGMII_CLOCK_PERIOD_NS 8 /* PCS is clocked at 125 MHz */
#define LINK_TIMER_VAL(ns) ((u32)((ns) / SGMII_CLOCK_PERIOD_NS))
@@ -333,7 +336,26 @@ struct phylink_pcs *lynx_pcs_create(struct mdio_device *mdio)
return lynx_to_phylink_pcs(lynx);
}
-EXPORT_SYMBOL(lynx_pcs_create);
+EXPORT_SYMBOL_GPL(lynx_pcs_create);
+
+static int lynx_pcs_probe(struct mdio_device *mdio)
+{
+ struct device *dev = &mdio->dev;
+ struct phylink_pcs *pcs;
+ int ret;
+
+ pcs = lynx_pcs_create(mdio);
+ if (!pcs)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev, pcs);
+ pcs->dev = dev;
+ ret = pcs_register(pcs);
+ if (ret)
+ return dev_err_probe(dev, ret, "could not register PCS\n");
+ dev_info(dev, "probed\n");
+ return 0;
+}
void lynx_pcs_destroy(struct phylink_pcs *pcs)
{
@@ -343,4 +365,55 @@ void lynx_pcs_destroy(struct phylink_pcs *pcs)
}
EXPORT_SYMBOL(lynx_pcs_destroy);
-MODULE_LICENSE("Dual BSD/GPL");
+static void lynx_pcs_remove(struct mdio_device *mdio)
+{
+ struct phylink_pcs *pcs = dev_get_drvdata(&mdio->dev);
+
+ pcs_unregister(pcs);
+ lynx_pcs_destroy(pcs);
+}
+
+static const struct of_device_id lynx_pcs_of_match[] = {
+ { .compatible = "fsl,lynx-pcs" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, lynx_pcs_of_match);
+
+static struct mdio_driver lynx_pcs_driver = {
+ .probe = lynx_pcs_probe,
+ .remove = lynx_pcs_remove,
+ .mdiodrv.driver = {
+ .name = "lynx-pcs",
+ .of_match_table = of_match_ptr(lynx_pcs_of_match),
+ .suppress_bind_attrs = true,
+ },
+};
+mdio_module_driver(lynx_pcs_driver);
+
+struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
+ struct mii_bus *bus, int addr)
+{
+ struct mdio_device *mdio;
+ struct phylink_pcs *pcs;
+ int err;
+
+ mdio = mdio_device_create(bus, addr);
+ if (IS_ERR(mdio))
+ return ERR_CAST(mdio);
+
+ mdio->bus_match = mdio_device_bus_match;
+ strncpy(mdio->modalias, "lynx-pcs", sizeof(mdio->modalias));
+ err = mdio_device_register(mdio);
+ if (err) {
+ mdio_device_free(mdio);
+ return ERR_PTR(err);
+ }
+
+ pcs = pcs_get_by_dev(dev, &mdio->dev);
+ mdio_device_free(mdio);
+ return pcs;
+}
+EXPORT_SYMBOL(lynx_pcs_create_on_bus);
+
+MODULE_DESCRIPTION("NXP Lynx 10G/28G PCS driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/pcs-lynx.h b/include/linux/pcs-lynx.h
index 5712cc2ce775..ef073b28fae9 100644
--- a/include/linux/pcs-lynx.h
+++ b/include/linux/pcs-lynx.h
@@ -6,12 +6,15 @@
#ifndef __LINUX_PCS_LYNX_H
#define __LINUX_PCS_LYNX_H
-#include <linux/mdio.h>
-#include <linux/phylink.h>
+struct device;
+struct mii_bus;
+struct phylink_pcs;
struct mdio_device *lynx_get_mdio_device(struct phylink_pcs *pcs);
struct phylink_pcs *lynx_pcs_create(struct mdio_device *mdio);
+struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
+ struct mii_bus *bus, int addr);
void lynx_pcs_destroy(struct phylink_pcs *pcs);
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 06/11] net: enetc: Convert to use PCS subsystem
2022-11-03 21:06 ` Sean Anderson
` (6 preceding siblings ...)
(?)
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson
This converts the ENETC driver to use the Lynx PCS subsystem, instead of
attaching the Lynx library to an MDIO device.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
Changes in v2:
- Split off from the lynx PCS patch
drivers/net/ethernet/freescale/enetc/Kconfig | 1 +
.../net/ethernet/freescale/enetc/enetc_pf.c | 23 ++++---------------
2 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig b/drivers/net/ethernet/freescale/enetc/Kconfig
index cdc0ff89388a..c7dcdeb9a333 100644
--- a/drivers/net/ethernet/freescale/enetc/Kconfig
+++ b/drivers/net/ethernet/freescale/enetc/Kconfig
@@ -5,6 +5,7 @@ config FSL_ENETC
select FSL_ENETC_IERB
select FSL_ENETC_MDIO
select PHYLINK
+ select PCS
select PCS_LYNX
select DIMLIB
help
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index bdf94335ee99..c7034230d7c0 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -8,6 +8,7 @@
#include <linux/of_platform.h>
#include <linux/of_mdio.h>
#include <linux/of_net.h>
+#include <linux/pcs.h>
#include <linux/pcs-lynx.h>
#include "enetc_ierb.h"
#include "enetc_pf.h"
@@ -876,7 +877,6 @@ static int enetc_imdio_create(struct enetc_pf *pf)
struct device *dev = &pf->si->pdev->dev;
struct enetc_mdio_priv *mdio_priv;
struct phylink_pcs *phylink_pcs;
- struct mdio_device *mdio_device;
struct mii_bus *bus;
int err;
@@ -900,17 +900,9 @@ static int enetc_imdio_create(struct enetc_pf *pf)
goto free_mdio_bus;
}
- mdio_device = mdio_device_create(bus, 0);
- if (IS_ERR(mdio_device)) {
- err = PTR_ERR(mdio_device);
- dev_err(dev, "cannot create mdio device (%d)\n", err);
- goto unregister_mdiobus;
- }
-
- phylink_pcs = lynx_pcs_create(mdio_device);
- if (!phylink_pcs) {
- mdio_device_free(mdio_device);
- err = -ENOMEM;
+ phylink_pcs = lynx_pcs_create_on_bus(dev, bus, 0);
+ if (IS_ERR(phylink_pcs)) {
+ err = PTR_ERR(phylink_pcs);
dev_err(dev, "cannot create lynx pcs (%d)\n", err);
goto unregister_mdiobus;
}
@@ -929,13 +921,6 @@ static int enetc_imdio_create(struct enetc_pf *pf)
static void enetc_imdio_remove(struct enetc_pf *pf)
{
- struct mdio_device *mdio_device;
-
- if (pf->pcs) {
- mdio_device = lynx_get_mdio_device(pf->pcs);
- mdio_device_free(mdio_device);
- lynx_pcs_destroy(pf->pcs);
- }
if (pf->imdio) {
mdiobus_unregister(pf->imdio);
mdiobus_free(pf->imdio);
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 07/11] net: dsa: felix: Convert to use PCS driver
2022-11-03 21:06 ` Sean Anderson
` (7 preceding siblings ...)
(?)
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson
This converts the Ocelot Felix driver to use the Lynx PCS driver,
instead of attaching the Lynx library to an MDIO device.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
Changes in v2:
- Split off from the lynx PCS patch
drivers/net/dsa/ocelot/Kconfig | 2 ++
drivers/net/dsa/ocelot/felix_vsc9959.c | 27 ++++++------------------
drivers/net/dsa/ocelot/seville_vsc9953.c | 27 ++++++------------------
3 files changed, 14 insertions(+), 42 deletions(-)
diff --git a/drivers/net/dsa/ocelot/Kconfig b/drivers/net/dsa/ocelot/Kconfig
index 08db9cf76818..eeba3d35f9ee 100644
--- a/drivers/net/dsa/ocelot/Kconfig
+++ b/drivers/net/dsa/ocelot/Kconfig
@@ -11,6 +11,7 @@ config NET_DSA_MSCC_FELIX
select NET_DSA_TAG_OCELOT_8021Q
select NET_DSA_TAG_OCELOT
select FSL_ENETC_MDIO
+ select PCS
select PCS_LYNX
help
This driver supports the VSC9959 (Felix) switch, which is embedded as
@@ -26,6 +27,7 @@ config NET_DSA_MSCC_SEVILLE
select MSCC_OCELOT_SWITCH_LIB
select NET_DSA_TAG_OCELOT_8021Q
select NET_DSA_TAG_OCELOT
+ select PCS
select PCS_LYNX
help
This driver supports the VSC9953 (Seville) switch, which is embedded
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c b/drivers/net/dsa/ocelot/felix_vsc9959.c
index ba893055b92d..f45c9a3088c8 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -11,6 +11,7 @@
#include <net/tc_act/tc_gate.h>
#include <soc/mscc/ocelot.h>
#include <linux/dsa/ocelot.h>
+#include <linux/pcs.h>
#include <linux/pcs-lynx.h>
#include <net/pkt_sched.h>
#include <linux/iopoll.h>
@@ -1015,7 +1016,6 @@ static int vsc9959_mdio_bus_alloc(struct ocelot *ocelot)
for (port = 0; port < felix->info->num_ports; port++) {
struct ocelot_port *ocelot_port = ocelot->ports[port];
struct phylink_pcs *phylink_pcs;
- struct mdio_device *mdio_device;
if (dsa_is_unused_port(felix->ds, port))
continue;
@@ -1023,19 +1023,13 @@ static int vsc9959_mdio_bus_alloc(struct ocelot *ocelot)
if (ocelot_port->phy_mode == PHY_INTERFACE_MODE_INTERNAL)
continue;
- mdio_device = mdio_device_create(felix->imdio, port);
- if (IS_ERR(mdio_device))
+ phylink_pcs = lynx_pcs_create_on_bus(dev, felix->imdio, port);
+ if (IS_ERR(phylink_pcs))
continue;
- phylink_pcs = lynx_pcs_create(mdio_device);
- if (!phylink_pcs) {
- mdio_device_free(mdio_device);
- continue;
- }
-
felix->pcs[port] = phylink_pcs;
- dev_info(dev, "Found PCS at internal MDIO address %d\n", port);
+ dev_info(dev, "Created PCS at internal MDIO address %d\n", port);
}
return 0;
@@ -1046,17 +1040,8 @@ static void vsc9959_mdio_bus_free(struct ocelot *ocelot)
struct felix *felix = ocelot_to_felix(ocelot);
int port;
- for (port = 0; port < ocelot->num_phys_ports; port++) {
- struct phylink_pcs *phylink_pcs = felix->pcs[port];
- struct mdio_device *mdio_device;
-
- if (!phylink_pcs)
- continue;
-
- mdio_device = lynx_get_mdio_device(phylink_pcs);
- mdio_device_free(mdio_device);
- lynx_pcs_destroy(phylink_pcs);
- }
+ for (port = 0; port < ocelot->num_phys_ports; port++)
+ pcs_put(ocelot->dev, felix->pcs[port]);
mdiobus_unregister(felix->imdio);
mdiobus_free(felix->imdio);
}
diff --git a/drivers/net/dsa/ocelot/seville_vsc9953.c b/drivers/net/dsa/ocelot/seville_vsc9953.c
index 1e1c6cd265fd..99e8043fbc2e 100644
--- a/drivers/net/dsa/ocelot/seville_vsc9953.c
+++ b/drivers/net/dsa/ocelot/seville_vsc9953.c
@@ -9,6 +9,7 @@
#include <linux/mdio/mdio-mscc-miim.h>
#include <linux/of_mdio.h>
#include <linux/of_platform.h>
+#include <linux/pcs.h>
#include <linux/pcs-lynx.h>
#include <linux/dsa/ocelot.h>
#include <linux/iopoll.h>
@@ -946,7 +947,6 @@ static int vsc9953_mdio_bus_alloc(struct ocelot *ocelot)
for (port = 0; port < felix->info->num_ports; port++) {
struct ocelot_port *ocelot_port = ocelot->ports[port];
struct phylink_pcs *phylink_pcs;
- struct mdio_device *mdio_device;
int addr = port + 4;
if (dsa_is_unused_port(felix->ds, port))
@@ -955,19 +955,13 @@ static int vsc9953_mdio_bus_alloc(struct ocelot *ocelot)
if (ocelot_port->phy_mode == PHY_INTERFACE_MODE_INTERNAL)
continue;
- mdio_device = mdio_device_create(felix->imdio, addr);
- if (IS_ERR(mdio_device))
+ phylink_pcs = lynx_pcs_create_on_bus(dev, felix->imdio, addr);
+ if (IS_ERR(phylink_pcs))
continue;
- phylink_pcs = lynx_pcs_create(mdio_device);
- if (!phylink_pcs) {
- mdio_device_free(mdio_device);
- continue;
- }
-
felix->pcs[port] = phylink_pcs;
- dev_info(dev, "Found PCS at internal MDIO address %d\n", addr);
+ dev_info(dev, "Created PCS at internal MDIO address %d\n", addr);
}
return 0;
@@ -978,17 +972,8 @@ static void vsc9953_mdio_bus_free(struct ocelot *ocelot)
struct felix *felix = ocelot_to_felix(ocelot);
int port;
- for (port = 0; port < ocelot->num_phys_ports; port++) {
- struct phylink_pcs *phylink_pcs = felix->pcs[port];
- struct mdio_device *mdio_device;
-
- if (!phylink_pcs)
- continue;
-
- mdio_device = lynx_get_mdio_device(phylink_pcs);
- mdio_device_free(mdio_device);
- lynx_pcs_destroy(phylink_pcs);
- }
+ for (port = 0; port < ocelot->num_phys_ports; port++)
+ pcs_put(ocelot->dev, felix->pcs[port]);
/* mdiobus_unregister and mdiobus_free handled by devres */
}
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 08/11] of: property: Add device link support for PCS
2022-11-03 21:06 ` Sean Anderson
` (8 preceding siblings ...)
(?)
@ 2022-11-03 21:06 ` Sean Anderson
2022-11-07 20:10 ` Rob Herring
-1 siblings, 1 reply; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson, Frank Rowand, Rob Herring,
Saravana Kannan, devicetree
This adds device link support for PCS devices. Both the recommended
pcs-handle and the deprecated pcsphy-handle properties are supported.
This should provide better probe ordering.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
(no changes since v1)
drivers/of/property.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 967f79b59016..ec360a616d17 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1318,6 +1318,8 @@ DEFINE_SIMPLE_PROP(pinctrl6, "pinctrl-6", NULL)
DEFINE_SIMPLE_PROP(pinctrl7, "pinctrl-7", NULL)
DEFINE_SIMPLE_PROP(pinctrl8, "pinctrl-8", NULL)
DEFINE_SIMPLE_PROP(remote_endpoint, "remote-endpoint", NULL)
+DEFINE_SIMPLE_PROP(pcs_handle, "pcs-handle", NULL)
+DEFINE_SIMPLE_PROP(pcsphy_handle, "pcsphy-handle", NULL)
DEFINE_SIMPLE_PROP(pwms, "pwms", "#pwm-cells")
DEFINE_SIMPLE_PROP(resets, "resets", "#reset-cells")
DEFINE_SIMPLE_PROP(leds, "leds", NULL)
@@ -1406,6 +1408,8 @@ static const struct supplier_bindings of_supplier_bindings[] = {
{ .parse_prop = parse_pinctrl7, },
{ .parse_prop = parse_pinctrl8, },
{ .parse_prop = parse_remote_endpoint, .node_not_dev = true, },
+ { .parse_prop = parse_pcs_handle, },
+ { .parse_prop = parse_pcsphy_handle, },
{ .parse_prop = parse_pwms, },
{ .parse_prop = parse_resets, },
{ .parse_prop = parse_leds, },
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 09/11] [DO NOT MERGE] net: dpaa: Convert to use PCS subsystem
2022-11-03 21:06 ` Sean Anderson
` (9 preceding siblings ...)
(?)
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson
This converts the ENETC driver to use the PCS subsystem, instead of
attaching the Lynx library to an MDIO device. The control flow is now a
bit different, since we don't know whether pcs-handle-names necessarily
exists.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
Changes in v2:
- Split off from the lynx PCS patch
.../net/ethernet/freescale/fman/fman_memac.c | 118 ++++++------------
1 file changed, 41 insertions(+), 77 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman_memac.c b/drivers/net/ethernet/freescale/fman/fman_memac.c
index 9349f841bd06..a88fcfbcb5e6 100644
--- a/drivers/net/ethernet/freescale/fman/fman_memac.c
+++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
@@ -11,7 +11,7 @@
#include <linux/slab.h>
#include <linux/io.h>
-#include <linux/pcs-lynx.h>
+#include <linux/pcs.h>
#include <linux/phy.h>
#include <linux/phy_fixed.h>
#include <linux/phy/phy.h>
@@ -974,25 +974,17 @@ static int memac_init(struct fman_mac *memac)
return 0;
}
-static void pcs_put(struct phylink_pcs *pcs)
-{
- struct mdio_device *mdiodev;
-
- if (IS_ERR_OR_NULL(pcs))
- return;
-
- mdiodev = lynx_get_mdio_device(pcs);
- lynx_pcs_destroy(pcs);
- mdio_device_free(mdiodev);
-}
-
static int memac_free(struct fman_mac *memac)
{
free_init_resources(memac);
- pcs_put(memac->sgmii_pcs);
- pcs_put(memac->qsgmii_pcs);
- pcs_put(memac->xfi_pcs);
+ if (!IS_ERR(memac->xfi_pcs))
+ pcs_put(memac->dev_id->dev, memac->xfi_pcs);
+ if (!IS_ERR(memac->qsgmii_pcs))
+ pcs_put(memac->dev_id->dev, memac->qsgmii_pcs);
+ if (!IS_ERR(memac->sgmii_pcs))
+ pcs_put(memac->dev_id->dev, memac->sgmii_pcs);
+
kfree(memac->memac_drv_param);
kfree(memac);
@@ -1039,25 +1031,6 @@ static struct fman_mac *memac_config(struct mac_device *mac_dev,
return memac;
}
-static struct phylink_pcs *memac_pcs_create(struct device_node *mac_node,
- int index)
-{
- struct device_node *node;
- struct mdio_device *mdiodev = NULL;
- struct phylink_pcs *pcs;
-
- node = of_parse_phandle(mac_node, "pcsphy-handle", index);
- if (node && of_device_is_available(node))
- mdiodev = of_mdio_find_device(node);
- of_node_put(node);
-
- if (!mdiodev)
- return ERR_PTR(-EPROBE_DEFER);
-
- pcs = lynx_pcs_create(mdiodev);
- return pcs;
-}
-
static bool memac_supports(struct mac_device *mac_dev, phy_interface_t iface)
{
/* If there's no serdes device, assume that it's been configured for
@@ -1076,7 +1049,6 @@ int memac_initialization(struct mac_device *mac_dev,
{
int err;
struct device_node *fixed;
- struct phylink_pcs *pcs;
struct fman_mac *memac;
unsigned long capabilities;
unsigned long *supported;
@@ -1101,56 +1073,48 @@ int memac_initialization(struct mac_device *mac_dev,
memac->memac_drv_param->max_frame_length = fman_get_max_frm();
memac->memac_drv_param->reset_on_init = true;
- err = of_property_match_string(mac_node, "pcs-handle-names", "xfi");
- if (err >= 0) {
- memac->xfi_pcs = memac_pcs_create(mac_node, err);
- if (IS_ERR(memac->xfi_pcs)) {
- err = PTR_ERR(memac->xfi_pcs);
- dev_err_probe(mac_dev->dev, err, "missing xfi pcs\n");
- goto _return_fm_mac_free;
- }
- } else if (err != -EINVAL && err != -ENODATA) {
+ memac->xfi_pcs = pcs_get_optional(mac_dev->dev, "xfi");
+ if (IS_ERR(memac->xfi_pcs)) {
+ err = PTR_ERR(memac->xfi_pcs);
+ dev_err_probe(mac_dev->dev, err, "missing xfi pcs\n");
goto _return_fm_mac_free;
}
- err = of_property_match_string(mac_node, "pcs-handle-names", "qsgmii");
- if (err >= 0) {
- memac->qsgmii_pcs = memac_pcs_create(mac_node, err);
- if (IS_ERR(memac->qsgmii_pcs)) {
- err = PTR_ERR(memac->qsgmii_pcs);
- dev_err_probe(mac_dev->dev, err,
- "missing qsgmii pcs\n");
- goto _return_fm_mac_free;
- }
- } else if (err != -EINVAL && err != -ENODATA) {
+ memac->qsgmii_pcs = pcs_get_optional(mac_dev->dev, "qsgmii");
+ if (IS_ERR(memac->qsgmii_pcs)) {
+ err = PTR_ERR(memac->qsgmii_pcs);
+ dev_err_probe(mac_dev->dev, err, "missing qsgmii pcs\n");
goto _return_fm_mac_free;
}
- /* For compatibility, if pcs-handle-names is missing, we assume this
- * phy is the first one in pcsphy-handle
- */
- err = of_property_match_string(mac_node, "pcs-handle-names", "sgmii");
- if (err == -EINVAL || err == -ENODATA)
- pcs = memac_pcs_create(mac_node, 0);
- else if (err < 0)
- goto _return_fm_mac_free;
- else
- pcs = memac_pcs_create(mac_node, err);
-
- if (IS_ERR(pcs)) {
- err = PTR_ERR(pcs);
- dev_err_probe(mac_dev->dev, err, "missing pcs\n");
+ memac->sgmii_pcs = pcs_get_optional(mac_dev->dev, "sgmii");
+ if (IS_ERR(memac->sgmii_pcs)) {
+ err = PTR_ERR(memac->sgmii_pcs);
+ dev_err_probe(mac_dev->dev, err, "missing sgmii pcs\n");
goto _return_fm_mac_free;
}
- /* If err is set here, it means that pcs-handle-names was missing above
- * (and therefore that xfi_pcs cannot be set). If we are defaulting to
- * XGMII, assume this is for XFI. Otherwise, assume it is for SGMII.
- */
- if (err && mac_dev->phy_if == PHY_INTERFACE_MODE_XGMII)
- memac->xfi_pcs = pcs;
- else
- memac->sgmii_pcs = pcs;
+ if (!memac->sgmii_pcs && !memac->qsgmii_pcs && !memac->xfi_pcs) {
+ struct phylink_pcs *pcs;
+
+ /* For compatibility, if pcs-handle-names is missing, we assume
+ * this phy is the first one in pcsphy-handle
+ */
+ pcs = pcs_get_optional(mac_dev->dev, NULL);
+ if (IS_ERR(pcs)) {
+ err = PTR_ERR(pcs);
+ dev_err_probe(mac_dev->dev, err, "missing pcs\n");
+ goto _return_fm_mac_free;
+ }
+
+ /* If the interface mode is XGMII, assume this is for XFI.
+ * Otherwise, assume this PCS is for SGMII.
+ */
+ if (memac->dev_id->phy_if == PHY_INTERFACE_MODE_XGMII)
+ memac->xfi_pcs = pcs;
+ else
+ memac->sgmii_pcs = pcs;
+ }
memac->serdes = devm_of_phy_get(mac_dev->dev, mac_node, "serdes");
err = PTR_ERR(memac->serdes);
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 10/11] [DO NOT MERGE] net: dpaa2: Convert to use PCS subsystem
2022-11-03 21:06 ` Sean Anderson
` (10 preceding siblings ...)
(?)
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson
This converts the DPAA2 driver to use the PCS subsystem, instead of
attaching the Lynx library to an MDIO device.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
Changes in v2:
- Split off from the lynx PCS patch
drivers/net/ethernet/freescale/dpaa2/Kconfig | 1 +
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 43 +++----------------
2 files changed, 8 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/Kconfig b/drivers/net/ethernet/freescale/dpaa2/Kconfig
index d029b69c3f18..2648e9fb6e13 100644
--- a/drivers/net/ethernet/freescale/dpaa2/Kconfig
+++ b/drivers/net/ethernet/freescale/dpaa2/Kconfig
@@ -3,6 +3,7 @@ config FSL_DPAA2_ETH
tristate "Freescale DPAA2 Ethernet"
depends on FSL_MC_BUS && FSL_MC_DPIO
select PHYLINK
+ select PCS
select PCS_LYNX
select FSL_XGMAC_MDIO
select NET_DEVLINK
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
index 49ff85633783..18f8f9f8d161 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
@@ -2,6 +2,7 @@
/* Copyright 2019 NXP */
#include <linux/acpi.h>
+#include <linux/pcs.h>
#include <linux/pcs-lynx.h>
#include <linux/phy/phy.h>
#include <linux/property.h>
@@ -246,32 +247,10 @@ static int dpaa2_pcs_create(struct dpaa2_mac *mac,
struct fwnode_handle *dpmac_node,
int id)
{
- struct mdio_device *mdiodev;
- struct fwnode_handle *node;
-
- node = fwnode_find_reference(dpmac_node, "pcs-handle", 0);
- if (IS_ERR(node)) {
- /* do not error out on old DTS files */
- netdev_warn(mac->net_dev, "pcs-handle node not found\n");
- return 0;
- }
-
- if (!fwnode_device_is_available(node)) {
- netdev_err(mac->net_dev, "pcs-handle node not available\n");
- fwnode_handle_put(node);
- return -ENODEV;
- }
-
- mdiodev = fwnode_mdio_find_device(node);
- fwnode_handle_put(node);
- if (!mdiodev)
- return -EPROBE_DEFER;
-
- mac->pcs = lynx_pcs_create(mdiodev);
- if (!mac->pcs) {
- netdev_err(mac->net_dev, "lynx_pcs_create() failed\n");
- put_device(&mdiodev->dev);
- return -ENOMEM;
+ mac->pcs = pcs_get_by_fwnode(&mac->mc_dev->dev, dpmac_node, NULL);
+ if (IS_ERR(mac->pcs)) {
+ netdev_err(mac->net_dev, "pcs_get_by_fwnode() failed\n");
+ return PTR_ERR(mac->pcs);
}
return 0;
@@ -279,16 +258,8 @@ static int dpaa2_pcs_create(struct dpaa2_mac *mac,
static void dpaa2_pcs_destroy(struct dpaa2_mac *mac)
{
- struct phylink_pcs *phylink_pcs = mac->pcs;
-
- if (phylink_pcs) {
- struct mdio_device *mdio = lynx_get_mdio_device(phylink_pcs);
- struct device *dev = &mdio->dev;
-
- lynx_pcs_destroy(phylink_pcs);
- put_device(dev);
- mac->pcs = NULL;
- }
+ pcs_put(&mac->mc_dev->dev, mac->pcs);
+ mac->pcs = NULL;
}
static void dpaa2_mac_set_supported_interfaces(struct dpaa2_mac *mac)
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH net-next v2 11/11] [DO NOT MERGE] net: pcs: lynx: Remove non-device functionality
2022-11-03 21:06 ` Sean Anderson
` (11 preceding siblings ...)
(?)
@ 2022-11-03 21:06 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-03 21:06 UTC (permalink / raw)
To: Heiner Kallweit, Russell King, netdev
Cc: Vladimir Oltean, Eric Dumazet, Paolo Abeni, Jakub Kicinski,
linux-kernel, Andrew Lunn, Ioana Ciornei, Madalin Bucur,
David S . Miller, Sean Anderson
As all former consumers of non-device lynx PCSs have been removed, we
can now remove the remaining functions retained for backwards-
compatibility.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
(no changes since v1)
drivers/net/pcs/pcs-lynx.c | 51 +++++---------------------------------
include/linux/pcs-lynx.h | 5 ----
2 files changed, 6 insertions(+), 50 deletions(-)
diff --git a/drivers/net/pcs/pcs-lynx.c b/drivers/net/pcs/pcs-lynx.c
index 3ea402049ef1..df9e8ad3f728 100644
--- a/drivers/net/pcs/pcs-lynx.c
+++ b/drivers/net/pcs/pcs-lynx.c
@@ -38,15 +38,6 @@ enum sgmii_speed {
};
#define phylink_pcs_to_lynx(pl_pcs) container_of((pl_pcs), struct lynx_pcs, pcs)
-#define lynx_to_phylink_pcs(lynx) (&(lynx)->pcs)
-
-struct mdio_device *lynx_get_mdio_device(struct phylink_pcs *pcs)
-{
- struct lynx_pcs *lynx = phylink_pcs_to_lynx(pcs);
-
- return lynx->mdio;
-}
-EXPORT_SYMBOL(lynx_get_mdio_device);
static void lynx_pcs_get_state_usxgmii(struct mdio_device *pcs,
struct phylink_link_state *state)
@@ -322,57 +313,28 @@ static const struct phylink_pcs_ops lynx_pcs_phylink_ops = {
.pcs_link_up = lynx_pcs_link_up,
};
-struct phylink_pcs *lynx_pcs_create(struct mdio_device *mdio)
+static int lynx_pcs_probe(struct mdio_device *mdio)
{
+ struct device *dev = &mdio->dev;
struct lynx_pcs *lynx;
+ int ret;
lynx = kzalloc(sizeof(*lynx), GFP_KERNEL);
if (!lynx)
- return NULL;
+ return -ENOMEM;
lynx->mdio = mdio;
+ lynx->pcs.dev = dev;
lynx->pcs.ops = &lynx_pcs_phylink_ops;
lynx->pcs.poll = true;
- return lynx_to_phylink_pcs(lynx);
-}
-EXPORT_SYMBOL_GPL(lynx_pcs_create);
-
-static int lynx_pcs_probe(struct mdio_device *mdio)
-{
- struct device *dev = &mdio->dev;
- struct phylink_pcs *pcs;
- int ret;
-
- pcs = lynx_pcs_create(mdio);
- if (!pcs)
- return -ENOMEM;
-
- dev_set_drvdata(dev, pcs);
- pcs->dev = dev;
- ret = pcs_register(pcs);
+ ret = devm_pcs_register(dev, &lynx->pcs);
if (ret)
return dev_err_probe(dev, ret, "could not register PCS\n");
dev_info(dev, "probed\n");
return 0;
}
-void lynx_pcs_destroy(struct phylink_pcs *pcs)
-{
- struct lynx_pcs *lynx = phylink_pcs_to_lynx(pcs);
-
- kfree(lynx);
-}
-EXPORT_SYMBOL(lynx_pcs_destroy);
-
-static void lynx_pcs_remove(struct mdio_device *mdio)
-{
- struct phylink_pcs *pcs = dev_get_drvdata(&mdio->dev);
-
- pcs_unregister(pcs);
- lynx_pcs_destroy(pcs);
-}
-
static const struct of_device_id lynx_pcs_of_match[] = {
{ .compatible = "fsl,lynx-pcs" },
{ },
@@ -381,7 +343,6 @@ MODULE_DEVICE_TABLE(of, lynx_pcs_of_match);
static struct mdio_driver lynx_pcs_driver = {
.probe = lynx_pcs_probe,
- .remove = lynx_pcs_remove,
.mdiodrv.driver = {
.name = "lynx-pcs",
.of_match_table = of_match_ptr(lynx_pcs_of_match),
diff --git a/include/linux/pcs-lynx.h b/include/linux/pcs-lynx.h
index ef073b28fae9..f8fe134c63e5 100644
--- a/include/linux/pcs-lynx.h
+++ b/include/linux/pcs-lynx.h
@@ -10,12 +10,7 @@ struct device;
struct mii_bus;
struct phylink_pcs;
-struct mdio_device *lynx_get_mdio_device(struct phylink_pcs *pcs);
-
-struct phylink_pcs *lynx_pcs_create(struct mdio_device *mdio);
struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
struct mii_bus *bus, int addr);
-void lynx_pcs_destroy(struct phylink_pcs *pcs);
-
#endif /* __LINUX_PCS_LYNX_H */
--
2.35.1.1320.gc452695387.dirty
^ permalink raw reply related [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 08/11] of: property: Add device link support for PCS
2022-11-03 21:06 ` [PATCH net-next v2 08/11] of: property: Add device link support for PCS Sean Anderson
@ 2022-11-07 20:10 ` Rob Herring
2022-11-07 20:22 ` Vladimir Oltean
0 siblings, 1 reply; 64+ messages in thread
From: Rob Herring @ 2022-11-07 20:10 UTC (permalink / raw)
To: Sean Anderson
Cc: Heiner Kallweit, Russell King, netdev, Vladimir Oltean,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Frank Rowand, Saravana Kannan, devicetree
On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
> This adds device link support for PCS devices. Both the recommended
> pcs-handle and the deprecated pcsphy-handle properties are supported.
> This should provide better probe ordering.
>
> Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> ---
>
> (no changes since v1)
>
> drivers/of/property.c | 4 ++++
> 1 file changed, 4 insertions(+)
Seems like no dependency on the rest of the series, so I can take this
patch?
Rob
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 08/11] of: property: Add device link support for PCS
2022-11-07 20:10 ` Rob Herring
@ 2022-11-07 20:22 ` Vladimir Oltean
2022-11-07 20:50 ` Sean Anderson
0 siblings, 1 reply; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-07 20:22 UTC (permalink / raw)
To: Rob Herring
Cc: Sean Anderson, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Frank Rowand, Saravana Kannan, devicetree
On Mon, Nov 07, 2022 at 02:10:10PM -0600, Rob Herring wrote:
> On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
> > This adds device link support for PCS devices. Both the recommended
> > pcs-handle and the deprecated pcsphy-handle properties are supported.
> > This should provide better probe ordering.
> >
> > Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> > ---
> >
> > (no changes since v1)
> >
> > drivers/of/property.c | 4 ++++
> > 1 file changed, 4 insertions(+)
>
> Seems like no dependency on the rest of the series, so I can take this
> patch?
Is fw_devlink well-behaved these days, so as to not break (forever defer)
the probing of the device having the pcs-handle, if no driver probed on
the referenced PCS? Because the latter is what will happen if no one
picks up Sean's patches to probe PCS devices in the usual device model
way, I think.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 08/11] of: property: Add device link support for PCS
2022-11-07 20:22 ` Vladimir Oltean
@ 2022-11-07 20:50 ` Sean Anderson
2022-11-07 21:36 ` Rob Herring
0 siblings, 1 reply; 64+ messages in thread
From: Sean Anderson @ 2022-11-07 20:50 UTC (permalink / raw)
To: Vladimir Oltean, Rob Herring
Cc: Heiner Kallweit, Russell King, netdev, Eric Dumazet, Paolo Abeni,
Jakub Kicinski, linux-kernel, Andrew Lunn, Ioana Ciornei,
Madalin Bucur, David S . Miller, Frank Rowand, Saravana Kannan,
devicetree
On 11/7/22 15:22, Vladimir Oltean wrote:
> On Mon, Nov 07, 2022 at 02:10:10PM -0600, Rob Herring wrote:
>> On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
>> > This adds device link support for PCS devices. Both the recommended
>> > pcs-handle and the deprecated pcsphy-handle properties are supported.
>> > This should provide better probe ordering.
>> >
>> > Signed-off-by: Sean Anderson <sean.anderson@seco.com>
>> > ---
>> >
>> > (no changes since v1)
>> >
>> > drivers/of/property.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>>
>> Seems like no dependency on the rest of the series, so I can take this
>> patch?
>
> Is fw_devlink well-behaved these days, so as to not break (forever defer)
> the probing of the device having the pcs-handle, if no driver probed on
> the referenced PCS? Because the latter is what will happen if no one
> picks up Sean's patches to probe PCS devices in the usual device model
> way, I think.
Last time [1], Saravana suggested to move this to the end of the series to
avoid such problems. FWIW, I just tried booting a LS1046A with the
following patches applied
01/11 (compatibles) 05/11 (device) 08/11 (link) 09/11 (consumer)
=================== ============== ============ ================
Y N Y N
Y Y Y Y
Y Y Y N
N Y Y N
N N Y N
and all interfaces probed each time. So maybe it is safe to pick
this patch.
--Sean
[1] https://lore.kernel.org/netdev/CAGETcx97ijCpVyOqCfnrDuGh+SahQCC-3QrJta5HOscUkJQdEw@mail.gmail.com/
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 08/11] of: property: Add device link support for PCS
2022-11-07 20:50 ` Sean Anderson
@ 2022-11-07 21:36 ` Rob Herring
2022-11-08 20:56 ` Saravana Kannan
0 siblings, 1 reply; 64+ messages in thread
From: Rob Herring @ 2022-11-07 21:36 UTC (permalink / raw)
To: Sean Anderson
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Frank Rowand, Saravana Kannan, devicetree
On Mon, Nov 7, 2022 at 2:50 PM Sean Anderson <sean.anderson@seco.com> wrote:
>
> On 11/7/22 15:22, Vladimir Oltean wrote:
> > On Mon, Nov 07, 2022 at 02:10:10PM -0600, Rob Herring wrote:
> >> On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
> >> > This adds device link support for PCS devices. Both the recommended
> >> > pcs-handle and the deprecated pcsphy-handle properties are supported.
> >> > This should provide better probe ordering.
> >> >
> >> > Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> >> > ---
> >> >
> >> > (no changes since v1)
> >> >
> >> > drivers/of/property.c | 4 ++++
> >> > 1 file changed, 4 insertions(+)
> >>
> >> Seems like no dependency on the rest of the series, so I can take this
> >> patch?
> >
> > Is fw_devlink well-behaved these days, so as to not break (forever defer)
> > the probing of the device having the pcs-handle, if no driver probed on
> > the referenced PCS? Because the latter is what will happen if no one
> > picks up Sean's patches to probe PCS devices in the usual device model
> > way, I think.
>
> Last time [1], Saravana suggested to move this to the end of the series to
> avoid such problems. FWIW, I just tried booting a LS1046A with the
> following patches applied
>
> 01/11 (compatibles) 05/11 (device) 08/11 (link) 09/11 (consumer)
> =================== ============== ============ ================
> Y N Y N
> Y Y Y Y
> Y Y Y N
> N Y Y N
> N N Y N
>
> and all interfaces probed each time. So maybe it is safe to pick
> this patch.
Maybe? Just take it with the rest of the series.
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 08/11] of: property: Add device link support for PCS
2022-11-07 21:36 ` Rob Herring
@ 2022-11-08 20:56 ` Saravana Kannan
2022-11-09 21:56 ` Vladimir Oltean
0 siblings, 1 reply; 64+ messages in thread
From: Saravana Kannan @ 2022-11-08 20:56 UTC (permalink / raw)
To: Rob Herring
Cc: Sean Anderson, Vladimir Oltean, Heiner Kallweit, Russell King,
netdev, Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Frank Rowand, devicetree
On Mon, Nov 7, 2022 at 1:36 PM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Nov 7, 2022 at 2:50 PM Sean Anderson <sean.anderson@seco.com> wrote:
> >
> > On 11/7/22 15:22, Vladimir Oltean wrote:
> > > On Mon, Nov 07, 2022 at 02:10:10PM -0600, Rob Herring wrote:
> > >> On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
> > >> > This adds device link support for PCS devices. Both the recommended
> > >> > pcs-handle and the deprecated pcsphy-handle properties are supported.
> > >> > This should provide better probe ordering.
> > >> >
> > >> > Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> > >> > ---
> > >> >
> > >> > (no changes since v1)
> > >> >
> > >> > drivers/of/property.c | 4 ++++
> > >> > 1 file changed, 4 insertions(+)
> > >>
> > >> Seems like no dependency on the rest of the series, so I can take this
> > >> patch?
> > >
> > > Is fw_devlink well-behaved these days, so as to not break (forever defer)
> > > the probing of the device having the pcs-handle, if no driver probed on
> > > the referenced PCS? Because the latter is what will happen if no one
> > > picks up Sean's patches to probe PCS devices in the usual device model
> > > way, I think.
> >
> > Last time [1], Saravana suggested to move this to the end of the series to
> > avoid such problems. FWIW, I just tried booting a LS1046A with the
> > following patches applied
> >
> > 01/11 (compatibles) 05/11 (device) 08/11 (link) 09/11 (consumer)
> > =================== ============== ============ ================
> > Y N Y N
> > Y Y Y Y
> > Y Y Y N
> > N Y Y N
> > N N Y N
> >
> > and all interfaces probed each time. So maybe it is safe to pick
> > this patch.
>
> Maybe? Just take it with the rest of the series.
>
> Acked-by: Rob Herring <robh@kernel.org>
Let's have Vladimir ack this. I'm not sure if it's fully safe yet. I
haven't done the necessary fixes for phy-handle yet, but I don't know
how pcs-handle and pcsphy-handle are used or if none of their uses
will hit the chicken and egg problem that some uses of phy-handle hit.
-Saravana
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 08/11] of: property: Add device link support for PCS
2022-11-08 20:56 ` Saravana Kannan
@ 2022-11-09 21:56 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-09 21:56 UTC (permalink / raw)
To: Saravana Kannan
Cc: Rob Herring, Sean Anderson, Heiner Kallweit, Russell King,
netdev, Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Frank Rowand, devicetree
On Tue, Nov 08, 2022 at 12:56:15PM -0800, Saravana Kannan wrote:
> > > Last time [1], Saravana suggested to move this to the end of the series to
> > > avoid such problems. FWIW, I just tried booting a LS1046A with the
> > > following patches applied
> > >
> > > 01/11 (compatibles) 05/11 (device) 08/11 (link) 09/11 (consumer)
> > > =================== ============== ============ ================
> > > Y N Y N
> > > Y Y Y Y
> > > Y Y Y N
> > > N Y Y N
> > > N N Y N
> > >
> > > and all interfaces probed each time. So maybe it is safe to pick
> > > this patch.
> >
> > Maybe? Just take it with the rest of the series.
> >
> > Acked-by: Rob Herring <robh@kernel.org>
>
> Let's have Vladimir ack this. I'm not sure if it's fully safe yet. I
> haven't done the necessary fixes for phy-handle yet, but I don't know
> how pcs-handle and pcsphy-handle are used or if none of their uses
> will hit the chicken and egg problem that some uses of phy-handle hit.
I can confirm that on today's net-next, the driver owning the pcs-handle
will probe even if the PCS driver is missing. With the mention that it
only does so after the driver_deferred_probe_timeout, which also in
today's net-next is by default 10 seconds if CONFIG_MODULES=y.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-03 21:06 ` Sean Anderson
(?)
@ 2022-11-09 22:41 ` Vladimir Oltean
-1 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-09 22:41 UTC (permalink / raw)
To: Sean Anderson
Cc: Heiner Kallweit, Russell King, netdev, Eric Dumazet, Paolo Abeni,
Jakub Kicinski, linux-kernel, Andrew Lunn, Ioana Ciornei,
Madalin Bucur, David S . Miller, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> Several (later) patches in this series cannot be applied until a stable
> release has occured containing the dts updates.
New kernels must remain compatible with old device trees.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-09 22:41 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-09 22:41 UTC (permalink / raw)
To: Sean Anderson
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Vladimir Oltean, Jakub Kicinski, Paolo Abeni,
Vivien Didelot, devicetree, linuxppc-dev, Claudiu Manoil,
Rob Herring, linux-arm-kernel, netdev, linux-kernel, Li Yang,
Shawn Guo, David S . Miller, Heiner Kallweit
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> Several (later) patches in this series cannot be applied until a stable
> release has occured containing the dts updates.
New kernels must remain compatible with old device trees.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-09 22:41 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-09 22:41 UTC (permalink / raw)
To: Sean Anderson
Cc: Heiner Kallweit, Russell King, netdev, Eric Dumazet, Paolo Abeni,
Jakub Kicinski, linux-kernel, Andrew Lunn, Ioana Ciornei,
Madalin Bucur, David S . Miller, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> Several (later) patches in this series cannot be applied until a stable
> release has occured containing the dts updates.
New kernels must remain compatible with old device trees.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-03 21:06 ` Sean Anderson
(?)
@ 2022-11-09 22:59 ` Vladimir Oltean
-1 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-09 22:59 UTC (permalink / raw)
To: Sean Anderson
Cc: Heiner Kallweit, Russell King, netdev, Eric Dumazet, Paolo Abeni,
Jakub Kicinski, linux-kernel, Andrew Lunn, Ioana Ciornei,
Madalin Bucur, David S . Miller, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> For a long time, PCSs have been tightly coupled with their MACs. For
> this reason, the MAC creates the "phy" or mdio device, and then passes
> it to the PCS to initialize. This has a few disadvantages:
>
> - Each MAC must re-implement the same steps to look up/create a PCS
> - The PCS cannot use functions tied to device lifetime, such as devm_*.
> - Generally, the PCS does not have easy access to its device tree node
Is there a clear need to solve these disadvantages? There comes extra
runtime complexity with the PCS-as-device scheme (plus the extra
complexity needed to address the DT backwards compatibility problems
it causes; not addressed here).
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-09 22:59 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-09 22:59 UTC (permalink / raw)
To: Sean Anderson
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Vladimir Oltean, Jakub Kicinski, Paolo Abeni,
Vivien Didelot, devicetree, linuxppc-dev, Claudiu Manoil,
Rob Herring, linux-arm-kernel, netdev, linux-kernel, Li Yang,
Shawn Guo, David S . Miller, Heiner Kallweit
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> For a long time, PCSs have been tightly coupled with their MACs. For
> this reason, the MAC creates the "phy" or mdio device, and then passes
> it to the PCS to initialize. This has a few disadvantages:
>
> - Each MAC must re-implement the same steps to look up/create a PCS
> - The PCS cannot use functions tied to device lifetime, such as devm_*.
> - Generally, the PCS does not have easy access to its device tree node
Is there a clear need to solve these disadvantages? There comes extra
runtime complexity with the PCS-as-device scheme (plus the extra
complexity needed to address the DT backwards compatibility problems
it causes; not addressed here).
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-09 22:59 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-09 22:59 UTC (permalink / raw)
To: Sean Anderson
Cc: Heiner Kallweit, Russell King, netdev, Eric Dumazet, Paolo Abeni,
Jakub Kicinski, linux-kernel, Andrew Lunn, Ioana Ciornei,
Madalin Bucur, David S . Miller, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> For a long time, PCSs have been tightly coupled with their MACs. For
> this reason, the MAC creates the "phy" or mdio device, and then passes
> it to the PCS to initialize. This has a few disadvantages:
>
> - Each MAC must re-implement the same steps to look up/create a PCS
> - The PCS cannot use functions tied to device lifetime, such as devm_*.
> - Generally, the PCS does not have easy access to its device tree node
Is there a clear need to solve these disadvantages? There comes extra
runtime complexity with the PCS-as-device scheme (plus the extra
complexity needed to address the DT backwards compatibility problems
it causes; not addressed here).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-09 22:41 ` Vladimir Oltean
(?)
@ 2022-11-10 14:55 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 14:55 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Heiner Kallweit, Russell King, netdev, Eric Dumazet, Paolo Abeni,
Jakub Kicinski, linux-kernel, Andrew Lunn, Ioana Ciornei,
Madalin Bucur, David S . Miller, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/9/22 17:41, Vladimir Oltean wrote:
> On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> Several (later) patches in this series cannot be applied until a stable
>> release has occured containing the dts updates.
>
> New kernels must remain compatible with old device trees.
Well, this binding is not present in older device trees, so it needs to
be added before these patches can be applied. It also could be possible
to manually bind the driver using e.g. a helper function (like what is
done with lynx_pcs_create_on_bus). Of course this would be tricky,
because we would need to unbind any generic phy driver attached, but
avoid unbinding an existing Lynx PCS driver.
As I understand it, kernels must be compatible with device trees from a
few kernels before and after. There is not a permanent guarantee of
backwards compatibility (like userspace has) because otherwise we would
never be able to make internal changes (such as what is done in this
series). I have suggested deferring these patches until after an LTS
release as suggested by Rob last time [1].
--Sean
[1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 14:55 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 14:55 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Vladimir Oltean, Jakub Kicinski, Paolo Abeni,
Vivien Didelot, devicetree, linuxppc-dev, Claudiu Manoil,
Rob Herring, linux-arm-kernel, netdev, linux-kernel, Li Yang,
Shawn Guo, David S . Miller, Heiner Kallweit
On 11/9/22 17:41, Vladimir Oltean wrote:
> On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> Several (later) patches in this series cannot be applied until a stable
>> release has occured containing the dts updates.
>
> New kernels must remain compatible with old device trees.
Well, this binding is not present in older device trees, so it needs to
be added before these patches can be applied. It also could be possible
to manually bind the driver using e.g. a helper function (like what is
done with lynx_pcs_create_on_bus). Of course this would be tricky,
because we would need to unbind any generic phy driver attached, but
avoid unbinding an existing Lynx PCS driver.
As I understand it, kernels must be compatible with device trees from a
few kernels before and after. There is not a permanent guarantee of
backwards compatibility (like userspace has) because otherwise we would
never be able to make internal changes (such as what is done in this
series). I have suggested deferring these patches until after an LTS
release as suggested by Rob last time [1].
--Sean
[1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 14:55 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 14:55 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Heiner Kallweit, Russell King, netdev, Eric Dumazet, Paolo Abeni,
Jakub Kicinski, linux-kernel, Andrew Lunn, Ioana Ciornei,
Madalin Bucur, David S . Miller, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/9/22 17:41, Vladimir Oltean wrote:
> On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> Several (later) patches in this series cannot be applied until a stable
>> release has occured containing the dts updates.
>
> New kernels must remain compatible with old device trees.
Well, this binding is not present in older device trees, so it needs to
be added before these patches can be applied. It also could be possible
to manually bind the driver using e.g. a helper function (like what is
done with lynx_pcs_create_on_bus). Of course this would be tricky,
because we would need to unbind any generic phy driver attached, but
avoid unbinding an existing Lynx PCS driver.
As I understand it, kernels must be compatible with device trees from a
few kernels before and after. There is not a permanent guarantee of
backwards compatibility (like userspace has) because otherwise we would
never be able to make internal changes (such as what is done in this
series). I have suggested deferring these patches until after an LTS
release as suggested by Rob last time [1].
--Sean
[1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-09 22:59 ` Vladimir Oltean
(?)
@ 2022-11-10 15:15 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 15:15 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Heiner Kallweit, Russell King, netdev, Eric Dumazet, Paolo Abeni,
Jakub Kicinski, linux-kernel, Andrew Lunn, Ioana Ciornei,
Madalin Bucur, David S . Miller, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/9/22 17:59, Vladimir Oltean wrote:
> On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> For a long time, PCSs have been tightly coupled with their MACs. For
>> this reason, the MAC creates the "phy" or mdio device, and then passes
>> it to the PCS to initialize. This has a few disadvantages:
>>
>> - Each MAC must re-implement the same steps to look up/create a PCS
>> - The PCS cannot use functions tied to device lifetime, such as devm_*.
>> - Generally, the PCS does not have easy access to its device tree node
>
> Is there a clear need to solve these disadvantages? There comes extra
> runtime complexity with the PCS-as-device scheme.
IMO this is actually simpler for driver implementers and consumers. You
can see this by looking at the diffstats for each of the patches. All of
the consumers are -30 or so. The driver is +30, but that's around the
length of lynx_pcs_create_on_bus (and of course the compatible strings
and driver).
> (plus the extra
> complexity needed to address the DT backwards compatibility problems
> it causes; not addressed here).
New drivers will not need to do this backwards-compatibility dance. They
can be written like almost every other driver in the kernel. There are
parallels here with how phy devices were implemented; first as a library
without drivers (or devices), and gradually converting to devices.
This is also motivated by Xilinx platforms where the PCS can be
implemented on an FPGA. Hard-coding the PCS for the MAC is not
desirable, since the device can change when the bitstream is changed.
Additionally, the devices may need to configure e.g. resets or clocks.
I plan to post a follow-up patch for [1] adding a Xilinx PCS/PMA driver
at some point.
--Sean
[1] https://lore.kernel.org/netdev/20211004191527.1610759-1-sean.anderson@seco.com/
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 15:15 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 15:15 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Vladimir Oltean, Jakub Kicinski, Paolo Abeni,
Vivien Didelot, devicetree, linuxppc-dev, Claudiu Manoil,
Rob Herring, linux-arm-kernel, netdev, linux-kernel, Li Yang,
Shawn Guo, David S . Miller, Heiner Kallweit
On 11/9/22 17:59, Vladimir Oltean wrote:
> On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> For a long time, PCSs have been tightly coupled with their MACs. For
>> this reason, the MAC creates the "phy" or mdio device, and then passes
>> it to the PCS to initialize. This has a few disadvantages:
>>
>> - Each MAC must re-implement the same steps to look up/create a PCS
>> - The PCS cannot use functions tied to device lifetime, such as devm_*.
>> - Generally, the PCS does not have easy access to its device tree node
>
> Is there a clear need to solve these disadvantages? There comes extra
> runtime complexity with the PCS-as-device scheme.
IMO this is actually simpler for driver implementers and consumers. You
can see this by looking at the diffstats for each of the patches. All of
the consumers are -30 or so. The driver is +30, but that's around the
length of lynx_pcs_create_on_bus (and of course the compatible strings
and driver).
> (plus the extra
> complexity needed to address the DT backwards compatibility problems
> it causes; not addressed here).
New drivers will not need to do this backwards-compatibility dance. They
can be written like almost every other driver in the kernel. There are
parallels here with how phy devices were implemented; first as a library
without drivers (or devices), and gradually converting to devices.
This is also motivated by Xilinx platforms where the PCS can be
implemented on an FPGA. Hard-coding the PCS for the MAC is not
desirable, since the device can change when the bitstream is changed.
Additionally, the devices may need to configure e.g. resets or clocks.
I plan to post a follow-up patch for [1] adding a Xilinx PCS/PMA driver
at some point.
--Sean
[1] https://lore.kernel.org/netdev/20211004191527.1610759-1-sean.anderson@seco.com/
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 15:15 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 15:15 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Heiner Kallweit, Russell King, netdev, Eric Dumazet, Paolo Abeni,
Jakub Kicinski, linux-kernel, Andrew Lunn, Ioana Ciornei,
Madalin Bucur, David S . Miller, Alexandre Belloni,
Benjamin Herrenschmidt, Claudiu Manoil, Florian Fainelli,
Frank Rowand, Krzysztof Kozlowski, Li Yang, Michael Ellerman,
Paul Mackerras, Rob Herring, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, Vladimir Oltean, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/9/22 17:59, Vladimir Oltean wrote:
> On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> For a long time, PCSs have been tightly coupled with their MACs. For
>> this reason, the MAC creates the "phy" or mdio device, and then passes
>> it to the PCS to initialize. This has a few disadvantages:
>>
>> - Each MAC must re-implement the same steps to look up/create a PCS
>> - The PCS cannot use functions tied to device lifetime, such as devm_*.
>> - Generally, the PCS does not have easy access to its device tree node
>
> Is there a clear need to solve these disadvantages? There comes extra
> runtime complexity with the PCS-as-device scheme.
IMO this is actually simpler for driver implementers and consumers. You
can see this by looking at the diffstats for each of the patches. All of
the consumers are -30 or so. The driver is +30, but that's around the
length of lynx_pcs_create_on_bus (and of course the compatible strings
and driver).
> (plus the extra
> complexity needed to address the DT backwards compatibility problems
> it causes; not addressed here).
New drivers will not need to do this backwards-compatibility dance. They
can be written like almost every other driver in the kernel. There are
parallels here with how phy devices were implemented; first as a library
without drivers (or devices), and gradually converting to devices.
This is also motivated by Xilinx platforms where the PCS can be
implemented on an FPGA. Hard-coding the PCS for the MAC is not
desirable, since the device can change when the bitstream is changed.
Additionally, the devices may need to configure e.g. resets or clocks.
I plan to post a follow-up patch for [1] adding a Xilinx PCS/PMA driver
at some point.
--Sean
[1] https://lore.kernel.org/netdev/20211004191527.1610759-1-sean.anderson@seco.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-10 14:55 ` Sean Anderson
(?)
@ 2022-11-10 15:29 ` Vladimir Oltean
-1 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-10 15:29 UTC (permalink / raw)
To: Sean Anderson
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Jakub Kicinski, Paolo Abeni, Vivien Didelot,
devicetree, linuxppc-dev, Claudiu Manoil, Rob Herring,
linux-arm-kernel, netdev, linux-kernel@vger.kernel.org
On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> On 11/9/22 17:41, Vladimir Oltean wrote:
> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> >> Several (later) patches in this series cannot be applied until a stable
> >> release has occured containing the dts updates.
> >
> > New kernels must remain compatible with old device trees.
>
> Well, this binding is not present in older device trees, so it needs to
> be added before these patches can be applied. It also could be possible
> to manually bind the driver using e.g. a helper function (like what is
> done with lynx_pcs_create_on_bus). Of course this would be tricky,
> because we would need to unbind any generic phy driver attached, but
> avoid unbinding an existing Lynx PCS driver.
If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
these PCS devices, would it be possible to probe them in a generic way
as MDIO devices, if they lack a compatible string?
> As I understand it, kernels must be compatible with device trees from a
> few kernels before and after. There is not a permanent guarantee of
> backwards compatibility (like userspace has) because otherwise we would
> never be able to make internal changes (such as what is done in this
> series). I have suggested deferring these patches until after an LTS
> release as suggested by Rob last time [1].
>
> --Sean
>
> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
Internal changes limit themselves to what doesn't break compatibility
with device trees in circulation. DT bindings are ABI. Compared to the
lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
sorry. The kernel has to continue probing them as Lynx PCS devices even
in lack of a compatible string.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 15:29 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-10 15:29 UTC (permalink / raw)
To: Sean Anderson
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> On 11/9/22 17:41, Vladimir Oltean wrote:
> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> >> Several (later) patches in this series cannot be applied until a stable
> >> release has occured containing the dts updates.
> >
> > New kernels must remain compatible with old device trees.
>
> Well, this binding is not present in older device trees, so it needs to
> be added before these patches can be applied. It also could be possible
> to manually bind the driver using e.g. a helper function (like what is
> done with lynx_pcs_create_on_bus). Of course this would be tricky,
> because we would need to unbind any generic phy driver attached, but
> avoid unbinding an existing Lynx PCS driver.
If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
these PCS devices, would it be possible to probe them in a generic way
as MDIO devices, if they lack a compatible string?
> As I understand it, kernels must be compatible with device trees from a
> few kernels before and after. There is not a permanent guarantee of
> backwards compatibility (like userspace has) because otherwise we would
> never be able to make internal changes (such as what is done in this
> series). I have suggested deferring these patches until after an LTS
> release as suggested by Rob last time [1].
>
> --Sean
>
> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
Internal changes limit themselves to what doesn't break compatibility
with device trees in circulation. DT bindings are ABI. Compared to the
lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
sorry. The kernel has to continue probing them as Lynx PCS devices even
in lack of a compatible string.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 15:29 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-10 15:29 UTC (permalink / raw)
To: Sean Anderson
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> On 11/9/22 17:41, Vladimir Oltean wrote:
> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> >> Several (later) patches in this series cannot be applied until a stable
> >> release has occured containing the dts updates.
> >
> > New kernels must remain compatible with old device trees.
>
> Well, this binding is not present in older device trees, so it needs to
> be added before these patches can be applied. It also could be possible
> to manually bind the driver using e.g. a helper function (like what is
> done with lynx_pcs_create_on_bus). Of course this would be tricky,
> because we would need to unbind any generic phy driver attached, but
> avoid unbinding an existing Lynx PCS driver.
If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
these PCS devices, would it be possible to probe them in a generic way
as MDIO devices, if they lack a compatible string?
> As I understand it, kernels must be compatible with device trees from a
> few kernels before and after. There is not a permanent guarantee of
> backwards compatibility (like userspace has) because otherwise we would
> never be able to make internal changes (such as what is done in this
> series). I have suggested deferring these patches until after an LTS
> release as suggested by Rob last time [1].
>
> --Sean
>
> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
Internal changes limit themselves to what doesn't break compatibility
with device trees in circulation. DT bindings are ABI. Compared to the
lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
sorry. The kernel has to continue probing them as Lynx PCS devices even
in lack of a compatible string.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-10 15:29 ` Vladimir Oltean
(?)
@ 2022-11-10 15:39 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 15:39 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/10/22 10:29, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
>> On 11/9/22 17:41, Vladimir Oltean wrote:
>> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> >> Several (later) patches in this series cannot be applied until a stable
>> >> release has occured containing the dts updates.
>> >
>> > New kernels must remain compatible with old device trees.
>>
>> Well, this binding is not present in older device trees, so it needs to
>> be added before these patches can be applied. It also could be possible
>> to manually bind the driver using e.g. a helper function (like what is
>> done with lynx_pcs_create_on_bus). Of course this would be tricky,
>> because we would need to unbind any generic phy driver attached, but
>> avoid unbinding an existing Lynx PCS driver.
>
> If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> these PCS devices, would it be possible to probe them in a generic way
> as MDIO devices, if they lack a compatible string?
PCS devices are not PHYs, and they do not necessarily conform to the
standard PHY registers. Some PCS devices aren't even on MDIO busses (and
are instead memory-mapped). To implement this, I think we would need to be
very careful. There's also the issue where PCS devices might not be
accessable before their mode is selected by the MAC or SerDes.
>> As I understand it, kernels must be compatible with device trees from a
>> few kernels before and after. There is not a permanent guarantee of
>> backwards compatibility (like userspace has) because otherwise we would
>> never be able to make internal changes (such as what is done in this
>> series). I have suggested deferring these patches until after an LTS
>> release as suggested by Rob last time [1].
>>
>> --Sean
>>
>> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
>
> Internal changes limit themselves to what doesn't break compatibility
> with device trees in circulation. DT bindings are ABI. Compared to the
> lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
> sorry. The kernel has to continue probing them as Lynx PCS devices even
> in lack of a compatible string.
I believe the idea here is to allow some leeway when updating so that
the kernel and device tree don't have to always be in sync. However, we
don't have to support a situation where the kernel is constantly updated
but the device tree is never updated. As long as a reasonable effort is
made to update (or *not* update) both the kernel and device tree, there
is no problem.
--Sean
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 15:39 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 15:39 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Jakub Kicinski, Paolo Abeni, Vivien Didelot,
devicetree, linuxppc-dev, Claudiu Manoil, Rob Herring,
linux-arm-kernel, netdev, linux-kernel@vger.kernel.org
On 11/10/22 10:29, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
>> On 11/9/22 17:41, Vladimir Oltean wrote:
>> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> >> Several (later) patches in this series cannot be applied until a stable
>> >> release has occured containing the dts updates.
>> >
>> > New kernels must remain compatible with old device trees.
>>
>> Well, this binding is not present in older device trees, so it needs to
>> be added before these patches can be applied. It also could be possible
>> to manually bind the driver using e.g. a helper function (like what is
>> done with lynx_pcs_create_on_bus). Of course this would be tricky,
>> because we would need to unbind any generic phy driver attached, but
>> avoid unbinding an existing Lynx PCS driver.
>
> If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> these PCS devices, would it be possible to probe them in a generic way
> as MDIO devices, if they lack a compatible string?
PCS devices are not PHYs, and they do not necessarily conform to the
standard PHY registers. Some PCS devices aren't even on MDIO busses (and
are instead memory-mapped). To implement this, I think we would need to be
very careful. There's also the issue where PCS devices might not be
accessable before their mode is selected by the MAC or SerDes.
>> As I understand it, kernels must be compatible with device trees from a
>> few kernels before and after. There is not a permanent guarantee of
>> backwards compatibility (like userspace has) because otherwise we would
>> never be able to make internal changes (such as what is done in this
>> series). I have suggested deferring these patches until after an LTS
>> release as suggested by Rob last time [1].
>>
>> --Sean
>>
>> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
>
> Internal changes limit themselves to what doesn't break compatibility
> with device trees in circulation. DT bindings are ABI. Compared to the
> lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
> sorry. The kernel has to continue probing them as Lynx PCS devices even
> in lack of a compatible string.
I believe the idea here is to allow some leeway when updating so that
the kernel and device tree don't have to always be in sync. However, we
don't have to support a situation where the kernel is constantly updated
but the device tree is never updated. As long as a reasonable effort is
made to update (or *not* update) both the kernel and device tree, there
is no problem.
--Sean
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 15:39 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 15:39 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/10/22 10:29, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
>> On 11/9/22 17:41, Vladimir Oltean wrote:
>> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> >> Several (later) patches in this series cannot be applied until a stable
>> >> release has occured containing the dts updates.
>> >
>> > New kernels must remain compatible with old device trees.
>>
>> Well, this binding is not present in older device trees, so it needs to
>> be added before these patches can be applied. It also could be possible
>> to manually bind the driver using e.g. a helper function (like what is
>> done with lynx_pcs_create_on_bus). Of course this would be tricky,
>> because we would need to unbind any generic phy driver attached, but
>> avoid unbinding an existing Lynx PCS driver.
>
> If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> these PCS devices, would it be possible to probe them in a generic way
> as MDIO devices, if they lack a compatible string?
PCS devices are not PHYs, and they do not necessarily conform to the
standard PHY registers. Some PCS devices aren't even on MDIO busses (and
are instead memory-mapped). To implement this, I think we would need to be
very careful. There's also the issue where PCS devices might not be
accessable before their mode is selected by the MAC or SerDes.
>> As I understand it, kernels must be compatible with device trees from a
>> few kernels before and after. There is not a permanent guarantee of
>> backwards compatibility (like userspace has) because otherwise we would
>> never be able to make internal changes (such as what is done in this
>> series). I have suggested deferring these patches until after an LTS
>> release as suggested by Rob last time [1].
>>
>> --Sean
>>
>> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
>
> Internal changes limit themselves to what doesn't break compatibility
> with device trees in circulation. DT bindings are ABI. Compared to the
> lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
> sorry. The kernel has to continue probing them as Lynx PCS devices even
> in lack of a compatible string.
I believe the idea here is to allow some leeway when updating so that
the kernel and device tree don't have to always be in sync. However, we
don't have to support a situation where the kernel is constantly updated
but the device tree is never updated. As long as a reasonable effort is
made to update (or *not* update) both the kernel and device tree, there
is no problem.
--Sean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-10 15:39 ` Sean Anderson
(?)
@ 2022-11-10 16:00 ` Vladimir Oltean
-1 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-10 16:00 UTC (permalink / raw)
To: Sean Anderson
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 10:39:30AM -0500, Sean Anderson wrote:
> On 11/10/22 10:29, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> >> On 11/9/22 17:41, Vladimir Oltean wrote:
> >> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> >> >> Several (later) patches in this series cannot be applied until a stable
> >> >> release has occured containing the dts updates.
> >> >
> >> > New kernels must remain compatible with old device trees.
> >>
> >> Well, this binding is not present in older device trees, so it needs to
> >> be added before these patches can be applied. It also could be possible
> >> to manually bind the driver using e.g. a helper function (like what is
> >> done with lynx_pcs_create_on_bus). Of course this would be tricky,
> >> because we would need to unbind any generic phy driver attached, but
> >> avoid unbinding an existing Lynx PCS driver.
> >
> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> > these PCS devices, would it be possible to probe them in a generic way
> > as MDIO devices, if they lack a compatible string?
>
> PCS devices are not PHYs, and they do not necessarily conform to the
> standard PHY registers. Some PCS devices aren't even on MDIO busses (and
> are instead memory-mapped). To implement this, I think we would need to be
> very careful. There's also the issue where PCS devices might not be
> accessable before their mode is selected by the MAC or SerDes.
I don't get where you're going with this. Does any of these arguments
apply to the Lynx PCS? If not, then what is the problem to using their
PHY ID register as a mechanism to auto-bind their PCS driver in lack of
a compatible string?
You already accept a compromise by having lynx_pcs_create_on_bus() be a
platform-specific way of instantiating a PCS. However, the only thing
that's platform-specific in the lynx_pcs_create_on_bus() implementation
is the modalias string:
struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
struct mii_bus *bus, int addr)
{
struct mdio_device *mdio;
struct phylink_pcs *pcs;
int err;
mdio = mdio_device_create(bus, addr);
if (IS_ERR(mdio))
return ERR_CAST(mdio);
mdio->bus_match = mdio_device_bus_match;
strncpy(mdio->modalias, "lynx-pcs", sizeof(mdio->modalias)); // <----- this
err = mdio_device_register(mdio);
if (err) {
mdio_device_free(mdio);
return ERR_PTR(err);
}
pcs = pcs_get_by_dev(dev, &mdio->dev);
mdio_device_free(mdio);
return pcs;
}
EXPORT_SYMBOL(lynx_pcs_create_on_bus);
Otherwise it could have been named just as well "pcs_create_on_bus()".
And this is what I'm saying. What if instead of probing based on
modalias, this function is made to bind the driver to the device based
on the PHY ID?
The point about this functionality being generic or not is totally moot,
since it's the driver who *decides* to call it (and wouldn't do so, if
it wasn't an MDIO device; see, there's an "mii_bus *bus" argument).
It could work both with LS1028A (enetc, felix, where there is no
pcs-handle), and it could also work with DPAA1/DPAA2, where there is a
pcs-handle but there is no compatible string for the PCS.
> >> As I understand it, kernels must be compatible with device trees from a
> >> few kernels before and after. There is not a permanent guarantee of
> >> backwards compatibility (like userspace has) because otherwise we would
> >> never be able to make internal changes (such as what is done in this
> >> series). I have suggested deferring these patches until after an LTS
> >> release as suggested by Rob last time [1].
> >>
> >> --Sean
> >>
> >> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
> >
> > Internal changes limit themselves to what doesn't break compatibility
> > with device trees in circulation. DT bindings are ABI. Compared to the
> > lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
> > sorry. The kernel has to continue probing them as Lynx PCS devices even
> > in lack of a compatible string.
>
> I believe the idea here is to allow some leeway when updating so that
> the kernel and device tree don't have to always be in sync. However, we
> don't have to support a situation where the kernel is constantly updated
> but the device tree is never updated. As long as a reasonable effort is
> made to update (or *not* update) both the kernel and device tree, there
> is no problem.
I don't think you'd have this opinion if device trees were not
maintained in the same git tree as the kernel itself. You have to
consider the case where the device tree blob is provided by a firmware
(say U-Boot) which you don't update in lockstep with the kernel.
Has nothing to do with "reasonable" or not.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 16:00 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-10 16:00 UTC (permalink / raw)
To: Sean Anderson
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Jakub Kicinski, Paolo Abeni, Vivien Didelot,
devicetree, linuxppc-dev, Claudiu Manoil, Rob Herring,
linux-arm-kernel, netdev, linux-kernel@vger.kernel.org
On Thu, Nov 10, 2022 at 10:39:30AM -0500, Sean Anderson wrote:
> On 11/10/22 10:29, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> >> On 11/9/22 17:41, Vladimir Oltean wrote:
> >> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> >> >> Several (later) patches in this series cannot be applied until a stable
> >> >> release has occured containing the dts updates.
> >> >
> >> > New kernels must remain compatible with old device trees.
> >>
> >> Well, this binding is not present in older device trees, so it needs to
> >> be added before these patches can be applied. It also could be possible
> >> to manually bind the driver using e.g. a helper function (like what is
> >> done with lynx_pcs_create_on_bus). Of course this would be tricky,
> >> because we would need to unbind any generic phy driver attached, but
> >> avoid unbinding an existing Lynx PCS driver.
> >
> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> > these PCS devices, would it be possible to probe them in a generic way
> > as MDIO devices, if they lack a compatible string?
>
> PCS devices are not PHYs, and they do not necessarily conform to the
> standard PHY registers. Some PCS devices aren't even on MDIO busses (and
> are instead memory-mapped). To implement this, I think we would need to be
> very careful. There's also the issue where PCS devices might not be
> accessable before their mode is selected by the MAC or SerDes.
I don't get where you're going with this. Does any of these arguments
apply to the Lynx PCS? If not, then what is the problem to using their
PHY ID register as a mechanism to auto-bind their PCS driver in lack of
a compatible string?
You already accept a compromise by having lynx_pcs_create_on_bus() be a
platform-specific way of instantiating a PCS. However, the only thing
that's platform-specific in the lynx_pcs_create_on_bus() implementation
is the modalias string:
struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
struct mii_bus *bus, int addr)
{
struct mdio_device *mdio;
struct phylink_pcs *pcs;
int err;
mdio = mdio_device_create(bus, addr);
if (IS_ERR(mdio))
return ERR_CAST(mdio);
mdio->bus_match = mdio_device_bus_match;
strncpy(mdio->modalias, "lynx-pcs", sizeof(mdio->modalias)); // <----- this
err = mdio_device_register(mdio);
if (err) {
mdio_device_free(mdio);
return ERR_PTR(err);
}
pcs = pcs_get_by_dev(dev, &mdio->dev);
mdio_device_free(mdio);
return pcs;
}
EXPORT_SYMBOL(lynx_pcs_create_on_bus);
Otherwise it could have been named just as well "pcs_create_on_bus()".
And this is what I'm saying. What if instead of probing based on
modalias, this function is made to bind the driver to the device based
on the PHY ID?
The point about this functionality being generic or not is totally moot,
since it's the driver who *decides* to call it (and wouldn't do so, if
it wasn't an MDIO device; see, there's an "mii_bus *bus" argument).
It could work both with LS1028A (enetc, felix, where there is no
pcs-handle), and it could also work with DPAA1/DPAA2, where there is a
pcs-handle but there is no compatible string for the PCS.
> >> As I understand it, kernels must be compatible with device trees from a
> >> few kernels before and after. There is not a permanent guarantee of
> >> backwards compatibility (like userspace has) because otherwise we would
> >> never be able to make internal changes (such as what is done in this
> >> series). I have suggested deferring these patches until after an LTS
> >> release as suggested by Rob last time [1].
> >>
> >> --Sean
> >>
> >> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
> >
> > Internal changes limit themselves to what doesn't break compatibility
> > with device trees in circulation. DT bindings are ABI. Compared to the
> > lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
> > sorry. The kernel has to continue probing them as Lynx PCS devices even
> > in lack of a compatible string.
>
> I believe the idea here is to allow some leeway when updating so that
> the kernel and device tree don't have to always be in sync. However, we
> don't have to support a situation where the kernel is constantly updated
> but the device tree is never updated. As long as a reasonable effort is
> made to update (or *not* update) both the kernel and device tree, there
> is no problem.
I don't think you'd have this opinion if device trees were not
maintained in the same git tree as the kernel itself. You have to
consider the case where the device tree blob is provided by a firmware
(say U-Boot) which you don't update in lockstep with the kernel.
Has nothing to do with "reasonable" or not.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 16:00 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-10 16:00 UTC (permalink / raw)
To: Sean Anderson
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 10:39:30AM -0500, Sean Anderson wrote:
> On 11/10/22 10:29, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> >> On 11/9/22 17:41, Vladimir Oltean wrote:
> >> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> >> >> Several (later) patches in this series cannot be applied until a stable
> >> >> release has occured containing the dts updates.
> >> >
> >> > New kernels must remain compatible with old device trees.
> >>
> >> Well, this binding is not present in older device trees, so it needs to
> >> be added before these patches can be applied. It also could be possible
> >> to manually bind the driver using e.g. a helper function (like what is
> >> done with lynx_pcs_create_on_bus). Of course this would be tricky,
> >> because we would need to unbind any generic phy driver attached, but
> >> avoid unbinding an existing Lynx PCS driver.
> >
> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> > these PCS devices, would it be possible to probe them in a generic way
> > as MDIO devices, if they lack a compatible string?
>
> PCS devices are not PHYs, and they do not necessarily conform to the
> standard PHY registers. Some PCS devices aren't even on MDIO busses (and
> are instead memory-mapped). To implement this, I think we would need to be
> very careful. There's also the issue where PCS devices might not be
> accessable before their mode is selected by the MAC or SerDes.
I don't get where you're going with this. Does any of these arguments
apply to the Lynx PCS? If not, then what is the problem to using their
PHY ID register as a mechanism to auto-bind their PCS driver in lack of
a compatible string?
You already accept a compromise by having lynx_pcs_create_on_bus() be a
platform-specific way of instantiating a PCS. However, the only thing
that's platform-specific in the lynx_pcs_create_on_bus() implementation
is the modalias string:
struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
struct mii_bus *bus, int addr)
{
struct mdio_device *mdio;
struct phylink_pcs *pcs;
int err;
mdio = mdio_device_create(bus, addr);
if (IS_ERR(mdio))
return ERR_CAST(mdio);
mdio->bus_match = mdio_device_bus_match;
strncpy(mdio->modalias, "lynx-pcs", sizeof(mdio->modalias)); // <----- this
err = mdio_device_register(mdio);
if (err) {
mdio_device_free(mdio);
return ERR_PTR(err);
}
pcs = pcs_get_by_dev(dev, &mdio->dev);
mdio_device_free(mdio);
return pcs;
}
EXPORT_SYMBOL(lynx_pcs_create_on_bus);
Otherwise it could have been named just as well "pcs_create_on_bus()".
And this is what I'm saying. What if instead of probing based on
modalias, this function is made to bind the driver to the device based
on the PHY ID?
The point about this functionality being generic or not is totally moot,
since it's the driver who *decides* to call it (and wouldn't do so, if
it wasn't an MDIO device; see, there's an "mii_bus *bus" argument).
It could work both with LS1028A (enetc, felix, where there is no
pcs-handle), and it could also work with DPAA1/DPAA2, where there is a
pcs-handle but there is no compatible string for the PCS.
> >> As I understand it, kernels must be compatible with device trees from a
> >> few kernels before and after. There is not a permanent guarantee of
> >> backwards compatibility (like userspace has) because otherwise we would
> >> never be able to make internal changes (such as what is done in this
> >> series). I have suggested deferring these patches until after an LTS
> >> release as suggested by Rob last time [1].
> >>
> >> --Sean
> >>
> >> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
> >
> > Internal changes limit themselves to what doesn't break compatibility
> > with device trees in circulation. DT bindings are ABI. Compared to the
> > lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
> > sorry. The kernel has to continue probing them as Lynx PCS devices even
> > in lack of a compatible string.
>
> I believe the idea here is to allow some leeway when updating so that
> the kernel and device tree don't have to always be in sync. However, we
> don't have to support a situation where the kernel is constantly updated
> but the device tree is never updated. As long as a reasonable effort is
> made to update (or *not* update) both the kernel and device tree, there
> is no problem.
I don't think you'd have this opinion if device trees were not
maintained in the same git tree as the kernel itself. You have to
consider the case where the device tree blob is provided by a firmware
(say U-Boot) which you don't update in lockstep with the kernel.
Has nothing to do with "reasonable" or not.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-10 15:29 ` Vladimir Oltean
(?)
@ 2022-11-10 16:01 ` Andrew Lunn
-1 siblings, 0 replies; 64+ messages in thread
From: Andrew Lunn @ 2022-11-10 16:01 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Sean Anderson, Vladimir Oltean, Heiner Kallweit, Russell King,
netdev, Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 03:29:26PM +0000, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> > On 11/9/22 17:41, Vladimir Oltean wrote:
> > > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> > >> Several (later) patches in this series cannot be applied until a stable
> > >> release has occured containing the dts updates.
> > >
> > > New kernels must remain compatible with old device trees.
> >
> > Well, this binding is not present in older device trees, so it needs to
> > be added before these patches can be applied. It also could be possible
> > to manually bind the driver using e.g. a helper function (like what is
> > done with lynx_pcs_create_on_bus). Of course this would be tricky,
> > because we would need to unbind any generic phy driver attached, but
> > avoid unbinding an existing Lynx PCS driver.
>
> If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> these PCS devices, would it be possible to probe them in a generic way
> as MDIO devices, if they lack a compatible string?
That is not how it currently works. If a device on an MDIO bus has a
compatible, it is assumed to be an mdio device, and it is probed in a
generic way as an sort of mdio device. It could be an Ethernet switch,
or Broadcom has some generic PHYs which are mdio devices, etc.
If there is no compatible, the ID registers are read and it is assumed
to be a PHY. It will be probed as a PHY. The probe() function will be
given a phydev etc.
It will need some core changes to allow an mdio device to be probed
via the ID registers.
Andrew
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 16:01 ` Andrew Lunn
0 siblings, 0 replies; 64+ messages in thread
From: Andrew Lunn @ 2022-11-10 16:01 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Sean Anderson, Vladimir Oltean, Heiner Kallweit, Russell King,
netdev, Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 03:29:26PM +0000, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> > On 11/9/22 17:41, Vladimir Oltean wrote:
> > > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> > >> Several (later) patches in this series cannot be applied until a stable
> > >> release has occured containing the dts updates.
> > >
> > > New kernels must remain compatible with old device trees.
> >
> > Well, this binding is not present in older device trees, so it needs to
> > be added before these patches can be applied. It also could be possible
> > to manually bind the driver using e.g. a helper function (like what is
> > done with lynx_pcs_create_on_bus). Of course this would be tricky,
> > because we would need to unbind any generic phy driver attached, but
> > avoid unbinding an existing Lynx PCS driver.
>
> If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> these PCS devices, would it be possible to probe them in a generic way
> as MDIO devices, if they lack a compatible string?
That is not how it currently works. If a device on an MDIO bus has a
compatible, it is assumed to be an mdio device, and it is probed in a
generic way as an sort of mdio device. It could be an Ethernet switch,
or Broadcom has some generic PHYs which are mdio devices, etc.
If there is no compatible, the ID registers are read and it is assumed
to be a PHY. It will be probed as a PHY. The probe() function will be
given a phydev etc.
It will need some core changes to allow an mdio device to be probed
via the ID registers.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 16:01 ` Andrew Lunn
0 siblings, 0 replies; 64+ messages in thread
From: Andrew Lunn @ 2022-11-10 16:01 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Alexandre Belloni, Madalin Bucur, Eric Dumazet, Paul Mackerras,
Krzysztof Kozlowski, Ioana Ciornei, UNGLinuxDriver, Frank Rowand,
Florian Fainelli, Saravana Kannan, Sean Anderson, Russell King,
Jakub Kicinski, Paolo Abeni, Vivien Didelot, devicetree,
linuxppc-dev, Claudiu Manoil, Rob Herring, linux-arm-kernel,
netdev, linux-kernel@vger.kernel.org
On Thu, Nov 10, 2022 at 03:29:26PM +0000, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> > On 11/9/22 17:41, Vladimir Oltean wrote:
> > > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> > >> Several (later) patches in this series cannot be applied until a stable
> > >> release has occured containing the dts updates.
> > >
> > > New kernels must remain compatible with old device trees.
> >
> > Well, this binding is not present in older device trees, so it needs to
> > be added before these patches can be applied. It also could be possible
> > to manually bind the driver using e.g. a helper function (like what is
> > done with lynx_pcs_create_on_bus). Of course this would be tricky,
> > because we would need to unbind any generic phy driver attached, but
> > avoid unbinding an existing Lynx PCS driver.
>
> If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> these PCS devices, would it be possible to probe them in a generic way
> as MDIO devices, if they lack a compatible string?
That is not how it currently works. If a device on an MDIO bus has a
compatible, it is assumed to be an mdio device, and it is probed in a
generic way as an sort of mdio device. It could be an Ethernet switch,
or Broadcom has some generic PHYs which are mdio devices, etc.
If there is no compatible, the ID registers are read and it is assumed
to be a PHY. It will be probed as a PHY. The probe() function will be
given a phydev etc.
It will need some core changes to allow an mdio device to be probed
via the ID registers.
Andrew
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-10 16:01 ` Andrew Lunn
(?)
@ 2022-11-10 16:32 ` Vladimir Oltean
-1 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-10 16:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: Sean Anderson, Vladimir Oltean, Heiner Kallweit, Russell King,
netdev, Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 05:01:34PM +0100, Andrew Lunn wrote:
> On Thu, Nov 10, 2022 at 03:29:26PM +0000, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> > > On 11/9/22 17:41, Vladimir Oltean wrote:
> > > > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> > > >> Several (later) patches in this series cannot be applied until a stable
> > > >> release has occured containing the dts updates.
> > > >
> > > > New kernels must remain compatible with old device trees.
> > >
> > > Well, this binding is not present in older device trees, so it needs to
> > > be added before these patches can be applied. It also could be possible
> > > to manually bind the driver using e.g. a helper function (like what is
> > > done with lynx_pcs_create_on_bus). Of course this would be tricky,
> > > because we would need to unbind any generic phy driver attached, but
> > > avoid unbinding an existing Lynx PCS driver.
> >
> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> > these PCS devices, would it be possible to probe them in a generic way
> > as MDIO devices, if they lack a compatible string?
>
> That is not how it currently works. If a device on an MDIO bus has a
> compatible, it is assumed to be an mdio device, and it is probed in a
> generic way as an sort of mdio device. It could be an Ethernet switch,
> or Broadcom has some generic PHYs which are mdio devices, etc.
>
> If there is no compatible, the ID registers are read and it is assumed
> to be a PHY. It will be probed as a PHY. The probe() function will be
> given a phydev etc.
>
> It will need some core changes to allow an mdio device to be probed
> via the ID registers.
Yes, it would require extending struct mdio_driver with something like
what struct phy_driver has (u32 phy_id, u32 phy_id_mask), or with a more
generic phy_id_match_table (similar to maybe of_match_table).
I don't see a conceptually simpler way though.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 16:32 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-10 16:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Belloni, Madalin Bucur, Eric Dumazet, Paul Mackerras,
Krzysztof Kozlowski, Ioana Ciornei, UNGLinuxDriver, Frank Rowand,
Florian Fainelli, Saravana Kannan, Sean Anderson, Russell King,
Jakub Kicinski, Paolo Abeni, Vivien Didelot, devicetree,
linuxppc-dev, Claudiu Manoil, Rob Herring, linux-arm-kernel,
netdev, linux-kernel@vger.kernel.org
On Thu, Nov 10, 2022 at 05:01:34PM +0100, Andrew Lunn wrote:
> On Thu, Nov 10, 2022 at 03:29:26PM +0000, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> > > On 11/9/22 17:41, Vladimir Oltean wrote:
> > > > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> > > >> Several (later) patches in this series cannot be applied until a stable
> > > >> release has occured containing the dts updates.
> > > >
> > > > New kernels must remain compatible with old device trees.
> > >
> > > Well, this binding is not present in older device trees, so it needs to
> > > be added before these patches can be applied. It also could be possible
> > > to manually bind the driver using e.g. a helper function (like what is
> > > done with lynx_pcs_create_on_bus). Of course this would be tricky,
> > > because we would need to unbind any generic phy driver attached, but
> > > avoid unbinding an existing Lynx PCS driver.
> >
> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> > these PCS devices, would it be possible to probe them in a generic way
> > as MDIO devices, if they lack a compatible string?
>
> That is not how it currently works. If a device on an MDIO bus has a
> compatible, it is assumed to be an mdio device, and it is probed in a
> generic way as an sort of mdio device. It could be an Ethernet switch,
> or Broadcom has some generic PHYs which are mdio devices, etc.
>
> If there is no compatible, the ID registers are read and it is assumed
> to be a PHY. It will be probed as a PHY. The probe() function will be
> given a phydev etc.
>
> It will need some core changes to allow an mdio device to be probed
> via the ID registers.
Yes, it would require extending struct mdio_driver with something like
what struct phy_driver has (u32 phy_id, u32 phy_id_mask), or with a more
generic phy_id_match_table (similar to maybe of_match_table).
I don't see a conceptually simpler way though.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 16:32 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-10 16:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: Sean Anderson, Vladimir Oltean, Heiner Kallweit, Russell King,
netdev, Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 05:01:34PM +0100, Andrew Lunn wrote:
> On Thu, Nov 10, 2022 at 03:29:26PM +0000, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> > > On 11/9/22 17:41, Vladimir Oltean wrote:
> > > > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> > > >> Several (later) patches in this series cannot be applied until a stable
> > > >> release has occured containing the dts updates.
> > > >
> > > > New kernels must remain compatible with old device trees.
> > >
> > > Well, this binding is not present in older device trees, so it needs to
> > > be added before these patches can be applied. It also could be possible
> > > to manually bind the driver using e.g. a helper function (like what is
> > > done with lynx_pcs_create_on_bus). Of course this would be tricky,
> > > because we would need to unbind any generic phy driver attached, but
> > > avoid unbinding an existing Lynx PCS driver.
> >
> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> > these PCS devices, would it be possible to probe them in a generic way
> > as MDIO devices, if they lack a compatible string?
>
> That is not how it currently works. If a device on an MDIO bus has a
> compatible, it is assumed to be an mdio device, and it is probed in a
> generic way as an sort of mdio device. It could be an Ethernet switch,
> or Broadcom has some generic PHYs which are mdio devices, etc.
>
> If there is no compatible, the ID registers are read and it is assumed
> to be a PHY. It will be probed as a PHY. The probe() function will be
> given a phydev etc.
>
> It will need some core changes to allow an mdio device to be probed
> via the ID registers.
Yes, it would require extending struct mdio_driver with something like
what struct phy_driver has (u32 phy_id, u32 phy_id_mask), or with a more
generic phy_id_match_table (similar to maybe of_match_table).
I don't see a conceptually simpler way though.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-10 16:00 ` Vladimir Oltean
(?)
@ 2022-11-10 16:56 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 16:56 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/10/22 11:00, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 10:39:30AM -0500, Sean Anderson wrote:
>> On 11/10/22 10:29, Vladimir Oltean wrote:
>> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
>> >> On 11/9/22 17:41, Vladimir Oltean wrote:
>> >> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> >> >> Several (later) patches in this series cannot be applied until a stable
>> >> >> release has occured containing the dts updates.
>> >> >
>> >> > New kernels must remain compatible with old device trees.
>> >>
>> >> Well, this binding is not present in older device trees, so it needs to
>> >> be added before these patches can be applied. It also could be possible
>> >> to manually bind the driver using e.g. a helper function (like what is
>> >> done with lynx_pcs_create_on_bus). Of course this would be tricky,
>> >> because we would need to unbind any generic phy driver attached, but
>> >> avoid unbinding an existing Lynx PCS driver.
>> >
>> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
>> > these PCS devices, would it be possible to probe them in a generic way
>> > as MDIO devices, if they lack a compatible string?
>>
>> PCS devices are not PHYs, and they do not necessarily conform to the
>> standard PHY registers. Some PCS devices aren't even on MDIO busses (and
>> are instead memory-mapped). To implement this, I think we would need to be
>> very careful. There's also the issue where PCS devices might not be
>> accessable before their mode is selected by the MAC or SerDes.
>
> I don't get where you're going with this. Does any of these arguments
> apply to the Lynx PCS? If not, then what is the problem to using their
> PHY ID register as a mechanism to auto-bind their PCS driver in lack of
> a compatible string?
>
> You already accept a compromise by having lynx_pcs_create_on_bus() be a
> platform-specific way of instantiating a PCS. However, the only thing
> that's platform-specific in the lynx_pcs_create_on_bus() implementation
> is the modalias string:
>
> struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
> struct mii_bus *bus, int addr)
> {
> struct mdio_device *mdio;
> struct phylink_pcs *pcs;
> int err;
>
> mdio = mdio_device_create(bus, addr);
> if (IS_ERR(mdio))
> return ERR_CAST(mdio);
>
> mdio->bus_match = mdio_device_bus_match;
> strncpy(mdio->modalias, "lynx-pcs", sizeof(mdio->modalias)); // <----- this
> err = mdio_device_register(mdio);
> if (err) {
> mdio_device_free(mdio);
> return ERR_PTR(err);
> }
>
> pcs = pcs_get_by_dev(dev, &mdio->dev);
> mdio_device_free(mdio);
> return pcs;
> }
> EXPORT_SYMBOL(lynx_pcs_create_on_bus);
>
> Otherwise it could have been named just as well "pcs_create_on_bus()".
Yes, this could be made generic when we convert other drivers. This
really is just intended for (non-dt) platform devices. It might even be
better to do this with swnodes...
> And this is what I'm saying. What if instead of probing based on
> modalias, this function is made to bind the driver to the device based
> on the PHY ID?
>
> The point about this functionality being generic or not is totally moot,
> since it's the driver who *decides* to call it (and wouldn't do so, if
> it wasn't an MDIO device; see, there's an "mii_bus *bus" argument).
>
> It could work both with LS1028A (enetc, felix, where there is no
> pcs-handle), and it could also work with DPAA1/DPAA2, where there is a
> pcs-handle but there is no compatible string for the PCS.
The crucial difference here is that if we have a pcs-handle property,
then the node it points to will have a device created by the MDIO
subsystem automatically. The reason for this create_on_bus stuff
is to make the process of
1. Create an MDIO bus with no firmware node
2. Create some MDIO devices on that bus
3. Bind them to the correct driver
4. Get the PCS from the driver
less error prone. But for pcs-handle stuff, this should be something
like
1. pcs_find_fwnode()
2. Look up the device for this node
3. Bind it to the correct driver (but taking care that we don't unbind
an existing driver if it is correct).
And then the driver can call pcs_get().
With your suggestion to use PHY_ID, we wouldn't need that. But we would
still need driver involvement, since probing MDIO busses is not safe in
general (since as Andrew mentioned there are things on the busses which
don't have PHY ID registers). And IMO if we need the driver to go "yes,
it's OK to probe this non-phy on this bus," then we might as well do
what I described above. This could be a bus flag, which I think would
work with existing devices.
I'm worried that this could cause regressions and take a while to iron
out. My current approach is fairly conservative and doesn't require
changes to unaffected code.
>> >> As I understand it, kernels must be compatible with device trees from a
>> >> few kernels before and after. There is not a permanent guarantee of
>> >> backwards compatibility (like userspace has) because otherwise we would
>> >> never be able to make internal changes (such as what is done in this
>> >> series). I have suggested deferring these patches until after an LTS
>> >> release as suggested by Rob last time [1].
>> >>
>> >> --Sean
>> >>
>> >> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
>> >
>> > Internal changes limit themselves to what doesn't break compatibility
>> > with device trees in circulation. DT bindings are ABI. Compared to the
>> > lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
>> > sorry. The kernel has to continue probing them as Lynx PCS devices even
>> > in lack of a compatible string.
>>
>> I believe the idea here is to allow some leeway when updating so that
>> the kernel and device tree don't have to always be in sync. However, we
>> don't have to support a situation where the kernel is constantly updated
>> but the device tree is never updated. As long as a reasonable effort is
>> made to update (or *not* update) both the kernel and device tree, there
>> is no problem.
>
> I don't think you'd have this opinion if device trees were not
> maintained in the same git tree as the kernel itself. You have to
> consider the case where the device tree blob is provided by a firmware
> (say U-Boot) which you don't update in lockstep with the kernel.
> Has nothing to do with "reasonable" or not.
This is exactly the reason why I am saying that we need to have the
device tree updates in the kernel for a bit before these latter patches
can get merged. Actually, it is probably unlikely that these will make
it into the next LTS release (either 6.0 or 6.1), so these will probably
be in device trees for a year before the kernel starts using them. But
once that is done, we are free to require them.
--Sean
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 16:56 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 16:56 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Jakub Kicinski, Paolo Abeni, Vivien Didelot,
devicetree, linuxppc-dev, Claudiu Manoil, Rob Herring,
linux-arm-kernel, netdev, linux-kernel@vger.kernel.org
On 11/10/22 11:00, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 10:39:30AM -0500, Sean Anderson wrote:
>> On 11/10/22 10:29, Vladimir Oltean wrote:
>> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
>> >> On 11/9/22 17:41, Vladimir Oltean wrote:
>> >> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> >> >> Several (later) patches in this series cannot be applied until a stable
>> >> >> release has occured containing the dts updates.
>> >> >
>> >> > New kernels must remain compatible with old device trees.
>> >>
>> >> Well, this binding is not present in older device trees, so it needs to
>> >> be added before these patches can be applied. It also could be possible
>> >> to manually bind the driver using e.g. a helper function (like what is
>> >> done with lynx_pcs_create_on_bus). Of course this would be tricky,
>> >> because we would need to unbind any generic phy driver attached, but
>> >> avoid unbinding an existing Lynx PCS driver.
>> >
>> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
>> > these PCS devices, would it be possible to probe them in a generic way
>> > as MDIO devices, if they lack a compatible string?
>>
>> PCS devices are not PHYs, and they do not necessarily conform to the
>> standard PHY registers. Some PCS devices aren't even on MDIO busses (and
>> are instead memory-mapped). To implement this, I think we would need to be
>> very careful. There's also the issue where PCS devices might not be
>> accessable before their mode is selected by the MAC or SerDes.
>
> I don't get where you're going with this. Does any of these arguments
> apply to the Lynx PCS? If not, then what is the problem to using their
> PHY ID register as a mechanism to auto-bind their PCS driver in lack of
> a compatible string?
>
> You already accept a compromise by having lynx_pcs_create_on_bus() be a
> platform-specific way of instantiating a PCS. However, the only thing
> that's platform-specific in the lynx_pcs_create_on_bus() implementation
> is the modalias string:
>
> struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
> struct mii_bus *bus, int addr)
> {
> struct mdio_device *mdio;
> struct phylink_pcs *pcs;
> int err;
>
> mdio = mdio_device_create(bus, addr);
> if (IS_ERR(mdio))
> return ERR_CAST(mdio);
>
> mdio->bus_match = mdio_device_bus_match;
> strncpy(mdio->modalias, "lynx-pcs", sizeof(mdio->modalias)); // <----- this
> err = mdio_device_register(mdio);
> if (err) {
> mdio_device_free(mdio);
> return ERR_PTR(err);
> }
>
> pcs = pcs_get_by_dev(dev, &mdio->dev);
> mdio_device_free(mdio);
> return pcs;
> }
> EXPORT_SYMBOL(lynx_pcs_create_on_bus);
>
> Otherwise it could have been named just as well "pcs_create_on_bus()".
Yes, this could be made generic when we convert other drivers. This
really is just intended for (non-dt) platform devices. It might even be
better to do this with swnodes...
> And this is what I'm saying. What if instead of probing based on
> modalias, this function is made to bind the driver to the device based
> on the PHY ID?
>
> The point about this functionality being generic or not is totally moot,
> since it's the driver who *decides* to call it (and wouldn't do so, if
> it wasn't an MDIO device; see, there's an "mii_bus *bus" argument).
>
> It could work both with LS1028A (enetc, felix, where there is no
> pcs-handle), and it could also work with DPAA1/DPAA2, where there is a
> pcs-handle but there is no compatible string for the PCS.
The crucial difference here is that if we have a pcs-handle property,
then the node it points to will have a device created by the MDIO
subsystem automatically. The reason for this create_on_bus stuff
is to make the process of
1. Create an MDIO bus with no firmware node
2. Create some MDIO devices on that bus
3. Bind them to the correct driver
4. Get the PCS from the driver
less error prone. But for pcs-handle stuff, this should be something
like
1. pcs_find_fwnode()
2. Look up the device for this node
3. Bind it to the correct driver (but taking care that we don't unbind
an existing driver if it is correct).
And then the driver can call pcs_get().
With your suggestion to use PHY_ID, we wouldn't need that. But we would
still need driver involvement, since probing MDIO busses is not safe in
general (since as Andrew mentioned there are things on the busses which
don't have PHY ID registers). And IMO if we need the driver to go "yes,
it's OK to probe this non-phy on this bus," then we might as well do
what I described above. This could be a bus flag, which I think would
work with existing devices.
I'm worried that this could cause regressions and take a while to iron
out. My current approach is fairly conservative and doesn't require
changes to unaffected code.
>> >> As I understand it, kernels must be compatible with device trees from a
>> >> few kernels before and after. There is not a permanent guarantee of
>> >> backwards compatibility (like userspace has) because otherwise we would
>> >> never be able to make internal changes (such as what is done in this
>> >> series). I have suggested deferring these patches until after an LTS
>> >> release as suggested by Rob last time [1].
>> >>
>> >> --Sean
>> >>
>> >> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
>> >
>> > Internal changes limit themselves to what doesn't break compatibility
>> > with device trees in circulation. DT bindings are ABI. Compared to the
>> > lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
>> > sorry. The kernel has to continue probing them as Lynx PCS devices even
>> > in lack of a compatible string.
>>
>> I believe the idea here is to allow some leeway when updating so that
>> the kernel and device tree don't have to always be in sync. However, we
>> don't have to support a situation where the kernel is constantly updated
>> but the device tree is never updated. As long as a reasonable effort is
>> made to update (or *not* update) both the kernel and device tree, there
>> is no problem.
>
> I don't think you'd have this opinion if device trees were not
> maintained in the same git tree as the kernel itself. You have to
> consider the case where the device tree blob is provided by a firmware
> (say U-Boot) which you don't update in lockstep with the kernel.
> Has nothing to do with "reasonable" or not.
This is exactly the reason why I am saying that we need to have the
device tree updates in the kernel for a bit before these latter patches
can get merged. Actually, it is probably unlikely that these will make
it into the next LTS release (either 6.0 or 6.1), so these will probably
be in device trees for a year before the kernel starts using them. But
once that is done, we are free to require them.
--Sean
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-10 16:56 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-10 16:56 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/10/22 11:00, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 10:39:30AM -0500, Sean Anderson wrote:
>> On 11/10/22 10:29, Vladimir Oltean wrote:
>> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
>> >> On 11/9/22 17:41, Vladimir Oltean wrote:
>> >> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> >> >> Several (later) patches in this series cannot be applied until a stable
>> >> >> release has occured containing the dts updates.
>> >> >
>> >> > New kernels must remain compatible with old device trees.
>> >>
>> >> Well, this binding is not present in older device trees, so it needs to
>> >> be added before these patches can be applied. It also could be possible
>> >> to manually bind the driver using e.g. a helper function (like what is
>> >> done with lynx_pcs_create_on_bus). Of course this would be tricky,
>> >> because we would need to unbind any generic phy driver attached, but
>> >> avoid unbinding an existing Lynx PCS driver.
>> >
>> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
>> > these PCS devices, would it be possible to probe them in a generic way
>> > as MDIO devices, if they lack a compatible string?
>>
>> PCS devices are not PHYs, and they do not necessarily conform to the
>> standard PHY registers. Some PCS devices aren't even on MDIO busses (and
>> are instead memory-mapped). To implement this, I think we would need to be
>> very careful. There's also the issue where PCS devices might not be
>> accessable before their mode is selected by the MAC or SerDes.
>
> I don't get where you're going with this. Does any of these arguments
> apply to the Lynx PCS? If not, then what is the problem to using their
> PHY ID register as a mechanism to auto-bind their PCS driver in lack of
> a compatible string?
>
> You already accept a compromise by having lynx_pcs_create_on_bus() be a
> platform-specific way of instantiating a PCS. However, the only thing
> that's platform-specific in the lynx_pcs_create_on_bus() implementation
> is the modalias string:
>
> struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
> struct mii_bus *bus, int addr)
> {
> struct mdio_device *mdio;
> struct phylink_pcs *pcs;
> int err;
>
> mdio = mdio_device_create(bus, addr);
> if (IS_ERR(mdio))
> return ERR_CAST(mdio);
>
> mdio->bus_match = mdio_device_bus_match;
> strncpy(mdio->modalias, "lynx-pcs", sizeof(mdio->modalias)); // <----- this
> err = mdio_device_register(mdio);
> if (err) {
> mdio_device_free(mdio);
> return ERR_PTR(err);
> }
>
> pcs = pcs_get_by_dev(dev, &mdio->dev);
> mdio_device_free(mdio);
> return pcs;
> }
> EXPORT_SYMBOL(lynx_pcs_create_on_bus);
>
> Otherwise it could have been named just as well "pcs_create_on_bus()".
Yes, this could be made generic when we convert other drivers. This
really is just intended for (non-dt) platform devices. It might even be
better to do this with swnodes...
> And this is what I'm saying. What if instead of probing based on
> modalias, this function is made to bind the driver to the device based
> on the PHY ID?
>
> The point about this functionality being generic or not is totally moot,
> since it's the driver who *decides* to call it (and wouldn't do so, if
> it wasn't an MDIO device; see, there's an "mii_bus *bus" argument).
>
> It could work both with LS1028A (enetc, felix, where there is no
> pcs-handle), and it could also work with DPAA1/DPAA2, where there is a
> pcs-handle but there is no compatible string for the PCS.
The crucial difference here is that if we have a pcs-handle property,
then the node it points to will have a device created by the MDIO
subsystem automatically. The reason for this create_on_bus stuff
is to make the process of
1. Create an MDIO bus with no firmware node
2. Create some MDIO devices on that bus
3. Bind them to the correct driver
4. Get the PCS from the driver
less error prone. But for pcs-handle stuff, this should be something
like
1. pcs_find_fwnode()
2. Look up the device for this node
3. Bind it to the correct driver (but taking care that we don't unbind
an existing driver if it is correct).
And then the driver can call pcs_get().
With your suggestion to use PHY_ID, we wouldn't need that. But we would
still need driver involvement, since probing MDIO busses is not safe in
general (since as Andrew mentioned there are things on the busses which
don't have PHY ID registers). And IMO if we need the driver to go "yes,
it's OK to probe this non-phy on this bus," then we might as well do
what I described above. This could be a bus flag, which I think would
work with existing devices.
I'm worried that this could cause regressions and take a while to iron
out. My current approach is fairly conservative and doesn't require
changes to unaffected code.
>> >> As I understand it, kernels must be compatible with device trees from a
>> >> few kernels before and after. There is not a permanent guarantee of
>> >> backwards compatibility (like userspace has) because otherwise we would
>> >> never be able to make internal changes (such as what is done in this
>> >> series). I have suggested deferring these patches until after an LTS
>> >> release as suggested by Rob last time [1].
>> >>
>> >> --Sean
>> >>
>> >> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/
>> >
>> > Internal changes limit themselves to what doesn't break compatibility
>> > with device trees in circulation. DT bindings are ABI. Compared to the
>> > lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
>> > sorry. The kernel has to continue probing them as Lynx PCS devices even
>> > in lack of a compatible string.
>>
>> I believe the idea here is to allow some leeway when updating so that
>> the kernel and device tree don't have to always be in sync. However, we
>> don't have to support a situation where the kernel is constantly updated
>> but the device tree is never updated. As long as a reasonable effort is
>> made to update (or *not* update) both the kernel and device tree, there
>> is no problem.
>
> I don't think you'd have this opinion if device trees were not
> maintained in the same git tree as the kernel itself. You have to
> consider the case where the device tree blob is provided by a firmware
> (say U-Boot) which you don't update in lockstep with the kernel.
> Has nothing to do with "reasonable" or not.
This is exactly the reason why I am saying that we need to have the
device tree updates in the kernel for a bit before these latter patches
can get merged. Actually, it is probably unlikely that these will make
it into the next LTS release (either 6.0 or 6.1), so these will probably
be in device trees for a year before the kernel starts using them. But
once that is done, we are free to require them.
--Sean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-10 16:56 ` Sean Anderson
(?)
@ 2022-11-14 17:23 ` Vladimir Oltean
-1 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-14 17:23 UTC (permalink / raw)
To: Sean Anderson
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> these will probably be in device trees for a year before the kernel
> starts using them. But once that is done, we are free to require them.
Sorry, you need to propose something that is not "we can break compatibility
with today's device trees one year from now".
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-14 17:23 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-14 17:23 UTC (permalink / raw)
To: Sean Anderson
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Vladimir Oltean, Jakub Kicinski, Paolo Abeni,
Vivien Didelot, devicetree, linuxppc-dev, Claudiu Manoil,
Rob Herring, linux-arm-kernel, netdev,
lin ux-kernel@vger.kernel.org, Leo Li, Shawn Guo,
David S . Miller, Heiner Kallweit
On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> these will probably be in device trees for a year before the kernel
> starts using them. But once that is done, we are free to require them.
Sorry, you need to propose something that is not "we can break compatibility
with today's device trees one year from now".
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-14 17:23 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-14 17:23 UTC (permalink / raw)
To: Sean Anderson
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> these will probably be in device trees for a year before the kernel
> starts using them. But once that is done, we are free to require them.
Sorry, you need to propose something that is not "we can break compatibility
with today's device trees one year from now".
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-14 17:23 ` Vladimir Oltean
(?)
@ 2022-11-14 18:08 ` Sean Anderson
-1 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-14 18:08 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/14/22 12:23, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
>> these will probably be in device trees for a year before the kernel
>> starts using them. But once that is done, we are free to require them.
>
> Sorry, you need to propose something that is not "we can break compatibility
> with today's device trees one year from now".
But only if the kernel gets updated and not the device tree. When can
such a situation occur? Are we stuck with this for the next 10 years all
because someone may have a device tree which they compiled in 2017, and
*insist* on using the latest kernel with? Is this how you run your
systems?
We don't get the device tree from firmware on this platform; usually it
is bundled with the kernel in a FIT or loaded from the same disk
partition as the kernel. I can imagine that they might not always be
updated at exactly the same time, but this is nuts.
The original device tree is broken because it doesn't include compatible
strings for devices on a generic bus. There's no way to fix that other
than hard-coding the driver. This can be done for some buses, but this
is an MDIO bus and we already assume devices without compatibles are
PHYs.
In the next version of this series, I will include a compatibility
function which can bind a driver automatically if one is missing when
looking up a phy. But I would really like to have an exit strategy.
--Sean
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-14 18:08 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-14 18:08 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev
On 11/14/22 12:23, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
>> these will probably be in device trees for a year before the kernel
>> starts using them. But once that is done, we are free to require them.
>
> Sorry, you need to propose something that is not "we can break compatibility
> with today's device trees one year from now".
But only if the kernel gets updated and not the device tree. When can
such a situation occur? Are we stuck with this for the next 10 years all
because someone may have a device tree which they compiled in 2017, and
*insist* on using the latest kernel with? Is this how you run your
systems?
We don't get the device tree from firmware on this platform; usually it
is bundled with the kernel in a FIT or loaded from the same disk
partition as the kernel. I can imagine that they might not always be
updated at exactly the same time, but this is nuts.
The original device tree is broken because it doesn't include compatible
strings for devices on a generic bus. There's no way to fix that other
than hard-coding the driver. This can be done for some buses, but this
is an MDIO bus and we already assume devices without compatibles are
PHYs.
In the next version of this series, I will include a compatibility
function which can bind a driver automatically if one is missing when
looking up a phy. But I would really like to have an exit strategy.
--Sean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-14 18:08 ` Sean Anderson
0 siblings, 0 replies; 64+ messages in thread
From: Sean Anderson @ 2022-11-14 18:08 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Vladimir Oltean, Jakub Kicinski, Paolo Abeni,
Vivien Didelot, devicetree, linuxppc-dev, Claudiu Manoil,
Rob Herring, linux-arm-kernel, netdev,
lin ux-kernel@vger.kernel.org, Leo Li, Shawn Guo,
David S . Miller, Heiner Kallweit
On 11/14/22 12:23, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
>> these will probably be in device trees for a year before the kernel
>> starts using them. But once that is done, we are free to require them.
>
> Sorry, you need to propose something that is not "we can break compatibility
> with today's device trees one year from now".
But only if the kernel gets updated and not the device tree. When can
such a situation occur? Are we stuck with this for the next 10 years all
because someone may have a device tree which they compiled in 2017, and
*insist* on using the latest kernel with? Is this how you run your
systems?
We don't get the device tree from firmware on this platform; usually it
is bundled with the kernel in a FIT or loaded from the same disk
partition as the kernel. I can imagine that they might not always be
updated at exactly the same time, but this is nuts.
The original device tree is broken because it doesn't include compatible
strings for devices on a generic bus. There's no way to fix that other
than hard-coding the driver. This can be done for some buses, but this
is an MDIO bus and we already assume devices without compatibles are
PHYs.
In the next version of this series, I will include a compatibility
function which can bind a driver automatically if one is missing when
looking up a phy. But I would really like to have an exit strategy.
--Sean
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-14 18:08 ` Sean Anderson
(?)
@ 2022-11-14 19:53 ` Vladimir Oltean
-1 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-14 19:53 UTC (permalink / raw)
To: Sean Anderson
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev, Arnd Bergmann, Marc Zyngier
On Mon, Nov 14, 2022 at 01:08:03PM -0500, Sean Anderson wrote:
> On 11/14/22 12:23, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> >> these will probably be in device trees for a year before the kernel
> >> starts using them. But once that is done, we are free to require them.
> >
> > Sorry, you need to propose something that is not "we can break compatibility
> > with today's device trees one year from now".
>
> But only if the kernel gets updated and not the device tree. When can
> such a situation occur? Are we stuck with this for the next 10 years all
> because someone may have a device tree which they compiled in 2017, and
> *insist* on using the latest kernel with? Is this how you run your
> systems?
I'm a developer (and I work on other platforms than the ones you're
planning to break), so the answer to this question doesn't mean a thing.
> We don't get the device tree from firmware on this platform; usually it
> is bundled with the kernel in a FIT or loaded from the same disk
> partition as the kernel. I can imagine that they might not always be
> updated at exactly the same time, but this is nuts.
What does "this" platform mean exactly? There are many platforms to
which you've added compatible strings to keep things working assuming a
dtb update, many of them very old. And those to which you did are not by
far all that exist. There is no requirement that all platform device
trees are upstreamed to the Linux kernel.
> The original device tree is broken because it doesn't include compatible
> strings for devices on a generic bus. There's no way to fix that other
> than hard-coding the driver. This can be done for some buses, but this
> is an MDIO bus and we already assume devices without compatibles are
> PHYs.
Let's be clear about this. It's "broken" in the sense that you don't like
the way in which it works, not in the sense that it results in a system
that doesn't work. And not having a compatible string is just as broken
as it is for other devices with detectable device IDs, like Ethernet
PHYs in general, PCI devices, etc.
The way in which that works here, specifically, is that a generic PHY driver
is bound to the Lynx PCS devices, driver which does nothing since nobody
calls phy_attach_direct() to it. Then, using fwnode_mdio_find_device(),
you follow the pcsphy-handle and you get a reference to the mdio_device
(parent class of phy_device) object that resulted from the generic PHY
driver probing on the PCS, and you program the PCS to do what you want.
The PHY core does assume that mdio_devices without compatible strings
are phy_devices, but also makes exceptions (and warns about it) - see
commit ae461131960b ("of: of_mdio: Add a whitelist of PHY compatibilities.").
Maybe the reverse exception could also be made, and a warning for that
be added as well.
> In the next version of this series, I will include a compatibility
> function which can bind a driver automatically if one is missing when
> looking up a phy. But I would really like to have an exit strategy.
You'll have to get agreement from higher level maintainers than me that
the strategy "wait one year, break old device trees" is okay. Generally
we wouldn't have answers to this kind of questions that depend on whom
you ask. Otherwise.. we would all know whom to ask and whom not to ;)
Sadly I haven't found anything "official" in either Documentation/devicetree/usage-model.rst
or Documentation/process/submitting-patches.rst. Maybe I missed it?
I've added Arnd Bergmann for an ack, and also Marc Zyngier, not because
of any particular connection to what's being changed here, but because
I happen to know that he might have strong opinions on the topic :)
Full context here:
https://patchwork.kernel.org/project/netdevbpf/cover/20221103210650.2325784-1-sean.anderson@seco.com/
If I'm the only one opposing this, I guess I'll look elsewhere.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-14 19:53 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-14 19:53 UTC (permalink / raw)
To: Sean Anderson
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Russell King, Vladimir Oltean, Jakub Kicinski, Paolo Abeni,
Vivien Didelot, devicetree, Arnd Bergmann, linuxppc-dev,
Claudiu Manoil, Rob Herring, linux-arm-kernel, netdev,
linux-kernel, Leo Li, Marc Zyngier, Shawn Guo, David S . Miller,
Heiner Kallweit
On Mon, Nov 14, 2022 at 01:08:03PM -0500, Sean Anderson wrote:
> On 11/14/22 12:23, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> >> these will probably be in device trees for a year before the kernel
> >> starts using them. But once that is done, we are free to require them.
> >
> > Sorry, you need to propose something that is not "we can break compatibility
> > with today's device trees one year from now".
>
> But only if the kernel gets updated and not the device tree. When can
> such a situation occur? Are we stuck with this for the next 10 years all
> because someone may have a device tree which they compiled in 2017, and
> *insist* on using the latest kernel with? Is this how you run your
> systems?
I'm a developer (and I work on other platforms than the ones you're
planning to break), so the answer to this question doesn't mean a thing.
> We don't get the device tree from firmware on this platform; usually it
> is bundled with the kernel in a FIT or loaded from the same disk
> partition as the kernel. I can imagine that they might not always be
> updated at exactly the same time, but this is nuts.
What does "this" platform mean exactly? There are many platforms to
which you've added compatible strings to keep things working assuming a
dtb update, many of them very old. And those to which you did are not by
far all that exist. There is no requirement that all platform device
trees are upstreamed to the Linux kernel.
> The original device tree is broken because it doesn't include compatible
> strings for devices on a generic bus. There's no way to fix that other
> than hard-coding the driver. This can be done for some buses, but this
> is an MDIO bus and we already assume devices without compatibles are
> PHYs.
Let's be clear about this. It's "broken" in the sense that you don't like
the way in which it works, not in the sense that it results in a system
that doesn't work. And not having a compatible string is just as broken
as it is for other devices with detectable device IDs, like Ethernet
PHYs in general, PCI devices, etc.
The way in which that works here, specifically, is that a generic PHY driver
is bound to the Lynx PCS devices, driver which does nothing since nobody
calls phy_attach_direct() to it. Then, using fwnode_mdio_find_device(),
you follow the pcsphy-handle and you get a reference to the mdio_device
(parent class of phy_device) object that resulted from the generic PHY
driver probing on the PCS, and you program the PCS to do what you want.
The PHY core does assume that mdio_devices without compatible strings
are phy_devices, but also makes exceptions (and warns about it) - see
commit ae461131960b ("of: of_mdio: Add a whitelist of PHY compatibilities.").
Maybe the reverse exception could also be made, and a warning for that
be added as well.
> In the next version of this series, I will include a compatibility
> function which can bind a driver automatically if one is missing when
> looking up a phy. But I would really like to have an exit strategy.
You'll have to get agreement from higher level maintainers than me that
the strategy "wait one year, break old device trees" is okay. Generally
we wouldn't have answers to this kind of questions that depend on whom
you ask. Otherwise.. we would all know whom to ask and whom not to ;)
Sadly I haven't found anything "official" in either Documentation/devicetree/usage-model.rst
or Documentation/process/submitting-patches.rst. Maybe I missed it?
I've added Arnd Bergmann for an ack, and also Marc Zyngier, not because
of any particular connection to what's being changed here, but because
I happen to know that he might have strong opinions on the topic :)
Full context here:
https://patchwork.kernel.org/project/netdevbpf/cover/20221103210650.2325784-1-sean.anderson@seco.com/
If I'm the only one opposing this, I guess I'll look elsewhere.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-14 19:53 ` Vladimir Oltean
0 siblings, 0 replies; 64+ messages in thread
From: Vladimir Oltean @ 2022-11-14 19:53 UTC (permalink / raw)
To: Sean Anderson
Cc: Vladimir Oltean, Heiner Kallweit, Russell King, netdev,
Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Rob Herring, Saravana Kannan,
Shawn Guo, UNGLinuxDriver, Vivien Didelot, devicetree,
linux-arm-kernel, linuxppc-dev, Arnd Bergmann, Marc Zyngier
On Mon, Nov 14, 2022 at 01:08:03PM -0500, Sean Anderson wrote:
> On 11/14/22 12:23, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> >> these will probably be in device trees for a year before the kernel
> >> starts using them. But once that is done, we are free to require them.
> >
> > Sorry, you need to propose something that is not "we can break compatibility
> > with today's device trees one year from now".
>
> But only if the kernel gets updated and not the device tree. When can
> such a situation occur? Are we stuck with this for the next 10 years all
> because someone may have a device tree which they compiled in 2017, and
> *insist* on using the latest kernel with? Is this how you run your
> systems?
I'm a developer (and I work on other platforms than the ones you're
planning to break), so the answer to this question doesn't mean a thing.
> We don't get the device tree from firmware on this platform; usually it
> is bundled with the kernel in a FIT or loaded from the same disk
> partition as the kernel. I can imagine that they might not always be
> updated at exactly the same time, but this is nuts.
What does "this" platform mean exactly? There are many platforms to
which you've added compatible strings to keep things working assuming a
dtb update, many of them very old. And those to which you did are not by
far all that exist. There is no requirement that all platform device
trees are upstreamed to the Linux kernel.
> The original device tree is broken because it doesn't include compatible
> strings for devices on a generic bus. There's no way to fix that other
> than hard-coding the driver. This can be done for some buses, but this
> is an MDIO bus and we already assume devices without compatibles are
> PHYs.
Let's be clear about this. It's "broken" in the sense that you don't like
the way in which it works, not in the sense that it results in a system
that doesn't work. And not having a compatible string is just as broken
as it is for other devices with detectable device IDs, like Ethernet
PHYs in general, PCI devices, etc.
The way in which that works here, specifically, is that a generic PHY driver
is bound to the Lynx PCS devices, driver which does nothing since nobody
calls phy_attach_direct() to it. Then, using fwnode_mdio_find_device(),
you follow the pcsphy-handle and you get a reference to the mdio_device
(parent class of phy_device) object that resulted from the generic PHY
driver probing on the PCS, and you program the PCS to do what you want.
The PHY core does assume that mdio_devices without compatible strings
are phy_devices, but also makes exceptions (and warns about it) - see
commit ae461131960b ("of: of_mdio: Add a whitelist of PHY compatibilities.").
Maybe the reverse exception could also be made, and a warning for that
be added as well.
> In the next version of this series, I will include a compatibility
> function which can bind a driver automatically if one is missing when
> looking up a phy. But I would really like to have an exit strategy.
You'll have to get agreement from higher level maintainers than me that
the strategy "wait one year, break old device trees" is okay. Generally
we wouldn't have answers to this kind of questions that depend on whom
you ask. Otherwise.. we would all know whom to ask and whom not to ;)
Sadly I haven't found anything "official" in either Documentation/devicetree/usage-model.rst
or Documentation/process/submitting-patches.rst. Maybe I missed it?
I've added Arnd Bergmann for an ack, and also Marc Zyngier, not because
of any particular connection to what's being changed here, but because
I happen to know that he might have strong opinions on the topic :)
Full context here:
https://patchwork.kernel.org/project/netdevbpf/cover/20221103210650.2325784-1-sean.anderson@seco.com/
If I'm the only one opposing this, I guess I'll look elsewhere.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
2022-11-14 19:53 ` Vladimir Oltean
(?)
@ 2022-11-17 13:38 ` Rob Herring
-1 siblings, 0 replies; 64+ messages in thread
From: Rob Herring @ 2022-11-17 13:38 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Sean Anderson, Vladimir Oltean, Heiner Kallweit, Russell King,
netdev, Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, devicetree, linux-arm-kernel,
linuxppc-dev, Arnd Bergmann, Marc Zyngier
On Mon, Nov 14, 2022 at 1:53 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Mon, Nov 14, 2022 at 01:08:03PM -0500, Sean Anderson wrote:
> > On 11/14/22 12:23, Vladimir Oltean wrote:
> > > On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> > >> these will probably be in device trees for a year before the kernel
> > >> starts using them. But once that is done, we are free to require them.
> > >
> > > Sorry, you need to propose something that is not "we can break compatibility
> > > with today's device trees one year from now".
> >
> > But only if the kernel gets updated and not the device tree. When can
> > such a situation occur? Are we stuck with this for the next 10 years all
> > because someone may have a device tree which they compiled in 2017, and
> > *insist* on using the latest kernel with? Is this how you run your
> > systems?
>
> I'm a developer (and I work on other platforms than the ones you're
> planning to break), so the answer to this question doesn't mean a thing.
>
> > We don't get the device tree from firmware on this platform; usually it
> > is bundled with the kernel in a FIT or loaded from the same disk
> > partition as the kernel. I can imagine that they might not always be
> > updated at exactly the same time, but this is nuts.
>
> What does "this" platform mean exactly? There are many platforms to
> which you've added compatible strings to keep things working assuming a
> dtb update, many of them very old. And those to which you did are not by
> far all that exist. There is no requirement that all platform device
> trees are upstreamed to the Linux kernel.
>
> > The original device tree is broken because it doesn't include compatible
> > strings for devices on a generic bus. There's no way to fix that other
> > than hard-coding the driver. This can be done for some buses, but this
> > is an MDIO bus and we already assume devices without compatibles are
> > PHYs.
>
> Let's be clear about this. It's "broken" in the sense that you don't like
> the way in which it works, not in the sense that it results in a system
> that doesn't work. And not having a compatible string is just as broken
> as it is for other devices with detectable device IDs, like Ethernet
> PHYs in general, PCI devices, etc.
>
> The way in which that works here, specifically, is that a generic PHY driver
> is bound to the Lynx PCS devices, driver which does nothing since nobody
> calls phy_attach_direct() to it. Then, using fwnode_mdio_find_device(),
> you follow the pcsphy-handle and you get a reference to the mdio_device
> (parent class of phy_device) object that resulted from the generic PHY
> driver probing on the PCS, and you program the PCS to do what you want.
>
> The PHY core does assume that mdio_devices without compatible strings
> are phy_devices, but also makes exceptions (and warns about it) - see
> commit ae461131960b ("of: of_mdio: Add a whitelist of PHY compatibilities.").
> Maybe the reverse exception could also be made, and a warning for that
> be added as well.
>
> > In the next version of this series, I will include a compatibility
> > function which can bind a driver automatically if one is missing when
> > looking up a phy. But I would really like to have an exit strategy.
>
> You'll have to get agreement from higher level maintainers than me that
> the strategy "wait one year, break old device trees" is okay. Generally
> we wouldn't have answers to this kind of questions that depend on whom
> you ask. Otherwise.. we would all know whom to ask and whom not to ;)
A window of time can work, but only when there's other reasons
everyone must update the firmware/DT.
> Sadly I haven't found anything "official" in either Documentation/devicetree/usage-model.rst
> or Documentation/process/submitting-patches.rst. Maybe I missed it?
Documentation/devicetree/bindings/ABI.rst
The exact policy depends on the platform (or family of platforms). In
short, if *anyone* cares, then compatibility should not be broken.
Vladimir uses platforms in question and cares, so don't break the
platforms.
Rob
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-17 13:38 ` Rob Herring
0 siblings, 0 replies; 64+ messages in thread
From: Rob Herring @ 2022-11-17 13:38 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Alexandre Belloni, Madalin Bucur, Eric Dumazet,
Paul Mackerras, Krzysztof Kozlowski, Ioana Ciornei,
UNGLinuxDriver, Frank Rowand, Florian Fainelli, Saravana Kannan,
Sean Anderson, Russell King, Vladimir Oltean, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, devicetree, Arnd Bergmann,
linuxppc-dev, Claudiu Manoil, linux-arm-kernel,
netdev@vger.kerne l.org, linux-kernel, Leo Li, Marc Zyngier,
Shawn Guo, David S . Miller, Heiner Kallweit
On Mon, Nov 14, 2022 at 1:53 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Mon, Nov 14, 2022 at 01:08:03PM -0500, Sean Anderson wrote:
> > On 11/14/22 12:23, Vladimir Oltean wrote:
> > > On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> > >> these will probably be in device trees for a year before the kernel
> > >> starts using them. But once that is done, we are free to require them.
> > >
> > > Sorry, you need to propose something that is not "we can break compatibility
> > > with today's device trees one year from now".
> >
> > But only if the kernel gets updated and not the device tree. When can
> > such a situation occur? Are we stuck with this for the next 10 years all
> > because someone may have a device tree which they compiled in 2017, and
> > *insist* on using the latest kernel with? Is this how you run your
> > systems?
>
> I'm a developer (and I work on other platforms than the ones you're
> planning to break), so the answer to this question doesn't mean a thing.
>
> > We don't get the device tree from firmware on this platform; usually it
> > is bundled with the kernel in a FIT or loaded from the same disk
> > partition as the kernel. I can imagine that they might not always be
> > updated at exactly the same time, but this is nuts.
>
> What does "this" platform mean exactly? There are many platforms to
> which you've added compatible strings to keep things working assuming a
> dtb update, many of them very old. And those to which you did are not by
> far all that exist. There is no requirement that all platform device
> trees are upstreamed to the Linux kernel.
>
> > The original device tree is broken because it doesn't include compatible
> > strings for devices on a generic bus. There's no way to fix that other
> > than hard-coding the driver. This can be done for some buses, but this
> > is an MDIO bus and we already assume devices without compatibles are
> > PHYs.
>
> Let's be clear about this. It's "broken" in the sense that you don't like
> the way in which it works, not in the sense that it results in a system
> that doesn't work. And not having a compatible string is just as broken
> as it is for other devices with detectable device IDs, like Ethernet
> PHYs in general, PCI devices, etc.
>
> The way in which that works here, specifically, is that a generic PHY driver
> is bound to the Lynx PCS devices, driver which does nothing since nobody
> calls phy_attach_direct() to it. Then, using fwnode_mdio_find_device(),
> you follow the pcsphy-handle and you get a reference to the mdio_device
> (parent class of phy_device) object that resulted from the generic PHY
> driver probing on the PCS, and you program the PCS to do what you want.
>
> The PHY core does assume that mdio_devices without compatible strings
> are phy_devices, but also makes exceptions (and warns about it) - see
> commit ae461131960b ("of: of_mdio: Add a whitelist of PHY compatibilities.").
> Maybe the reverse exception could also be made, and a warning for that
> be added as well.
>
> > In the next version of this series, I will include a compatibility
> > function which can bind a driver automatically if one is missing when
> > looking up a phy. But I would really like to have an exit strategy.
>
> You'll have to get agreement from higher level maintainers than me that
> the strategy "wait one year, break old device trees" is okay. Generally
> we wouldn't have answers to this kind of questions that depend on whom
> you ask. Otherwise.. we would all know whom to ask and whom not to ;)
A window of time can work, but only when there's other reasons
everyone must update the firmware/DT.
> Sadly I haven't found anything "official" in either Documentation/devicetree/usage-model.rst
> or Documentation/process/submitting-patches.rst. Maybe I missed it?
Documentation/devicetree/bindings/ABI.rst
The exact policy depends on the platform (or family of platforms). In
short, if *anyone* cares, then compatibility should not be broken.
Vladimir uses platforms in question and cares, so don't break the
platforms.
Rob
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner
@ 2022-11-17 13:38 ` Rob Herring
0 siblings, 0 replies; 64+ messages in thread
From: Rob Herring @ 2022-11-17 13:38 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Sean Anderson, Vladimir Oltean, Heiner Kallweit, Russell King,
netdev, Eric Dumazet, Paolo Abeni, Jakub Kicinski, linux-kernel,
Andrew Lunn, Ioana Ciornei, Madalin Bucur, David S . Miller,
Alexandre Belloni, Benjamin Herrenschmidt, Claudiu Manoil,
Florian Fainelli, Frank Rowand, Krzysztof Kozlowski, Leo Li,
Michael Ellerman, Paul Mackerras, Saravana Kannan, Shawn Guo,
UNGLinuxDriver, Vivien Didelot, devicetree, linux-arm-kernel,
linuxppc-dev, Arnd Bergmann, Marc Zyngier
On Mon, Nov 14, 2022 at 1:53 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Mon, Nov 14, 2022 at 01:08:03PM -0500, Sean Anderson wrote:
> > On 11/14/22 12:23, Vladimir Oltean wrote:
> > > On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> > >> these will probably be in device trees for a year before the kernel
> > >> starts using them. But once that is done, we are free to require them.
> > >
> > > Sorry, you need to propose something that is not "we can break compatibility
> > > with today's device trees one year from now".
> >
> > But only if the kernel gets updated and not the device tree. When can
> > such a situation occur? Are we stuck with this for the next 10 years all
> > because someone may have a device tree which they compiled in 2017, and
> > *insist* on using the latest kernel with? Is this how you run your
> > systems?
>
> I'm a developer (and I work on other platforms than the ones you're
> planning to break), so the answer to this question doesn't mean a thing.
>
> > We don't get the device tree from firmware on this platform; usually it
> > is bundled with the kernel in a FIT or loaded from the same disk
> > partition as the kernel. I can imagine that they might not always be
> > updated at exactly the same time, but this is nuts.
>
> What does "this" platform mean exactly? There are many platforms to
> which you've added compatible strings to keep things working assuming a
> dtb update, many of them very old. And those to which you did are not by
> far all that exist. There is no requirement that all platform device
> trees are upstreamed to the Linux kernel.
>
> > The original device tree is broken because it doesn't include compatible
> > strings for devices on a generic bus. There's no way to fix that other
> > than hard-coding the driver. This can be done for some buses, but this
> > is an MDIO bus and we already assume devices without compatibles are
> > PHYs.
>
> Let's be clear about this. It's "broken" in the sense that you don't like
> the way in which it works, not in the sense that it results in a system
> that doesn't work. And not having a compatible string is just as broken
> as it is for other devices with detectable device IDs, like Ethernet
> PHYs in general, PCI devices, etc.
>
> The way in which that works here, specifically, is that a generic PHY driver
> is bound to the Lynx PCS devices, driver which does nothing since nobody
> calls phy_attach_direct() to it. Then, using fwnode_mdio_find_device(),
> you follow the pcsphy-handle and you get a reference to the mdio_device
> (parent class of phy_device) object that resulted from the generic PHY
> driver probing on the PCS, and you program the PCS to do what you want.
>
> The PHY core does assume that mdio_devices without compatible strings
> are phy_devices, but also makes exceptions (and warns about it) - see
> commit ae461131960b ("of: of_mdio: Add a whitelist of PHY compatibilities.").
> Maybe the reverse exception could also be made, and a warning for that
> be added as well.
>
> > In the next version of this series, I will include a compatibility
> > function which can bind a driver automatically if one is missing when
> > looking up a phy. But I would really like to have an exit strategy.
>
> You'll have to get agreement from higher level maintainers than me that
> the strategy "wait one year, break old device trees" is okay. Generally
> we wouldn't have answers to this kind of questions that depend on whom
> you ask. Otherwise.. we would all know whom to ask and whom not to ;)
A window of time can work, but only when there's other reasons
everyone must update the firmware/DT.
> Sadly I haven't found anything "official" in either Documentation/devicetree/usage-model.rst
> or Documentation/process/submitting-patches.rst. Maybe I missed it?
Documentation/devicetree/bindings/ABI.rst
The exact policy depends on the platform (or family of platforms). In
short, if *anyone* cares, then compatibility should not be broken.
Vladimir uses platforms in question and cares, so don't break the
platforms.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2022-11-17 13:40 UTC | newest]
Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-03 21:06 [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner Sean Anderson
2022-11-03 21:06 ` Sean Anderson
2022-11-03 21:06 ` Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 01/11] arm64: dts: Add compatible strings for Lynx PCSs Sean Anderson
2022-11-03 21:06 ` Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 02/11] powerpc: " Sean Anderson
2022-11-03 21:06 ` Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 03/11] net: dsa: ocelot: suppress PHY device scanning on the internal MDIO bus Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 04/11] net: pcs: Add subsystem Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 05/11] net: pcs: lynx: Convert to an MDIO driver Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 06/11] net: enetc: Convert to use PCS subsystem Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 07/11] net: dsa: felix: Convert to use PCS driver Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 08/11] of: property: Add device link support for PCS Sean Anderson
2022-11-07 20:10 ` Rob Herring
2022-11-07 20:22 ` Vladimir Oltean
2022-11-07 20:50 ` Sean Anderson
2022-11-07 21:36 ` Rob Herring
2022-11-08 20:56 ` Saravana Kannan
2022-11-09 21:56 ` Vladimir Oltean
2022-11-03 21:06 ` [PATCH net-next v2 09/11] [DO NOT MERGE] net: dpaa: Convert to use PCS subsystem Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 10/11] [DO NOT MERGE] net: dpaa2: " Sean Anderson
2022-11-03 21:06 ` [PATCH net-next v2 11/11] [DO NOT MERGE] net: pcs: lynx: Remove non-device functionality Sean Anderson
2022-11-09 22:41 ` [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner Vladimir Oltean
2022-11-09 22:41 ` Vladimir Oltean
2022-11-09 22:41 ` Vladimir Oltean
2022-11-10 14:55 ` Sean Anderson
2022-11-10 14:55 ` Sean Anderson
2022-11-10 14:55 ` Sean Anderson
2022-11-10 15:29 ` Vladimir Oltean
2022-11-10 15:29 ` Vladimir Oltean
2022-11-10 15:29 ` Vladimir Oltean
2022-11-10 15:39 ` Sean Anderson
2022-11-10 15:39 ` Sean Anderson
2022-11-10 15:39 ` Sean Anderson
2022-11-10 16:00 ` Vladimir Oltean
2022-11-10 16:00 ` Vladimir Oltean
2022-11-10 16:00 ` Vladimir Oltean
2022-11-10 16:56 ` Sean Anderson
2022-11-10 16:56 ` Sean Anderson
2022-11-10 16:56 ` Sean Anderson
2022-11-14 17:23 ` Vladimir Oltean
2022-11-14 17:23 ` Vladimir Oltean
2022-11-14 17:23 ` Vladimir Oltean
2022-11-14 18:08 ` Sean Anderson
2022-11-14 18:08 ` Sean Anderson
2022-11-14 18:08 ` Sean Anderson
2022-11-14 19:53 ` Vladimir Oltean
2022-11-14 19:53 ` Vladimir Oltean
2022-11-14 19:53 ` Vladimir Oltean
2022-11-17 13:38 ` Rob Herring
2022-11-17 13:38 ` Rob Herring
2022-11-17 13:38 ` Rob Herring
2022-11-10 16:01 ` Andrew Lunn
2022-11-10 16:01 ` Andrew Lunn
2022-11-10 16:01 ` Andrew Lunn
2022-11-10 16:32 ` Vladimir Oltean
2022-11-10 16:32 ` Vladimir Oltean
2022-11-10 16:32 ` Vladimir Oltean
2022-11-09 22:59 ` Vladimir Oltean
2022-11-09 22:59 ` Vladimir Oltean
2022-11-09 22:59 ` Vladimir Oltean
2022-11-10 15:15 ` Sean Anderson
2022-11-10 15:15 ` Sean Anderson
2022-11-10 15:15 ` Sean Anderson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.