Le 18/08/2010 01:16, Ilya Yanok a écrit : > Hello Ben, Everybody, > > some boards used to have their PHY quirks in board-specific reset_phy() > function. This used to work because of reset_phy() being called later > than Ethernet drivers initialization during startup. > But nowadays some drivers (in particular I faced this problem using > mpc5xxx_fec driver) use 'on demand' PHY initialization, and > board-specific quirks don't have effect any more... Actually, > CONFIG_RESET_PHY_R is broken even without 'on demand' PHY > initialization: at least mpc5xxx_fec driver can decide to reinit PHY > during normal operation and board-specific reset_phy() function won't be > called in this case too... Another design flaw of the CONFIG_RESET_PHY_R > feature is that boards with more than one Ethernet controller are pretty > common today and usually we want to initialize only the PHY connected to > the controller we are trying to use at the moment and there is no way to > tell the reset_phy() function which PHY we want to reset... > > Ben, do you have any ideas how we could fix this? > > I believe on of possible solutions here would be to introduce generic > PHY layer in U-Boot but unfortunately this would be too much efforts for > us in this project... Maybe somebody is aware of such work being done so > we can join? > > Regards, Ilya.
Hi Ilya, At the moment your problem is not being able to reset the PHY at times other than boot, i.e. the 'PHY API' would be limited to reset_phy() which is pretty much board-specific anyway. What prevents simply adding calls to reset_phy() to the driver? It needs them anyway, so it will never be compiled without a reset_phy() to call, right? Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot