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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
