From: Petr Machata <petrm@nvidia.com>
To: Ido Schimmel <idosch@nvidia.com>
Cc: <netdev@vger.kernel.org>, <davem@davemloft.net>,
<kuba@kernel.org>, <pabeni@redhat.com>, <edumazet@google.com>,
<horms@kernel.org>, <danieller@nvidia.com>, <petrm@nvidia.com>,
<andrew@lunn.ch>, <damodharam.ammepalli@broadcom.com>,
<michael.chan@broadcom.com>, <andrew.gospodarek@broadcom.com>
Subject: Re: [PATCH net] ethtool: cmis_cdb: Fix incorrect read / write length extension
Date: Thu, 10 Apr 2025 10:41:40 +0200 [thread overview]
Message-ID: <874iywxv9u.fsf@nvidia.com> (raw)
In-Reply-To: <20250409112440.365672-1-idosch@nvidia.com>
Ido Schimmel <idosch@nvidia.com> writes:
> The 'read_write_len_ext' field in 'struct ethtool_cmis_cdb_cmd_args'
> stores the maximum number of bytes that can be read from or written to
> the Local Payload (LPL) page in a single multi-byte access.
>
> Cited commit started overwriting this field with the maximum number of
> bytes that can be read from or written to the Extended Payload (LPL)
> pages in a single multi-byte access. Transceiver modules that support
> auto paging can advertise a number larger than 255 which is problematic
> as 'read_write_len_ext' is a 'u8', resulting in the number getting
> truncated and firmware flashing failing [1].
>
> Fix by ignoring the maximum EPL access size as the kernel does not
> currently support auto paging (even if the transceiver module does) and
> will not try to read / write more than 128 bytes at once.
>
> [1]
> Transceiver module firmware flashing started for device enp177s0np0
> Transceiver module firmware flashing in progress for device enp177s0np0
> Progress: 0%
> Transceiver module firmware flashing encountered an error for device enp177s0np0
> Status message: Write FW block EPL command failed, LPL length is longer
> than CDB read write length extension allows.
>
> Fixes: 9a3b0d078bd8 ("net: ethtool: Add support for writing firmware blocks using EPL payload")
> Reported-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com>
> Closes: https://lore.kernel.org/netdev/20250402183123.321036-3-michael.chan@broadcom.com/
> Tested-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
next prev parent reply other threads:[~2025-04-10 8:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 11:24 [PATCH net] ethtool: cmis_cdb: Fix incorrect read / write length extension Ido Schimmel
2025-04-09 18:02 ` Damodharam Ammepalli
2025-04-09 23:42 ` Jakub Kicinski
2025-04-10 8:41 ` Petr Machata [this message]
2025-04-10 12:40 ` patchwork-bot+netdevbpf
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=874iywxv9u.fsf@nvidia.com \
--to=petrm@nvidia.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=andrew@lunn.ch \
--cc=damodharam.ammepalli@broadcom.com \
--cc=danieller@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 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.