Re: [PATCH v2 10/11] ARM: dts: stm32: add ethernet1 and ethernet2 for STM32MP135F-DK board
From: Alexandre TORGUE
Date: Thu May 16 2024 - 04:00:48 EST
Hi
On 5/16/24 02:23, Marek Vasut wrote:
On 5/13/24 6:01 PM, Alexandre TORGUE wrote:
Hi Marek
Hi,
On 4/26/24 17:44, Marek Vasut wrote:
On 4/26/24 2:57 PM, Christophe Roullier wrote:
Add dual Ethernet:
-Ethernet1: RMII with crystal
-Ethernet2: RMII without crystal
PHYs used are SMSC (LAN8742A)
With Ethernet1, we can performed WoL from PHY instead of GMAC point
of view.
(in this case IRQ for WoL is managed as wakeup pin and configured
in OS secure).
How does the Linux PHY driver process such a PHY IRQ ?
Or is Linux unaware of the PHY IRQ ? Doesn't that cause issues ?
In this case, we want to have an example to wakeup the system from
Standby low power mode (VDDCPU and VDD_CORE off) thanks to a magic
packet detected by the PHY. The PHY then assert his interrupt output
signal.
On MP13 DK platform, this PHY signal is connected to a specific GPIO
aka "Wakeup pins" (only 6 wakeup pins an MP13). Those specific GPIOs
are handled by the PWR peripheral which is controlled by the secure OS.
What does configure the PHY for this wakeup mode ?
Linux device tree.
On WoL packet, the Secure OS catches the PHY interrupt and uses
asynchronous notification mechanism to warn Linux (on our platform we
use a PPI). On Linux side, Optee core driver creates an irq
domain/irqchip triggered on the asynchronous notification. Each device
which use a wakeup pin need then to request an IRQ on this "Optee irq
domain".
This OPTEE irq domain will be pushed soon.
I suspect it might make sense to add this WoL part separately from the
actual ethernet DT nodes, so ethernet could land and the WoL
functionality can be added when it is ready ?
If at the end we want to have this Wol from PHY then I agree we need to
wait. We could push a WoL from MAC for this node before optee driver
patches merge but not sure it makes sens.
Alex