Date:   Fri, 17 May 2019 19:23:39 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Ioana Ciornei <ioana.ciornei@....com>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vladimir Oltean <olteanv@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: dsa: using multi-gbps speeds on CPU port

On Fri, May 17, 2019 at 11:10:10AM -0700, Florian Fainelli wrote:
> On 5/17/19 11:03 AM, Russell King - ARM Linux admin wrote:
> > On Fri, May 17, 2019 at 05:37:00PM +0000, Ioana Ciornei wrote:
> >>> Subject: Re: dsa: using multi-gbps speeds on CPU port
> >>>
> >>> Hi everyone,
> >>>
> >>> On Wed, 15 May 2019 09:09:26 -0700
> >>> Florian Fainelli <f.fainelli@...il.com> wrote:
> >>>
> >>>> On 5/15/19 7:02 AM, Maxime Chevallier wrote:
> >>>>> Hi Andrew,
> >>>>>
> >>>>> On Wed, 15 May 2019 15:27:01 +0200
> >>>>> Andrew Lunn <andrew@...n.ch> wrote:
> >>>>>
> >>>>>> I think you are getting your terminology wrong. 'master' is eth0 in
> >>>>>> the example you gave above. CPU and DSA ports don't have netdev
> >>>>>> structures, and so any PHY used with them is not corrected to a
> >>>>>> netdev.
> >>>>>
> >>>>> Ah yes sorry, I'm still in the process of getting familiar with the
> >>>>> internals of DSA :/
> >>>>>
> >>>>>>> I'll be happy to help on that, but before prototyping anything, I wanted
> >>>>>>> to have your thougts on this, and see if you had any plans.
> >>>>>>
> >>>>>> There are two different issues here.
> >>>>>>
> >>>>>> 1) Is using a fixed-link on a CPU or DSA port the right way to do this?
> >>>>>> 2) Making fixed-link support > 1G.
> >>>>>>
> >>>>>> The reason i decided to use fixed-link on CPU and DSA ports is that
> >>>>>> we already have all the code needed to configure a port, and an API
> >>>>>> to do it, the adjust_link() callback. Things have moved on since
> >>>>>> then, and we now have an additional API, .phylink_mac_config(). It
> >>>>>> might be better to directly use that. If there is a max-speed
> >>>>>> property, create a phylink_link_state structure, which has no
> >>>>>> reference to a netdev, and pass it to .phylink_mac_config().
> >>>>>>
> >>>>>> It is just an idea, but maybe you could investigate if that would
> >>>>>> work.
> >>>
> >>> I've quickly prototyped and tested this solution, and besides a few tweaks that
> >>> are needed on the mv88e6xxx driver side, it works fine.
> >>>
> >>> I'll post an RFC with this shortly, so that you can see what it looks like.
> >>>
> >>> As Russell said, there wasn't anything needed on the master interface side.
> >>>
> >>>>
> >>>> Vladimir mentioned a few weeks ago that he is considering adding
> >>>> support for PHYLIB and PHYLINK to run without a net_device instance,
> >>>> you two should probably coordinate with each other and make sure both
> >>>> of your requirements (which are likely the same) get addressed.
> >>>
> >>> That would help a lot solving this issue indeed, I'll be happy to help on that,
> >>> thanks for the tip !
> >>>
> >>> Maxime
> >>>
> >>
> >> Hi Maxime,
> >>
> >> I am currently maintaining some drivers for Freescale/NXP DPAA2 Ethernet. This architecture has a management firmware that abstracts and simplifies the hardware configuration into a so called object model. DPAA2 is a little too modular and you have the concept of a network interface object (DPNI) which is completely self-contained and separate from the hardware port itself (DPMAC). You can connect DPNIs to DPMACs but also DPNIs to one another. The dpaa2-eth driver conceptually handles a DPNI object. Among other things, the management firmware presents the link state information to the DPNI object as abstract as possible (speed, duplex, up/down etc.). The firmware gathers this information from whomever the DPNI is connected to. Since the firmware can't reuse Linux PHY drivers due to incompatible licensing, we need another driver which acts as glue logic between the PHY drivers and the firmware. This is the out-of-tree dpmac driver that notifies the firmware of any external PHY events. At the end of the day, the dpaa2-eth driver gets notified of these external PHY events after the firmware itself is notified and raises an interrupt line. 
> >>
> >> To start the PHY state machine for a port, the dpmac driver must fabricate a netdevice which it does not register with the stack. One would, of course, suggest to move the PHY management directly into the dpaa2-eth driver. But the firmware's ABI is already stable and besides, it is not desirable to grant MDIO access to users of the DPNI object.
> >>
> >> Obviously, that fake netdevice has to go before the dpmac driver sees mainline. What you guys are proposing (the phylink/netdev decoupling) would also benefit our scenario. I talked to Vladimir and we'll make sure that whatever works for us is also benefiting the DSA cpu/cascade port. Hopefully we'll have some patches early next week.
> > 
> > For SFP, I've already removed much of the netdev bits from that layer,
> > but I don't see any way to really get rid of it from phylink - we need
> > access to the netdev state there to know what the carrier state is for
> > the netdev (phylink tracks that state and manages the carrier state on
> > behalf of the MAC driver.)
> 
> We can make that a callback that is optional in case you want to use a
> PHYLINK instance without a backing net_device. If you pass a valid
> net_device pointer, then we default to netif_carrier_ok(), else the
> caller of phylink_create() (which would have to be renamed, or exposed
> with an additional argument, say phylink_create_cb()) needs to provide it.

You'll need:
- a callback to set the carrier state
- a callback to get the current carrier state

at the very least.

Then there's all the netdev printing functions that would have to be
converted to something (which really ought to keep staying which
Linux interface they're referring to).  Given that we are called
before the netdev has a name, and using the device struct isn't
sufficient, I don't see an easy solution to that.  We need it,
especially as we have boards with multiple ethernet devices using
this, so the information that phylink prints has to be meaningful.
Using the parent device is _painful_ so doesn't hack it - and we
have situations where we have multiple ethernet devices for one
parent device.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Powered by blists - more mailing lists