netdev - Re: [PATCH v2 10/11] ARM: dts: stm32: add ethernet1 and ethernet2 for STM32MP135F-DK board

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5544e11b-25a8-4465-a7cc-f1e9b1d0f0cc@foss.st.com>
Date: Thu, 16 May 2024 09:58:46 +0200
From: Alexandre TORGUE <alexandre.torgue@...s.st.com>
To: Marek Vasut <marex@...x.de>,
        Christophe Roullier
	<christophe.roullier@...s.st.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo
 Abeni <pabeni@...hat.com>, Rob Herring <robh+dt@...nel.org>,
        Krzysztof
 Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley
	<conor+dt@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Richard
 Cochran <richardcochran@...il.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Liam
 Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>
CC: <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 10/11] ARM: dts: stm32: add ethernet1 and ethernet2 for
 STM32MP135F-DK board

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