| Message ID | 1465163150-21429-2-git-send-email-hauke@hauke-m.de |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
On Sun, Jun 05, 2016 at 11:45:49PM +0200, Hauke Mehrtens wrote: > This binding makes it possible to control the LEDs of an Ethernet PHY. > These settings allow it to abstract the hardware configuration which > tells the hardware when to switch the LED constant on or blink for > example. This will be used by the Intel XWAY PHY driver. I also > checked datasheets for some other Ethernet PHYs and it should be > possible to also control their LED behavior with these settings, but > they all did not allow a so fine control over the LED behavior. > > Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> > --- > Documentation/devicetree/bindings/phy/phy-leds.txt | 52 ++++++++++++++++++++++ > include/dt-bindings/phy/phy-leds.h | 27 +++++++++++ > 2 files changed, 79 insertions(+) > create mode 100644 Documentation/devicetree/bindings/phy/phy-leds.txt > create mode 100644 include/dt-bindings/phy/phy-leds.h This should probably be tied into the LED bindings and subsys and be less Ethernet specific and less PHY specific. I find it to be a confusing mixture of h/w capabilities and configuration. > > 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? > + led-blink-fast: condition the LED should fast blink How fast is fast? > + > +These property values define the states a LED is triggered by the > +hardware. Not all PHYs support all states. It is possible to connect > +these property values with OR to trigger the LED in multiple stats like > +10MBit/s and 100MBit/s. The possible combinations are device specific. > +property values: > + PHY_LED_OFF: LED is off > + PHY_LED_LINK10: link is 10MBit/s > + PHY_LED_LINK100: link is 100MBit/s > + PHY_LED_LINK1000: link is 1000MBit/s > + PHY_LED_PDOWN: link is powered down > + PHY_LED_EEE: link is in EEE mode > + PHY_LED_ANEG: auto negotiation is running > + PHY_LED_ABIST: analog self testing is running > + PHY_LED_CDIAG: cable diagnostics is running > + PHY_LED_COPPER: copper interface detected > + PHY_LED_FIBER: fiber interface detected > + PHY_LED_TXACT: Transmit activity > + PHY_LED_RXACT: Receive activity > + PHY_LED_COL: Collision > + > +Example: > + > +#include <dt-bindings/phy/phy-leds.h> > +phy@0 { > + compatible = "ethernet-phy-ieee802.3-c22"; > + reg = <0x0>; > + #address-cells = <1>; > + #size-cells = <0>; > + led@0 { > + compatible = "phy,led"; phy is not a vendor prefix. Does ethernet-phy-ieee802.3-c22 define capabilities and how to program LEDs? > + reg = <0>; What does the reg value correlate to? > + led-const-on = <(PHY_LED_LINK10 | PHY_LED_LINK100 | PHY_LED_LINK1000)>; > + led-pulse = <(PHY_LED_TXACT | PHY_LED_RXACT)>; > + }; > + led@2 { > + compatible = "phy,led"; > + reg = <2>; > + led-blink-slow = <PHY_LED_EEE>; > + led-blink-fast = <PHY_LED_PDOWN>; > + }; > +}; -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Best regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. 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. John -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 + led-blink-fast: condition the LED should fast blink + +These property values define the states a LED is triggered by the +hardware. Not all PHYs support all states. It is possible to connect +these property values with OR to trigger the LED in multiple stats like +10MBit/s and 100MBit/s. The possible combinations are device specific. +property values: + PHY_LED_OFF: LED is off + PHY_LED_LINK10: link is 10MBit/s + PHY_LED_LINK100: link is 100MBit/s + PHY_LED_LINK1000: link is 1000MBit/s + PHY_LED_PDOWN: link is powered down + PHY_LED_EEE: link is in EEE mode + PHY_LED_ANEG: auto negotiation is running + PHY_LED_ABIST: analog self testing is running + PHY_LED_CDIAG: cable diagnostics is running + PHY_LED_COPPER: copper interface detected + PHY_LED_FIBER: fiber interface detected + PHY_LED_TXACT: Transmit activity + PHY_LED_RXACT: Receive activity + PHY_LED_COL: Collision + +Example: + +#include <dt-bindings/phy/phy-leds.h> +phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + led@0 { + compatible = "phy,led"; + reg = <0>; + led-const-on = <(PHY_LED_LINK10 | PHY_LED_LINK100 | PHY_LED_LINK1000)>; + led-pulse = <(PHY_LED_TXACT | PHY_LED_RXACT)>; + }; + led@2 { + compatible = "phy,led"; + reg = <2>; + led-blink-slow = <PHY_LED_EEE>; + led-blink-fast = <PHY_LED_PDOWN>; + }; +}; diff --git a/include/dt-bindings/phy/phy-leds.h b/include/dt-bindings/phy/phy-leds.h new file mode 100644 index 0000000..801fdaf --- /dev/null +++ b/include/dt-bindings/phy/phy-leds.h @@ -0,0 +1,27 @@ +/* + * Copyright (C) 2016 Hauke Mehrtens <hauke@hauke-m.de> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + */ + +#ifndef _DT_BINDINGS_PHY_LEDS +#define _DT_BINDINGS_PHY_LEDS + +#define PHY_LED_OFF (1 << 0) /* is off */ +#define PHY_LED_LINK10 (1 << 1) /* link is 10MBit/s */ +#define PHY_LED_LINK100 (1 << 2) /* link is 100MBit/s */ +#define PHY_LED_LINK1000 (1 << 3) /* link is 1000MBit/s */ +#define PHY_LED_PDOWN (1 << 4) /* link is powered down */ +#define PHY_LED_EEE (1 << 5) /* link is in EEE mode */ +#define PHY_LED_ANEG (1 << 6) /* auto negotiation is running */ +#define PHY_LED_ABIST (1 << 7) /* analog self testing is running */ +#define PHY_LED_CDIAG (1 << 8) /* cable diagnostics is running */ +#define PHY_LED_COPPER (1 << 9) /* copper interface detected */ +#define PHY_LED_FIBER (1 << 10) /* fiber interface detected */ +#define PHY_LED_TXACT (1 << 11) /* Transmit activity */ +#define PHY_LED_RXACT (1 << 12) /* Receive activity */ +#define PHY_LED_COL (1 << 13) /* Collision */ + +#endif /* _DT_BINDINGS_PHY_LEDS */
This binding makes it possible to control the LEDs of an Ethernet PHY. These settings allow it to abstract the hardware configuration which tells the hardware when to switch the LED constant on or blink for example. This will be used by the Intel XWAY PHY driver. I also checked datasheets for some other Ethernet PHYs and it should be possible to also control their LED behavior with these settings, but they all did not allow a so fine control over the LED behavior. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> --- Documentation/devicetree/bindings/phy/phy-leds.txt | 52 ++++++++++++++++++++++ include/dt-bindings/phy/phy-leds.h | 27 +++++++++++ 2 files changed, 79 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-leds.txt create mode 100644 include/dt-bindings/phy/phy-leds.h