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