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: <9c1d80eb-03e7-4d39-b516-cbcae0d50e4a@denx.de>
Date: Thu, 16 May 2024 02:23:56 +0200
From: Marek Vasut <marex@...x.de>
To: Alexandre TORGUE <alexandre.torgue@...s.st.com>,
 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

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 ?

> 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 ?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ