netdev - Re: [RFC net-next] sfp/phylink: move module EEPROM ethtool access into netdev core ethtool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171217182922.GB29596@lunn.ch>
Date:   Sun, 17 Dec 2017 19:29:22 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Russell King <rmk+kernel@...linux.org.uk>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC net-next] sfp/phylink: move module EEPROM ethtool access
 into netdev core ethtool

On Sun, Dec 17, 2017 at 02:48:27PM +0000, Russell King wrote:
> Provide a pointer to the SFP bus in struct net_device, so that the
> ethtool module EEPROM methods can access the SFP directly, rather
> than needing every user to provide a hook for it.
> 
> Signed-off-by: Russell King <rmk+kernel@...linux.org.uk>
> ---
> Questions:
> 1. Is it worth adding a pointer to struct net_device for these two
>    methods, rather than having multiple duplicate veneers to vector
>    the ethtool module EEPROM ioctls through to the SFP bus layer?
> 
> 2. Should this allow network/phy drivers to override the default -
>    the code is currently structured to allow phy drivers to override
>    network drivers implementations, which seems the wrong way around.

Hi Russell

Looking at drivers which implement reading the EEPROM, very few of
them expose the i2c bus, as a linux i2c bus. They seem to send
commands off to the firmware, and have it return a block of data.  So
converting to using the generic SFP code is not going to be too easy.

Probably a low hanging fruit is to expose a few library like functions
for parsing the EEPROM data. As you said, there seems to be a few bugs
in the drivers with respect to actually interpreting the data. So
having one central implementation, without bugs, would be good.

Rather than adding the sfp bus to net_device, i think phylink will get
more use. And the default implementation of these methods can look at
the phylink to see if there is an sfp device. We are unlikely to be
able to replace phydev with phylink, but maybe all new 10Gbps PHY and
fibre modules not hidden behind firmware could use phylink? So having
phylink in net_device could make sense. There has been a move to
remove phydev from the drivers private structure and use the one in
net_device. Maybe we should do the same for phylink?

    Andrew