Message-ID: <e3369d04-67e0-734f-4604-f66a84a3b9af@kontron.com>
Date:   Thu, 28 Jul 2022 19:34:45 +0200
From:   Gilles BULOZ <gilles.buloz@...tron.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: Marvell 88E1512 PHY LED2 mode mismatch with Elkhartlake pin mode

Thanks Andrew for the explainations.

Having a look to the Intel ElkhartLake CRB schematics, the three 88E1512 have their LED2/INT# pin connected to the Elkhartlake so It 
seems this board is using architecture 1)
I'm currious to see if booting this CRB with a Fedora 36 would give the same issue than the one I have on my custom board based on 
the CRB : PHY in POLL mode with LED2/INT# set to link/activity by marvell.ko, but Elkhartlake pin with interrupt enabled, leading to 
a spurious power-on on link activity when in off state (S5)
I'm going to ask Intel support for the status on the CRB or try to get a CRB to test by myself.

Today, I discovered that if I blacklist or remove marvell.ko, a generic PHY driver is used instead (phy-generic.ko). This driver 
seems to keep the state of the LED2/INT# pin set by the BIOS that is "link up". So I n this case I get a spurious power-on when the 
link goes down then up.
Regardless of the PHY driver, shutting down the interface with "ifconfig <ethname> down" before shutting down the system is a 
working workaround (no toggle on LED2/INT# so no spurious power on)

Gilles

Le 26/07/2022 à 17:55, Andrew Lunn a écrit :
>> The value programmed by the BIOS to MII_PHY_LED_CTRL is 0x0030 meaning
>> LED2=link, LED1=activity, and LED0=link (and reserved bit 12 is set to 0
>> instead of keeping it to its default 1). So this is also not something OK if
>> the interrupt is enabled on the Elkartlake side for LED2/INT#
> O.K, so it is a different situation to the link i gave.
>
>>> Is the IRQ described in ACPI?
>> OK, I'm going to check for it
>>> Maybe you could wire it up. Set
>>> phydev->irq before connecting the PHY,
>> OK do you do that (set phydev->irq) ?
>>> and then phylib will use the
>>> IRQ, not polling. That might also solve your wakeup problem, in that
>>> when the interrupt is disabled at shutdown, it should disable it in
>>> the PHY.
>> Is the PHY interrupt needed to support WakeOnLan ?
>> And is the PHY POLL mode what we have on the EHL CRB (I don't have the CRB here so I can't check that) ?
> Needing the interrupt will depend on how power management works on
> your device.
>
> There are two basic architectures which can be used.
>
> 1) The interrupt controller is kept running on suspend, and it can
> wake the system up when an interrupt happens. You need to call
> enable_irq_wake() to let the interrupt core code know this. Picking a random example:
>
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fnet%2Fethernet%2Fbroadcom%2Fbcmsysport.c%23L546&amp;data=05%7C01%7Cgilles.buloz%40kontron.com%7C8bf9a027f842497e93ce08da6f1f3fec%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637944477262739726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=xSQxiM3lLrYyeKEbCS%2BRGI%2BdhCl7fqngYCIyBU0OOEs%3D&amp;reserved=0
>
> 2) The output from the PHY is connected to PMIC. The pin changing
> state causes the PMIC to turn the power back on. The SoC itself is not
> involved. And the driver does not need to use interrupts, in fact it
> cannot use interrupts, if the pin is connected to the PMIC and not the
> SoC.
>
> It sounds like you have 1), so yes, you should be using the interrupt
> for WOL to work.
>
>      Andrew
>
> .

Powered by blists - more mailing lists