Messages in this thread |  | | Date | Tue, 21 Aug 2018 11:32:46 +0200 | From | Michal Kubecek <> | Subject | Re: [RFC PATCH net-next v2 10/17] ethtool: implement GET_SETTINGS message |
| |
On Mon, Jul 30, 2018 at 08:54:55PM +0200, Andrew Lunn wrote: > > +/* Internal kernel helper to query a device ethtool_link_settings. > > + * > > + * Backward compatibility note: for compatibility with legacy drivers > > + * that implement only the ethtool_cmd API, this has to work with both > > + * drivers implementing get_link_ksettings API and drivers > > + * implementing get_settings API. When drivers implement get_settings > > + * and report ethtool_cmd deprecated fields > > + * (transceiver/maxrxpkt/maxtxpkt), these fields are silently ignored > > + * because the resulting struct ethtool_link_settings does not report them. > > ~/linux/drivers$ grep -r [.]get_settings * > net/ethernet/8390/etherh.c: .get_settings = etherh_get_settings, > > I don't think it is worth adding support for .get_settings for just > one driver. It is better to just convert that driver to the new API.
I have prepared a patch converting 8390/etherh driver to use {g,s}et_link_ksettings and I'm going to submit it when net-next opens. Do you think we can then drop {g,s}et_settings callbacks completely (i.e. also from ioctl() code and ethtool_ops)? Do we care about unconverted out of tree drivers?
Michal Kubecek
|  |