Hi all, I come back to this thread to re-start the conversation as I still have the issue...
Le 16/04/2016 à 00:45, Alexandre Belloni a écrit : > On 16/04/2016 at 00:30:26 +0200, Andrew Lunn wrote : >> On Sat, Apr 16, 2016 at 12:17:11AM +0200, Alexandre Belloni wrote: >>> On 16/04/2016 at 00:05:08 +0200, Andrew Lunn wrote : >>>>> Trace without my patch: >>>>> libphy: MACB_mii_bus: probed >>>>> macb f8020000.ethernet eth0: Cadence GEM rev 0x00020120 at 0xf8020000 irq >>>>> 27 (fc:c2:3d:0c:6e:05) >>>>> Micrel KSZ8081 or KSZ8091 f8020000.etherne:01: attached PHY driver >>>>> [Micrel KSZ8081 or KSZ8091] (mii_bus:phy_addr=f8020000.etherne:01, >>>>> irq=171) >>>>> Micrel KSZ8081 or KSZ8091 f8020000.etherne:01: PHY state change READY -> >>>>> READY >>>>> [...] >>>>> Micrel KSZ8081 or KSZ8091 f8020000.etherne:01: PHY state change READY -> >>>>> READY >>>> >>>> Are there some state changes before this? How is it getting to state >>>> READY? It would expect it to start in DOWN, from when the phy device >>>> was created in phy_device_create(). >>>> >>> >>> No other changes. I forgot to mention that this is when booting with a >>> cable plugged in. Unplugging and replugging the cable makes the link >>> detection work fine even without the patch. >> >> Are you tftpbooting? I.e. has the boot loader already done an auto >> negotiation? >> > > Yes. Yes indeed: this is my use-case: load the kernel from U-Boot using tftp and having the rootfs in NAND flash so, no NFS rootfs for me. >> I've looked at the code and i still don't see how it gets to READY. >> What i do see is that when you connect the phy to the MAC, the >> interrupt handler is installed. So maybe there are some PHY interrupts >> before the interface is opened? Could you put a print in >> phy_interrupt(). >> > > That is indeed the case, and I'm not sure why because > 99f81afc139c6edd14d77a91ee91685a414a1c66 is trying to disable AN at > boot. I don't know what happens to the phy, but this patch does fix the issue for me: Tested-by: Nicolas Ferre <nicolas.fe...@atmel.com> The other alternative that I'm considering seriously as I'm still struggled with this is to simply remove the phy IRQ from my board DT. Best regards, -- Nicolas Ferre
