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 301CE33A715 for ; Mon, 19 Jan 2026 09:35:18 +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=1768815321; cv=none; b=VIyXI+aktW57l/8XubbexDfZfuzCcBJ3o3N1xFXApGC9u0DM0JTzuP2XlXkEEp+Qm83n3fwFP7CwYPR3umBE0suTsKCSfSSD0j8M1DuWkku7TuVmOJrKrdE5ARxhgbP+oVdc1bMtn6eR01982gX6oVxNKzza/zIx4ipm3Yh2Reo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768815321; c=relaxed/simple; bh=/rbsgtwh0IFmobpYZIg0T/1qRai3iU7Ujtclbpd0ZlU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Skik3bBZFh/iJ6U5hQM/4CjTDu5W1auJKA1vWEUefDmMZtju1m0HB5dSuNQvKTaanWK86NTCJeXs7OsPnn6wIfDzbZcHO2GGRXrvZmtNpZhtVNiZS0dlrJIMwE3pfYfoE2BJ2GlusImJ1VgDET6RkPoVnDUx8o/PJsQ3hWysdfI= 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=BPkFrCJI; 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="BPkFrCJI" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 04697C2033E; Mon, 19 Jan 2026 09:27:32 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id DC34660731; Mon, 19 Jan 2026 09:27:58 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 9701710B69822; Mon, 19 Jan 2026 10:27:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1768814878; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=QO0a3o9xTofyckkMjL1Y/gdZw32YkbHo0CE1eCRMHCI=; b=BPkFrCJIXEObVHgwmOFiAVu4V3QldAy8U2FZjIRU3PYtj8BQ+3uH9pxG/cucWuIpmc57nt 1Wx2nj4+UEMv/TClfb03AT1v/EY6cg8tWFLd/6zt1zJDuTkmWHX5fz70Usmw6weHbx9pXo sdHqgk95XC9wxcVLbh0gS85HWqYMfr4cslsaOdmjvXFI9Jjt0ciRdXoz9S7E/sezOIEPZU bvCxPZ/n7JgCAFTvCNY8NeBjZCQErTxFqnrPAZHeMG4NGFYKsqTap+asaz2FzjOw/28HdU QFScPtUlRYzXA+ffyNfk9fm5Gi9qfQndCTw7B26fsxD2p8fHk2P6PT0BXHoLBg== Message-ID: Date: Mon, 19 Jan 2026 10:27:52 +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 RFC net-next v2 1/2] net: phy: marvell: 88e1111: define gigabit features To: "Russell King (Oracle)" , Josua Mayer Cc: Andrew Lunn , Heiner Kallweit , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260101-cisco-1g-sfp-phy-features-v2-0-47781d9e7747@solid-run.com> <20260101-cisco-1g-sfp-phy-features-v2-1-47781d9e7747@solid-run.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, Josua, On 02/01/2026 13:47, Russell King (Oracle) wrote: > If the operational mode of the PHY is reconfigured at runtime, then I > think it would be reasonable to re-read the supported linkmodes. > However, I think this will cause issues for phylink, as currently it > wants to know the link modes that are supported so it can choose an > appropriate interface mode. Russell, I agree that your patches for phydev->supported_interfaces are required, but I also think we need another piece of the puzzle to solve Josua's issue. >From what I get, it's impossible from the PHY driver's perspective only, to know which configuration the PHY is in, i.e. is it in : 1000X to 1000T SGMII to 1000T SGMII to something else ? This is one of the issues I was facing with the SGMII to 100FX adapters. Selecting the right phy_interface, is one thing, but it doesn't address the fact that whe don't know which linkmodes to put in phydev->supported. The approach I took to address that is in patch 3 of this series [1] : - The SFP's eeprom should ideally store information about the MDI of the module, is it outputing fiber at 1G, at 100M, is it BaseT, etc. - in sfp_sm_probe_phy(), we have the sfp_module_caps fully parsed, with fixups and quirks applied, so what I do is store a pointer to those in struct phy_device - The PHY driver can then use that in its .get_features() to report the proper linkmodes. Of course, this may not be the right approach. What do we trust more, the SFP eeprom, or the PHY's reported linkmodes through features discovery ? IMO relying on the SFP subsystem to build a proper list of linkmodes we can achieve on the module is a bit better, as we have the opportunity to apply fixups and quirks. Maxime [1] : https://lore.kernel.org/all/20260114225731.811993-1-maxime.chevallier@bootlin.com/#t