From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (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 19E8F1A5B84; Fri, 9 Jan 2026 20:19:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767989974; cv=none; b=WqdVWN/9kq12K1h99oShFvidw28MOwsNQJd0kAZdj8FUdSv3IjZju6FWpOrUz1CVLTI3YfKGwXCEbSXR7F554snW5erraASM+UvZNtSleOrRFt4a0wIwsnf73h3cSUEAKyyyWzw/SuXqWkMz0WJkoe5vmisl78ox4CuE3xYjys0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767989974; c=relaxed/simple; bh=I2nnjmwaNfXgjLJ8SmnxPwl6ImxChekcUju5ImCnXuU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Vg6mQnTkROEFclRVDiA+lZOUu81iOaWPntHcxj5tEpOBSAWNEJlgk+vwrCRR8YyAwB9AamSi3cjV7YSpcPcDCel2c8IpaTntvWfnCYGcmX5Dpqca5r1K9NfZBdKy440AtcdWG9lYNC8AXCupxwsSTruQlLfjuj+57X9gOSs/QDs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.99) (envelope-from ) id 1veIx9-000000002ES-2XNt; Fri, 09 Jan 2026 20:19:23 +0000 Date: Fri, 9 Jan 2026 20:19:20 +0000 From: Daniel Golle To: Heiner Kallweit Cc: Andrew Lunn , Russell King , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vladimir Oltean , Michael Klein , Aleksander Jan Bajkowski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 4/5] net: phy: realtek: demystify PHYSR register location Message-ID: References: <1261b3d5-3e09-4dd6-8645-fd546cbdce62@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jan 09, 2026 at 05:31:40PM +0000, Daniel Golle wrote: > On Fri, Jan 09, 2026 at 12:26:42PM +0000, Daniel Golle wrote: > > On Fri, Jan 09, 2026 at 08:32:33AM +0100, Heiner Kallweit wrote: > > > On 1/9/2026 4:03 AM, Daniel Golle wrote: > > > > Turns out that register address RTL_VND2_PHYSR (0xa434) maps to > > > > Clause-22 register MII_RESV2. Use that to get rid of yet another magic > > > > number, and rename access macros accordingly. > > > > > > > > > > RTL_VND2_PHYSR is documented in the datasheet, at least for RTL8221B(I)-VB-CG. > > > (this datasheet is publicly available, I don't have access to other datasheets) > > > MII_RESV2 isn't documented there. Is MII_RESV2 documented in any other datasheet? > > > > No datasheet mentions the nature of paging only affecting registers > > 0x10~0x17, I've figured that out by code analysis and testing (ie. > > dumping all registers for all known/used pages using mdio-tools in > > userspace, and writing to PHYCR1 toggling BIT(13) and confirming that it > > affects the PHY in the expected way). Don't ask me why they ommit this > > in the datasheets, I suspect the people writing the datasheets are given > > some auto-generated code and also don't have unterstanding of the actual > > internals (maybe to "protect" their precious IP?). > > > > Anyway, as RTL_VND2_PHYSR is 0xa434 on MDIO_MMD_VEND2, and we know that > > 0xa400~0xa43c maps to the standard C22 registers, I concluded that > > 0xa434 on MDIO_MMD_VEND2 is identical to C22 register 0x1a, ie. > > MII_RESV2. I've also noticed that the mechanism to translate registers > > on MDIO_MMD_VEND2 to paged C22 registers only makes use of registers > > 0x10~0x17, so it became apparent that other registers are not affected > > by paging. > > > > I've confirmed all that by testing on RTL8211F and RTL8221B. As pointed > > out this also holds true for internal PHYs on r8169 which emulate C22 > > registers in the exact same way. Hence the PHY driver can be simplified, > > as there is no need to set and restore the page around the reading of > > PHYSR. > > Just did some additional testing also with r8169 (with internal 2.5G PHY > 0x001cc840), and PHYSR reads fine as MII_RESV2, letting the Ethernet > driver handle the mapping to MDIO_MMD_VEND2 instead of using a paged > read in the PHY driver. > Same for 10ec:8168 ("Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)") with PHY ID 0x001cc800 ("Generic FE-GE Realtek PHY"), works all fine with this series applied. So I agree that for r8169 this change doesn't make a difference, but for standalone PHYs it does make things more simple and also means less MDIO operations (1 instead of 3) to do the same thing.