| Message ID | 20220930200933.4111249-1-sean.anderson@seco.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: dpaa: Convert to phylink | expand |
On 9/30/22 4:09 PM, Sean Anderson wrote: > This series converts the DPAA driver to phylink. > > I have tried to maintain backwards compatibility with existing device > trees whereever possible. However, one area where I was unable to > achieve this was with QSGMII. Please refer to patch 2 for details. > > All mac drivers have now been converted. I would greatly appreciate if > anyone has T-series or P-series boards they can test/debug this series > on. I only have an LS1046ARDB. Everything but QSGMII should work without > breakage; QSGMII needs patches 7 and 8. For this reason, the last 4 > patches in this series should be applied together (and should not go > through separate trees). > > Changes in v6: > - Remove unnecessary $ref from renesas,rzn1-a5psw > - Remove unnecessary type from pcs-handle-names > - Add maxItems to pcs-handle > - Fix 81-character line > - Fix uninitialized variable in dtsec_mac_config > > Changes in v5: > - Add Lynx PCS binding > > Changes in v4: > - Use pcs-handle-names instead of pcs-names, as discussed > - Don't fail if phy support was not compiled in > - Split off rate adaptation series > - Split off DPAA "preparation" series > - Split off Lynx 10G support > - t208x: Mark MAC1 and MAC2 as 10G > - Add XFI PCS for t208x MAC1/MAC2 > > Changes in v3: > - Expand pcs-handle to an array > - Add vendor prefix 'fsl,' to rgmii and mii properties. > - Set maxItems for pcs-names > - Remove phy-* properties from example because dt-schema complains and I > can't be bothered to figure out how to make it work. > - Add pcs-handle as a preferred version of pcsphy-handle > - Deprecate pcsphy-handle > - Remove mii/rmii properties > - Put the PCS mdiodev only after we are done with it (since the PCS > does not perform a get itself). > - Remove _return label from memac_initialization in favor of returning > directly > - Fix grabbing the default PCS not checking for -ENODATA from > of_property_match_string > - Set DTSEC_ECNTRL_R100M in dtsec_link_up instead of dtsec_mac_config > - Remove rmii/mii properties > - Replace 1000Base... with 1000BASE... to match IEEE capitalization > - Add compatibles for QSGMII PCSs > - Split arm and powerpcs dts updates > > Changes in v2: > - Better document how we select which PCS to use in the default case > - Move PCS_LYNX dependency to fman Kconfig > - Remove unused variable slow_10g_if > - Restrict valid link modes based on the phy interface. This is easier > to set up, and mostly captures what I intended to do the first time. > We now have a custom validate which restricts half-duplex for some SoCs > for RGMII, but generally just uses the default phylink validate. > - Configure the SerDes in enable/disable > - Properly implement all ethtool ops and ioctls. These were mostly > stubbed out just enough to compile last time. > - Convert 10GEC and dTSEC as well > - Fix capitalization of mEMAC in commit messages > - Add nodes for QSGMII PCSs > - Add nodes for QSGMII PCSs > > Sean Anderson (9): > dt-bindings: net: Expand pcs-handle to an array > dt-bindings: net: Add Lynx PCS binding > dt-bindings: net: fman: Add additional interface properties > net: fman: memac: Add serdes support > net: fman: memac: Use lynx pcs driver > net: dpaa: Convert to phylink > powerpc: dts: t208x: Mark MAC1 and MAC2 as 10G > powerpc: dts: qoriq: Add nodes for QSGMII PCSs > arm64: dts: layerscape: Add nodes for QSGMII PCSs > > .../bindings/net/dsa/renesas,rzn1-a5psw.yaml | 2 +- > .../bindings/net/ethernet-controller.yaml | 11 +- > .../bindings/net/fsl,fman-dtsec.yaml | 53 +- > .../bindings/net/fsl,qoriq-mc-dpmac.yaml | 2 +- > .../devicetree/bindings/net/fsl-fman.txt | 5 +- > .../bindings/net/pcs/fsl,lynx-pcs.yaml | 40 + > .../boot/dts/freescale/fsl-ls1043-post.dtsi | 24 + > .../boot/dts/freescale/fsl-ls1046-post.dtsi | 25 + > .../fsl/qoriq-fman3-0-10g-0-best-effort.dtsi | 3 +- > .../boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi | 10 +- > .../fsl/qoriq-fman3-0-10g-1-best-effort.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi | 45 ++ > .../boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi | 45 ++ > .../boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi | 3 +- > .../boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi | 3 +- > .../boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi | 3 +- > .../boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi | 10 +- > .../boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi | 3 +- > .../boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi | 10 +- > arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 4 +- > drivers/net/ethernet/freescale/dpaa/Kconfig | 4 +- > .../net/ethernet/freescale/dpaa/dpaa_eth.c | 89 +-- > .../ethernet/freescale/dpaa/dpaa_ethtool.c | 90 +-- > drivers/net/ethernet/freescale/fman/Kconfig | 4 +- > .../net/ethernet/freescale/fman/fman_dtsec.c | 460 +++++------ > .../net/ethernet/freescale/fman/fman_mac.h | 10 - > .../net/ethernet/freescale/fman/fman_memac.c | 747 +++++++++--------- > .../net/ethernet/freescale/fman/fman_tgec.c | 131 ++- > drivers/net/ethernet/freescale/fman/mac.c | 168 +--- > drivers/net/ethernet/freescale/fman/mac.h | 23 +- > 39 files changed, 1076 insertions(+), 1051 deletions(-) > create mode 100644 Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml > create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi > create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi > I noticed that this series was marked "RFC" in patchwork. I consider this series ready to apply. I am requesting *testing*, in particular on 10gec/dtsec boards (P-series). Since no one seems to have tried that over the past 4 months that I've been working on this series, perhaps the best way for it to get tested is to apply it... --Sean
On Tue, 4 Oct 2022 11:28:19 -0400 Sean Anderson wrote: > I noticed that this series was marked "RFC" in patchwork. Because the cover letter has RTF in the subject, presumably. > I consider this series ready to apply. I am requesting *testing*, in > particular on 10gec/dtsec boards (P-series). Since no one seems to > have tried that over the past 4 months that I've been working on this > series, perhaps the best way for it to get tested is to apply it... You know the situation the best as the author, you should make a clear call on the nature of the posting. It's either RFC/RFT or a ready-to-go-in posting. Maybe in smaller subsystems you can post an RFC/RTF and then it gets applied after some time without a repost but we don't do that. The normal processing time for a patch is 1-3 days while we like to give people a week to test. So the patches would have to rot in the review queue for extra half a week. At our patch rate this is unsustainable.
On 10/4/22 12:52 PM, Jakub Kicinski wrote: > On Tue, 4 Oct 2022 11:28:19 -0400 Sean Anderson wrote: >> I noticed that this series was marked "RFC" in patchwork. > > Because the cover letter has RTF in the subject, presumably. > >> I consider this series ready to apply. I am requesting *testing*, in >> particular on 10gec/dtsec boards (P-series). Since no one seems to >> have tried that over the past 4 months that I've been working on this >> series, perhaps the best way for it to get tested is to apply it... > > You know the situation the best as the author, you should make > a clear call on the nature of the posting. It's either RFC/RFT > or a ready-to-go-in posting. Well, I consider the memac stuff to be well tested, but I don't have 10gec/dtsec hardware. I was hoping that someone with the hardware might look at this series if I stuck RFT in the subject. I suspect there are still some bugs in those drivers. > Maybe in smaller subsystems you can post an RFC/RTF and then it > gets applied after some time without a repost but we don't do that. > The normal processing time for a patch is 1-3 days while we like > to give people a week to test. So the patches would have to rot in > the review queue for extra half a week. At our patch rate this is > unsustainable. > Well, I have gotten reviews for the device tree stuff, but the core changes (what I consider to be the actual content of the series) is missing Reviewed-bys. I don't anticipate making any major changes to the series unless I get some feedback one way or another. If having RFT in the subject is preventing that review, I will remove it. --Sean