On Sat, 26 Jan 2019 at 01:14, Sergey Kubushyn <k...@koi8.net> wrote: > Thanks for a reply. The problem here is not with leftover descriptors -- it > is MDIO bus not working at all. It is either bogus speed/clock in DM mode or > something else that I haven't found yet. Reading all zeroes means there is > no communication with the PHY whatsoever, it comes from bare wire. And there > is no need for the PHY to be present at all for an MDIO transaction to > complete successfully -- PHY is a slave device with all clocks coming from > FEC MDIO so it WILL complete successfully even if it not connected to a PHY. > It is kinda like SPI that always succeeds for the master.
What I found when debugging the Linux driver is that an MII interrupt was being delivered too early after the first MDIO read the driver issues, resulting in it reading back the wrong value. I was able to reliably stop this from happening by zeroing out ENET_MMFR immediately before the driver sets ENET_MSCR. If I disable networking in U-Boot then the problem in the Linux driver doesn't occur at all, so the only explanation I can come up with is that U-Boot is somehow leaving something in ENET_MMFR which is being unintentionally triggered when the Linux driver sets ENET_MSCR. You have a very good point though because the reads are still completing in U-Boot, even if they always come back zero, so I'm not really sure how there would end up being something left over in ENET_MMFR. Chris _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
