mbox series

[RESEND,net-next,v3,0/3] net: enetc: remove bootloader dependency

Message ID 20200701213433.9217-1-michael@walle.cc
Headers show
Series net: enetc: remove bootloader dependency | expand

Message

Michael Walle July 1, 2020, 9:34 p.m. UTC
This is a resend of the series because the conversion to the phylink
interface will likely take longer:
https://lore.kernel.org/netdev/CA+h21hpBodyY8CtNH2ktRdc2FqPi=Fjp94=VVZvzSVbnvnfKVg@mail.gmail.com/
Unfortunately, we have boards in the wild with a bootloader which doesn't
set the PCS up correctly. Thus I'd really see this patches picked up as an
intermediate step until the phylink conversion is ready. Vladimir Oltean
already offered to convert enetc to phylink when he converts the felix to
phylink. After this series the PCS setup of the enetc looks almost the same
as the current felix setup. Thus conversion should be easy.

These patches were picked from the following series:
https://lore.kernel.org/netdev/1567779344-30965-1-git-send-email-claudiu.manoil@nxp.com/
They have never been resent. I've picked them up, addressed Andrews
comments, fixed some more bugs and asked Claudiu if I can keep their SOB
tags; he agreed. I've tested this on our board which happens to have a
bootloader which doesn't do the enetc setup in all cases. Though, only
SGMII mode was tested.

changes since v2:
 - removed SOBs from "net: enetc: Initialize SerDes for SGMII and USXGMII
   protocols" because almost everything has changed.
 - get a phy_device for the internal PCS PHY so we can use the phy_
   functions instead of raw mdiobus writes
 - reuse macros already defined in fsl_mdio.h, move missing bits from
   felix to fsl_mdio.h, because they share the same PCS PHY building
   block
 - added 2500BaseX mode (based on felix init routine)
 - changed xgmii mode to usxgmii mode, because it is actually USXGMII and
   felix does the same.
 - fixed devad, which is 0x1f (MMD_VEND2)

changes since v1:
 - mdiobus id is '"imdio-%s", dev_name(dev)' because the plain dev_name()
   is used by the emdio.
 - use mdiobus_write() instead of imdio->write(imdio, ..), since this is
   already a full featured mdiobus
 - set phy_mask to ~0 to avoid scanning the bus
 - use phy_interface_mode_is_rgmii(phy_mode) to also include the RGMII
   modes with pad delays.
 - move enetc_imdio_init() to enetc_pf.c, there shouldn't be any other
   users, should it?
 - renamed serdes to SerDes
 - printing the error code of mdiobus_register() in the error path
 - call mdiobus_unregister() on _remove()
 - call devm_mdiobus_free() if mdiobus_register() fails, since an
   error is not fatal

Alex Marginean (1):
  net: enetc: Use DT protocol information to set up the ports

Michael Walle (2):
  net: dsa: felix: move USXGMII defines to common place
  net: enetc: Initialize SerDes for SGMII and USXGMII protocols

 drivers/net/dsa/ocelot/felix_vsc9959.c        |  21 --
 .../net/ethernet/freescale/enetc/enetc_hw.h   |   3 +
 .../net/ethernet/freescale/enetc/enetc_pf.c   | 191 +++++++++++++++---
 .../net/ethernet/freescale/enetc/enetc_pf.h   |   5 +
 include/linux/fsl/enetc_mdio.h                |  19 ++
 5 files changed, 194 insertions(+), 45 deletions(-)

Comments

Russell King (Oracle) July 1, 2020, 9:53 p.m. UTC | #1
On Wed, Jul 01, 2020 at 11:34:30PM +0200, Michael Walle wrote:
> This is a resend of the series because the conversion to the phylink
> interface will likely take longer:
> https://lore.kernel.org/netdev/CA+h21hpBodyY8CtNH2ktRdc2FqPi=Fjp94=VVZvzSVbnvnfKVg@mail.gmail.com/

I don't think it will; I've given people notice of potential changes
back in February, and as Florian has pointed out, that's ample enough
time that it's now no problem if I push my series and it causes
breakage to drivers that haven't updated.  I've also gone way beyond
what would normally be done, fixing up almost every driver the best
I can with the exception of two - felix DSA and Mediatek.

Some of the patches have been reviewed already, Ioana at NXP is happy
with them.  There's a bit of tweaking of a couple of patches and
adding some documentation, and then they're good to go.

I'm not going to wait for Felix or Mediatek.  As I say, I've given
plenty of warning, and it's only a _suspicion_ of breakage on my
side.
Vladimir Oltean July 1, 2020, 10:04 p.m. UTC | #2
On Thu, 2 Jul 2020 at 00:53, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> fixing up almost every driver the best I can with the exception of two -
> felix DSA and Mediatek.
>
> I'm not going to wait for Felix or Mediatek.  As I say, I've given
> plenty of warning, and it's only a _suspicion_ of breakage on my
> side.
>

What do you mean "I'm not going to wait for Felix"?
https://patchwork.ozlabs.org/project/netdev/patch/20200625152331.3784018-5-olteanv@gmail.com/
We left it at:

> I'm not going to review patch 7
> tonight because of this fiasco.  To pissed off to do a decent job, so
> you're just going to have to wait.

So, I was actively waiting for you to review it ever since, just like
you said, so I could send a v2. Were you waiting for anything?

Thank you,
-Vladimir
Russell King (Oracle) July 2, 2020, 8:41 a.m. UTC | #3
On Thu, Jul 02, 2020 at 01:04:02AM +0300, Vladimir Oltean wrote:
> On Thu, 2 Jul 2020 at 00:53, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > fixing up almost every driver the best I can with the exception of two -
> > felix DSA and Mediatek.
> >
> > I'm not going to wait for Felix or Mediatek.  As I say, I've given
> > plenty of warning, and it's only a _suspicion_ of breakage on my
> > side.
> >
> 
> What do you mean "I'm not going to wait for Felix"?
> https://patchwork.ozlabs.org/project/netdev/patch/20200625152331.3784018-5-olteanv@gmail.com/
> We left it at:
> 
> > I'm not going to review patch 7
> > tonight because of this fiasco.  To pissed off to do a decent job, so
> > you're just going to have to wait.
> 
> So, I was actively waiting for you to review it ever since, just like
> you said, so I could send a v2. Were you waiting for anything?

I stopped being interested in your series with the patch 5 commit
description issue; what happened there is really demotivating.
Vladimir Oltean July 2, 2020, 9:41 a.m. UTC | #4
On Thu, 2 Jul 2020 at 11:41, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Thu, Jul 02, 2020 at 01:04:02AM +0300, Vladimir Oltean wrote:
> > On Thu, 2 Jul 2020 at 00:53, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > fixing up almost every driver the best I can with the exception of two -
> > > felix DSA and Mediatek.
> > >
> > > I'm not going to wait for Felix or Mediatek.  As I say, I've given
> > > plenty of warning, and it's only a _suspicion_ of breakage on my
> > > side.
> > >
> >
> > What do you mean "I'm not going to wait for Felix"?
> > https://patchwork.ozlabs.org/project/netdev/patch/20200625152331.3784018-5-olteanv@gmail.com/
> > We left it at:
> >
> > > I'm not going to review patch 7
> > > tonight because of this fiasco.  To pissed off to do a decent job, so
> > > you're just going to have to wait.
> >
> > So, I was actively waiting for you to review it ever since, just like
> > you said, so I could send a v2. Were you waiting for anything?
>
> I stopped being interested in your series with the patch 5 commit
> description issue; what happened there is really demotivating.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Yes, but I mean, the fact that reviewing felix is "demotivating" can
only have 2 courses of action as far as I can see:
- I do resubmit the series with feedback that you've given so far, but
it's likely going to take a few more iterations because you haven't
reviewed the current series in its entirety, and you haven't in fact
reviewed the part which you consider as a dependency for your work yet
(the mac_link_up conversion). But this goes against your argument that
the lynx pcs will land quickly, so Michael should just wait a little
bit more.
- As per your "I'm not going to wait for Felix or Mediatek" phrase,
you might decide you just don't deal with DSA any longer, and you
proceed with the PCS patches by essentially breaking the dependency.
In this case, I'm not sure why Michael would need to wait either,
since _you_ are deciding to not wait for DSA, neither is he.

I'm fine either way, but one thing is not going to change, and that's
the ordering of my patches in the "PHYLINK integration improvements
for Felix DSA driver" series. As you know, most NXP users are not
using David's net-next directly (and that is at their! request), but a
"vendor" kernel which we try to keep as close to David's tree as
humanly possible, and which goes through a lot of testing. But if
there are going to be treewide changes in the phylink API (and there
_are_ already, that mac_link_up thing, which we haven't backported),
then there needs to be a strict ordering relationship between the
cleanup commits, which we can cherry-pick, and the adaptation to an
API which we haven't (nor we intend to) backport to 5.4, because it's
too much for little practical benefit. You seem to be hung up on that,
and we won't be making much progress if that continues, I'm afraid.

There are a lot of things to be done that depend on the lynx-pcs
thing, and there are multiple groups of people who are all waiting.
The new seville DSA driver, which _almost_ got into the previous
release cycle but missed the train due to a dependency with Mark
Brown's tree, also has a Lynx PCS integrated in it. I would like to
reuse the lynx-pcs module, but from what I can see, the bottleneck for
everybody seems to be reviewing the mac_link_up conversion of felix.

Thank you,
-Vladimir
Russell King (Oracle) July 4, 2020, 10 a.m. UTC | #5
On Thu, Jul 02, 2020 at 12:41:39PM +0300, Vladimir Oltean wrote:
> On Thu, 2 Jul 2020 at 11:41, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Thu, Jul 02, 2020 at 01:04:02AM +0300, Vladimir Oltean wrote:
> > > On Thu, 2 Jul 2020 at 00:53, Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > fixing up almost every driver the best I can with the exception of two -
> > > > felix DSA and Mediatek.
> > > >
> > > > I'm not going to wait for Felix or Mediatek.  As I say, I've given
> > > > plenty of warning, and it's only a _suspicion_ of breakage on my
> > > > side.
> > > >
> > >
> > > What do you mean "I'm not going to wait for Felix"?
> > > https://patchwork.ozlabs.org/project/netdev/patch/20200625152331.3784018-5-olteanv@gmail.com/
> > > We left it at:
> > >
> > > > I'm not going to review patch 7
> > > > tonight because of this fiasco.  To pissed off to do a decent job, so
> > > > you're just going to have to wait.
> > >
> > > So, I was actively waiting for you to review it ever since, just like
> > > you said, so I could send a v2. Were you waiting for anything?
> >
> > I stopped being interested in your series with the patch 5 commit
> > description issue; what happened there is really demotivating.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> 
> Yes, but I mean, the fact that reviewing felix is "demotivating" can
> only have 2 courses of action as far as I can see:

Sigh. I give up with you.