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  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]
Date:   Sat, 25 Jul 2020 19:47:58 +0200
From:   Andrew Lunn <>
To:     Marek Behun <>
Cc:     Pavel Machek <>,,,,
        Dan Murphy <>,
        Ondřej Jirman <>,
        Russell King <>,
        Thomas Petazzoni <>,
        Gregory Clement <>,
Subject: Re: [PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add
 support for PHY LEDs via LED class

On Sat, Jul 25, 2020 at 07:39:50PM +0200, Marek Behun wrote:
> On Sat, 25 Jul 2020 17:03:42 +0200
> Andrew Lunn <> wrote:
> > Does hi-z mean off? In the implementation i did, i did not list off
> > and on as triggers. I instead used them for untriggered
> > brightness. That allowed the software triggers to work, so i had the
> > PHY blinking the heartbeat etc. But i had to make it optional, since a
> > quick survey of datasheets suggested not all PHYs support simple
> > on/off control.
> I don't actually know what hi-z means, but enabling it disabled the LED.
> But there is another register value for OFF...

Can the pin be used for other things? Maybe it needs to be configured
for high impedance when it is used as a shared interrupt?  If it does
not seem like a useful LED setting, i would drop it for the moment.

> > Something beyond the scope of this patchset is implementing etHool -p
> > 
> >        -p --identify
> >               Initiates adapter-specific action intended to enable an operator to
> > 	      easily identify the adapter by sight. Typically this involves  blink‐
> >               ing one or more LEDs on the specific network port.
> > 
> > If we have software controlled on/off, then a software trigger seems
> > like i good way to do this.
> I'll look into this.

No rush. As i said, out of scope for this patchset. Just keep it in
mind. It should be something we can implement once in phylib, and then
all phy drivers which have LED support get it for free.


Powered by blists - more mailing lists