[lkml]   [2016]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH net-next v8 05/19] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API
Sure, I will send an update:

struct ethtool_link_settings {
__u32 cmd;
__u32 speed;
__u8 duplex;
__u8 port;
__u8 phy_address;
__u8 autoneg;
__u8 mdio_support;
__u8 eth_tp_mdix;
__u8 eth_tp_mdix_ctrl;
__s8 link_mode_masks_nwords;
__u32 reserved[8];
__u32 link_mode_masks[0];

(+ same renaming for the ioctl sub-cmds)

that would still replace GSET/SSET/ethtool_cmd.

would that be ok?

Or, just to make sure: would you rather keep GSET/SSET/ethtool_cmd as
now for everything but the link mode masks (that would be marked as
deprecated), and have only a new command G/SLINK_MODES + struct
ethtool_link_mode_support that would only take care of the link mode

On Fri, Feb 12, 2016 at 5:49 PM, Ben Hutchings <> wrote:
> On Tue, 2016-02-09 at 16:29 -0800, David Decotigny wrote:
>> From: David Decotigny <>
>> This patch defines a new ETHTOOL_GSETTINGS/SSETTINGS API, handled by
>> the new get_ksettings/set_ksettings callbacks. This API provides
>> support for most legacy ethtool_cmd fields, adds support for larger
>> link mode masks (up to 4064 bits, variable length), and removes
>> ethtool_cmd deprecated fields (transceiver/maxrxpkt/maxtxpkt).
> [...]
> I previously asked you to include 'link' in the command names and
> structure name. This would clarify that these are now only for link
> settings and reduce the risk of confusion between old and new commands.
> However, you didn't reply to that review. Do you have any objection to
> doing this?
> Ben.
> --
> Ben Hutchings
> Sturgeon's Law: Ninety percent of everything is crap.

 \ /
  Last update: 2016-02-18 21:01    [W:0.144 / U:45.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site