netdev - Re: Marvell 88E1512 PHY LED2 mode mismatch with Elkhartlake pin mode

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: <YuAOao5X5kj87dt2@lunn.ch>
Date:   Tue, 26 Jul 2022 17:55:22 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Gilles BULOZ <gilles.buloz@...tron.com>
Cc:     netdev@...r.kernel.org
Subject: Re: Marvell 88E1512 PHY LED2 mode mismatch with Elkhartlake pin mode

> 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://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/broadcom/bcmsysport.c#L546

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