[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZD1DQN8HlSbVC+ci@corigine.com>
Date: Mon, 17 Apr 2023 15:01:52 +0200
From: Simon Horman <simon.horman@...igine.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
UNGLinuxDriver@...rochip.com,
Xiaoliang Yang <xiaoliang.yang_1@....com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 4/7] net: mscc: ocelot: don't rely on cached
verify_status in ocelot_port_get_mm()
On Sat, Apr 15, 2023 at 08:05:48PM +0300, Vladimir Oltean wrote:
> ocelot_mm_update_port_status() updates mm->verify_status, but when the
> verification state of a port changes, an IRQ isn't emitted, but rather,
> only when the verification state reaches one of the final states (like
> DISABLED, FAILED, SUCCEEDED) - things that would affect mm->tx_active,
> which is what the IRQ *is* actually emitted for.
>
> That is to say, user space may miss reports of an intermediary MAC Merge
> verification state (like from INITIAL to VERIFYING), unless there was an
> IRQ notifying the driver of the change in mm->tx_active as well.
>
> This is not a huge deal, but for reliable reporting to user space, let's
> call ocelot_mm_update_port_status() synchronously from
> ocelot_port_get_mm(), which makes user space see the current MM status.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
Reviewed-by: Simon Horman <simon.horman@...igine.com>
Powered by blists - more mailing lists