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 4092A339708; Wed, 3 Jun 2026 09:48:35 +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=1780480117; cv=none; b=ijLv/IqV00IJ3pOxLbpvkXjhbUmjvHp0IemwxPVXmbXMrcyQBuUsX5swiSSBADUUJc1I3CHtbl+3Y847ayhNuWdkx9zTJrjBQb2dz4iJ/3CXcUAAsaBp/Dq06H72SalEyVuS83ZZT7/KSickn60CfL4W7t9Lz2PBd2MFPDHUBzE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780480117; c=relaxed/simple; bh=hDnLDvhqbVCU2VOwBDHfh7+5jqwgjR/RNFzjS3fwavM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Xi4fQwW+F91v9CRzU9CSNENKR9PRkFn+r+MkMc5v3PNBMWhpZu4Pexxdv9W9LIn3kgoD5GcF+xYT12lsipRt7+S8Eh8NuajSl4fDS/9zsiY9zUvqvtVEIqcGTQWEJRkdKjyK4wwB0joBpOrwKNRu2VHjugFWCATwf+lDResNACM= 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=m0prZVM6; 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="m0prZVM6" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id BB11A1A378D; Wed, 3 Jun 2026 09:48:33 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 856715FFA8; Wed, 3 Jun 2026 09:48:33 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 691CE10888CC5; Wed, 3 Jun 2026 11:48:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1780480112; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=lsa284HlyvD7YcDPlDuDUhOG7yi8maBQiEgj343AeqA=; b=m0prZVM6kdyfWz2eQLzUPyjLAzhR+2OFD/pJEx8SLeVIojbAKA/nvTwxnUkmsx0gnFe6XE Mmns3gtmmSm0Y7AS0b20ZnzN6NRcH9OSF0j0BrfNIC56z3cN0doJkk6klJntbpdJHuJtqX Ie51OjubB4NGaKNbUVDQMQzcaPaxxkbxjxTSiVn0Y8tvmSiaBgn2OIofYYs9NjvLt22+1P Na8Lzqn3OYkJF6sKzznG/3VnMm49oTSknwDz2bX+d4cqF+60A2S1EMlt7W/wytO7l+ma09 /8oweZqQVr5RqlWk+qxOh6i/TPBYbO9Ezssi3AnCcjjSSVl8x/1qhsZDC/KiZw== Message-ID: Date: Wed, 3 Jun 2026 11:48:27 +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 v1 1/5] net: phy: realtek: add support for dummy phy To: Javen , "hkallweit1@gmail.com" , "nic_swsd@realtek.com" , "andrew+netdev@lunn.ch" , "davem@davemloft.net" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "horms@kernel.org" Cc: "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20260603065916.334-1-javen_xu@realsil.com.cn> <20260603065916.334-2-javen_xu@realsil.com.cn> <7496c873-fee7-4584-ad70-4315d7b94f8f@bootlin.com> <0bc2ae0e-316c-447e-9098-f18f4b491328@bootlin.com> <7c35fa5bb5f24afdb42e2d45a4e559c3@realsil.com.cn> Content-Language: en-US From: Maxime Chevallier In-Reply-To: <7c35fa5bb5f24afdb42e2d45a4e559c3@realsil.com.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 Hi, On 6/3/26 11:13, Javen wrote: >> Hi, >> >> On 6/3/26 10:00, Javen wrote: >>>> On 6/3/26 08:59, javen wrote: >>>>> From: Javen Xu >>>>> >>>>> Add support for rtl8116af dummy phy driver, match phy id and read >>>>> link speed from MII_BMCR. >>>>> >>>>> Signed-off-by: Javen Xu >>>> >>>> Can you elaborate more on why this is needed ? >>>> >>>> The cover says : >>>> " >>>> In this mode, the driver >>>> needs a dummy PHY ID so that phylib can attach to a dummy Realtek PHY >>>> driver, while selected standard PHY registers are handled through the >>>> SerDes register. >>>> " >>>> >>>> Why can't you use the SerDes registers for your PHY driver ? The >>>> phrase above suggests that the "SerDes registers" have the typical >>>> C22/45 layout. There are PHYs and PCSs out there that aren't accessed >>>> through regular MDIO with regmap being used to translate the mdio >>>> accesses done by phylib into the actual register access method used. >>>> >>>> Maxime >>>> >>> >>> Thanks for your review. >>> Maybe I shouldn't call it a "dummy" PHY. It is actually a real, dedicated PHY >> driver for the RTL8116af operating in Fiber/SerDes mode. The reason we >> cannot use the standard generic PHY driver is that hardware does not >> correctly populate the standard Gigabit Status Register (MII_STAT1000, Reg >> 0x0a). >>> Here is a snippet of our MDIO read trace during link up: >>> r8169 0000:85:00.1: MDIO read: tp->ocp_base=0xa400, reg=0x0a, >>> value=0x0000 >>> r8169 0000:85:00.1: MDIO read: tp->ocp_base=0xa400, reg=0x05, >>> value=0x41a0 Reg 0x0a returns 0x0000, the phylib generic status parser fails >> to resolve the 1000Mbps link, causing the driver to incorrectly fall back to a >> forced 10Mbps, even though the physical link is actually UP at 1000Mbps. >> Therefore, we need to register a custom PHY driver to provide a >> specific .read_status callback that parses MII_BMCR instead of relying on >> MII_STAT1000. >> >> This behaviour of not getting proper information through the standard >> register happens on multiple different PHYs, so having a dedicated driver is >> the way to go indeed. >> >> What does this PHY do exactly, does it connect to an SFP cage as the name >> seems to imply ? If so, what kind of mode can it support ? >> 1000BaseX/100BaseX, maybe SGMII as well ? >> >> What I don't quite understand then is why you have the need to return a >> custom PHY ID that matches that "dummy" driver, in the next patch. >> >> If this is a regular PHY with C22 registers, what's the original content of >> PHYSID1/2 ? M >> >> Can you explain what the hardware looks like exactly ? What are the different >> components involved, etc ? >> >> Maxime > > It supports 1000BaseX mode. Ok, but the driver for the "dummy" phy seems to be able to report SPEED_100, which you can't achieve with 1000BaseX. Either this is a stray check in the PHY driver, or there's more to it than 1000BaseX :) Also, if this is 1000BaseX maybe you need to use the C37 helpers to read the link status : https://elixir.bootlin.com/linux/v7.1-rc5/source/drivers/net/phy/phy_device.c#L2607 > The datapath in Fiber mode is strictly and simply: MAC -> PCS -> SerDes. MAC accesses the PCS registers via MAC OCP channel. Although it is accessed via MAC OCP, the register definitions at those addresses are exactly the same as the IEEE 802.3 Clause 22 PHY standard registers. > Reading Reg 0x02 and 0x03 via this MAC OCP interface simply returns 0x00000000. > [ 1671.299837] r8169 0000:85:00.1: 8116af read: reg=0x02, value=0x0000 > [ 1671.299906] r8169 0000:85:00.1: 8116af read: reg=0x03, value=0x0000 > So we need a dummy phy id to attach phy driver. So this PHY actually doesn't exist ? what you have is a PCS that you access over MDIO, right ? It seems it all boils down to how the realtek MAC driver deals with PHYs and PCSs and SFP, that is without using phylink or the SFP infrastructure at all :( Can you check for the C37 thing and the SPEED_100 reporting ? Maxime > > BRs, > Javen >