Thread (6 messages) 6 messages, 4 authors, 2018-03-19

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

flat view

From: Andrew Lunn <andrew@lunn.ch>
Date: 2018-03-19 20:39:34

On Mon, Mar 19, 2018 at 12:20:32PM -0700, Florian Fainelli wrote:
On 12/17/2017 06:48 AM, Russell King wrote:
quoted
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 <redacted>
---
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help