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.faine...@gmail.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 <and...@lunn.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. -- Florian
