From: Danielle Ratson <danieller@nvidia.com>
To: <netdev@vger.kernel.org>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<pabeni@redhat.com>, <corbet@lwn.net>, <linux@armlinux.org.uk>,
<sdf@google.com>, <kory.maincent@bootlin.com>,
<maxime.chevallier@bootlin.com>, <vladimir.oltean@nxp.com>,
<przemyslaw.kitszel@intel.com>, <ahmed.zaki@intel.com>,
<richardcochran@gmail.com>, <shayagr@amazon.com>,
<paul.greenwalt@intel.com>, <jiri@resnulli.us>,
<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<mlxsw@nvidia.com>, <petrm@nvidia.com>, <idosch@nvidia.com>,
<danieller@nvidia.com>
Subject: [PATCH net-next v5 01/10] ethtool: Add ethtool operation to write to a transceiver module EEPROM
Date: Wed, 24 Apr 2024 16:30:14 +0300 [thread overview]
Message-ID: <20240424133023.4150624-2-danieller@nvidia.com> (raw)
In-Reply-To: <20240424133023.4150624-1-danieller@nvidia.com>
From: Ido Schimmel <idosch@nvidia.com>
Ethtool can already retrieve information from a transceiver module
EEPROM by invoking the ethtool_ops::get_module_eeprom_by_page operation.
Add a corresponding operation that allows ethtool to write to a
transceiver module EEPROM.
The new write operation is purely an in-kernel API and is not exposed to
user space.
The purpose of this operation is not to enable arbitrary read / write
access, but to allow the kernel to write to specific addresses as part
of transceiver module firmware flashing. In the future, more
functionality can be implemented on top of these read / write
operations.
Adjust the comments of the 'ethtool_module_eeprom' structure as it is
no longer used only for read access.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Danielle Ratson <danieller@nvidia.com>
---
include/linux/ethtool.h | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 6fd9107d3cc0..fa1a5d0e3213 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -504,17 +504,16 @@ struct ethtool_ts_stats {
#define ETH_MODULE_MAX_I2C_ADDRESS 0x7f
/**
- * struct ethtool_module_eeprom - EEPROM dump from specified page
- * @offset: Offset within the specified EEPROM page to begin read, in bytes.
- * @length: Number of bytes to read.
- * @page: Page number to read from.
- * @bank: Page bank number to read from, if applicable by EEPROM spec.
+ * struct ethtool_module_eeprom - plug-in module EEPROM read / write parameters
+ * @offset: When @offset is 0-127, it is used as an address to the Lower Memory
+ * (@page must be 0). Otherwise, it is used as an address to the
+ * Upper Memory.
+ * @length: Number of bytes to read / write.
+ * @page: Page number.
+ * @bank: Bank number, if supported by EEPROM spec.
* @i2c_address: I2C address of a page. Value less than 0x7f expected. Most
* EEPROMs use 0x50 or 0x51.
* @data: Pointer to buffer with EEPROM data of @length size.
- *
- * This can be used to manage pages during EEPROM dump in ethtool and pass
- * required information to the driver.
*/
struct ethtool_module_eeprom {
u32 offset;
@@ -822,6 +821,8 @@ struct ethtool_rxfh_param {
* @get_module_eeprom_by_page: Get a region of plug-in module EEPROM data from
* specified page. Returns a negative error code or the amount of bytes
* read.
+ * @set_module_eeprom_by_page: Write to a region of plug-in module EEPROM,
+ * from kernel space only. Returns a negative error code or zero.
* @get_eth_phy_stats: Query some of the IEEE 802.3 PHY statistics.
* @get_eth_mac_stats: Query some of the IEEE 802.3 MAC statistics.
* @get_eth_ctrl_stats: Query some of the IEEE 802.3 MAC Ctrl statistics.
@@ -956,6 +957,9 @@ struct ethtool_ops {
int (*get_module_eeprom_by_page)(struct net_device *dev,
const struct ethtool_module_eeprom *page,
struct netlink_ext_ack *extack);
+ int (*set_module_eeprom_by_page)(struct net_device *dev,
+ const struct ethtool_module_eeprom *page,
+ struct netlink_ext_ack *extack);
void (*get_eth_phy_stats)(struct net_device *dev,
struct ethtool_eth_phy_stats *phy_stats);
void (*get_eth_mac_stats)(struct net_device *dev,
--
2.43.0
next prev parent reply other threads:[~2024-04-24 13:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 13:30 [PATCH net-next v5 00/10] Add ability to flash modules' firmware Danielle Ratson
2024-04-24 13:30 ` Danielle Ratson [this message]
2024-04-24 13:30 ` [PATCH net-next v5 02/10] mlxsw: Implement ethtool operation to write to a transceiver module EEPROM Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 03/10] ethtool: Add an interface for flashing transceiver modules' firmware Danielle Ratson
2024-04-30 2:14 ` Jakub Kicinski
2024-04-24 13:30 ` [PATCH net-next v5 04/10] ethtool: Add flashing transceiver modules' firmware notifications ability Danielle Ratson
2024-04-30 3:11 ` Jakub Kicinski
2024-04-30 18:11 ` Danielle Ratson
2024-04-30 20:03 ` Jakub Kicinski
2024-05-01 7:53 ` Ido Schimmel
2024-05-01 14:37 ` Jakub Kicinski
2024-05-22 13:08 ` Danielle Ratson
2024-05-22 13:45 ` Jakub Kicinski
2024-05-22 13:56 ` Danielle Ratson
2024-05-22 14:22 ` Jakub Kicinski
2024-04-24 13:30 ` [PATCH net-next v5 05/10] include: netdevice: Add module firmware flashing in progress flag to net_device Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 06/10] net: sfp: Add more extended compliance codes Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 07/10] ethtool: cmis_cdb: Add a layer for supporting CDB commands Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 08/10] ethtool: cmis_fw_update: add a layer for supporting firmware update using CDB Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 09/10] ethtool: Add ability to flash transceiver modules' firmware Danielle Ratson
2024-04-30 3:22 ` Jakub Kicinski
2024-04-24 13:30 ` [PATCH net-next v5 10/10] ethtool: Veto some operations during firmware flashing process Danielle Ratson
2024-04-30 3:23 ` Jakub Kicinski
2024-04-30 17:48 ` Danielle Ratson
2024-04-30 18:01 ` Jakub Kicinski
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=20240424133023.4150624-2-danieller@nvidia.com \
--to=danieller@nvidia.com \
--cc=ahmed.zaki@intel.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=jiri@resnulli.us \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paul.greenwalt@intel.com \
--cc=petrm@nvidia.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=richardcochran@gmail.com \
--cc=sdf@google.com \
--cc=shayagr@amazon.com \
--cc=vladimir.oltean@nxp.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).