From: Moshe Shemesh <email@example.com>
To: Andrew Lunn <firstname.lastname@example.org>, Don Bollinger <email@example.com>
Cc: "'David S. Miller'" <firstname.lastname@example.org>,
'Jakub Kicinski' <email@example.com>,
'Adrian Pop' <firstname.lastname@example.org>,
'Michal Kubecek' <email@example.com>, <firstname.lastname@example.org>,
'Vladyslav Tarasiuk' <email@example.com>
Subject: Re: [RFC PATCH V4 net-next 1/5] ethtool: Allow network drivers to dump arbitrary EEPROM data
Date: Wed, 24 Mar 2021 12:03:32 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 3/23/2021 2:27 AM, Andrew Lunn wrote:
>>> +#define ETH_MODULE_EEPROM_PAGE_LEN 256
>> Sorry to keep raising issues, but I think you want to make this constant
> Yes, i also think the KAPI should be limited to returning a maximum of
> a 1/2 page per call.
>>> +#define MODULE_EEPROM_MAX_OFFSET (257 *
>> The device actually has 257 addressable chunks of 128 bytes each. With
>> ETH_MODULE_EEPROM_PAGE_LEN set to 256, your constant is 2X too big.
>> Note also, SFP devices (but not QSFP or CMIS) actually have another 256
>> bytes available at 0x50, in addition to the full 257*128 at 0x51. So SFP is
>> actually 259*128 or (256 + 257 * 128).
>> Devices that don't support pages have much lower limits (256 bytes for
>> QSFP/CMIS and 512 for SFP). Some SFP only support 256 bytes. Most devices
>> will return nonsense for pages above 3. So, this check is really only an
>> absolute limit. The SFP driver that takes this request will probably check
>> against a more refined MAX length (eg modinfo->eeprom_len).
>> I suggest setting this constant to 259 * (ETH_MODULE_EEPROM_PAGE_LEN / 2).
>> Let the driver refine it from there.
> I don't even see a need for this. The offset should be within one 1/2
> page, of one bank. So offset >= 0 and <= 127. Length is also > 0 and
> <- 127. And offset+length is <= 127.
> For the moment, please forget about backwards compatibility with the
> IOCTL interface. Lets get a new clean KAPI and a new clean internal
> API between the ethtool core and the drivers. Once we have that agreed
> on, we can work on the various compatibility shims we need to work
> between old and new APIs in various places.
OK, so following the comments here, I will ignore backward compatibility
of having global offset and length.
That means I assume in this KAPI I am asked to get data from specific
page. Should I also require user space to send page number to this KAPI
(I mean make page number mandatory) ?
next prev parent reply other threads:[~2021-03-24 10:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 17:11 [RFC PATCH V4 net-next 0/5] ethtool: Extend module EEPROM dump API Moshe Shemesh
2021-03-22 17:11 ` [RFC PATCH V4 net-next 1/5] ethtool: Allow network drivers to dump arbitrary EEPROM data Moshe Shemesh
2021-03-22 18:17 ` Don Bollinger
2021-03-23 0:27 ` Andrew Lunn
2021-03-23 1:23 ` Don Bollinger
2021-03-23 2:03 ` Andrew Lunn
2021-03-23 17:47 ` Don Bollinger
2021-03-23 22:17 ` Andrew Lunn
2021-03-24 10:14 ` Moshe Shemesh
2021-03-24 10:03 ` Moshe Shemesh [this message]
2021-03-24 12:15 ` Andrew Lunn
2021-03-23 0:54 ` Andrew Lunn
2021-03-24 10:05 ` Moshe Shemesh
2021-03-22 17:11 ` [RFC PATCH V4 net-next 2/5] net/mlx5: Refactor module EEPROM query Moshe Shemesh
2021-03-22 17:11 ` [RFC PATCH V4 net-next 3/5] net/mlx5: Implement get_module_eeprom_by_page() Moshe Shemesh
2021-03-22 17:11 ` [RFC PATCH V4 net-next 4/5] net/mlx5: Add support for DSFP module EEPROM dumps Moshe Shemesh
2021-03-22 17:11 ` [RFC PATCH V4 net-next 5/5] ethtool: Add fallback to get_module_eeprom from netlink command Moshe Shemesh
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.