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-mibo... nas220 https://patchwork.ozlabs.org/project/uboot/patch/cd6ec4ef-8c17-c340-f3d7-555...
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