On Wed, Jan 30, 2019 at 12:08:39PM -0500, John David Anglin wrote: > On 2019-01-22 7:22 p.m., Andrew Lunn wrote: > > >From my Espressobin > > > > cat /proc/interrupts > > ... > > 44: 0 0 mv88e6xxx-g1 3 Edge mv88e6xxx-g1-atu-prob > > 46: 0 0 mv88e6xxx-g1 5 Edge mv88e6xxx-g1-vtu-prob > > 48: 38 24 mv88e6xxx-g1 7 Edge mv88e6xxx-g2 > > 51: 0 1 mv88e6xxx-g2 1 Edge > > !soc!internal-regs@d0000000!mdio@32004!switch0@1!mdio:11 > > 52: 0 0 mv88e6xxx-g2 2 Edge > > !soc!internal-regs@d0000000!mdio@32004!switch0@1!mdio:12 > > 53: 38 23 mv88e6xxx-g2 3 Edge > > !soc!internal-regs@d0000000!mdio@32004!switch0@1!mdio:13 > > > > These are PHY interrupts. > If we come back to my trying to use the INTn pin on the esspressobin, I > have found that clearing and resetting the interrupt > enable bits in the global control register (offset 0x4) restarts link > detection when the device is stuck. This suggests that the > INTn connection to MPP2_23 is low when the the GIC interrupt is enabled > on this pin. Possibly, this is caused by the fact > that EEIntEn is set to 1 on reset. INTn then goes low when EEPROM > loading is done. Another possibility might be race conditions > in processing interrupts. > > Thoughts?
Hi David You need active low interrupts. Without it, i think you are always going to have race conditions which will cause interrupts to get stuck/lost. I would suggest you remove the interrupt from your device tree and use the mv88e6xxx polling method. If i remember correctly, it currently polls 10 per second, so PHY link up/down is going to be 5 times faster on average than when phylib is polling the PHY. Andrew
