[PATCH 0/2] NET: PHY: Add PHY LED control binding.

[PATCH 0/2] NET: PHY: Add PHY LED control binding.

[Hauke Mehrtens]

This is now spitted out of the patch series that adds support the 
Ethernet PHY. The second patch depends on the Ethernet PHY code which I 
send before. How should this get merged, or should I split this in a 
different way?

Hauke Mehrtens (2):
  NET: PHY: Add PHY LED control binding.
  NET: PHY: Intel XWAY: add LED configuration support

 .../devicetree/bindings/phy/intel-xway.txt         |  77 +++++++++++
 Documentation/devicetree/bindings/phy/phy-leds.txt |  52 +++++++
 drivers/net/phy/intel-xway.c                       | 152 +++++++++++++++++++++
 include/dt-bindings/phy/phy-leds.h                 |  27 ++++
 4 files changed, 308 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/intel-xway.txt
 create mode 100644 Documentation/devicetree/bindings/phy/phy-leds.txt
 create mode 100644 include/dt-bindings/phy/phy-leds.h

-- 
2.8.1

[PATCH 1/2] NET: PHY: Add PHY LED control binding.

[Hauke Mehrtens]

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-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
---
 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

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-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
+ *
+ * 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 */
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] NET: PHY: Intel XWAY: add LED configuration support

[Hauke Mehrtens]

This makes it possible to configure the behavior of the LEDs connected
to a PHY. The LEDs are controlled by the chip, this makes it possible
to configure the behavior when the hardware should activate and
deactivate the LEDs.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
 .../devicetree/bindings/phy/intel-xway.txt         |  77 +++++++++++
 drivers/net/phy/intel-xway.c                       | 152 +++++++++++++++++++++
 2 files changed, 229 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/intel-xway.txt

diff --git a/Documentation/devicetree/bindings/phy/intel-xway.txt b/Documentation/devicetree/bindings/phy/intel-xway.txt
new file mode 100644
index 0000000..02891c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel-xway.txt
@@ -0,0 +1,77 @@
+Intel XWAY Ethernet PHY binding
+------------------------------
+
+This supports the Intel XWAY (former Lantiq) 11G and 22E PHYs. These
+PHYs are also named PEF 7061, PEF 7071 and PEF 7072.
+
+Required properties:
+ - compatible:	should be "ethernet-phy-ieee802.3-c22"
+ - reg:		MDIO address of this PHY
+
+
+LEDs:
+The PEF 7071 PHY supports 3 LEDs, the PEF 7072 PHY supports 4 LEDs. Use
+one subnode for each LED. By default the LEDs 0, 1 and 2 are switched
+to be constant on when a 10MBit/s, 100MBit/s or 1000MBit/s link is
+detected and they blink when TX or RX traffic is detected. All 3 LEDs
+are doing the same as most known devices only have one LED.
+
+To change the behavior create a subnode with the following attributes:
+
+Required properties:
+ - compatible: 	should be: "phy,led"
+ - reg:		led number
+
+optional properties:
+ - led-const-on:	Conditions when being constant on
+			Possible options are one of these:
+			LED_LINK10, LED_LINK100 and LED_LINK1000, or
+			some of these 3 values connected with OR.
+			PHY_LED_PDOWN, PHY_LED_EEE, PHY_LED_ANEG,
+			PHY_LED_ABIST, PHY_LED_CDIAG, PHY_LED_COPPER,
+			PHY_LED_FIBER.
+ - led-pulse:		Conditions when led is pulsed
+			The following values can be connected with OR:
+			PHY_LED_TXACT, PHY_LED_RXACT, PHY_LED_COL
+ - led-blink-slow:	Conditions when led should blink with 2Hz:
+			Possible options are one of these:
+			LED_LINK10, LED_LINK100 and LED_LINK1000, or
+			some of these 3 values connected with OR.
+			PHY_LED_PDOWN, PHY_LED_EEE, PHY_LED_ANEG,
+			PHY_LED_ABIST, PHY_LED_CDIAG.
+ - led-blink-fast:	Conditions when led should blink with 16Hz:
+			Possible options are one of these:
+			LED_LINK10, LED_LINK100 and LED_LINK1000, or
+			some of these 3 values connected with OR.
+			PHY_LED_PDOWN, PHY_LED_EEE, PHY_LED_ANEG,
+			PHY_LED_ABIST, PHY_LED_CDIAG.
+
+When multiple properties are set they are applied with the following priority:
+ 1. led-pulse
+ 2. led-blink-fast
+ 3. led-blink-slow
+ 4. led-const-on
+ 5. off
+
+
+Example:
+
+#include <dt-bindings/phy/phy-leds.h>
+phy@0 {
+	compatible = "intel,phy11g", "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/drivers/net/phy/intel-xway.c b/drivers/net/phy/intel-xway.c
index c300ab5..6469ded 100644
--- a/drivers/net/phy/intel-xway.c
+++ b/drivers/net/phy/intel-xway.c
@@ -17,6 +17,7 @@
 #include <linux/module.h>
 #include <linux/phy.h>
 #include <linux/of.h>
+#include <dt-bindings/phy/phy-leds.h>
 
 #define XWAY_MDIO_IMASK			0x19	/* interrupt mask */
 #define XWAY_MDIO_ISTAT			0x1A	/* interrupt status */
@@ -152,11 +153,158 @@
 #define PHY_ID_PHY11G_VR9		0xD565A409
 #define PHY_ID_PHY22F_VR9		0xD565A419
 
+static void xway_gphy_config_led(struct phy_device *phydev,
+				 struct device_node *led_np)
+{
+	const __be32 *addr, *blink_fast_p, *const_on_p, *pulse_p, *blink_slow_p;
+	u32 num, blink_fast, const_on, pulse, blink_slow;
+	u32 ledxl;
+	u32 ledxh;
+
+	addr = of_get_property(led_np, "reg", NULL);
+	if (!addr)
+		return;
+	num = be32_to_cpu(*addr);
+
+	if (num < 0 || num > 3)
+		return;
+
+	ledxh = XWAY_MMD_LEDxH_BLINKF_NONE | XWAY_MMD_LEDxH_CON_LINK10XX;
+	blink_fast_p = of_get_property(led_np, "led-blink-fast", NULL);
+	if (blink_fast_p) {
+		ledxh &= ~XWAY_MMD_LEDxH_BLINKF_MASK;
+		blink_fast = be32_to_cpu(*blink_fast_p);
+		if ((blink_fast & PHY_LED_LINK10) &&
+		    (blink_fast & PHY_LED_LINK100) &&
+		    (blink_fast & PHY_LED_LINK1000)) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_LINK10XX;
+		} else if ((blink_fast & PHY_LED_LINK10) &&
+			   (blink_fast & PHY_LED_LINK1000)) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_LINK10_0;
+		} else if ((blink_fast & PHY_LED_LINK10) &&
+			   (blink_fast & PHY_LED_LINK100)) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_LINK10X;
+		} else if ((blink_fast & PHY_LED_LINK100) &&
+			   (blink_fast & PHY_LED_LINK1000)) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_LINK100X;
+		} else if (blink_fast & PHY_LED_LINK10) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_LINK10;
+		} else if (blink_fast & PHY_LED_LINK100) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_LINK100;
+		} else if (blink_fast & PHY_LED_LINK1000) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_LINK1000;
+		} else if (blink_fast & PHY_LED_PDOWN) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_PDOWN;
+		} else if (blink_fast & PHY_LED_EEE) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_EEE;
+		} else if (blink_fast & PHY_LED_ANEG) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_ANEG;
+		} else if (blink_fast & PHY_LED_ABIST) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_ABIST;
+		} else if (blink_fast & PHY_LED_CDIAG) {
+			ledxh |= XWAY_MMD_LEDxH_BLINKF_CDIAG;
+		}
+	}
+	const_on_p = of_get_property(led_np, "led-const-on", NULL);
+	if (const_on_p) {
+		ledxh &= ~XWAY_MMD_LEDxH_CON_MASK;
+		const_on = be32_to_cpu(*const_on_p);
+		if ((const_on & PHY_LED_LINK10) &&
+		    (const_on & PHY_LED_LINK100) &&
+		    (const_on & PHY_LED_LINK1000)) {
+			ledxh |= XWAY_MMD_LEDxH_CON_LINK10XX;
+		} else if ((const_on & PHY_LED_LINK10) &&
+			   (const_on & PHY_LED_LINK1000)) {
+			ledxh |= XWAY_MMD_LEDxH_CON_LINK10_0;
+		} else if ((const_on & PHY_LED_LINK10) &&
+			   (const_on & PHY_LED_LINK100)) {
+			ledxh |= XWAY_MMD_LEDxH_CON_LINK10X;
+		} else if ((const_on & PHY_LED_LINK100) &&
+			   (const_on & PHY_LED_LINK1000)) {
+			ledxh |= XWAY_MMD_LEDxH_CON_LINK100X;
+		} else if (const_on & PHY_LED_LINK10) {
+			ledxh |= XWAY_MMD_LEDxH_CON_LINK10;
+		} else if (const_on & PHY_LED_LINK100) {
+			ledxh |= XWAY_MMD_LEDxH_CON_LINK100;
+		} else if (const_on & PHY_LED_LINK1000) {
+			ledxh |= XWAY_MMD_LEDxH_CON_LINK1000;
+		} else if (const_on & PHY_LED_PDOWN) {
+			ledxh |= XWAY_MMD_LEDxH_CON_PDOWN;
+		} else if (const_on & PHY_LED_EEE) {
+			ledxh |= XWAY_MMD_LEDxH_CON_EEE;
+		} else if (const_on & PHY_LED_ANEG) {
+			ledxh |= XWAY_MMD_LEDxH_CON_ANEG;
+		} else if (const_on & PHY_LED_ABIST) {
+			ledxh |= XWAY_MMD_LEDxH_CON_ABIST;
+		} else if (const_on & PHY_LED_CDIAG) {
+			ledxh |= XWAY_MMD_LEDxH_CON_CDIAG;
+		} else if (const_on & PHY_LED_COPPER) {
+			ledxh |= XWAY_MMD_LEDxH_CON_COPPER;
+		} else if (const_on & PHY_LED_FIBER) {
+			ledxh |= XWAY_MMD_LEDxH_CON_FIBER;
+		}
+	}
+	phy_write_mmd_indirect(phydev, XWAY_MMD_LED0H + (num * 2),
+			       MDIO_MMD_VEND2, ledxh);
+
+	ledxl = XWAY_MMD_LEDxL_PULSE_TXACT | XWAY_MMD_LEDxL_PULSE_RXACT |
+		XWAY_MMD_LEDxL_BLINKS_NONE;
+	pulse_p = of_get_property(led_np, "led-pulse", NULL);
+	if (pulse_p) {
+		ledxl &= ~XWAY_MMD_LEDxL_PULSE_MASK;
+		pulse = be32_to_cpu(*pulse_p);
+		if (pulse & PHY_LED_TXACT)
+			ledxl |= XWAY_MMD_LEDxL_PULSE_TXACT;
+		if (pulse & PHY_LED_RXACT)
+			ledxl |= XWAY_MMD_LEDxL_PULSE_RXACT;
+		if (pulse & PHY_LED_COL)
+			ledxl |= XWAY_MMD_LEDxL_PULSE_COL;
+	}
+	blink_slow_p = of_get_property(led_np, "led-blink-slow", NULL);
+	if (blink_slow_p) {
+		ledxl &= ~XWAY_MMD_LEDxL_BLINKS_MASK;
+		blink_slow = be32_to_cpu(*blink_slow_p);
+		if ((blink_slow & PHY_LED_LINK10) &&
+		    (blink_slow & PHY_LED_LINK100) &&
+		    (blink_slow & PHY_LED_LINK1000)) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_LINK10XX;
+		} else if ((blink_slow & PHY_LED_LINK10) &&
+			   (blink_slow & PHY_LED_LINK1000)) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_LINK10_0;
+		} else if ((blink_slow & PHY_LED_LINK10) &&
+			   (blink_slow & PHY_LED_LINK100)) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_LINK10X;
+		} else if ((blink_slow & PHY_LED_LINK100) &&
+			   (blink_slow & PHY_LED_LINK1000)) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_LINK100X;
+		} else if (blink_slow & PHY_LED_LINK10) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_LINK10;
+		} else if (blink_slow & PHY_LED_LINK100) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_LINK100;
+		} else if (blink_slow & PHY_LED_LINK1000) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_LINK1000;
+		} else if (blink_slow & PHY_LED_PDOWN) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_PDOWN;
+		} else if (blink_slow & PHY_LED_EEE) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_EEE;
+		} else if (blink_slow & PHY_LED_ANEG) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_ANEG;
+		} else if (blink_slow & PHY_LED_ABIST) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_ABIST;
+		} else if (blink_slow & PHY_LED_CDIAG) {
+			ledxl |= XWAY_MMD_LEDxL_BLINKS_CDIAG;
+		}
+	}
+	phy_write_mmd_indirect(phydev, XWAY_MMD_LED0L + (num * 2),
+			       MDIO_MMD_VEND2, ledxl);
+}
+
 static int xway_gphy_config_init(struct phy_device *phydev)
 {
 	int err;
 	u32 ledxh;
 	u32 ledxl;
+	struct device_node *led_np;
 
 	/* Mask all interrupts */
 	err = phy_write(phydev, XWAY_MDIO_IMASK, 0);
@@ -190,6 +338,10 @@ static int xway_gphy_config_init(struct phy_device *phydev)
 	phy_write_mmd_indirect(phydev, XWAY_MMD_LED2H, MDIO_MMD_VEND2, ledxh);
 	phy_write_mmd_indirect(phydev, XWAY_MMD_LED2L, MDIO_MMD_VEND2, ledxl);
 
+	for_each_child_of_node(phydev->mdio.dev.of_node, led_np)
+		if (of_device_is_compatible(led_np, "phy,led"))
+			xway_gphy_config_led(phydev, led_np);
+
 	return 0;
 }
 
-- 
2.8.1

Re: [PATCH 1/2] NET: PHY: Add PHY LED control binding.

[Rob Herring]

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>;
> +	};
> +};

Re: [PATCH 1/2] NET: PHY: Add PHY LED control binding.

[Alexander Stein]

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

Re: [PATCH 1/2] NET: PHY: Add PHY LED control binding.

[John Crispin]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] NET: PHY: Add PHY LED control binding.

[Hauke Mehrtens]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] NET: PHY: Add PHY LED control binding.

[Hauke Mehrtens]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html