[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240122205046.5bb0ffe7@kernel.org>
Date: Mon, 22 Jan 2024 20:50:46 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Danielle Ratson <danieller@...dia.com>
Cc: <netdev@...r.kernel.org>, <davem@...emloft.net>, <edumazet@...gle.com>,
<pabeni@...hat.com>, <corbet@....net>, <linux@...linux.org.uk>,
<sdf@...gle.com>, <kory.maincent@...tlin.com>,
<maxime.chevallier@...tlin.com>, <vladimir.oltean@....com>,
<przemyslaw.kitszel@...el.com>, <ahmed.zaki@...el.com>,
<richardcochran@...il.com>, <shayagr@...zon.com>,
<paul.greenwalt@...el.com>, <jiri@...nulli.us>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<mlxsw@...dia.com>, <petrm@...dia.com>, <idosch@...dia.com>
Subject: Re: [RFC PATCH net-next 3/9] ethtool: Add an interface for flashing
transceiver modules' firmware
On Mon, 22 Jan 2024 10:45:24 +0200 Danielle Ratson wrote:
> +The firmware update process can take several minutes to complete. Therefore,
> +during the update process notifications are emitted from the kernel to user
> +space updating it about the status and progress.
We should state more explicitly that the op just starts the process,
and does not block. Looks like cable test already uses _ACT as a
suffix, is it based on some standard? Doesn't seem all that intuitive
to me (or at least less intuitive than calling it _START...)
Powered by blists - more mailing lists