This patch adds ethernet PHY reset GPIO config for Beaglebone Black
series boards with revision C3. This fixes a random phy startup failure
bug discussed at [1]. The GPIO pin used for reset is not used on older
revisions, so it is ok to apply to all board revisions. The reset timing
was discussed and tested at [2].
[1] https://forum.digikey.com/t/ethernet-device-is-not-detecting-on-ubuntu-20-04-lts-on-bbg/19948
[2] https://forum.beagleboard.org/t/recognizing-a-beaglebone-black-rev-c3-board/31249/
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Shengyu Qu <[email protected]>
---
Changes since v1:
- Using /**/ rather than // to comment
---
arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi b/arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
index 7b784a87efc6..96451c8a815c 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
@@ -145,6 +145,8 @@ davinci_mdio_default: davinci-mdio-default-pins {
/* MDIO */
AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLUP | SLEWCTRL_FAST, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLUP, MUX_MODE0)
+ /* Added to support GPIO controlled PHY reset */
+ AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_OUTPUT_PULLUP, MUX_MODE7)
>;
};
@@ -153,6 +155,8 @@ davinci_mdio_sleep: davinci-mdio-sleep-pins {
/* MDIO reset value */
AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MDC, PIN_INPUT_PULLDOWN, MUX_MODE7)
+ /* Added to support GPIO controlled PHY reset */
+ AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_INPUT_PULLDOWN, MUX_MODE7)
>;
};
@@ -378,6 +382,10 @@ &davinci_mdio_sw {
ethphy0: ethernet-phy@0 {
reg = <0>;
+ /* Support GPIO reset on revision C3 boards */
+ reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <300>;
+ reset-deassert-us = <6500>;
};
};
--
2.41.0
* Shengyu Qu <[email protected]> [230806 11:51]:
> This patch adds ethernet PHY reset GPIO config for Beaglebone Black
> series boards with revision C3. This fixes a random phy startup failure
> bug discussed at [1]. The GPIO pin used for reset is not used on older
> revisions, so it is ok to apply to all board revisions. The reset timing
> was discussed and tested at [2].
Nice, should we add some Fixes tag for this so it gets applied to
the stable kernels automatically?
Regards,
Tony
Hello Tony,
I think that's OK. What should I do?
Best regards,
Shengyu
> * Shengyu Qu <[email protected]> [230806 11:51]:
>> This patch adds ethernet PHY reset GPIO config for Beaglebone Black
>> series boards with revision C3. This fixes a random phy startup failure
>> bug discussed at [1]. The GPIO pin used for reset is not used on older
>> revisions, so it is ok to apply to all board revisions. The reset timing
>> was discussed and tested at [2].
> Nice, should we add some Fixes tag for this so it gets applied to
> the stable kernels automatically?
>
> Regards,
>
> Tony
* Shengyu Qu <[email protected]> [230809 11:33]:
> I think that's OK. What should I do?
Can you check if there is maybe some earlier Linux kernel commit
that this fixes?
If so we can have a Fixes tag and it will be applied automatically
to the stable kernels.
If it's adding new feature and no Fixes tag can be set, I can just
add Cc: stable for it.
Regards,
Tony
Hi Tony,
No commit is fixed by this, since this is a hardware design problem on
older revision board. :(
Best regards,
Shengyu
> * Shengyu Qu <[email protected]> [230809 11:33]:
>> I think that's OK. What should I do?
> Can you check if there is maybe some earlier Linux kernel commit
> that this fixes?
>
> If so we can have a Fixes tag and it will be applied automatically
> to the stable kernels.
>
> If it's adding new feature and no Fixes tag can be set, I can just
> add Cc: stable for it.
>
> Regards,
>
> Tony
* Shengyu Qu <[email protected]> [230810 13:48]:
> Hi Tony,
>
> No commit is fixed by this, since this is a hardware design problem on
>
> older revision board. :(
OK no worries, I'll add both to omap-for-v6.5/fixes. Depending how the
current -rc cycle goes, it may not get merged until for v6.6-rc1 FYI.
Thanks,
Tony