Ethtool supports module EEPROM dumps via the `ethtool -m <dev>` command.
But in current state its functionality is limited - offset and length
parameters, which are used to specify a linear desired region of EEPROM
data to dump, is not enough, considering emergence of complex module
EEPROM layouts such as CMIS 4.0.
Moreover, CMIS 4.0 extends the amount of pages that may be accessible by
introducing another parameter for page addressing - banks.
Besides, currently module EEPROM is represented as a chunk of
concatenated pages, where lower 128 bytes of all pages, except page 00h,
are omitted. Offset and length are used to address parts of this fake
linear memory. But in practice drivers, which implement
get_module_info() and get_module_eeprom() ethtool ops still calculate
page number and set I2C address on their own.
This series tackles these issues by adding ethtool op, which allows to
pass page number, bank number and I2C address in addition to offset and
length parameters to the driver, adds corresponding netlink
infrastructure and implements the new interface in mlx5 driver.
This allows to extend userspace 'ethtool -m' CLI by adding new
parameters - page, bank and i2c. New command line format:
ethtool -m <dev> [hex on|off] [raw on|off] [offset N] [length N] [page N] [bank N] [i2c N]
The consequence of this series is a possibility to dump arbitrary EEPROM
page at a time, in contrast to dumps of concatenated pages. Therefore,
offset and length change their semantics and may be used only to specify
a part of data within a page, which size is currently limited to 256
bytes.
As for backwards compatibility with get_module_info() and
get_module_eeprom() pair, the series addresses it as well by
implementing a fallback mechanism. As mentioned earlier, drivers derive
a page number from 'global' offset, so this can be done vice versa
without their involvement thanks to standardization. If kernel netlink
handler of 'ethtool -m' command detects that new ethtool op is not
supported by the driver, it calculates offset from given page number and
page offset and calls old ndos, if they are available.
Change log:
v1 -> v2:
- Limited i2c_address values by 127
- Added page bound check for offset and length
- Added defines for these two points
- Added extack to ndo parameters
- Moved ethnl_ops_begin(dev) and set error path accordingly
Vladyslav Tarasiuk (5):
ethtool: Allow network drivers to dump arbitrary EEPROM data
net/mlx5: Refactor module EEPROM query
net/mlx5: Implement get_module_eeprom_data_by_page()
net/mlx5: Add support for DSFP module EEPROM dumps
ethtool: Add fallback to get_module_eeprom from netlink command
.../ethernet/mellanox/mlx5/core/en_ethtool.c | 42 +++
.../net/ethernet/mellanox/mlx5/core/port.c | 101 ++++++--
include/linux/ethtool.h | 7 +-
include/linux/mlx5/port.h | 12 +
include/uapi/linux/ethtool.h | 26 ++
include/uapi/linux/ethtool_netlink.h | 19 ++
net/ethtool/Makefile | 2 +-
net/ethtool/eeprom.c | 239 ++++++++++++++++++
net/ethtool/netlink.c | 10 +
net/ethtool/netlink.h | 2 +
10 files changed, 430 insertions(+), 30 deletions(-)
create mode 100644 net/ethtool/eeprom.c
--
2.18.2
From: Vladyslav Tarasiuk <redacted>
Define get_module_eeprom_data_by_page() ethtool callback and implement
netlink infrastructure.
get_module_eeprom_data_by_page() allows network drivers to dump a part
of module's EEPROM specified by page and bank numbers along with offset
and length. It is effectively a netlink replacement for
get_module_info() and get_module_eeprom() pair, which is needed due to
emergence of complex non-linear EEPROM layouts.
Signed-off-by: Vladyslav Tarasiuk <redacted>
---
include/linux/ethtool.h | 7 +-
include/uapi/linux/ethtool.h | 26 +++++
include/uapi/linux/ethtool_netlink.h | 19 ++++
net/ethtool/Makefile | 2 +-
net/ethtool/eeprom.c | 157 +++++++++++++++++++++++++++
net/ethtool/netlink.c | 10 ++
net/ethtool/netlink.h | 2 +
7 files changed, 221 insertions(+), 2 deletions(-)
create mode 100644 net/ethtool/eeprom.c
@@ -81,6 +81,7 @@ enum {#define ETH_RSS_HASH_NO_CHANGE 0structnet_device;+structnetlink_ext_ack;/* Some generic methods drivers may use in their ethtool_ops */u32ethtool_op_get_link(structnet_device*dev);
@@ -428,6 +428,39 @@ int mlx5_query_module_eeprom(struct mlx5_core_dev *dev,}EXPORT_SYMBOL_GPL(mlx5_query_module_eeprom);+intmlx5_query_module_eeprom_data(structmlx5_core_dev*dev,+structmlx5_module_eeprom_query_params*params,+u8*data)+{+u8module_id;+interr;++err=mlx5_query_module_num(dev,¶ms->module_number);+if(err)+returnerr;++err=mlx5_query_module_id(dev,params->module_number,&module_id);+if(err)+returnerr;++if(module_id!=MLX5_MODULE_ID_SFP&&+module_id!=MLX5_MODULE_ID_QSFP&&+module_id!=MLX5_MODULE_ID_QSFP28&&+module_id!=MLX5_MODULE_ID_QSFP_PLUS){+mlx5_core_err(dev,"Module ID not recognized: 0x%x\n",module_id);+return-EINVAL;+}++if(params->i2c_address!=MLX5_I2C_ADDR_HIGH&&+params->i2c_address!=MLX5_I2C_ADDR_LOW){+mlx5_core_err(dev,"I2C address not recognized: 0x%x\n",params->i2c_address);+return-EINVAL;+}++returnmlx5_query_mcia(dev,params,data);+}+EXPORT_SYMBOL_GPL(mlx5_query_module_eeprom_data);+staticintmlx5_query_port_pvlc(structmlx5_core_dev*dev,u32*pvlc,intpvlc_size,u8local_port){
From: Vladyslav Tarasiuk <redacted>
Prepare for ethtool_ops::get_module_eeprom_data() implementation by
extracting common part of mlx5_query_module_eeprom() into a separate
function.
Signed-off-by: Vladyslav Tarasiuk <redacted>
---
.../net/ethernet/mellanox/mlx5/core/port.c | 79 +++++++++++--------
include/linux/mlx5/port.h | 9 +++
2 files changed, 54 insertions(+), 34 deletions(-)
From: Vladyslav Tarasiuk <redacted>
In case netlink get_module_eeprom_data_by_page() callback is not
implemented by the driver, try to call old get_module_info() and
get_module_eeprom() pair. Recalculate parameters to get_module_eeprom()
offset and len using page number and their sizes. Return error if
this can't be done.
Signed-off-by: Vladyslav Tarasiuk <redacted>
---
net/ethtool/eeprom.c | 84 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 83 insertions(+), 1 deletion(-)
@@ -446,7 +446,8 @@ int mlx5_query_module_eeprom_data(struct mlx5_core_dev *dev,if(module_id!=MLX5_MODULE_ID_SFP&&module_id!=MLX5_MODULE_ID_QSFP&&module_id!=MLX5_MODULE_ID_QSFP28&&-module_id!=MLX5_MODULE_ID_QSFP_PLUS){+module_id!=MLX5_MODULE_ID_QSFP_PLUS&&+module_id!=MLX5_MODULE_ID_DSFP){mlx5_core_err(dev,"Module ID not recognized: 0x%x\n",module_id);return-EINVAL;}
From: Don Bollinger <hidden> Date: 2021-03-05 00:57:31
On Thu, Mar 04, 2021 at 10:57AM-0800, Moshe Shemesh wrote:
Ethtool supports module EEPROM dumps via the `ethtool -m <dev>`
command.
But in current state its functionality is limited - offset and length
parameters,
which are used to specify a linear desired region of EEPROM data to dump,
is
not enough, considering emergence of complex module EEPROM layouts
such as CMIS 4.0.
Moreover, CMIS 4.0 extends the amount of pages that may be accessible by
introducing another parameter for page addressing - banks.
This is nice work, addressing the banks problem (though there are no devices
with bank switching yet?)
I suggest this change increase the maximum size of EEPROM to the maximum
the architecture allows. That's 256 pages (128 bytes) plus the lower page
for
a total of 257*256 bytes. SFP devices can access another 256 bytes since
they
use two i2c addresses but only one of them is paged. The size increase is
necessary for bank support since banked pages are all above the current
640 byte limit. Note that the SFF-* specs do not specify what is in pages
above page 3 (except CMIS), but they DO specify that those pages are
available for proprietary uses by module vendors. I will call out these
changes
in the following patches.
Ethtool also supports module 'change-eeprom', a write function mirroring the
dump function. That path needs to be implemented too. There are some
very interesting proprietary tricks that some modules can do by writing
the right magic to the right registers, some of which are on pages in the
0xF0 range.
Besides, currently module EEPROM is represented as a chunk of
concatenated pages, where lower 128 bytes of all pages, except page 00h,
are omitted. Offset and length are used to address parts of this fake
linear
memory. But in practice drivers, which implement
get_module_info() and get_module_eeprom() ethtool ops still calculate
page number and set I2C address on their own.
This series tackles these issues by adding ethtool op, which allows to
pass
page number, bank number and I2C address in addition to offset and length
parameters to the driver, adds corresponding netlink infrastructure and
implements the new interface in mlx5 driver.
This allows to extend userspace 'ethtool -m' CLI by adding new parameters
-
page, bank and i2c. New command line format:
ethtool -m <dev> [hex on|off] [raw on|off] [offset N] [length N] [page N]
[bank N] [i2c N]
The consequence of this series is a possibility to dump arbitrary EEPROM
page at a time, in contrast to dumps of concatenated pages. Therefore,
offset and length change their semantics and may be used only to specify a
part of data within a page, which size is currently limited to 256 bytes.
Just to be clear, if you define a page to be 256 bytes, and only specify
offset
within a page, then offset 0-127 is the same for every page on the device,
and useful offsets for each page start at 128. This can be confusing, but I
think it is the right approach.
As for backwards compatibility with get_module_info() and
get_module_eeprom() pair, the series addresses it as well by implementing
a fallback mechanism. As mentioned earlier, drivers derive a page number
from 'global' offset, so this can be done vice versa without their
involvement
thanks to standardization. If kernel netlink handler of 'ethtool -m'
command
detects that new ethtool op is not supported by the driver, it calculates
offset from given page number and page offset and calls old ndos, if they
are
available.
Change log:
v1 -> v2:
- Limited i2c_address values by 127
- Added page bound check for offset and length
- Added defines for these two points
- Added extack to ndo parameters
- Moved ethnl_ops_begin(dev) and set error path accordingly
Vladyslav Tarasiuk (5):
ethtool: Allow network drivers to dump arbitrary EEPROM data
net/mlx5: Refactor module EEPROM query
net/mlx5: Implement get_module_eeprom_data_by_page()
net/mlx5: Add support for DSFP module EEPROM dumps
ethtool: Add fallback to get_module_eeprom from netlink command
.../ethernet/mellanox/mlx5/core/en_ethtool.c | 42 +++
.../net/ethernet/mellanox/mlx5/core/port.c | 101 ++++++--
include/linux/ethtool.h | 7 +-
include/linux/mlx5/port.h | 12 +
include/uapi/linux/ethtool.h | 26 ++
include/uapi/linux/ethtool_netlink.h | 19 ++
net/ethtool/Makefile | 2 +-
net/ethtool/eeprom.c | 239 ++++++++++++++++++
net/ethtool/netlink.c | 10 +
net/ethtool/netlink.h | 2 +
10 files changed, 430 insertions(+), 30 deletions(-) create mode 100644
net/ethtool/eeprom.c
--
2.18.2
From: Don Bollinger <hidden> Date: 2021-03-05 00:57:52
On Thu, Mar 04, 2021 at 10:57AM-0800, Moshe Shemesh wrote:
quoted hunk
From: Vladyslav Tarasiuk <redacted>
Define get_module_eeprom_data_by_page() ethtool callback and
implement netlink infrastructure.
get_module_eeprom_data_by_page() allows network drivers to dump a
part of module's EEPROM specified by page and bank numbers along with
offset and length. It is effectively a netlink replacement for
get_module_info() and get_module_eeprom() pair, which is needed due to
emergence of complex non-linear EEPROM layouts.
Signed-off-by: Vladyslav Tarasiuk <redacted>
---
include/linux/ethtool.h | 7 +-
include/uapi/linux/ethtool.h | 26 +++++
include/uapi/linux/ethtool_netlink.h | 19 ++++
net/ethtool/Makefile | 2 +-
net/ethtool/eeprom.c | 157 +++++++++++++++++++++++++++
net/ethtool/netlink.c | 10 ++
net/ethtool/netlink.h | 2 +
7 files changed, 221 insertions(+), 2 deletions(-) create mode 100644
net/ethtool/eeprom.c
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h index
@@ -81,6 +81,7 @@ enum {#define ETH_RSS_HASH_NO_CHANGE 0structnet_device;+structnetlink_ext_ack;/* Some generic methods drivers may use in their ethtool_ops */u32ethtool_op_get_link(structnet_device*dev);@@-410,6+411,8@@
struct ethtool_pause_stats {
* @get_ethtool_phy_stats: Return extended statistics about the PHY
device.
* This is only useful if the device maintains PHY statistics and
* cannot use the standard PHY library helpers.
+ * @get_module_eeprom_data_by_page: Get a region of plug-in module
EEPROM data
+ * from specified page. Returns a negative error code or zero.
*
* All operations are optional (i.e. the function pointer may be set
* to %NULL) and callers must take this into account. Callers must @@
Note here that bytes at offset 0-127 are the same for every page of the
module, only bytes at offset 128 and higher are actually paged.
+ * @length: Number of bytes to read.
+ * @page: Page number to read from.
+ * @bank: Page bank number to read from, if applicable by EEPROM spec.
+ * @i2c_address: I2C address of a page. Value less than 0x7f expected.
Most
+ * EEPROMs use 0x50 or 0x51.
The standards are all very clear, the only legal values are 0x50 and 0x51.
It isn't 'expected', it is required. I suggest that 0xA0 and 0xA2 also be
silently accepted, and translated to 0x50 and 0x51 respectively. Some
of the specs use A0/A2 instead of 0x50/0x51. They actually mean the
same thing.
quoted hunk
+ * @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_eeprom_data {
+ __u32 offset;
+ __u32 length;
+ __u32 page;
+ __u32 bank;
+ __u32 i2c_address;
+ __u8 *data;
+};
+
/**
* struct ethtool_eee - Energy Efficient Ethernet information
* @cmd: ETHTOOL_{G,S}EEE
@@ -1865,6 +1887,10 @@ static inline int ethtool_validate_duplex(__u8
Please don't add this MAX_LEN constant. Even better, remove
the two above it as well.
The proper value for all 3 of these MAX_LEN items is the
architectural limit imposed by the 8 bit page register plus the constant
lower page (hence 257*128 bytes). The 8436 and 8636
specs do not actually limit these devices to 640 bytes (3 pages).
There is no MAX_LEN listed for SFF_8472. If there is one, it should
actually be 259 * 128 bytes (to account for 256 more bytes on the
unpaged 0x50 i2c address).
Nor is there one for CMIS. The maximum
architected length for CMIS is (257*128) + (127 * 16 * 128). That's
the QSFP max length plus 127 more banks of 16 pages.
Actually there are only two legal values for the i2c address (0x50, 0x51).
Rather than defining a MAX address, consider defining the legal values,
or... is it used at all? Leave it out?
+
/* Reset flags */
/* The reset() operation must clear the flags for the components which
* were actually reset. On successful return, the flags indicate the
diff --git
quoted hunk
a/include/uapi/linux/ethtool_netlink.h
b/include/uapi/linux/ethtool_netlink.h
index a286635ac9b8..60dd848d0b54 100644
I would be much more restrictive, with one flexibility...
if (request->i2c_address == 0xA0) request->i2c_address = 0x50;
if (request->i2c_address == 0xA2) request->i2c_address = 0x51;
if (request->i2c_address < 0x50) || (request->i2c_address > 0x51)
return -EINVAL;
This is really problematic as there are MANY different max values, within
the specs, for the various EEPROMs being generically supported here.
I would leave it to the drivers to handle out-of-range requests. If you
really want to check, you need to know which spec the module supports,
whether it supports pages, and whether it supports banks. I have not
found a register that actually reports the number of supported pages
that an eeprom supports. The specs should have included that :-(.
Why does this stanza depend on DATA_PAGE? In this new data
structure, no requests can cross the 256 byte page boundary.
I suggest, rather then -EINVAL, you should reduce the length to reach
the end of the page:
if (request->offset + request->length) > ETH_MODULE_EEPROM_PAGE_LEN)
request->length = ETH_MODULE_EEPROM_PAGE_LEN -
request->offset.
Note that this matches the choice you made to truncate rather than
error out in fallback_set_parms().
+
+ if (tb[ETHTOOL_A_EEPROM_DATA_PAGE])
+ request->page =
nla_get_u32(tb[ETHTOOL_A_EEPROM_DATA_PAGE]);
+ if (tb[ETHTOOL_A_EEPROM_DATA_BANK])
+ request->bank =
nla_get_u32(tb[ETHTOOL_A_EEPROM_DATA_BANK]);
Other checks:
Page and bank have to be between 0 and 255 (inclusive), they
go into an 8 bit register in the eeprom.
Offset and length can't be negative.
From: Don Bollinger <hidden> Date: 2021-03-05 00:57:57
On Thu, Mar 04, 2021 at 10:57AM-0800, Moshe Shemesh wrote:
quoted hunk
From: Vladyslav Tarasiuk <redacted>
In case netlink get_module_eeprom_data_by_page() callback is not
implemented by the driver, try to call old get_module_info() and
get_module_eeprom() pair. Recalculate parameters to
get_module_eeprom() offset and len using page number and their sizes.
Return error if this can't be done.
Signed-off-by: Vladyslav Tarasiuk <redacted>
---
net/ethtool/eeprom.c | 84
+++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 83 insertions(+), 1 deletion(-)
diff --git a/net/ethtool/eeprom.c b/net/ethtool/eeprom.c index
This is translating the new data structure into the old. Hence, I assume we
have i2c_addr, page, bank, offset, len to work with, and we should use
all of them. We shouldn't be applying the legacy data structure's rules
to how we interpret the *request data. Therefore...
This is tricky to map to old behavior. The new data structure should give
lower
memory for offsets less than 128, and paged upper memory for offsets of 128
and higher. There is no way to describe that request as {offset, length} in
the
old ethtool format with a fake linear memory.
if (request->page) {
if (offset < 128) && (offset + length > 128)
return -EINVAL;
if (offset > 127) offset = request->page * 128 + offset;
+
+ if (!length)
+ length = modinfo->eeprom_len;
+
+ if (offset >= modinfo->eeprom_len)
+ return -EINVAL;
+
+ if (modinfo->eeprom_len < offset + length)
+ length = modinfo->eeprom_len - offset;
+
+ eeprom->cmd = ETHTOOL_GMODULEEEPROM;
+ eeprom->len = length;
+ eeprom->offset = offset;
+
+ switch (modinfo->type) {
+ case ETH_MODULE_SFF_8079:
+ if (request->page > 1)
+ return -EINVAL;
+ break;
+ case ETH_MODULE_SFF_8472:
+ if (request->page > 3)
Not sure this is needed, there can be pages higher than 3.
+ return -EINVAL;
I *think* the linear memory on SFP puts 0x50 in the first
256 bytes, 0x51 after that, including pages after that. So,
the old fashioned linear memory offset needs to be adjusted
for accesses to 0x51. Thus add:
if (request->i2c_address == 0x51)
offset += 256;
+ break;
+ case ETH_MODULE_SFF_8436:
+ case ETH_MODULE_SFF_8636:
Not sure this is needed, there can be pages higher than 3.
We don't need to reject if there is an i2c_address. Indeed, we need that
to determine the correct offset for the legacy linear memory offset.
Note my comment on an earlier patch in this series, I would have rejected
any request that didn't have either 0x50 or 0x51 here.
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-03-05 01:33:05
quoted
+ * @length: Number of bytes to read.
+ * @page: Page number to read from.
+ * @bank: Page bank number to read from, if applicable by EEPROM spec.
+ * @i2c_address: I2C address of a page. Value less than 0x7f expected.
Most
+ * EEPROMs use 0x50 or 0x51.
The standards are all very clear
Our experience so far is that manufactures of SFP modules like to
ignore the standard. And none of the standards seem to cover copper
modules, which have additional registers at some other page.
Admittedly, they cannot be mapped as pages, you need some proprietary
protocol to map MDIO onto I2C. But i would not be surprised to find
some SFP that maps the FLASH of the microcontroller onto an address,
which we might be able to read out using this API.
So i suggested we keep it generic, allowing access to these
proprietary registers at other addresses. And if there is nothing
there, you probably get a 1/2 page of 0xff.
I suggest that 0xA0 and 0xA2 also be silently accepted, and
translated to 0x50 and 0x51 respectively.
No, i don't like having two different values mean the same thing. It
just leads to confusion. And userspace is going to be confused when it
asks for 0xA0 but the reply says it is for 0x50.
The Linux I2C subsystem does not magically map 8bit addresses in 7bit
addresses. We should follow what the Linux I2C subsystem does.
This is really problematic as there are MANY different max values, within
the specs
I agree. We should only be returning one 1/2 page as a maximum. So it
should be limited to 128 bytes. And offset+length should not go beyond
the end of a 1/2 page.
quoted
+ if (tb[ETHTOOL_A_EEPROM_DATA_PAGE])
+ request->page =
nla_get_u32(tb[ETHTOOL_A_EEPROM_DATA_PAGE]);
+ if (tb[ETHTOOL_A_EEPROM_DATA_BANK])
+ request->bank =
nla_get_u32(tb[ETHTOOL_A_EEPROM_DATA_BANK]);
Other checks:
Page and bank have to be between 0 and 255 (inclusive), they
go into an 8 bit register in the eeprom.
This is translating the new data structure into the old. Hence, I assume we
have i2c_addr, page, bank, offset, len to work with, and we should use
all of them.
Nope. We actually have none of them. The old API just asked the driver
to give me the data in the SFP. And the driver gets to decide what it
returns, following a well known layout. The driver can decide to give
just the first 1/2 page, or any number of multiple 1/2 pages in a well
known linear way, which ethtool knows how to decode.
So when mapping the new KAPI onto the old driver API, you need to call
the old API, and see if what is returned can be used to fulfil the
KAPI request. If the bytes are there, great, return them, otherwise
EOPNOTSUPP.
And we also need to consider the other way around. The old KAPI is
used, and the MAC driver only supports the new driver API. Since the
linear layout is well know, you need to make a number of calls into
the driver to read the 1/2 pages, and them glue them together and
return them.
I've not reviewed this code in detail yet, so i've no idea how it
actually works. But i would like to see as much compatibility as
possible. That has been the approach with moving from IOCTL to netlink
with ethool. Everything the old KAPI can do, netlink should also be
able to, plus there can be additional features.
quoted
+ switch (modinfo->type) {
+ case ETH_MODULE_SFF_8079:
+ if (request->page > 1)
+ return -EINVAL;
+ break;
+ case ETH_MODULE_SFF_8472:
+ if (request->page > 3)
Not sure this is needed, there can be pages higher than 3.
Not with the old KAPI call. As far as i remember, it stops at three
pages. But i need to check the ethtool(1) sources to be sure.
Andrew
If you look at all the other such enums in ethtool_netlink, you will
see a comment indicating the type. Please add them here as well.
Please also update Documentation/networking/ethtool-netlink.rst.
Andrew
This is translating the new data structure into the old. Hence, I
assume we have i2c_addr, page, bank, offset, len to work with, and we
should use all of them.
Nope. We actually have none of them. The old API just asked the driver to
give me the data in the SFP. And the driver gets to decide what it
returns,
following a well known layout. The driver can decide to give just the
first 1/2
page, or any number of multiple 1/2 pages in a well known linear way,
which
ethtool knows how to decode.
This code is to take a new KAPI request (a struct eeprom_data_req_info), and
create an old driver API request (a struct ethtool_eeprom) that will get the
same data. It isn't actually fetching the data, it is just forming the data
structure
to create the request. So, we do indeed have all of the new KAPI
parameters,
and need to use all of them to precisely create the matching old KAPI
request.
So when mapping the new KAPI onto the old driver API, you need to call the
old API, and see if what is returned can be used to fulfil the KAPI
request. If
the bytes are there, great, return them, otherwise EOPNOTSUPP.
Actually, this code has to figure out in advance whether the old API can
return
the data to fulfill the request, then form a request to accomplish that.
And we also need to consider the other way around. The old KAPI is used,
and the MAC driver only supports the new driver API. Since the linear
layout
is well know, you need to make a number of calls into the driver to read
the
1/2 pages, and them glue them together and return them.
That is a great idea, probably not difficult. It is not in this patch set.
I've not reviewed this code in detail yet, so i've no idea how it actually
works.
But i would like to see as much compatibility as possible. That has been
the
approach with moving from IOCTL to netlink with ethool. Everything the old
KAPI can do, netlink should also be able to, plus there can be additional
features.
quoted
quoted
+ switch (modinfo->type) {
+ case ETH_MODULE_SFF_8079:
+ if (request->page > 1)
+ return -EINVAL;
+ break;
+ case ETH_MODULE_SFF_8472:
+ if (request->page > 3)
Not sure this is needed, there can be pages higher than 3.
Not with the old KAPI call. As far as i remember, it stops at three pages.
But i
need to check the ethtool(1) sources to be sure.
Andrew
This is tricky to map to old behavior. The new data structure should give
lower memory for offsets less than 128, and paged upper memory for
offsets of 128 and higher. There is no way to describe that request as
{offset, length} in the old ethtool format with a fake linear memory.
if (request->page) {
if (offset < 128) && (offset + length > 128)
return -EINVAL;
Actually, reflecting on Andrew's response, it occurs to me this does not
have to be an error. The routine eeprom_data_fallback() (below) could
detect this case (a request crossing the 128 byte offset boundary) and
create two requests, one for lower memory and one for the paged
upper memory. That can't be done as a single request with the linear
memory model, but the two pieces can be read separately and glued
together.
Don
On Thu, Mar 04, 2021 at 10:57AM-0800, Moshe Shemesh wrote:
quoted
From: Vladyslav Tarasiuk <redacted>
Define get_module_eeprom_data_by_page() ethtool callback and
implement netlink infrastructure.
get_module_eeprom_data_by_page() allows network drivers to dump a
part of module's EEPROM specified by page and bank numbers along with
offset and length. It is effectively a netlink replacement for
get_module_info() and get_module_eeprom() pair, which is needed due to
emergence of complex non-linear EEPROM layouts.
Signed-off-by: Vladyslav Tarasiuk <redacted>
---
include/linux/ethtool.h | 7 +-
include/uapi/linux/ethtool.h | 26 +++++
include/uapi/linux/ethtool_netlink.h | 19 ++++
net/ethtool/Makefile | 2 +-
net/ethtool/eeprom.c | 157 +++++++++++++++++++++++++++
net/ethtool/netlink.c | 10 ++
net/ethtool/netlink.h | 2 +
7 files changed, 221 insertions(+), 2 deletions(-) create mode 100644
net/ethtool/eeprom.c
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h index
@@ -81,6 +81,7 @@ enum {#define ETH_RSS_HASH_NO_CHANGE 0structnet_device;+structnetlink_ext_ack;/* Some generic methods drivers may use in their ethtool_ops */u32ethtool_op_get_link(structnet_device*dev);@@-410,6+411,8@@
struct ethtool_pause_stats {
* @get_ethtool_phy_stats: Return extended statistics about the PHY
device.
* This is only useful if the device maintains PHY statistics and
* cannot use the standard PHY library helpers.
+ * @get_module_eeprom_data_by_page: Get a region of plug-in module
EEPROM data
+ * from specified page. Returns a negative error code or zero.
*
* All operations are optional (i.e. the function pointer may be set
* to %NULL) and callers must take this into account. Callers must @@
Note here that bytes at offset 0-127 are the same for every page of the
module, only bytes at offset 128 and higher are actually paged.
Right, but still having the offset relative to 128 will be confusing.
quoted
+ * @length: Number of bytes to read.
+ * @page: Page number to read from.
+ * @bank: Page bank number to read from, if applicable by EEPROM spec.
+ * @i2c_address: I2C address of a page. Value less than 0x7f expected.
Most
+ * EEPROMs use 0x50 or 0x51.
The standards are all very clear, the only legal values are 0x50 and 0x51.
It isn't 'expected', it is required. I suggest that 0xA0 and 0xA2 also be
silently accepted, and translated to 0x50 and 0x51 respectively. Some
of the specs use A0/A2 instead of 0x50/0x51. They actually mean the
same thing.
quoted
+ * @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_eeprom_data {
+ __u32 offset;
+ __u32 length;
+ __u32 page;
+ __u32 bank;
+ __u32 i2c_address;
+ __u8 *data;
+};
+
/**
* struct ethtool_eee - Energy Efficient Ethernet information
* @cmd: ETHTOOL_{G,S}EEE
@@ -1865,6 +1887,10 @@ static inline int ethtool_validate_duplex(__u8
Please don't add this MAX_LEN constant. Even better, remove
the two above it as well.
These constants are relevant to the ioctl function and used by the
drivers. For netlink new KAPI I will remove the new MAX_LEN per your
explanation, thanks.
The proper value for all 3 of these MAX_LEN items is the
architectural limit imposed by the 8 bit page register plus the constant
lower page (hence 257*128 bytes). The 8436 and 8636
specs do not actually limit these devices to 640 bytes (3 pages).
There is no MAX_LEN listed for SFF_8472. If there is one, it should
actually be 259 * 128 bytes (to account for 256 more bytes on the
unpaged 0x50 i2c address).
Nor is there one for CMIS. The maximum
architected length for CMIS is (257*128) + (127 * 16 * 128). That's
the QSFP max length plus 127 more banks of 16 pages.
Actually there are only two legal values for the i2c address (0x50, 0x51).
Rather than defining a MAX address, consider defining the legal values,
or... is it used at all? Leave it out?
As Andrew commented there might be usage of other i2c adresses, I will
keep it.
quoted
+
/* Reset flags */
/* The reset() operation must clear the flags for the components which
* were actually reset. On successful return, the flags indicate the
diff --git
quoted
a/include/uapi/linux/ethtool_netlink.h
b/include/uapi/linux/ethtool_netlink.h
index a286635ac9b8..60dd848d0b54 100644
I would be much more restrictive, with one flexibility...
if (request->i2c_address == 0xA0) request->i2c_address = 0x50;
if (request->i2c_address == 0xA2) request->i2c_address = 0x51;
if (request->i2c_address < 0x50) || (request->i2c_address > 0x51)
return -EINVAL;
This is really problematic as there are MANY different max values, within
the specs, for the various EEPROMs being generically supported here.
I would leave it to the drivers to handle out-of-range requests. If you
really want to check, you need to know which spec the module supports,
whether it supports pages, and whether it supports banks. I have not
found a register that actually reports the number of supported pages
that an eeprom supports. The specs should have included that :-(.
Will remove this check per your explanation, thanks.
Why does this stanza depend on DATA_PAGE? In this new data
structure, no requests can cross the 256 byte page boundary.
I suggest, rather then -EINVAL, you should reduce the length to reach
the end of the page:
if (request->offset + request->length) > ETH_MODULE_EEPROM_PAGE_LEN)
request->length = ETH_MODULE_EEPROM_PAGE_LEN -
request->offset.
Backward compatibility, users use the command without page and bank as
it was till now expect to get data that can cross page as it worked till
now, I can't break it.
Note that this matches the choice you made to truncate rather than
error out in fallback_set_parms().
We truncate in fallback_set_params() to eeprom_len.
length = modinfo->eeprom_len - offset;
quoted
+
+ if (tb[ETHTOOL_A_EEPROM_DATA_PAGE])
+ request->page =
nla_get_u32(tb[ETHTOOL_A_EEPROM_DATA_PAGE]);
+ if (tb[ETHTOOL_A_EEPROM_DATA_BANK])
+ request->bank =
nla_get_u32(tb[ETHTOOL_A_EEPROM_DATA_BANK]);
Other checks:
Page and bank have to be between 0 and 255 (inclusive), they
go into an 8 bit register in the eeprom.
If you look at all the other such enums in ethtool_netlink, you will
see a comment indicating the type. Please add them here as well.
Please also update Documentation/networking/ethtool-netlink.rst.
On Thu, Mar 04, 2021 at 10:57AM-0800, Moshe Shemesh wrote:
quoted
From: Vladyslav Tarasiuk <redacted>
In case netlink get_module_eeprom_data_by_page() callback is not
implemented by the driver, try to call old get_module_info() and
get_module_eeprom() pair. Recalculate parameters to
get_module_eeprom() offset and len using page number and their sizes.
Return error if this can't be done.
Signed-off-by: Vladyslav Tarasiuk <redacted>
---
net/ethtool/eeprom.c | 84
+++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 83 insertions(+), 1 deletion(-)
diff --git a/net/ethtool/eeprom.c b/net/ethtool/eeprom.c index
This is translating the new data structure into the old. Hence, I assume we
have i2c_addr, page, bank, offset, len to work with, and we should use
all of them. We shouldn't be applying the legacy data structure's rules
to how we interpret the *request data. Therefore...
This is tricky to map to old behavior. The new data structure should give
lower
memory for offsets less than 128, and paged upper memory for offsets of 128
and higher. There is no way to describe that request as {offset, length} in
the
old ethtool format with a fake linear memory.
if (request->page) {
if (offset < 128) && (offset + length > 128)
return -EINVAL;
if (offset > 127) offset = request->page * 128 + offset;
Yes, if we got page, that's the new API.
quoted
+
+ if (!length)
+ length = modinfo->eeprom_len;
+
+ if (offset >= modinfo->eeprom_len)
+ return -EINVAL;
+
+ if (modinfo->eeprom_len < offset + length)
+ length = modinfo->eeprom_len - offset;
+
+ eeprom->cmd = ETHTOOL_GMODULEEEPROM;
+ eeprom->len = length;
+ eeprom->offset = offset;
+
+ switch (modinfo->type) {
+ case ETH_MODULE_SFF_8079:
+ if (request->page > 1)
+ return -EINVAL;
+ break;
+ case ETH_MODULE_SFF_8472:
+ if (request->page > 3)
Not sure this is needed, there can be pages higher than 3.
quoted
+ return -EINVAL;
I *think* the linear memory on SFP puts 0x50 in the first
256 bytes, 0x51 after that, including pages after that. So,
the old fashioned linear memory offset needs to be adjusted
for accesses to 0x51. Thus add:
if (request->i2c_address == 0x51)
offset += 256;
Will check that. In the old KAPI the i2c address is not a parameter, so
it depends on driver implementation.
quoted
+ break;
+ case ETH_MODULE_SFF_8436:
+ case ETH_MODULE_SFF_8636:
Not sure this is needed, there can be pages higher than 3.