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] [day] [month] [year] [list]

Date:   Mon, 19 Mar 2018 21:39:23 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Russell King <rmk+kernel@...linux.org.uk>,
        "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 Mon, Mar 19, 2018 at 12:20:32PM -0700, Florian Fainelli wrote:
> On 12/17/2017 06:48 AM, 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?
> 
> Considering the negative diffstat and the fact that it solves real
> problems for you, I would say yes.

We have also received a bunch of patches removing the phydev pointer
for driver private structures and making use of the net_device one. It
would be nice to avoid the same with phylink.

      Andrew