netdev - Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem

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]

Date:	Wed, 23 Mar 2016 19:50:06 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	Vishal Thanki <vishalthanki@...il.com>
Cc:	f.fainelli@...il.com, ujhelyi.m@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem

On Wed, Mar 23, 2016 at 06:51:37PM +0100, Vishal Thanki wrote:
> Hi all,
> 
> Based on suggestions from Andrew and Florian, I have made some changes
> to expose the ethernet PHY LEDs using kernel LED subsystem. The following
> ALPHA patchset introduces two new LED triggers:
> 
> 1) <phydev>-eth-phy-link:
> To monitor the PHY Link status
> 
> 2) <phydev>-eth-phy-activity:
> To monitor the PHY activity status. This trigger may still some more work
> because as of now it just takes decision to set the trigger based on
> PHY state machine and triggers the blink_set with delay_on and delay_off
> parameters set to 0.

My suggestion was that the hardware needs to control the LEDs. You
have software doing it. You might be able to do this with the PHY
state machine for link. But activity is never going to be accepted if
software control.

The LED trigger attached to an LED should be used to configure the
hardware to drive the LED as wanted.

The exception to this is when there is no trigger attached, and the
brightness can set the on/off state, if the hardware supports this.

	   Andrew