SoCs supporting ULP0 or ULP1 modes and variants of Cadence Ethernet IP
(controlled by macb driver) may behave buggy when Wake-on-Lan (WoL) is
configured and WoL packet is received while in ULP0/ULP1. On some SoCs
Ethernet interface is not working after resume. On other SoCs the CPU
goes to abort on resume path when switching execution from internal SRAM
to DRAM. For ULP1 + WoL the issue is related a particular restart
sequence of the internal clocks when resuming. These clocks are
automatically managed by PMC and may happen that GMAC peripheral clock
is restarted few clock cycles before internal clocks causing blocking
of Ethernet's DMA. As a consequence Ethernet TX transactions are stopped
and RX transactions are partially stopped (packets are received by MAC,
RX counters incremented but the data is not transferred to DRAM). The
workaround for this is to disable Ethernet's peripheral clock when
going to ULP1. Same behavior has been reproduced on ULP0 for some
platforms (SAMA5D2, SAMA5D3) and the same workaround solves the issue.

The problem has been solved on pm.c as quirk to avoid polluting the
MACB driver with AT91 specific issues as this driver is generic to
multiple vendors.

At probe pointers to struct device_node are retrieved and on the
at91_pm_enter() the quirk specifics are applied: for all Ethernet
interfaces that were parsed the peripheral clocks are disabled. A
special handling is done for modes in dns_modes mask as these are
considered modes that blocks the system if WoL packet are received
but for which applying quirk will lead to not waking up on WoL
packets: in situation where Ethernet interface(s) has suspend mode
in dns_modes mask and Ethernet interface(s) is the only available
wakeup source the suspend is canceled.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>