[PATCH] arm: kirkwood: Sheevaplug : Use Marvell uclass mvgbe and PHY driver for Ethernet
Stefan Roese
sr at denx.de
Wed Mar 23 07:56:57 CET 2022
Hi Tony,
On 3/22/22 22:20, Tony Dinh wrote:
> I did a review for the Kirkwood boards regarding the
> CONFIG_RESET_PHY_R usage. Here is my finding, and also a suggestion
> below to go forward with the conflict patches.
>
> There are about 25 out of the total of 33 Kirkwood boards that either
> use CONFIG_RESET_PHY_R to invoke reset_phy(), or don't use
> CONFIG_RESET_PHY_R at all. And CONFIG_RESET_PHY_R is necessary for the
> boards that have reset_phy(), because even though we have DM_ETH
> enabled on these boards, the reset_phy() invokes miiphy_xxx calls to
> do ad-hoc setups for the board. CONFIG_PHY_MARVELL is not enabled, so
> the proper Marvell PHY driver is not used.
>
> d2net_v2_defconfig
> dns325_defconfig
> ds109_defconfig
> guruplug_defconfig
> ib62x0_defconfig
> inetspace_v2_defconfig
> kmcoge5un_defconfig
> km_kirkwood_128m16_defconfig
> km_kirkwood_defconfig
> km_kirkwood_pci_defconfig
> kmnusa_defconfig
> kmsuse2_defconfig
> lschlv2_defconfig
> lsxhl_defconfig
> net2big_v2_defconfig
> netspace_lite_v2_defconfig
> netspace_max_v2_defconfig
> netspace_mini_v2_defconfig
> netspace_v2_defconfig
> nsa310s_defconfig
> openrd_base_defconfig
> openrd_client_defconfig
> openrd_ultimate_defconfig
> SBx81LIFKW_defconfig
> SBx81LIFXCAT_defconfig
>
> I have converted another 6 boards to use DM_ETH and PHY_MARVELL, so
> these 6 do not use CONFIG_RESET_PHY_R.
>
> dockstar_defconfig
> dreamplug_defconfig
> goflexhome_defconfig
> iconnect_defconfig
> pogo_e02_defconfig
> pogo_v4_defconfig
>
> Currently, we have 2 patches pending for 2 boards. The Sheevaplug (by
> me) and NAS220 (by Hajo Noerenberg). These 2 patches implement DM_ETH
> and PHY_MARVELL, so we are removing CONFIG_RESET_PHY_R in these 2
> boards. But we also add undef CONFIG_RESET_PHY_R.
>
> These 2 pending patches conflict with Tom's patch to move
> CONFIG_RESET_PHY_R to Kconfig.
> sheevaplug
> https://patchwork.ozlabs.org/project/uboot/patch/20220306231220.31868-1-mibodhi@gmail.com/
> nas220
> https://patchwork.ozlabs.org/project/uboot/patch/cd6ec4ef-8c17-c340-f3d7-555e17878fb1@noerenberg.de/
>
> So 1st approach is: we will hold off on these 2 pending patches. And
> wait for Tom's patch to merge to master. And then we will send another
> patch version (version 2 for Sheevaplug, and version 4 for NSA220).
Good.
> The 2nd approach is: I will send in another patch to revert Tom's
> change to these 2 defconfigs, and then the 2 pending patches can be
> applied cleanly. And I send in another patch to reverse the undefs for
> CONFIG_RESET_PHY_R.
>
> I'd vote for the 1st approach, because by holding off the 2 pending
> patches, we don't lose any functionality in the meantime. And it will
> be much easier to do.
Yes, please let's move this way.
Thanks,
Stefan
More information about the U-Boot
mailing list