Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external RTL8365MB
There is no Device Tree description of the RTL8365MB switch, can it be
driven/controlled via MDIO, SPI or GPIOs by any chance? This is not a
show stopper for accepting the patch, just wondering if you are somehow
trying to get that switch controlled by the rtl8366 DSA driver as well?
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external RTL8365MB
There is no Device Tree description of the RTL8365MB switch, can it be
driven/controlled via MDIO, SPI or GPIOs by any chance? This is not a
show stopper for accepting the patch, just wondering if you are somehow
trying to get that switch controlled by the rtl8366 DSA driver as well?
There's a v1 patch on net-next adding DSA support for RTL8365MB by Alvin Šipraga, CC'ing them. There's also a v2 patch coming.
https://lore.kernel.org/netdev/20210822193145.1312668-1-alvin@pqrs.dk/
I've been mailing Alvin to figure out how to define it on the device tree. They have provided very useful information. Quoting a few:
quoted
I'm trying to write the device tree to support this switch. I'm not sure
whether the default GPIO IDs of mdc-gpios, mdio-gpios, reset-gpios &
interrupts on realtek-smi.txt kernel documentation are correct.
These gpios are just an example. It really depends how your board is
wired up. You have to figure out which SoC pad is wired to the MDC,
MDIO, and RESET pins on the RTL8365MB. Then you have to make sure the
pinmux is set up correctly so that these pads correspond to some GPIO
with a given ID, and then pick the right GPIO controller (&chipcommon?)
and put the ID after that. It will not necessarily be 21, 22, 14.
In summary:
- figure out which pads are wired to MDC, MDIO, RESET
- figure out pinmux to make them into gpios
- figure out gpio ID and describe that in the device tree
I have backported the v1 patch to kernel 5.10 and tried an example definition on the device tree to test it out on RT-AC88U. It's on this branch:
https://github.com/arinc9/openwrt/commits/realtek-work-asus_rt-ac88u
It doesn't work as is, likely missing further configuration, which I'm clueless to figure out myself. I'd very appreciate it if you could weigh in.
[ 1.598858] realtek-smi switch@1: failed to get RESET GPIO
---
[ 3.015528] realtek-smi switch@1: deasserted RESET
[ 3.021171] realtek-smi switch@1: found an RTL8365MB-VC switch (ver=0x0040)
[ 3.028193] realtek-smi switch@1: unable to register switch ret = -517
---
[ 3.405527] realtek-smi switch@1: deasserted RESET
[ 3.411165] realtek-smi switch@1: found an RTL8365MB-VC switch (ver=0x0040)
[ 3.418449] DSA: tree 0 already setup! Disjoint trees?
[ 3.423607] realtek-smi switch@1: unable to register switch ret = -17
[ 3.430137] realtek-smi: probe of switch@1 failed with error -17
---
I was thinking, we figure out how to define it properly on the device tree and make the driver work whilst the v2 patch is applied to net-next. Then we could send another patch defining the switch on the device tree.
There's the "compatible = "realtek,rtl8365mb";" property, which would be undefined until the driver is added.
Cheers.
Arınç
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external RTL8365MB
There is no Device Tree description of the RTL8365MB switch, can it be
driven/controlled via MDIO, SPI or GPIOs by any chance? This is not a
show stopper for accepting the patch, just wondering if you are somehow
trying to get that switch controlled by the rtl8366 DSA driver as well?
There's a v1 patch on net-next adding DSA support for RTL8365MB by Alvin Šipraga, CC'ing them. There's also a v2 patch coming.
https://lore.kernel.org/netdev/20210822193145.1312668-1-alvin@pqrs.dk/
I've been mailing Alvin to figure out how to define it on the device tree. They have provided very useful information. Quoting a few:
>> I'm trying to write the device tree to support this switch. I'm not sure
>> whether the default GPIO IDs of mdc-gpios, mdio-gpios, reset-gpios &
>> interrupts on realtek-smi.txt kernel documentation are correct.
>> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
>
> These gpios are just an example. It really depends how your board is
> wired up. You have to figure out which SoC pad is wired to the MDC,
> MDIO, and RESET pins on the RTL8365MB. Then you have to make sure the
> pinmux is set up correctly so that these pads correspond to some GPIO
> with a given ID, and then pick the right GPIO controller (&chipcommon?)
> and put the ID after that. It will not necessarily be 21, 22, 14.
> In summary:
>
> - figure out which pads are wired to MDC, MDIO, RESET
> - figure out pinmux to make them into gpios
> - figure out gpio ID and describe that in the device tree
>
I have backported the v1 patch to kernel 5.10 and tried an example definition on the device tree to test it out on RT-AC88U. It's on this branch:
https://github.com/arinc9/openwrt/commits/realtek-work-asus_rt-ac88u
Your dsa,member proper looks reversed, you would want it to be:
dsa,member = <1 0>;
to indicate that these are indeed disjoint DSA trees with the tree being 1 and the switch being member 0 (the one and only). This part of the driver/binding looks a bit weird too:
switch@1 {
+ compatible = "realtek,rtl8365mb";
+ /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
+ mdc-gpios = <&chipcommon 6 GPIO_ACTIVE_HIGH>;
+ mdio-gpios = <&chipcommon 7 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&chipcommon 14 GPIO_ACTIVE_LOW>;
this is clearly a MDIO-attached switch, so it should be a children of the GPIO controller node. There is a hardware MDIO controller on the BCM5301X so you should be able to avoid using bit-banging here and instead using the BCM5301X's MDIO controller proper.
It doesn't work as is, likely missing further configuration, which I'm clueless to figure out myself. I'd very appreciate it if you could weigh in.
[ 1.598858] realtek-smi switch@1: failed to get RESET GPIO
---
[ 3.015528] realtek-smi switch@1: deasserted RESET
[ 3.021171] realtek-smi switch@1: found an RTL8365MB-VC switch (ver=0x0040)
[ 3.028193] realtek-smi switch@1: unable to register switch ret = -517
---
[ 3.405527] realtek-smi switch@1: deasserted RESET
[ 3.411165] realtek-smi switch@1: found an RTL8365MB-VC switch (ver=0x0040)
[ 3.418449] DSA: tree 0 already setup! Disjoint trees?
[ 3.423607] realtek-smi switch@1: unable to register switch ret = -17
[ 3.430137] realtek-smi: probe of switch@1 failed with error -17
---
I was thinking, we figure out how to define it properly on the device tree and make the driver work whilst the v2 patch is applied to net-next. Then we could send another patch defining the switch on the device tree.
There's the "compatible = "realtek,rtl8365mb";" property, which would be undefined until the driver is added.
That works for me, which is why I already applied your patch.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external RTL8365MB
There is no Device Tree description of the RTL8365MB switch, can it be
driven/controlled via MDIO, SPI or GPIOs by any chance? This is not a
show stopper for accepting the patch, just wondering if you are somehow
trying to get that switch controlled by the rtl8366 DSA driver as well?
There's a v1 patch on net-next adding DSA support for RTL8365MB by Alvin Šipraga, CC'ing them. There's also a v2 patch coming.
https://lore.kernel.org/netdev/20210822193145.1312668-1-alvin@pqrs.dk/
I've been mailing Alvin to figure out how to define it on the device tree. They have provided very useful information. Quoting a few:
>> I'm trying to write the device tree to support this switch. I'm not sure
>> whether the default GPIO IDs of mdc-gpios, mdio-gpios, reset-gpios &
>> interrupts on realtek-smi.txt kernel documentation are correct.
>> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
>
> These gpios are just an example. It really depends how your board is
> wired up. You have to figure out which SoC pad is wired to the MDC,
> MDIO, and RESET pins on the RTL8365MB. Then you have to make sure the
> pinmux is set up correctly so that these pads correspond to some GPIO
> with a given ID, and then pick the right GPIO controller (&chipcommon?)
> and put the ID after that. It will not necessarily be 21, 22, 14.
> In summary:
>
> - figure out which pads are wired to MDC, MDIO, RESET
> - figure out pinmux to make them into gpios
> - figure out gpio ID and describe that in the device tree
>
I have backported the v1 patch to kernel 5.10 and tried an example definition on the device tree to test it out on RT-AC88U. It's on this branch:
https://github.com/arinc9/openwrt/commits/realtek-work-asus_rt-ac88u
Your dsa,member proper looks reversed, you would want it to be:
dsa,member = <1 0>;
Thanks!
to indicate that these are indeed disjoint DSA trees with the tree being 1 and the switch being member 0 (the one and only). This part of the driver/binding looks a bit weird too:
switch@1 {
+ compatible = "realtek,rtl8365mb";
+ /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
+ mdc-gpios = <&chipcommon 6 GPIO_ACTIVE_HIGH>;
+ mdio-gpios = <&chipcommon 7 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&chipcommon 14 GPIO_ACTIVE_LOW>;
this is clearly a MDIO-attached switch, so it should be a children of the GPIO controller node. There is a hardware MDIO controller on the BCM5301X so you should be able to avoid using bit-banging here and instead using the BCM5301X's MDIO controller proper.
I took linksys panamera device tree as an example, this device is very similar to Asus RT-AC88U.
https://github.com/Broadcom/stblinux/blob/devicetree/next/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
I commented out the "reg" property on switch@1 so we can see if it finds the switch while scanning PHY addresses on mdio 200.
I don't know if the default "interrupt-controller" and "compatible = "realtek,smi-mdio", "dsa-mdio";" specification is correct, so I took them out for now.
mdio-mux@18003000 {
/* BIT(9) = 1 => external mdio */
mdio@200 {
reg = <0x200>;
#address-cells = <1>;
#size-cells = <0>;
switch@1 {
compatible = "realtek,rtl8365mb";
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&chipcommon 10 GPIO_ACTIVE_LOW>;
reset-names = "robo_reset";
/* reg = <0>;*/
dsa,member = <1 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinmux_mdio>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan8";
};
port@1 {
reg = <1>;
label = "lan7";
};
port@2 {
reg = <2>;
label = "lan6";
};
port@3 {
reg = <3>;
label = "lan5";
};
port@4 {
reg = <4>;
label = "cpu";
ethernet = <&sw0_p5>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
};
Here's relevant part of the bootlog. Full bootlog is in the attachments.
[ 2.027843] bcm_iproc 18029200.spi: using bspi-mspi mode
[ 2.034744] libphy: Fixed MDIO Bus: probed
[ 2.039638] libphy: iProc MDIO bus: probed
[ 2.043764] iproc-mdio 18003000.mdio: Broadcom iProc MDIO bus registered
[ 2.051215] libphy: mdio_mux: probed
[ 2.055587] libphy: mdio_mux: probed
[ 2.059196] mdio_bus 0.200: switch@1 has invalid PHY address
[ 2.064894] mdio_bus 0.200: scan phy switch at address 0
[ 2.070231] mdio_bus 0.200: scan phy switch at address 1
[ 2.075554] mdio_bus 0.200: scan phy switch at address 2
[ 2.080894] mdio_bus 0.200: scan phy switch at address 3
[ 2.086217] mdio_bus 0.200: scan phy switch at address 4
[ 2.091549] mdio_bus 0.200: scan phy switch at address 5
[ 2.096870] mdio_bus 0.200: scan phy switch at address 6
[ 2.102202] mdio_bus 0.200: scan phy switch at address 7
[ 2.107523] mdio_bus 0.200: scan phy switch at address 8
[ 2.112864] mdio_bus 0.200: scan phy switch at address 9
[ 2.118186] mdio_bus 0.200: scan phy switch at address 10
[ 2.123608] mdio_bus 0.200: scan phy switch at address 11
[ 2.129022] mdio_bus 0.200: scan phy switch at address 12
[ 2.134442] mdio_bus 0.200: scan phy switch at address 13
[ 2.139858] mdio_bus 0.200: scan phy switch at address 14
[ 2.145274] mdio_bus 0.200: scan phy switch at address 15
[ 2.150697] mdio_bus 0.200: scan phy switch at address 16
[ 2.156110] mdio_bus 0.200: scan phy switch at address 17
[ 2.161528] mdio_bus 0.200: scan phy switch at address 18
[ 2.166937] mdio_bus 0.200: scan phy switch at address 19
[ 2.172355] mdio_bus 0.200: scan phy switch at address 20
[ 2.177764] mdio_bus 0.200: scan phy switch at address 21
[ 2.183183] mdio_bus 0.200: scan phy switch at address 22
[ 2.188592] mdio_bus 0.200: scan phy switch at address 23
[ 2.194011] mdio_bus 0.200: scan phy switch at address 24
[ 2.199427] mdio_bus 0.200: scan phy switch at address 25
[ 2.204834] mdio_bus 0.200: scan phy switch at address 26
[ 2.210253] mdio_bus 0.200: scan phy switch at address 27
[ 2.215662] mdio_bus 0.200: scan phy switch at address 28
[ 2.221080] mdio_bus 0.200: scan phy switch at address 29
[ 2.226490] mdio_bus 0.200: scan phy switch at address 30
[ 2.231914] mdio_bus 0.200: scan phy switch at address 31
[ 2.237939] b53-srab-switch 18007000.ethernet-switch: found switch: BCM53012, rev 0
[ 2.245957] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
Looks like the switch is not on 0x200, what else can we try?
Arınç
Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external RTL8365MB
There is no Device Tree description of the RTL8365MB switch, can it be
driven/controlled via MDIO, SPI or GPIOs by any chance? This is not a
show stopper for accepting the patch, just wondering if you are somehow
trying to get that switch controlled by the rtl8366 DSA driver as well?
There's a v1 patch on net-next adding DSA support for RTL8365MB by
Alvin Šipraga, CC'ing them. There's also a v2 patch coming.
https://lore.kernel.org/netdev/20210822193145.1312668-1-alvin@pqrs.dk/
I've been mailing Alvin to figure out how to define it on the device
tree. They have provided very useful information. Quoting a few:
>> I'm trying to write the device tree to support this switch. I'm
not sure
>> whether the default GPIO IDs of mdc-gpios, mdio-gpios, reset-gpios &
>> interrupts on realtek-smi.txt kernel documentation are correct.
>>
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
>
> These gpios are just an example. It really depends how your board is
> wired up. You have to figure out which SoC pad is wired to the MDC,
> MDIO, and RESET pins on the RTL8365MB. Then you have to make sure the
> pinmux is set up correctly so that these pads correspond to some GPIO
> with a given ID, and then pick the right GPIO controller
(&chipcommon?)
> and put the ID after that. It will not necessarily be 21, 22, 14.
> In summary:
>
> - figure out which pads are wired to MDC, MDIO, RESET
> - figure out pinmux to make them into gpios
> - figure out gpio ID and describe that in the device tree
>
I have backported the v1 patch to kernel 5.10 and tried an example
definition on the device tree to test it out on RT-AC88U. It's on
this branch:
https://github.com/arinc9/openwrt/commits/realtek-work-asus_rt-ac88u
Your dsa,member proper looks reversed, you would want it to be:
dsa,member = <1 0>;
Thanks!
quoted
to indicate that these are indeed disjoint DSA trees with the tree
being 1 and the switch being member 0 (the one and only). This part of
the driver/binding looks a bit weird too:
switch@1 {
+ compatible = "realtek,rtl8365mb";
+ /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
+ mdc-gpios = <&chipcommon 6 GPIO_ACTIVE_HIGH>;
+ mdio-gpios = <&chipcommon 7 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&chipcommon 14 GPIO_ACTIVE_LOW>;
this is clearly a MDIO-attached switch, so it should be a children of
the GPIO controller node. There is a hardware MDIO controller on the
BCM5301X so you should be able to avoid using bit-banging here and
instead using the BCM5301X's MDIO controller proper.
I took linksys panamera device tree as an example, this device is very
similar to Asus RT-AC88U.
https://github.com/Broadcom/stblinux/blob/devicetree/next/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
I commented out the "reg" property on switch@1 so we can see if it finds
the switch while scanning PHY addresses on mdio 200.
I don't know if the default "interrupt-controller" and "compatible =
"realtek,smi-mdio", "dsa-mdio";" specification is correct, so I took
them out for now.
mdio-mux@18003000 {
/* BIT(9) = 1 => external mdio */
mdio@200 {
reg = <0x200>;
#address-cells = <1>;
#size-cells = <0>;
switch@1 {
compatible = "realtek,rtl8365mb";
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&chipcommon 10 GPIO_ACTIVE_LOW>;
reset-names = "robo_reset";
/* reg = <0>;*/
dsa,member = <1 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinmux_mdio>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan8";
};
port@1 {
reg = <1>;
label = "lan7";
};
port@2 {
reg = <2>;
label = "lan6";
};
port@3 {
reg = <3>;
label = "lan5";
};
port@4 {
reg = <4>;
label = "cpu";
ethernet = <&sw0_p5>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
};
Here's relevant part of the bootlog. Full bootlog is in the attachments.
[ 2.027843] bcm_iproc 18029200.spi: using bspi-mspi mode
[ 2.034744] libphy: Fixed MDIO Bus: probed
[ 2.039638] libphy: iProc MDIO bus: probed
[ 2.043764] iproc-mdio 18003000.mdio: Broadcom iProc MDIO bus registered
[ 2.051215] libphy: mdio_mux: probed
[ 2.055587] libphy: mdio_mux: probed
[ 2.059196] mdio_bus 0.200: switch@1 has invalid PHY address
[ 2.064894] mdio_bus 0.200: scan phy switch at address 0
[ 2.070231] mdio_bus 0.200: scan phy switch at address 1
[ 2.075554] mdio_bus 0.200: scan phy switch at address 2
[ 2.080894] mdio_bus 0.200: scan phy switch at address 3
[ 2.086217] mdio_bus 0.200: scan phy switch at address 4
[ 2.091549] mdio_bus 0.200: scan phy switch at address 5
[ 2.096870] mdio_bus 0.200: scan phy switch at address 6
[ 2.102202] mdio_bus 0.200: scan phy switch at address 7
[ 2.107523] mdio_bus 0.200: scan phy switch at address 8
[ 2.112864] mdio_bus 0.200: scan phy switch at address 9
[ 2.118186] mdio_bus 0.200: scan phy switch at address 10
[ 2.123608] mdio_bus 0.200: scan phy switch at address 11
[ 2.129022] mdio_bus 0.200: scan phy switch at address 12
[ 2.134442] mdio_bus 0.200: scan phy switch at address 13
[ 2.139858] mdio_bus 0.200: scan phy switch at address 14
[ 2.145274] mdio_bus 0.200: scan phy switch at address 15
[ 2.150697] mdio_bus 0.200: scan phy switch at address 16
[ 2.156110] mdio_bus 0.200: scan phy switch at address 17
[ 2.161528] mdio_bus 0.200: scan phy switch at address 18
[ 2.166937] mdio_bus 0.200: scan phy switch at address 19
[ 2.172355] mdio_bus 0.200: scan phy switch at address 20
[ 2.177764] mdio_bus 0.200: scan phy switch at address 21
[ 2.183183] mdio_bus 0.200: scan phy switch at address 22
[ 2.188592] mdio_bus 0.200: scan phy switch at address 23
[ 2.194011] mdio_bus 0.200: scan phy switch at address 24
[ 2.199427] mdio_bus 0.200: scan phy switch at address 25
[ 2.204834] mdio_bus 0.200: scan phy switch at address 26
[ 2.210253] mdio_bus 0.200: scan phy switch at address 27
[ 2.215662] mdio_bus 0.200: scan phy switch at address 28
[ 2.221080] mdio_bus 0.200: scan phy switch at address 29
[ 2.226490] mdio_bus 0.200: scan phy switch at address 30
[ 2.231914] mdio_bus 0.200: scan phy switch at address 31
[ 2.237939] b53-srab-switch 18007000.ethernet-switch: found switch:
BCM53012, rev 0
[ 2.245957] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
Looks like the switch is not on 0x200, what else can we try?
0x200 is not the address of the Realtek switch on the MDIO bus, 0x200 is
the offset with mdio mux that needs to be toggled (bit 9). You still
need to provide the Ethernet switch's address on the MDIO bus which
appears to be 0.
Auto-probing of devices only works for Ethernet PHYs, not for "pure"
MDIO devices such as Ethernet switches.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external RTL8365MB
There is no Device Tree description of the RTL8365MB switch, can it be
driven/controlled via MDIO, SPI or GPIOs by any chance? This is not a
show stopper for accepting the patch, just wondering if you are somehow
trying to get that switch controlled by the rtl8366 DSA driver as well?
There's a v1 patch on net-next adding DSA support for RTL8365MB by
Alvin Šipraga, CC'ing them. There's also a v2 patch coming.
https://lore.kernel.org/netdev/20210822193145.1312668-1-alvin@pqrs.dk/
I've been mailing Alvin to figure out how to define it on the device
tree. They have provided very useful information. Quoting a few:
>> I'm trying to write the device tree to support this switch. I'm
not sure
>> whether the default GPIO IDs of mdc-gpios, mdio-gpios, reset-gpios &
>> interrupts on realtek-smi.txt kernel documentation are correct.
>>
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
>
> These gpios are just an example. It really depends how your board is
> wired up. You have to figure out which SoC pad is wired to the MDC,
> MDIO, and RESET pins on the RTL8365MB. Then you have to make sure the
> pinmux is set up correctly so that these pads correspond to some GPIO
> with a given ID, and then pick the right GPIO controller
(&chipcommon?)
> and put the ID after that. It will not necessarily be 21, 22, 14.
> In summary:
>
> - figure out which pads are wired to MDC, MDIO, RESET
> - figure out pinmux to make them into gpios
> - figure out gpio ID and describe that in the device tree
>
I have backported the v1 patch to kernel 5.10 and tried an example
definition on the device tree to test it out on RT-AC88U. It's on
this branch:
https://github.com/arinc9/openwrt/commits/realtek-work-asus_rt-ac88u
Your dsa,member proper looks reversed, you would want it to be:
dsa,member = <1 0>;
Thanks!
quoted
to indicate that these are indeed disjoint DSA trees with the tree
being 1 and the switch being member 0 (the one and only). This part of
the driver/binding looks a bit weird too:
switch@1 {
+ compatible = "realtek,rtl8365mb";
+ /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
+ mdc-gpios = <&chipcommon 6 GPIO_ACTIVE_HIGH>;
+ mdio-gpios = <&chipcommon 7 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&chipcommon 14 GPIO_ACTIVE_LOW>;
this is clearly a MDIO-attached switch, so it should be a children of
the GPIO controller node. There is a hardware MDIO controller on the
BCM5301X so you should be able to avoid using bit-banging here and
instead using the BCM5301X's MDIO controller proper.
I took linksys panamera device tree as an example, this device is very
similar to Asus RT-AC88U.
https://github.com/Broadcom/stblinux/blob/devicetree/next/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
I commented out the "reg" property on switch@1 so we can see if it finds
the switch while scanning PHY addresses on mdio 200.
I don't know if the default "interrupt-controller" and "compatible =
"realtek,smi-mdio", "dsa-mdio";" specification is correct, so I took
them out for now.
mdio-mux@18003000 {
/* BIT(9) = 1 => external mdio */
mdio@200 {
reg = <0x200>;
#address-cells = <1>;
#size-cells = <0>;
switch@1 {
compatible = "realtek,rtl8365mb";
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&chipcommon 10 GPIO_ACTIVE_LOW>;
reset-names = "robo_reset";
/* reg = <0>;*/
dsa,member = <1 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinmux_mdio>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan8";
};
port@1 {
reg = <1>;
label = "lan7";
};
port@2 {
reg = <2>;
label = "lan6";
};
port@3 {
reg = <3>;
label = "lan5";
};
port@4 {
reg = <4>;
label = "cpu";
ethernet = <&sw0_p5>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
};
Here's relevant part of the bootlog. Full bootlog is in the attachments.
[ 2.027843] bcm_iproc 18029200.spi: using bspi-mspi mode
[ 2.034744] libphy: Fixed MDIO Bus: probed
[ 2.039638] libphy: iProc MDIO bus: probed
[ 2.043764] iproc-mdio 18003000.mdio: Broadcom iProc MDIO bus registered
[ 2.051215] libphy: mdio_mux: probed
[ 2.055587] libphy: mdio_mux: probed
[ 2.059196] mdio_bus 0.200: switch@1 has invalid PHY address
[ 2.064894] mdio_bus 0.200: scan phy switch at address 0
[ 2.070231] mdio_bus 0.200: scan phy switch at address 1
[ 2.075554] mdio_bus 0.200: scan phy switch at address 2
[ 2.080894] mdio_bus 0.200: scan phy switch at address 3
[ 2.086217] mdio_bus 0.200: scan phy switch at address 4
[ 2.091549] mdio_bus 0.200: scan phy switch at address 5
[ 2.096870] mdio_bus 0.200: scan phy switch at address 6
[ 2.102202] mdio_bus 0.200: scan phy switch at address 7
[ 2.107523] mdio_bus 0.200: scan phy switch at address 8
[ 2.112864] mdio_bus 0.200: scan phy switch at address 9
[ 2.118186] mdio_bus 0.200: scan phy switch at address 10
[ 2.123608] mdio_bus 0.200: scan phy switch at address 11
[ 2.129022] mdio_bus 0.200: scan phy switch at address 12
[ 2.134442] mdio_bus 0.200: scan phy switch at address 13
[ 2.139858] mdio_bus 0.200: scan phy switch at address 14
[ 2.145274] mdio_bus 0.200: scan phy switch at address 15
[ 2.150697] mdio_bus 0.200: scan phy switch at address 16
[ 2.156110] mdio_bus 0.200: scan phy switch at address 17
[ 2.161528] mdio_bus 0.200: scan phy switch at address 18
[ 2.166937] mdio_bus 0.200: scan phy switch at address 19
[ 2.172355] mdio_bus 0.200: scan phy switch at address 20
[ 2.177764] mdio_bus 0.200: scan phy switch at address 21
[ 2.183183] mdio_bus 0.200: scan phy switch at address 22
[ 2.188592] mdio_bus 0.200: scan phy switch at address 23
[ 2.194011] mdio_bus 0.200: scan phy switch at address 24
[ 2.199427] mdio_bus 0.200: scan phy switch at address 25
[ 2.204834] mdio_bus 0.200: scan phy switch at address 26
[ 2.210253] mdio_bus 0.200: scan phy switch at address 27
[ 2.215662] mdio_bus 0.200: scan phy switch at address 28
[ 2.221080] mdio_bus 0.200: scan phy switch at address 29
[ 2.226490] mdio_bus 0.200: scan phy switch at address 30
[ 2.231914] mdio_bus 0.200: scan phy switch at address 31
[ 2.237939] b53-srab-switch 18007000.ethernet-switch: found switch:
BCM53012, rev 0
[ 2.245957] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
Looks like the switch is not on 0x200, what else can we try?
0x200 is not the address of the Realtek switch on the MDIO bus, 0x200 is
the offset with mdio mux that needs to be toggled (bit 9). You still
need to provide the Ethernet switch's address on the MDIO bus which
appears to be 0.
Oh, we flip the 9th bit. 2 to the power of 9 = 0x200. Got it!
I tried 0 and 29 as the PHY ID. I'd assume the DSA realtek-smi driver would start probing the switch, however, nothing happens. Full log in attachments.
[ 2.026772] bcm_iproc 18029200.spi: using bspi-mspi mode
[ 2.033467] libphy: Fixed MDIO Bus: probed
[ 2.038123] libphy: iProc MDIO bus: probed
[ 2.042331] iproc-mdio 18003000.mdio: Broadcom iProc MDIO bus registered
[ 2.049823] libphy: mdio_mux: probed
[ 2.054206] libphy: mdio_mux: probed
[ 2.058713] b53-srab-switch 18007000.ethernet-switch: found switch: BCM53012, rev 0
[ 2.066671] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
Quoting Documentation/devicetree/bindings/net/dsa/realtek-smi.txt for further reference.
Realtek SMI-based Switches
==========================
The SMI "Simple Management Interface" is a two-wire protocol using
bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
not use the MDIO protocol. This binding defines how to specify the
SMI-based Realtek devices.
Auto-probing of devices only works for Ethernet PHYs, not for "pure"
MDIO devices such as Ethernet switches.
0x200 is not the address of the Realtek switch on the MDIO bus, 0x200 is
the offset with mdio mux that needs to be toggled (bit 9). You still
need to provide the Ethernet switch's address on the MDIO bus which
appears to be 0.
Oh, we flip the 9th bit. 2 to the power of 9 = 0x200. Got it!
I tried 0 and 29 as the PHY ID. I'd assume the DSA realtek-smi driver
would start probing the switch, however, nothing happens. Full log in
attachments.
[ 2.026772] bcm_iproc 18029200.spi: using bspi-mspi mode
[ 2.033467] libphy: Fixed MDIO Bus: probed
[ 2.038123] libphy: iProc MDIO bus: probed
[ 2.042331] iproc-mdio 18003000.mdio: Broadcom iProc MDIO bus registered
[ 2.049823] libphy: mdio_mux: probed
[ 2.054206] libphy: mdio_mux: probed
[ 2.058713] b53-srab-switch 18007000.ethernet-switch: found switch:
BCM53012, rev 0
[ 2.066671] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
Quoting Documentation/devicetree/bindings/net/dsa/realtek-smi.txt for
further reference.
quoted
Realtek SMI-based Switches
==========================
The SMI "Simple Management Interface" is a two-wire protocol using
bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
not use the MDIO protocol. This binding defines how to specify the
SMI-based Realtek devices.
Ah this is the key here, using the MDIO controller won't work sorry
about misleading you. I suppose you will have to go back to the previous
Device Tree representation you had, but change the dsa,member property
and then you should be in business baring additional bugs/features.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoting Documentation/devicetree/bindings/net/dsa/realtek-smi.txt for
further reference.
quoted
Realtek SMI-based Switches
==========================
The SMI "Simple Management Interface" is a two-wire protocol using
bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
not use the MDIO protocol. This binding defines how to specify the
SMI-based Realtek devices.
Ah this is the key here, using the MDIO controller won't work sorry
about misleading you. I suppose you will have to go back to the previous
Device Tree representation you had, but change the dsa,member property
and then you should be in business baring additional bugs/features.
All good. After fixing "dsa,member" on the original specification, the log slightly changed. I'm going to see if I can switch to the net-next kernel on OpenWrt to test the driver further. Something might be wrong with my backport.
[ 1.377530] realtek-smi switch@1: failed to get RESET GPIO
---
[ 2.759267] realtek-smi switch@1: deasserted RESET
[ 2.764927] realtek-smi switch@1: found an RTL8365MB-VC switch (ver=0x0040)
[ 2.771956] realtek-smi switch@1: unable to register switch ret = -517
---
[ 3.149262] realtek-smi switch@1: deasserted RESET
[ 3.154906] realtek-smi switch@1: found an RTL8365MB-VC switch (ver=0x0040)
[ 3.287052] realtek-smi switch@1: failed to get parent irq: -22
[ 3.293060] realtek-smi switch@1: no interrupt support
[ 3.298211] realtek-smi switch@1: no MDIO bus node
[ 3.303025] realtek-smi switch@1: could not set up MDIO bus
[ 3.308648] realtek-smi switch@1: unable to register switch ret = -19
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel