From: "Marek Behún" <kabel@kernel.org>
To: Michal Kubecek <mkubecek@suse.cz>, netdev@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>,
Russell King <linux@armlinux.org.uk>,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: ethtool ioctl ABI: preferred way to expand uapi structure ethtool_eee for additional link modes?
Date: Thu, 4 Jan 2024 16:14:16 +0100 [thread overview]
Message-ID: <20240104161416.05d02400@dellmb> (raw)
Hello,
the legacy ioctls ETHTOOL_GSET and ETHTOOL_SSET, which pass structure
ethtool_cmd, were superseded by ETHTOOL_GLINKSETTINGS and
ETHTOOL_SLINKSETTINGS.
This was done because the original structure only contains 32-bit words
for supported, advertising and lp_advertising link modes. The new
structure ethtool_link_settings contains member
s8 link_mode_masks_nwords;
and a flexible array
__u32 link_mode_masks[];
in order to overcome this issue.
But currently we still have only legacy structure ethtool_eee for EEE
settings:
struct ethtool_eee {
__u32 cmd;
__u32 supported;
__u32 advertised;
__u32 lp_advertised;
__u32 eee_active;
__u32 eee_enabled;
__u32 tx_lpi_enabled;
__u32 tx_lpi_timer;
__u32 reserved[2];
};
Thus ethtool is unable to get/set EEE configuration for example for
2500base-T and 5000base-T link modes, which are now available in
several PHY drivers.
We can remedy this by either:
- adding another ioctl for EEE settings, as was done with the GSET /
SSET
- using the original ioctl, but making the structure flexible (we can
replace the reserved fields with information that the array is
flexible), i.e.:
struct ethtool_eee {
__u32 cmd;
__u32 supported;
__u32 advertised;
__u32 lp_advertised;
__u32 eee_active;
__u32 eee_enabled;
__u32 tx_lpi_enabled;
__u32 tx_lpi_timer;
s8 link_mode_masks_nwords; /* zero if legacy 32-bit link modes */
__u8 reserved[7];
__u32 link_mode_masks[];
/* filled in if link_mode_masks_nwords > 0, with layout:
* __u32 map_supported[link_mode_masks_nwords];
* __u32 map_advertised[link_mode_masks_nwords];
* __u32 map_lp_advertised[link_mode_masks_nwords];
*/
};
this way we will be left with another 7 reserved bytes for future (is
this enough?)
What would you prefer?
Marek
next reply other threads:[~2024-01-04 15:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 15:14 Marek Behún [this message]
2024-01-04 15:36 ` ethtool ioctl ABI: preferred way to expand uapi structure ethtool_eee for additional link modes? Andrew Lunn
2024-01-04 16:06 ` Heiner Kallweit
2024-01-04 16:21 ` Marek Behún
2024-01-04 16:39 ` Heiner Kallweit
2024-01-04 16:17 ` Maxime Chevallier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240104161416.05d02400@dellmb \
--to=kabel@kernel.org \
--cc=andrew@lunn.ch \
--cc=hkallweit1@gmail.com \
--cc=linux@armlinux.org.uk \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.