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] [day] [month] [year] [list]
Message-ID: <78ce16eb-824c-dfe8-2c28-04f3f05a2fd2@hauke-m.de>
Date:	Tue, 21 Jun 2016 00:17:29 +0200
From:	Hauke Mehrtens <hauke@...ke-m.de>
To:	John Crispin <john@...ozen.org>,
	Alexander Stein <alexander.stein@...tec-electronic.com>,
	Rob Herring <robh@...nel.org>
Cc:	f.fainelli@...il.com, netdev@...r.kernel.org, andrew@...n.ch,
	openwrt@...sin.me, hauke.mehrtens@...el.com,
	daniel.schwierzeck@...il.com, eckert.florian@...glemail.com,
	devicetree@...r.kernel.org, thomas.langer@...el.com
Subject: Re: [PATCH 1/2] NET: PHY: Add PHY LED control binding.

On 06/09/2016 10:13 PM, Hauke Mehrtens wrote:
> On 06/09/2016 08:12 AM, John Crispin wrote:
>>
>>
>> On 09/06/2016 08:06, Alexander Stein wrote:
>>> On Wednesday 08 June 2016 14:30:08, Rob Herring wrote:
>>>>> diff --git a/Documentation/devicetree/bindings/phy/phy-leds.txt
>>>>> b/Documentation/devicetree/bindings/phy/phy-leds.txt new file mode 100644
>>>>> index 0000000..1a35e3d
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/phy/phy-leds.txt
>>>>> @@ -0,0 +1,52 @@
>>>>> +LED configuration for Ethernet phys
>>>>> +
>>>>> +All these properties are optional, not all properties are supported by
>>>>> +all PHYs. When more then one property name is define for one LED the
>>>>> +order they get applied is device depended.
>>>>> +Property names:
>>>>> +	led-const-on: conditions the LED should be constant on
>>>>> +	led-pulse: condition the LED should be pulsed on
>>>>> +	led-blink-slow: condition the LED should slowly blink
>>>>
>>>> How slow is slow?
>>>
>>> This depends on the MMD.INTERNAL.LEDCH.SBF setting which is 2 Hz by default.
>>>
>>>>> +	led-blink-fast: condition the LED should fast blink
>>>>
>>>> How fast is fast?
>>>
>>> This depends on the MMD.INTERNAL.LEDCH.FBF setting which is 16 Hz by default.
>>>
>>> Both can be set independently to 2, 4, 8 or 16 Hz.
>>>
>>
>> and both are intel/lantiq implementation specific and hence should not
>> be part of a generic led-phy binding.
> 
> Ok, I can remove them, I think the constant on and the pulse are used by
> many Ethernet PHYs.
> 
>> imho these leds should be exposed via a led driver and the configurtion
>> should be exposed via a led driver specific trigger, in the same manner
>> in which wireless macs do it.
> 
> Where is a good example on how this is done?
> Is this then also triggered by the hardware or does the software has to
> trigger it?
> 
> Hauke
> 

I looked into ath9k and could only find a normal LED device which gets
triggered by the software here:
http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/gpio.c#L45
This also registers a LED trigger in mac80211, but that also looks like
it triggers it by software:
http://lxr.free-electrons.com/source/net/mac80211/led.c#L286

In the PHY use case using software to trigger the LEDs is not so good
because the PHYs could on a hardware switch and it could be that the
traffic is not seen by the CPU.

Hauke

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ