From: Ioana Ciornei <ioana.ciornei@nxp.com> To: Russell King - ARM Linux admin <linux@armlinux.org.uk> Cc: Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Heiner Kallweit <hkallweit1@gmail.com>, Mark Rutland <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Leo Li <leoyang.li@nxp.com>, Rob Herring <robh+dt@kernel.org>, Shawn Guo <shawnguo@kernel.org>, "David S. Miller" <davem@davemloft.net>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: RE: [RFC net-next 3/5] arm64: dts: lx2160a: add PCS MDIO nodes Date: Thu, 26 Mar 2020 21:26:46 +0000 [thread overview] Message-ID: <DB8PR04MB682817485CBD1EFA1AA179F1E0CF0@DB8PR04MB6828.eurprd04.prod.outlook.com> (raw) In-Reply-To: <20200326212104.GE25745@shell.armlinux.org.uk> > Subject: Re: [RFC net-next 3/5] arm64: dts: lx2160a: add PCS MDIO nodes > > On Thu, Mar 26, 2020 at 09:14:13PM +0000, Ioana Ciornei wrote: > > > Subject: [RFC net-next 3/5] arm64: dts: lx2160a: add PCS MDIO nodes > > > > > > *NOT FOR MERGING* > > > > > > Add PCS MDIO nodes for the LX2160A, which will be used when the MAC > > > is in PHY mode and is using in-band negotiation. > > > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > > --- > > > .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 144 > > > ++++++++++++++++++ > > > 1 file changed, 144 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > > > index e5ee5591e52b..732af33eec18 100644 > > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > > > @@ -960,6 +960,132 @@ > > > status = "disabled"; > > > }; > > > > > > + pcs_mdio1: mdio@8c07000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c07000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > > Are the PCS MDIO buses shareable? I am asking this because in case of QSGMII > our structure is a little bit quirky. > > There are 4 MACs but all PCSs sit on the first MACs internal MDIO bus only. The > other 3 internal MDIO buses are empty. > > I haven't looked at QSGMII yet, I've only considered single-lane setups and only > implemented that. For _this_ part, it doesn't matter as this is just declaring > where the hardware is. I think that matters more for the dpmac nodes. Sorry for misplacing the comment. I am going to take a look tomorrow and see how workable this approach is going to be in the long term since I have a board with QSGMII handy. > > > > + > > > + pcs_mdio2: mdio@8c0b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c0b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio3: mdio@8c0f000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c0f000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio4: mdio@8c13000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c13000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio5: mdio@8c17000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c17000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio6: mdio@8c1b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c1b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio7: mdio@8c1f000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c1f000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio8: mdio@8c23000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c23000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio9: mdio@8c27000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c27000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio10: mdio@8c2b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c2b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio11: mdio@8c2f000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c2f000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio12: mdio@8c33000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c33000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio13: mdio@8c37000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c37000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio14: mdio@8c3b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c3b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio15: mdio@8c3f000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c3f000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio16: mdio@8c43000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c43000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio17: mdio@8c47000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c47000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio18: mdio@8c4b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c4b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > > Please sort the nodes alphabetically. > > Huh? The nodes in this file are already sorted according to address, and this > patch preserves that sorting. The hex address field also happens to be > alphabetical. > > Or do you mean the label for these modes - I've never heard of sorting by label > for a SoC file. Uhh, I remember now. For some reason I thought this was a board file. Ioana [snip]
WARNING: multiple messages have this Message-ID (diff)
From: Ioana Ciornei <ioana.ciornei@nxp.com> To: Russell King - ARM Linux admin <linux@armlinux.org.uk> Cc: Mark Rutland <mark.rutland@arm.com>, Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Leo Li <leoyang.li@nxp.com>, Rob Herring <robh+dt@kernel.org>, Shawn Guo <shawnguo@kernel.org>, "David S. Miller" <davem@davemloft.net>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Heiner Kallweit <hkallweit1@gmail.com> Subject: RE: [RFC net-next 3/5] arm64: dts: lx2160a: add PCS MDIO nodes Date: Thu, 26 Mar 2020 21:26:46 +0000 [thread overview] Message-ID: <DB8PR04MB682817485CBD1EFA1AA179F1E0CF0@DB8PR04MB6828.eurprd04.prod.outlook.com> (raw) In-Reply-To: <20200326212104.GE25745@shell.armlinux.org.uk> > Subject: Re: [RFC net-next 3/5] arm64: dts: lx2160a: add PCS MDIO nodes > > On Thu, Mar 26, 2020 at 09:14:13PM +0000, Ioana Ciornei wrote: > > > Subject: [RFC net-next 3/5] arm64: dts: lx2160a: add PCS MDIO nodes > > > > > > *NOT FOR MERGING* > > > > > > Add PCS MDIO nodes for the LX2160A, which will be used when the MAC > > > is in PHY mode and is using in-band negotiation. > > > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > > --- > > > .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 144 > > > ++++++++++++++++++ > > > 1 file changed, 144 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > > > index e5ee5591e52b..732af33eec18 100644 > > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > > > @@ -960,6 +960,132 @@ > > > status = "disabled"; > > > }; > > > > > > + pcs_mdio1: mdio@8c07000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c07000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > > Are the PCS MDIO buses shareable? I am asking this because in case of QSGMII > our structure is a little bit quirky. > > There are 4 MACs but all PCSs sit on the first MACs internal MDIO bus only. The > other 3 internal MDIO buses are empty. > > I haven't looked at QSGMII yet, I've only considered single-lane setups and only > implemented that. For _this_ part, it doesn't matter as this is just declaring > where the hardware is. I think that matters more for the dpmac nodes. Sorry for misplacing the comment. I am going to take a look tomorrow and see how workable this approach is going to be in the long term since I have a board with QSGMII handy. > > > > + > > > + pcs_mdio2: mdio@8c0b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c0b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio3: mdio@8c0f000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c0f000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio4: mdio@8c13000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c13000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio5: mdio@8c17000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c17000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio6: mdio@8c1b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c1b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio7: mdio@8c1f000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c1f000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio8: mdio@8c23000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c23000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio9: mdio@8c27000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c27000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio10: mdio@8c2b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c2b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio11: mdio@8c2f000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c2f000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio12: mdio@8c33000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c33000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio13: mdio@8c37000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c37000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio14: mdio@8c3b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c3b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio15: mdio@8c3f000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c3f000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio16: mdio@8c43000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c43000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio17: mdio@8c47000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c47000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > + pcs_mdio18: mdio@8c4b000 { > > > + compatible = "fsl,fman-memac-mdio"; > > > + reg = <0x0 0x8c4b000 0x0 0x1000>; > > > + little-endian; > > > + status = "disabled"; > > > + }; > > > + > > > > Please sort the nodes alphabetically. > > Huh? The nodes in this file are already sorted according to address, and this > patch preserves that sorting. The hex address field also happens to be > alphabetical. > > Or do you mean the label for these modes - I've never heard of sorting by label > for a SoC file. Uhh, I remember now. For some reason I thought this was a board file. Ioana [snip] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-26 21:26 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-17 14:49 [RFC net-next 0/2] split phylink PCS operations and add PCS support for dpaa2 Russell King - ARM Linux admin 2020-03-17 14:52 ` [RFC net-next 1/5] net: phylink: rename 'ops' to 'mac_ops' Russell King 2020-03-17 16:20 ` Andrew Lunn 2020-03-17 14:52 ` [RFC net-next 2/5] net: phylink: add separate pcs operations structure Russell King 2020-03-17 15:48 ` Jose Abreu 2020-03-17 15:56 ` Russell King - ARM Linux admin 2020-03-17 16:04 ` Jose Abreu 2020-03-17 16:52 ` Russell King - ARM Linux admin 2020-03-18 7:45 ` Jose Abreu 2020-03-19 11:14 ` Russell King - ARM Linux admin 2020-03-20 9:55 ` Jose Abreu 2020-03-17 16:38 ` Andrew Lunn 2020-03-17 16:54 ` Russell King - ARM Linux admin 2020-03-19 12:14 ` Russell King - ARM Linux admin 2020-03-19 15:06 ` Andrew Lunn 2020-03-19 17:20 ` Russell King - ARM Linux admin 2020-03-19 20:59 ` Russell King - ARM Linux admin 2020-03-24 19:46 ` Russell King - ARM Linux admin 2020-03-17 14:52 ` [RFC net-next 3/5] arm64: dts: lx2160a: add PCS MDIO nodes Russell King 2020-03-26 21:14 ` Ioana Ciornei 2020-03-26 21:14 ` Ioana Ciornei 2020-03-26 21:21 ` Russell King - ARM Linux admin 2020-03-26 21:21 ` Russell King - ARM Linux admin 2020-03-26 21:26 ` Ioana Ciornei [this message] 2020-03-26 21:26 ` Ioana Ciornei 2020-03-17 14:53 ` [RFC net-next 4/5] dpaa2-mac: add 1000BASE-X/SGMII PCS support Russell King 2020-03-26 22:09 ` Ioana Ciornei 2020-03-17 14:53 ` [RFC net-next 5/5] dpaa2-mac: add 10GBASE-R " Russell King 2020-03-26 14:57 ` [RFC net-next 0/2] split phylink PCS operations and add PCS support for dpaa2 Russell King - ARM Linux admin 2020-03-26 14:57 ` Russell King - ARM Linux admin 2020-03-26 15:04 ` Andrew Lunn 2020-03-26 15:04 ` Andrew Lunn 2020-03-26 15:14 ` [PATCH " Russell King - ARM Linux admin 2020-03-30 4:57 ` David Miller 2020-03-30 8:44 ` Russell King - ARM Linux admin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=DB8PR04MB682817485CBD1EFA1AA179F1E0CF0@DB8PR04MB6828.eurprd04.prod.outlook.com \ --to=ioana.ciornei@nxp.com \ --cc=andrew@lunn.ch \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=f.fainelli@gmail.com \ --cc=hkallweit1@gmail.com \ --cc=leoyang.li@nxp.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux@armlinux.org.uk \ --cc=mark.rutland@arm.com \ --cc=netdev@vger.kernel.org \ --cc=robh+dt@kernel.org \ --cc=shawnguo@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.