linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>
Subject: [RFC PATCH net-next 1/9] ethtool: Add ethtool operation to write to a transceiver module EEPROM
Date: Mon, 22 Jan 2024 10:45:22 +0200	[thread overview]
Message-ID: <20240122084530.32451-2-danieller@nvidia.com> (raw)
In-Reply-To: <20240122084530.32451-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 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>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
 include/linux/ethtool.h | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 325e0778e937..bb253d90352b 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -474,17 +474,14 @@ struct ethtool_rmon_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: Offset within the specified page, in bytes.
+ * @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;
@@ -789,6 +786,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.
+ *	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.
@@ -921,6 +920,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.40.1


  reply	other threads:[~2024-01-22  8:46 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22  8:45 [RFC PATCH net-next 0/9] Add ability to flash modules' firmware Danielle Ratson
2024-01-22  8:45 ` Danielle Ratson [this message]
2024-01-23 17:03   ` [RFC PATCH net-next 1/9] ethtool: Add ethtool operation to write to a transceiver module EEPROM Russell King (Oracle)
2024-01-24 13:10     ` Danielle Ratson
2024-01-25 20:26   ` Andrew Lunn
2024-01-25 20:45     ` Andrew Lunn
2024-01-30  7:43       ` Danielle Ratson
2024-01-31 11:51     ` Danielle Ratson
2024-01-22  8:45 ` [RFC PATCH net-next 2/9] mlxsw: Implement " Danielle Ratson
2024-01-22  8:45 ` [RFC PATCH net-next 3/9] ethtool: Add an interface for flashing transceiver modules' firmware Danielle Ratson
2024-01-23  1:37   ` Jakub Kicinski
2024-01-23  4:50   ` Jakub Kicinski
2024-01-23 13:34     ` Danielle Ratson
2024-01-23 15:53       ` Jakub Kicinski
2024-01-22  8:45 ` [RFC PATCH net-next 4/9] ethtool: Add flashing transceiver modules' firmware notifications ability Danielle Ratson
2024-01-22  8:45 ` [RFC PATCH net-next 5/9] include: netdevice: Add module firmware flashing in progress flag to net_device Danielle Ratson
2024-01-22  8:45 ` [RFC PATCH net-next 6/9] net: sfp: Add more extended compliance codes Danielle Ratson
2024-01-23 17:09   ` Russell King (Oracle)
2024-01-22  8:45 ` [RFC PATCH net-next 7/9] ethtool: cmis_cdb: Add a layer for supporting CDB commands Danielle Ratson
2024-01-22 10:31   ` Simon Horman
2024-01-22 14:35     ` Danielle Ratson
2024-01-22 20:03       ` Simon Horman
2024-01-23 17:17   ` Russell King (Oracle)
2024-01-30  7:55     ` Danielle Ratson
2024-01-22  8:45 ` [RFC PATCH net-next 8/9] ethtool: cmis_fw_update: add a layer for supporting firmware update using CDB Danielle Ratson
2024-01-23  4:44   ` Jakub Kicinski
2024-01-23 12:08     ` Danielle Ratson
2024-01-23  5:07   ` Jakub Kicinski
2024-01-22  8:45 ` [RFC PATCH net-next 9/9] ethtool: Add ability to flash transceiver modules' firmware Danielle Ratson
2024-01-22 10:37   ` Simon Horman
2024-01-22 15:25     ` Danielle Ratson
2024-01-23  5:05   ` Jakub Kicinski
2024-01-23 13:05     ` Danielle Ratson
2024-01-23 15:49       ` Jakub Kicinski
2024-01-24 15:46         ` Danielle Ratson
2024-01-24 17:06           ` Jakub Kicinski
2024-01-23 16:27   ` Russell King (Oracle)
2024-01-24 13:11     ` Danielle Ratson
2024-01-25 21:03   ` Andrew Lunn
2024-01-31 15:48     ` Danielle Ratson
2024-01-31 15:52       ` Danielle Ratson
2024-01-31 16:30         ` Andrew Lunn
2024-04-08 12:50         ` Danielle Ratson
2024-04-08 23:53           ` Andrew Lunn

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=20240122084530.32451-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 NNTP newsgroup(s).