From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F6ED39A063 for ; Wed, 3 Jun 2026 14:37:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780497440; cv=none; b=UkxdHAwlmVbzh2gQxFJ8ZuNaR7AqmtNvA58rVOLOMlPkNFETc8x2+UWKzWxodIznX9vcaRX7yiQ6G2miMBUG/uE0oFiwd1GrxIhF0iTxhwOPbbz4U7SNMAUUYTEAmlyJcoZTvyFmX1Bcd+FnVo0n+KNM4uYvmIeoLDB4m1wX6P0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780497440; c=relaxed/simple; bh=7sotkPWu1wfNu67XWnbqYZkTGv9k1u0xzUPyOcRSLKo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QPAh5Iw4yq6XDnm466rm9c+TkitF0tWvrh5aB2zAbVYfTJro5k/4X+In9Bm59CNEiPKXPQZj2yhyJQn/x/aY+ONWK0Dict0DTz4/19Rp4Tg/CnV48gTV69sg3SLBzUjbAWzyphiTvJLQhrDhUMQ0pTlHUb/nfdQnLnUamkrh9lE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=hotmail.com; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.219.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=hotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-8ccdef9f3d4so56588446d6.2 for ; Wed, 03 Jun 2026 07:37:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780497438; x=1781102238; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7sotkPWu1wfNu67XWnbqYZkTGv9k1u0xzUPyOcRSLKo=; b=NJ5edYaQio4Tb2YdyH5fo77loB3fEwEkKpeP+FnobR1osmwoHXThuyu6dkZHNT2TtL /sKtLNInDoc5iwWAbHul+4Zn/E38NTvidPNGnzPs+F2LRM4f+RQWdNA/FT+pklWwIMxo SC0IFrF5URCkJk9k1AdxoAxvgcFtGj5H8aFHCdj6hZ1vPBNiFcD4hu/tBYIdNnfaqPta Yf8/A1n7/Mve7gQ41ytyneYqJcjxgBLtz+n70qgrHYIzyastByJ0pO4e91iID/LsU1Xl IRYOl4H2PQzDFi5zRTO4qdy/y/DxG5m6W/tjoVChVAcTOBjD2On4WEydlF7FE5DnlIcL I84Q== X-Forwarded-Encrypted: i=1; AFNElJ/ry/VtCDWztprYZUqJJNxApfXW88qaLYQTHPFqYgvXOo4q93SrxRYUHo+QqmsbEJ6ZJZqlfN3Si7b+I38=@vger.kernel.org X-Gm-Message-State: AOJu0YwJe6nnZe0dkS/SS1qQhFnIGjQfe0NREEUkMNoQGfnWxeT6i3B3 Xgpaw19ughLi2Z9t5+tWtsaLh4l1pY0h5dn7IPNOf/xYRWEXDzVnU1BX X-Gm-Gg: Acq92OEdRKIiselUruazyAQdmeO7hBEYzTegzelz8V9zmkXTVGF6fh9XxxygDwFGzDJ C4GRxiOLvtryK6od6uEkt2H2FiPU2YJN29h6qnPgWGTiJWzlNlmvWd5RzkNx0AxJT9iYO+UK1+8 Vm36LHWVWnX8mIUuraXVUxushdyZPeTEmZWqcIT7tQSmQaTiw2LfvGjQg1Y49g8pxhQkrKZwU1q zRHgaqI5FmBxKKbtmZDbc0hl3bVdKpi6FQwuGPZVLrCgWt1NP7YVBGMsDLg0sVU86hypdPBoO4r sRNKI4lm48dUNpbaVc2lDeDeNG3GDvfF3G3qSiRHYvwCozxA/b/B4pOEnonwPXb+gEtFY4Ps3+M /bSXMPM3jY9P1Yki2uCUcjjIp8jyfnVi/Z07fdan/RuzCsO30N+QXhZbjrBs3N8S1yTorpKxBVj +6RhhclVV2BG0J/h6f84RzVi/lVM8+KNHayOBFlCVi3327U/DfGqx2qNgF0cyHhY9TaY4qGF1Co fdisljYRHbABgP1V3A8tkBXSNoSxw+Vck7mXorXNpo= X-Received: by 2002:a05:6214:459b:b0:8ca:25d3:bf41 with SMTP id 6a1803df08f44-8cecdc52a1dmr52727396d6.8.1780497438259; Wed, 03 Jun 2026 07:37:18 -0700 (PDT) Received: from lxc-docker-tertiary.local (pool-108-45-26-115.washdc.fios.verizon.net. [108.45.26.115]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ceccd9fda2sm21883976d6.2.2026.06.03.07.37.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 07:37:17 -0700 (PDT) From: Greg Patrick To: Andrew Lunn Cc: Russell King , Heiner Kallweit , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Subject: Re: [PATCH net-next v1] net: phy: sfp: detect presence via I2C when no MOD_DEF0 GPIO Date: Wed, 3 Jun 2026 14:37:17 +0000 Message-ID: <20260603143717.2985309-1-gregspatrick@hotmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: <20260602235528.2795028-1-gregspatrick@hotmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Thanks for the review, Andrew -- folding your three replies together. > > ... wires none of the cage sideband signals to a software-visible GPIO. > Are they wired to a software invisible GPIO? Or nowhere at all? Nowhere usable that I can find. TX_DISABLE is driven via a PCA9534 I/O expander, but no presence/MOD_ABS line reaches a readable input: the RTL9303 gpio0 lines the sister TL-ST1008F uses for MOD_DEF0 read stuck-low here, the single PCA9534 is fully consumed by TX_DISABLE, and there is no RTL8231. I haven't traced the PCB or decompiled the vendor firmware, so I can't prove it goes literally nowhere versus somewhere I can't reach -- but there is no software-readable presence source. I'll reword the commit message to say that precisely. > You might want to differentiate between an SFF and an SFP, using the > compatible. An SFF has no need for an MOD_DEF0 GPIO. I did not look, > maybe the code already does? It doesn't currently, and you're right that my patch wrongly changes the sff,sff case too: sff_data has no SFP_F_PRESENT in .gpios, so a soldered sff,sff never has a MOD_DEF0 GPIO and always hits this branch. v2 keeps the always-present path for sff,sff and uses the I2C probe only for an sff,sfp cage with no MOD_DEF0 GPIO, gated on (sff->gpios & SFP_F_PRESENT). > Did you try a 0 byte read? That is what tools like i2cdetect use. I can't on this board: the cage I2C master is the RTL9303's SMBus controller, which advertises only I2C_FUNC_SMBUS_BYTE_DATA -- no I2C_FUNC_I2C and, notably, no SMBus Quick Command (the zero-length probe i2cdetect uses). sfp_i2c_configure() therefore selects sfp_smbus_byte_read() with i2c_max_block_size = 1, and the presence probe reuses that same path. A 1-byte read is the lightest primitive this controller supports, and it is also the only form that works through sfp->read on both raw-I2C and SMBus-only adapters -- a zero-length transfer is not expressible there. (I checked on the hardware: i2ctransfer reports "Adapter does not have I2C transfers capability", and i2cdetect -F shows Quick Command unsupported but Receive/Read Byte supported, which is what presence detection rides on.) > > -static unsigned int sff_gpio_get_state(struct sfp *sfp) > Humm. Why? That deletion was wrong, for the sff,sff reason above -- I'll keep sff_gpio_get_state() in v2. I'll send the v2 with these changes after the 24h window. Thanks again. Greg