[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200317141839.GT24270@lunn.ch>
Date: Tue, 17 Mar 2020 15:18:39 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH REPOST3 net-next 0/3] net: add phylink support for PCS
On Sat, Mar 14, 2020 at 10:44:59PM +0000, Russell King - ARM Linux admin wrote:
> On Sat, Mar 14, 2020 at 11:00:18PM +0100, Andrew Lunn wrote:
> > On Sat, Mar 14, 2020 at 10:31:02AM +0000, Russell King - ARM Linux admin wrote:
> > > Depends on "net: mii clause 37 helpers".
> > >
> > > This series adds support for IEEE 802.3 register set compliant PCS
> > > for phylink. In order to do this, we:
> > >
> > > 1. add accessors for modifying a MDIO device register, and use them in
> > > phylib, rather than duplicating the code from phylib.
> > > 2. add support for decoding the advertisement from clause 22 compatible
> > > register sets for clause 37 advertisements and SGMII advertisements.
> > > 3. add support for clause 45 register sets for 10GBASE-R PCS.
> >
> > Hi Russell
> >
> > How big is the patchset which actually makes use of this code? It is
> > normal to add helpers and at least one user in the same patchset. But
> > if that would make the patchset too big, there could be some leeway.
>
> The minimum is three patches:
>
> arm64: dts: lx2160a: add PCS MDIO nodes
> dpaa2-mac: add 1000BASE-X/SGMII PCS support
> dpaa2-mac: add 10GBASE-R PCS support
Hi Russell
Are the two dpaa2-mac changes safe without the DT changes? I guess
so. So it seems sensible to post a set of 5 patches.
> and, at the moment, depending on whether you want 1G or 10G speeds,
> changes to the board firmware to select the serdes group mode.
And this is where we start speculating. I guess a new firmware API
will be needed to allow for runtime selection of the serdes group
mode. But i guess such an API change would not invalidate the PCS
work? There is still likely to be two PCS. So it seems O.K. to merge
this, and then fix it up later to work with whatever is added to the
firmware. There is on KAPI involved here?
Andrew
Powered by blists - more mailing lists