Received-SPF: pass (google.com: domain of linux-kernel+bounces-204561-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Thu, 6 Jun 2024 17:21:45 +0200
From: Andrew Lunn <andrew@lunn.ch>
To: =?iso-8859-1?B?Q3Pza+FzLA==?= Bence <csokas.bence@prolan.hu>,
	Russell King <rmk+kernel@armlinux.org.uk>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Russell King <linux@armlinux.org.uk>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH] net: sfp: Always call `sfp_sm_mod_remove()` on remove
Message-ID: <24a48e5a-efb3-4066-af6f-69f4a254b9c3@lunn.ch>
References: <20240605084251.63502-1-csokas.bence@prolan.hu>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240605084251.63502-1-csokas.bence@prolan.hu>

On Wed, Jun 05, 2024 at 10:42:51AM +0200, Cs?k?s, Bence wrote:
> If the module is in SFP_MOD_ERROR, `sfp_sm_mod_remove()` will
> not be run. As a consequence, `sfp_hwmon_remove()` is not getting
> run either, leaving a stale `hwmon` device behind. `sfp_sm_mod_remove()`
> itself checks `sfp->sm_mod_state` anyways, so this check was not
> really needed in the first place.
> 
> Signed-off-by: "Cs?k?s, Bence" <csokas.bence@prolan.hu>

I was expecting Russell to review this. Maybe he missed it.

This looks O.K. to me:

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew