Re: dsa: using multi-gbps speeds on CPU port

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hi Andrew,

On Wed, 15 May 2019 15:27:01 +0200
Andrew Lunn <andrew@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.

Ok I see what you mean, this would allow us to get rid of the phydev
built from the fixed-link, and the .adjust_link call. I'll prototype
that, thanks for the hint.

>On the master interface, the armada 8040, eth0, you still need
>something. However, if you look at phylink_parse_fixedlink(), it puts
>the speed etc into a phylink_link_state. It never instantiates a
>fixed-phy. So i think that could be expanded to support higher speeds
>without too much trouble. The interesting part is the IOCTL handler.

Yes I'm not too worried about that part, unless I missed something this
shouldn't be too problematic.

Once again, thanks for your help,

Maxime