[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cf8ba323-5d15-b5b6-fe7c-9f9a7da2c18a@hauke-m.de>
Date: Thu, 9 Jun 2016 22:13:28 +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 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
Powered by blists - more mailing lists