From: Ido Schimmel <idosch@nvidia.com>
To: "Krzysztof Olędzki" <ole@ans.pl>
Cc: Andrew Lunn <andrew@lunn.ch>, Michal Kubecek <mkubecek@suse.cz>,
Moshe Shemesh <moshe@nvidia.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
tariqt@nvidia.com, Dan Merillat <git@dan.merillat.org>
Subject: Re: [PATCH] qsfp: Better handling of Page 03h netlink read failure
Date: Mon, 8 Jul 2024 19:12:15 +0300 [thread overview]
Message-ID: <ZowP36I9jcRmUDkg@shredder.mtl.com> (raw)
In-Reply-To: <56384f82-6ce7-49c8-a20e-ffdf119804ae@ans.pl>
Hi, thanks for the patch. Some comments below (mainly about the
process).
Subject prefix should be "[PATCH ethtool]" instead of "[PATCH]"
Best to post as a separate thread instead of as a reply to a thread.
Looks weird in lore (https://lore.kernel.org/netdev/) otherwise.
On Sun, Jul 07, 2024 at 08:41:38PM -0700, Krzysztof Olędzki wrote:
> Page 03h may not be available due to a bug in a driver.
> This is a non-fatal error and sff8636_dom_parse() handles this
> correctly, allowing it to provide the remaining information.
In addition to the problem, need to describe what the patch is doing in
imperative mood. Something like:
"
When dumping the EEPROM contents of a QSFP transceiver module, ethtool
will only ask the kernel to retrieve Upper Page 03h if the module
advertised it as supported.
However, some kernel drivers like mlx4 are currently unable to provide
the page, resulting in the kernel returning an error. Since Upper Page
03h is optional, do not treat the error as fatal. Instead, print an
error message and allow ethtool to continue and parse / print the
contents of the other pages.
Before:
# ethtool -m eth3
<OUTPUT BEFORE>
After:
# ethtool -m eth3
<OUTPUT AFTER>
Fixes: 25b64c66f58d ("ethtool: Add netlink handler for getmodule (-m)")
Signed-off-by: Krzysztof Olędzki <ole@ans.pl>
"
>
> Also, add an error message to clarify otherwise cryptic
> "netlink error: Invalid argument" message.
> ---
> qsfp.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/qsfp.c b/qsfp.c
> index a2921fb..208eddc 100644
> --- a/qsfp.c
> +++ b/qsfp.c
> @@ -1038,8 +1038,16 @@ sff8636_memory_map_init_pages(struct cmd_context *ctx,
>
> sff8636_request_init(&request, 0x3, SFF8636_PAGE_SIZE);
> ret = nl_get_eeprom_page(ctx, &request);
> - if (ret < 0)
> - return ret;
> + if (ret < 0) {
> + /* Page 03h is not available due to a bug in the driver.
> + * This is a non-fatal error and sff8636_dom_parse()
> + * handles this correctly.
> + */
> +
Unnecessary blank line
> + fprintf(stderr, "Failed to read Upper Page 03h, driver error?\n");
> + return 0;
> + }
> +
> map->page_03h = request.data - SFF8636_PAGE_SIZE;
>
> return 0;
> --
> 2.45.2
>
next prev parent reply other threads:[~2024-07-08 16:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-21 6:26 "netlink error: Invalid argument" with ethtool-5.13+ on recent kernels due to "ethtool: Add netlink handler for getmodule (-m)" - 25b64c66f58d3df0ad7272dda91c3ab06fe7a303, also no SFP-DOM support via netlink? Krzysztof Olędzki
2024-05-21 6:55 ` Michal Kubecek
2024-05-21 7:02 ` Krzysztof Olędzki
2024-05-21 7:16 ` Krzysztof Olędzki
2024-05-21 7:34 ` Michal Kubecek
2024-05-21 7:38 ` Krzysztof Olędzki
2024-05-21 20:21 ` Andrew Lunn
2024-05-22 4:54 ` Krzysztof Olędzki
2024-05-22 8:40 ` Ido Schimmel
2024-05-22 12:44 ` Andrew Lunn
2024-05-23 5:29 ` Krzysztof Olędzki
2024-05-23 10:37 ` Michal Kubecek
2024-05-23 10:48 ` Ido Schimmel
2024-05-23 15:35 ` Andrew Lunn
2024-07-08 3:41 ` [PATCH] net/mlx4: Add support for EEPROM high pages query for QSFP/QSFP+/QSFP28 Krzysztof Olędzki
2024-07-08 16:28 ` Ido Schimmel
2024-07-09 11:17 ` Dan Merillat
2024-07-08 3:41 ` [PATCH] qsfp: Better handling of Page 03h netlink read failure Krzysztof Olędzki
2024-07-08 16:12 ` Ido Schimmel [this message]
2024-07-31 0:55 ` Krzysztof Olędzki
2024-07-31 8:48 ` Ido Schimmel
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=ZowP36I9jcRmUDkg@shredder.mtl.com \
--to=idosch@nvidia.com \
--cc=andrew@lunn.ch \
--cc=git@dan.merillat.org \
--cc=mkubecek@suse.cz \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=ole@ans.pl \
--cc=tariqt@nvidia.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).