| Message ID | 20240314-for-mediatek-mt7531-phy-address-v1-1-52f58db01acd@arinc9.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Set PHY address of MT7531 switch to 0x1f on MediaTek arm64 boards | expand |
On 3/14/24 05:20, Arınç ÜNAL via B4 Relay wrote: > From: Arınç ÜNAL <arinc.unal@arinc9.com> > > The MT7531 switch listens on PHY address 0x1f on an MDIO bus. I've got two > findings that support this. There's no bootstrapping option to change the > PHY address of the switch. The Linux driver hardcodes 0x1f as the PHY > address of the switch. So the reg property on the device tree is currently > ignored by the Linux driver. > > Therefore, describe the correct PHY address on boards that have this > switch. Can we call it a pseudo PHY to use a similar terminology as what is done through drivers/net/dsa/{bcm_sf2,b53}*? This is not a real PHY as in it has no actual transceiver/digital signal processing logic, this is a piece of logic that snoops for MDIO transactions at that specific address and lets you access the switch's internal register as if it was a MDIO device. LGTM otherwise!
On 3/16/2024 12:43 AM, Arınç ÜNAL wrote: > On 15.03.2024 20:26, Florian Fainelli wrote: >> On 3/14/24 05:20, Arınç ÜNAL via B4 Relay wrote: >>> From: Arınç ÜNAL <arinc.unal@arinc9.com> >>> >>> The MT7531 switch listens on PHY address 0x1f on an MDIO bus. I've >>> got two >>> findings that support this. There's no bootstrapping option to change >>> the >>> PHY address of the switch. The Linux driver hardcodes 0x1f as the PHY >>> address of the switch. So the reg property on the device tree is >>> currently >>> ignored by the Linux driver. >>> >>> Therefore, describe the correct PHY address on boards that have this >>> switch. >> >> Can we call it a pseudo PHY to use a similar terminology as what is >> done through drivers/net/dsa/{bcm_sf2,b53}*? >> >> This is not a real PHY as in it has no actual transceiver/digital >> signal processing logic, this is a piece of logic that snoops for MDIO >> transactions at that specific address and lets you access the switch's >> internal register as if it was a MDIO device. > > I can get behind calling the switch a psuedo-PHY in the context of MDIO. > However, as described on "22.2.4.5.5 PHYAD (PHY Address)" of "22.2.4.5 > Management frame structure" of the active standard IEEE Std 802.3™‐2022, > the field is called "PHY Address". The patch log doesn't give an identifier > as to what a switch is in the context of MDIO. Only that it listens on a > certain PHY address which the term complies with IEEE Std 802.3™‐2022. > > So I don't see an improvement to be made on the patch log. Feel free to > elaborate further. I would just s/PHY/MDIO bus address/ since that is simply more generic, but if it is not written as-is in the spec, then I won't fight it much more than I already did.
On 3/18/24 08:26, Arınç ÜNAL wrote: > On 18.03.2024 16:02, Florian Fainelli wrote: >>>> Can we call it a pseudo PHY to use a similar terminology as what is >>>> done through drivers/net/dsa/{bcm_sf2,b53}*? >>>> >>>> This is not a real PHY as in it has no actual transceiver/digital >>>> signal processing logic, this is a piece of logic that snoops for >>>> MDIO transactions at that specific address and lets you access the >>>> switch's internal register as if it was a MDIO device. >>> >>> I can get behind calling the switch a psuedo-PHY in the context of MDIO. >>> However, as described on "22.2.4.5.5 PHYAD (PHY Address)" of "22.2.4.5 >>> Management frame structure" of the active standard IEEE Std 802.3™‐2022, >>> the field is called "PHY Address". The patch log doesn't give an >>> identifier >>> as to what a switch is in the context of MDIO. Only that it listens on a >>> certain PHY address which the term complies with IEEE Std 802.3™‐2022. >>> >>> So I don't see an improvement to be made on the patch log. Feel free to >>> elaborate further. >> >> I would just s/PHY/MDIO bus address/ since that is simply more >> generic, but if it is not written as-is in the spec, then I won't >> fight it much more than I already did. > > I'm not sure what you're referring to by spec. Are you asking how specific > the name of the PHYAD field is described on the standard? Spec = IEEE Std 802.3-2022 standard, aka the document you are quoting.
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts index 224bb289660c..811b227d6f50 100644 --- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts +++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts @@ -149,9 +149,9 @@ mdio: mdio-bus { #address-cells = <1>; #size-cells = <0>; - switch@0 { + switch@1f { compatible = "mediatek,mt7531"; - reg = <0>; + reg = <0x1f>; interrupt-controller; #interrupt-cells = <1>; interrupts-extended = <&pio 53 IRQ_TYPE_LEVEL_HIGH>; diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts index 41629769bdc8..3c2423cb38fd 100644 --- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts +++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts @@ -134,9 +134,9 @@ mdio-bus { #address-cells = <1>; #size-cells = <0>; - switch@0 { + switch@1f { compatible = "mediatek,mt7531"; - reg = <0>; + reg = <0x1f>; reset-gpios = <&pio 54 0>; ports {