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