From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.tipi-net.de (mail.tipi-net.de [194.13.80.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D65F35202D; Sat, 30 May 2026 12:33:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=194.13.80.246 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780144432; cv=none; b=WJtuVh/lroRYaB7cwmg/ZVh8w1yUPYpzAUg2tEn4Fb0+QclO9Nqe0BGAmq0OJRE6jDPZKE04oOeCgl2ME6L77tPqvWIsm4T9y2nqcypoZHnvc/sEaGfn5kasfgTcTJvUIRiB/1W169RnWlBISx9HDk2cX6YUvAMOvnvv4CJBPUo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780144432; c=relaxed/simple; bh=FVzu+jOauDq6f5xbyxt3UGZcyypS3GCv2v5kSRdGvnY=; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:Content-Type; b=Mek75c1y0KvaNxCWJQw+2NCTUE6Hc8CjD5swZkhqqXGn9qiZxon6ZwwSIBw6cSxxTkc1dlkuSfz2jTZ20A9h2ZwftJbdQ9rmjZKQ7aRYddMWTN4JJvy+fOuxNWEunNTTSsRs6dFTvWA9Zdq9QODzEWYd8cQ3HsUku5SLIg1kK9Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tipi-net.de; spf=pass smtp.mailfrom=tipi-net.de; dkim=pass (2048-bit key) header.d=tipi-net.de header.i=@tipi-net.de header.b=0ci+IJtU; arc=none smtp.client-ip=194.13.80.246 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tipi-net.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tipi-net.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tipi-net.de header.i=@tipi-net.de header.b="0ci+IJtU" Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 34994A08DA; Sat, 30 May 2026 14:33:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tipi-net.de; s=dkim; t=1780144419; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=P7PESjsUf1EFCTeforqehft+BJJDknN1xZrEHuBl+1A=; b=0ci+IJtUf2Qy4E2Afy4mp6gUkA6zSnDiEsw/XtavbE/a0b41QoxXzi00FeT5K4FeatFRQF gQSK2pzJ6hCOcNSMqrECLCqPL4nPXUalPRZYNCeEd/pkYDW2xnMVUK7SodwCWBTOuHQNid XCaAMeABje6c77u/Tt5QDYEajMPSlm59whBjkp0HbbBSgRPXCLuHfSsm1F0UQd29q7Bvxr 7kPsw91yDUPrVptq6reea8+kjL+4AKHfgBq5bUK3dQ9TR5YYhj7cMJ7o/plI7lVDSaFZ8g hYNvLzdC14ejtNnJWbH4q1IrgPPSrNTMYkU/WaTKsHsXQ4HPPfNLwSNWuyHtTw== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Sat, 30 May 2026 14:33:35 +0200 From: Nicolai Buchwitz To: "Maxime Chevallier (Netdev Foundation)" Cc: Andrew Lunn , davem@davemloft.net, Eric Dumazet , Jakub Kicinski , Paolo Abeni , Russell King , Heiner Kallweit , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com Subject: Re: [PATCH net] net: phy: clean the sfp upstream if phy probing fails In-Reply-To: <20260530072706.3167745-1-maxime.chevallier@bootlin.com> References: <20260530072706.3167745-1-maxime.chevallier@bootlin.com> Message-ID: X-Sender: nb@tipi-net.de Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 Hi Maxime On 30.5.2026 09:27, Maxime Chevallier (Netdev Foundation) wrote: > Sashiko reported that we don't call sfp_bus_del_upstream() in the probe > failure path, so let's add it, otherwise the sfp-bus is left with a > dangling 'upstream' field, that may be used later on during SFP events. > > This issue existed before the generic phylib sfp support, back when > drivers were calling phy_sfp_probe themselves. > > Fixes: 298e54fa810e ("net: phy: add core phylib sfp support") > Signed-off-by: Maxime Chevallier (Netdev Foundation) > > --- > drivers/net/phy/phy_device.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/net/phy/phy_device.c > b/drivers/net/phy/phy_device.c > index 3370eb822017..6c2ef91fd197 100644 > --- a/drivers/net/phy/phy_device.c > +++ b/drivers/net/phy/phy_device.c > @@ -3775,6 +3775,9 @@ static int phy_probe(struct device *dev) > return 0; > > out: While at it, should phy_cleanup_ports() also be added? Failure of_phy_leds() or genphy_c45_read_eee_adv() would IMHO also produce a leak. > + sfp_bus_del_upstream(phydev->sfp_bus); > + phydev->sfp_bus = NULL; > + > if (!phydev->is_on_sfp_module) > phy_led_triggers_unregister(phydev); Reviewed-by: Nicolai Buchwitz Thanks, Nicolai