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 D2612385D84 for ; Wed, 10 Jun 2026 07:30:50 +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=1781076654; cv=none; b=tf+J2FModpCaCKaFx5H5+WWMxyEiNK6vhopbP4Y24ueKDiS7Em1EENCeno4S8x4axDm2m24kRHPuy/LdwND9mELPSyXf6ne1Y/dSb8h+GUAh4M9eeeroSHoLI/cfAvVWBsrxtDCiksG76zVM8MNV5F4tmLlXN9oXYYPoLqhuta0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781076654; c=relaxed/simple; bh=IigwtTcrIQognWI4jbkMZAJaKP3duykd2Z83udMFGdk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bCVQYoI8Q97oXH/ZvhLFRbBIGjFvgopaRdM6/qVfkljPRoVpYbkRL9XYDvZFk+c8MJNpFU7jUUmWW43e0bnc2gMX7WSgDswWSPptA29jBH06d8YuvOywjyav16gjx2OxH6TPTm2H5dG14gkPFEoWnf+YZjAd7locEXnNKdE+leo= 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=t/Izaowf; 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="t/Izaowf" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id D51FEC49F43; Wed, 10 Jun 2026 07:30:44 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 0830B5FFC9; Wed, 10 Jun 2026 07:30:43 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 56E91106B96FE; Wed, 10 Jun 2026 09:30:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1781076642; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=juSc6QnvI0q/sb8xWkAHDkPnxJLB2/dxCvNlblbk6JM=; b=t/IzaowfbSd6+7BtUmBLBCLxJjxDylqFsGxqjsOJ2L1sI1hxyADXIIv8CH38Bwqrmmzrxa IQ7L99KZb7k9w4/2IqwRFlTRt2SNKowicZ1iCZeT/9eE2SyP/NcErqDcIKCRmvPMJ8XI2c S2ZU06axsxoOkNdf6vrI/xjtpbWxMalG0nSG/JoueVvMhnwpBgCUdUxyWjAN7ks3Dcy36u XiG8yreQNjh/TRl4LInf2nyTPyBMUpYy+l6KmnkD/1ow71vUPfVtcsYdethmHm1Mc6gqtR eGsaGIOtTRaXcB+7o3Vrvx6oXXu7anbmRYt5v3DtYRJ9KlF20xMVol8Ss3aJ3A== Message-ID: <399497f5-ab96-4a8c-81ef-d3c4588fe341@bootlin.com> Date: Wed, 10 Jun 2026 09:30:38 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2] 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 References: <20260604151614.3310544-1-gregspatrick@hotmail.com> Content-Language: en-US From: Maxime Chevallier In-Reply-To: <20260604151614.3310544-1-gregspatrick@hotmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 Hi Greg, On 6/4/26 17:16, 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). > > For such an SFP cage, derive presence from a throttled single-byte I2C read > of the module EEPROM instead: an ACK asserts SFP_F_PRESENT, two 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. > > 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 > --- > v2: > - Keep sff_gpio_get_state() and gate the new I2C-probe presence on the > cage advertising SFP_F_PRESENT (an "sff,sfp" cage), so a soldered > "sff,sff" module keeps its always-present behaviour. (Andrew Lunn) > - Reword the commit message to state precisely that no presence signal > reaches a readable input on the affected board, and that the cage bus > is the RTL9303 SMBus master. (Andrew Lunn) > - On using a 0-byte read like i2cdetect: not available on this board -- > the cage master advertises only I2C_FUNC_SMBUS_BYTE_DATA (no > I2C_FUNC_I2C, no SMBus Quick Command), so sfp_i2c_configure() selects > sfp_smbus_byte_read() and a 1-byte read is the lightest presence > primitive; it also works through sfp->read on both raw-I2C and > SMBus-only adapters, whereas a zero-length transfer does not. (Andrew Lunn) > > v1: https://lore.kernel.org/netdev/20260602235528.2795028-1-gregspatrick@hotmail.com/ > > drivers/net/phy/sfp.c | 77 +++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 74 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c > index 376c705a9..056bbe6de 100644 > --- a/drivers/net/phy/sfp.c > +++ b/drivers/net/phy/sfp.c > @@ -206,6 +206,11 @@ static const enum gpiod_flags gpio_flags[] = { > #define T_PROBE_RETRY_SLOW msecs_to_jiffies(5000) > #define R_PROBE_RETRY_SLOW 12 > > +/* Interval at which sfp_i2c_get_state() re-probes the I2C bus for module > + * presence on boards without a MOD_DEF0 GPIO (see sfp_i2c_get_state()). > + */ > +#define T_PROBE_PRESENT msecs_to_jiffies(2000) I'm genuinly wondering if 2s for this isn't too slow. With a 4s total including the retry, this definitely leaves time for a user to swap the module with another different one, and we wouldn't see the hotswap from linux here, leading to very interesting problems. I think we need a faster removal-detection time. I'd like to give this patch a try, however I won't be able to do so before at least saturday :( Feel free to send a V3 though Maxime