From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (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 38E6C411695 for ; Mon, 15 Jun 2026 17:19:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781543958; cv=none; b=dwMSnm8BngKromXkkq3+fnxTo6XRXVI5FHKqmqDanAtlEsfUxd0ZUuOkbM47NrkTekBSZad1TpGqtYwqXOoRDZOV7fNcj+TGYQe0tFH7PWftbRY23M1Dae319gwQQZ10m+XdkRlGXCw7xcdqqSzsjkmYHb4Sg7Fdgt+lHYUPk8c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781543958; c=relaxed/simple; bh=wbYoLma2CMZQ7WQBuZbeCdna6PIX7E+9uWxHemNpbUM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QHukvExR++J6VNFUjoFo7sZ0RpPMTF8nHd9UDIqawgDskmkpa4vMXrmuO7EksL544FrXpX+WxkNEZuVGtqrVSa2ekfYLKSKd/O7bETAsdfKWt5thmm+ahY6h2nUuL3AJz4NAfO6xztmRXRc/kkFfkItoVXfDdbDBCasgWGQvqrU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=Tu2Q+9FV; arc=none smtp.client-ip=185.171.202.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="Tu2Q+9FV" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 97D05C51474; Mon, 15 Jun 2026 17:19:18 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 49EC560015; Mon, 15 Jun 2026 17:19:14 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id A141A106C96C2; Mon, 15 Jun 2026 19:19:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1781543953; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=jhNSiRQ30BnlVswWDQJYLs05F5wmSrj7Tp+I0w+TuNA=; b=Tu2Q+9FVVa4Xi1RwwsSA+66TDJ0gtHs8y42c8kZOtKTU300RfeKdU1swZ3M8Zb1CU7WDRs AbVCkqsPPHv294X1fOjD1sZoqQ6OaXxsdX8Bv1hARygsVbgJG69qj62AXl1Sv3L24LCnYy k4uvTLVKnM72jOI3iPVRPfy0da7sRd2RzCD7lMCIB3RBXmvaD35tp9gVV8GO3qw6KMiomX w1C2uZtIhRiyucfkkLNRMWf3LPWvPrK2tdIiDiY1GeOZZkKPyXrbkaQdwunRBRfpig5qvr CS8LIzL5rKDWzn15aUlwoPOwaJocR2Dcl5ApbxnjCYiFycalfXG5w937xeWZpg== Message-ID: Date: Mon, 15 Jun 2026 19:19:07 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v3] net: phy: sfp: detect presence via I2C when no MOD_DEF0 GPIO To: Greg Patrick , Russell King , Andrew Lunn , Heiner Kallweit Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Manuel Stocker References: <20260611175341.2223184-1-gregspatrick@hotmail.com> Content-Language: en-US From: Maxime Chevallier In-Reply-To: <20260611175341.2223184-1-gregspatrick@hotmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 Hi, On 6/11/26 19:53, Greg Patrick wrote: > An SFP cage (compatible "sff,sfp") whose MOD_DEF0 signal is not wired to a > GPIO currently falls back to sff_gpio_get_state(), which unconditionally > reports the module as present. An empty cage therefore fails its probe and > is parked in SFP_MOD_ERROR forever; because SFP_F_PRESENT never deasserts > there is no REMOVE event to recover the state machine, so a module inserted > after boot is never detected, and empty cages spam -EIO at boot. > > This affects boards that route none of the cage presence signal to a > software-readable input. On the NicGiga S100-0800S-M (RTL9303, 8x SFP+) the > cage I2C bus is the switch's SMBus master; TX_DISABLE is driven via a > PCA9534 I/O expander, but no MOD_ABS/MOD_DEF0 line reaches a readable GPIO > (the RTL9303 gpio0 lines read stuck-low, the single PCA9534 is fully > consumed by TX_DISABLE, and there is no RTL8231). The Horaco ZX-SW82TS-L2P > (RTL9302D, 2x SFP+) is independently affected in the same way. > > For such an SFP cage, derive presence from a throttled single-byte I2C read > of the module EEPROM instead: a successful read asserts SFP_F_PRESENT, > R_PROBE_ABSENT consecutive failures clear it (to ride out a transient error > on a live module). The existing poll then emits SFP_E_INSERT / SFP_E_REMOVE > normally, giving working hot-plug and silencing the boot-time -EIO spam on > empty cages. Presence is re-probed every T_PROBE_PRESENT, so insertion is > detected within that interval and removal within > T_PROBE_PRESENT * R_PROBE_ABSENT. > > A soldered-down module (compatible "sff,sff") has no presence signal and is > genuinely always present, so it continues to use sff_gpio_get_state(); the > new path is gated on the cage type advertising SFP_F_PRESENT. > > Signed-off-by: Greg Patrick > Tested-by: Manuel Stocker Reviewed-by: Maxime Chevallier And it doesn't regress any boards I've tested this on (although this was very quick testing), so Tested-by: Maxime Chevallier I'm wondering if a followup could be to add another loud warning to dmesg that the HW design is broken, leading to potentially quirky behaviour. We have lots of those for SFP. Maxime