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