From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 607533C6A59; Thu, 5 Mar 2026 16:35:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772728562; cv=none; b=RV4neW8lksaLm+B/T4oXxCQqPihXIVJiyjjFPheKmpPx65wbqCpPJ/uE79HJ4mi7dlMWukT3S5kh5Dd3W3MyMSAwET5kBPidGnyHgwlRThdX7dWE2b/N+mxRihbZn5vZELZzLxlDzMqxJ8R6xoMUcWqecmSiAj48Xg149jfVhWo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772728562; c=relaxed/simple; bh=9Pilo2yniHGaelgdzcmw0lQrsgOHGBzjKjSdHmYMUcs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=f9etFnNT2q/NfwT00Ife9vDcFLDYZQ/pDy2ggIkEy1g8nX8sio3kaGHRV5Tt7O5zNskLavq8dcfB6VkGRil+HZ9EbQGTm02RT1585010tSjCqUNcuRgehYj3u91AmkHNbI5eCQL6EGEbLmLWI0AQXeIYX1f4922n9B7ZZrJ6csY= 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=HYsHjkGd; arc=none smtp.client-ip=185.246.84.56 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="HYsHjkGd" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id B83A21A2CE8; Thu, 5 Mar 2026 16:35:56 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 8C3A95FF89; Thu, 5 Mar 2026 16:35:56 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 4614E103696FE; Thu, 5 Mar 2026 17:35:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1772728555; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=15Zb7kxTviDLCqrwzjiGkkoGHFZBevdkVCcEYyh/Ufs=; b=HYsHjkGdcUotWQtQCj+NSKBKNXJO1Jl+PkEnuYnC2CrhCzfixRKZkIwOC4NlxfO3VSz8oS F9F+zug5k03aFSDBCcpESHwwzEs6vW02uBZSCLpQgQsqopYBjwE8KhFj5GAHh0y2yQAJlO 4/sai+w69VoUVvayR01t8dEDmtZeQDG8KaGYpuP1fZeHUcznX6P640htQXC/TVQRRftJPd J5SR3fgPjgivUiwTmxif9U8qzgWGvqWExdjlznwh1Ldr3CWenr/Wh+oFgVaKsvXSF+W5ch ef1thgPXcBRrIq1GGUBTRNQmHwAh4PBB/BNxF8sCNejT3pw4jQPyQbZNXHVTJg== Message-ID: Date: Thu, 5 Mar 2026 17:35:50 +0100 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 2/6] net: phylink: Allow more interfaces in SFP interface selection To: "Russell King (Oracle)" Cc: davem@davemloft.net, Andrew Lunn , Jakub Kicinski , Eric Dumazet , Paolo Abeni , Jonas Jelonek , Florian Fainelli , Heiner Kallweit , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, Simon Horman , Romain Gantois , =?UTF-8?Q?Marek_Beh=C3=BAn?= , bcm-kernel-feedback-list@broadcom.com References: <20260114225731.811993-1-maxime.chevallier@bootlin.com> <20260114225731.811993-3-maxime.chevallier@bootlin.com> <18657687-343f-4197-bdab-0eb0bed96964@bootlin.com> From: Maxime Chevallier Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 Hi Russell, On 05/03/2026 16:05, Russell King (Oracle) wrote: > On Fri, Feb 13, 2026 at 09:41:43AM +0100, Maxime Chevallier wrote: >> Hi Russell, >> >> On 15/01/2026 00:30, Russell King (Oracle) wrote: >>> On Wed, Jan 14, 2026 at 11:57:24PM +0100, Maxime Chevallier wrote: >>>> When phylink handles an SFP module that contains a PHY, it selects a >>>> phy_interface to use to communicate with it. This selection ensures that >>>> the highest speed gets achieved, based on the linkmodes we want to >>>> support in the module. >>>> >>>> This approach doesn't take into account the supported interfaces >>>> reported by the module >>> >>> This is intentional by design, because the capabilities of the PHY >>> override in this case. Unfortunately, as I've said previously, the >>> rush to throw in a regurgitated version of my obsoleted >>> "host_interfaces" rather messed up my replacement patch set which >>> had the PHY driver advertising the interface capabilities of the >>> PHY, which were then going to be used to make the PHY interface >>> selection when attaching the PHY. >>> >>> I've still got the code, but I can't now push it into mainline >>> because, with the obsolete host_interfaces stuff merged, we will end >>> up with two competing solutions. >>> >>> In any case, I really would appreciate people looking through >>> http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue >>> >>> before doing development on SFP and phylink to see whether I've >>> already something that solves their issue. Quite simply, I don't have >>> the time to push every patch out that I have, especially as I'm up to >>> my eyeballs with the crappy stmmac driver now, but also because I >>> have work items from Oracle that reduce the time I can work on >>> mainline. >> >> net-next being closed, I was going through my backlog and I was thinking >> about giving this series another go after net-next re-opens, I'd like to >> sync with you about the way forward. >> >> In your tree there's : >> >> net: phylink: use phy interface mode bitmaps for SFP PHYs >> net: phy: add supported_interfaces to Aquantia AQR113C >> net: phy: add supported_interfaces to marvell10g PHYs >> net: phy: add supported_interfaces to marvell PHYs >> net: phy: add supported_interfaces to bcm84881 >> net: phy: add supported_interfaces to phylib >> >> These would be pre-requisites for the 100FX-SGMII SFP support, as the >> interface resolution currently doesn't elect SGMII for 100FX modules. >> >> That would require some changes to the current host_interfaces API as >> well, potentially replacing it altogether. >> >> Is this something you can do, or can I get your permission to submit >> these (ofc maybe with more stuff to deal with host_interfaces) > > One of the issues that will need to be solved is how to tell > 100FX-SGMII (e.g. https://www.fs.com/uk/products/37770.html) which need > SGMII apart from 100FX modules that don't (e.g. > https://www.fs.com/uk/products/37324.html) > > host_interfaces don't satisfy that, because this has nothing to do with > what the host can do. Either the module has a PHY and uses SGMII on > the host side, or it doesn't have a PHY in which case 100BASE-X needs > to be used. If we have a PHY, then we will work out using what we > already have. > > Given that 100FX-SGMII, the PHY _should_ be coming up in SGMII mode, > so that's what we need to use to talk to them. _should_ indeed. All modules I got required some level of configuration of the internal PHY for it to work, and without Florian's help [1] on how to setup the broadcom PHY in SGMII to 100FX mode, all the modules I tried were just fancy paperweights :( [1] : https://lore.kernel.org/netdev/24146e10-5e9c-42f5-9bbe-fe69ddb01d95@broadcom.com/ > If we change the PHY's > mode to something else, we get into the horrid problems that is rate > matching, which gives us the problem that we don't have very good > support for that (e.g. PHYs that require the MAC to pace the transmit > rate.) > > I suspect there is no way to tell these SFPs apart using the EEPROM, > which means we're left with the "does this module that looks like a > optical module have a PHY?" problem that we already use for copper > SFPs. If there's no detectable PHY, then we'd likely have to assume > that the SFP requires 100BASE-X. > I agree with that completely. From the few such modules I have, we don't have much to work with in the eeprom to come-up with a proper generic support for these. I see no way around that other than probing for a PHY for every 100FX module, and see what we get. Alternatively, we could rely on fixups and have that internal hardcoded database of supported modules ? Maxime