From: Jakub Kicinski <kuba@kernel.org>
To: Danielle Ratson <danieller@nvidia.com>
Cc: <netdev@vger.kernel.org>, <davem@davemloft.net>,
<edumazet@google.com>, <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: Re: [PATCH net-next v5 10/10] ethtool: Veto some operations during firmware flashing process
Date: Mon, 29 Apr 2024 20:23:31 -0700 [thread overview]
Message-ID: <20240429202331.29f3dafa@kernel.org> (raw)
In-Reply-To: <20240424133023.4150624-11-danieller@nvidia.com>
On Wed, 24 Apr 2024 16:30:23 +0300 Danielle Ratson wrote:
> Some operations cannot be performed during the firmware flashing process.
>
> For example:
>
> - Port must be down during the whole flashing process to avoid packet loss
> while committing reset for example.
>
> - Writing to EEPROM interrupts the flashing process, so operations like
> ethtool dump, module reset, get and set power mode should be vetoed.
>
> - Split port firmware flashing should be vetoed.
>
> - Flashing firmware on a device which is already in a flashing process
> should be forbidden.
>
> Use the 'module_fw_flashing_in_progress' flag introduced in a previous
> patch to veto those operations and prevent interruptions while preforming
> module firmware flash.
Feels a little out of order to add this check after the functionality.
I'd merge this with patch 5.
next prev parent reply other threads:[~2024-04-30 3:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 13:30 [PATCH net-next v5 00/10] Add ability to flash modules' firmware Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 01/10] ethtool: Add ethtool operation to write to a transceiver module EEPROM Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 02/10] mlxsw: Implement " Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 03/10] ethtool: Add an interface for flashing transceiver modules' firmware Danielle Ratson
2024-04-30 2:14 ` Jakub Kicinski
2024-04-24 13:30 ` [PATCH net-next v5 04/10] ethtool: Add flashing transceiver modules' firmware notifications ability Danielle Ratson
2024-04-30 3:11 ` Jakub Kicinski
2024-04-30 18:11 ` Danielle Ratson
2024-04-30 20:03 ` Jakub Kicinski
2024-05-01 7:53 ` Ido Schimmel
2024-05-01 14:37 ` Jakub Kicinski
2024-05-22 13:08 ` Danielle Ratson
2024-05-22 13:45 ` Jakub Kicinski
2024-05-22 13:56 ` Danielle Ratson
2024-05-22 14:22 ` Jakub Kicinski
2024-05-27 16:10 ` Ido Schimmel
2024-05-27 16:30 ` Jakub Kicinski
2024-04-24 13:30 ` [PATCH net-next v5 05/10] include: netdevice: Add module firmware flashing in progress flag to net_device Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 06/10] net: sfp: Add more extended compliance codes Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 07/10] ethtool: cmis_cdb: Add a layer for supporting CDB commands Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 08/10] ethtool: cmis_fw_update: add a layer for supporting firmware update using CDB Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 09/10] ethtool: Add ability to flash transceiver modules' firmware Danielle Ratson
2024-04-30 3:22 ` Jakub Kicinski
2024-04-24 13:30 ` [PATCH net-next v5 10/10] ethtool: Veto some operations during firmware flashing process Danielle Ratson
2024-04-30 3:23 ` Jakub Kicinski [this message]
2024-04-30 17:48 ` Danielle Ratson
2024-04-30 18:01 ` Jakub Kicinski
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=20240429202331.29f3dafa@kernel.org \
--to=kuba@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=corbet@lwn.net \
--cc=danieller@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=jiri@resnulli.us \
--cc=kory.maincent@bootlin.com \
--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 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.