Re: [PATCH REPOST3 net-next 0/3] net: add phylink support for PCS

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Tue, Mar 17, 2020 at 03:18:39PM +0100, Andrew Lunn wrote:
> 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.

That would need to be tested; it hasn't yet been tested to prove
that nothing breaks as a result.

> > 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.

It is not speculation, what I've said is factual.  "At the moment"
describes the present situation.  If it was any different, then the
discussions that are going on between SolidRun and NXP would have
been over very quickly.  This was raised back in December, and
conference calls are still on-going on this issue, so that's about
four months so far.

There is also some evidence that if we attempt to reprogram the
Serdes PLLs at runtime, that will raise an exception and completely
reset the chip. There is also some evidence that experimenting with
changing the setup somehow bricked one of the Honeycomb boards.

So no, what I've said is not speculation.

The fact is that today, I need two different firmware images, one for
1G speeds and another for 10G speeds on _all_ the SFP+/QSFP+ cages -
it's either all at 1G or all at 10G.  This is due to the "reset
configuration word" block that is loaded from boot media at reset time
to configure the hardware.

Even different RAM speeds need different RCW contents and therefore
different firmware.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up