All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: "Marek Behún" <marek.behun@nic.cz>
Cc: netdev@vger.kernel.org, linux-leds@vger.kernel.org,
	"Pavel Machek" <pavel@ucw.cz>, "Dan Murphy" <dmurphy@ti.com>,
	"Ondřej Jirman" <megous@megous.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Andrew Lunn" <andrew@lunn.ch>,
	linux-kernel@vger.kernel.org,
	"Matthias Schiffer" <matthias.schiffer@ew.tq-group.com>,
	"David S. Miller" <davem@davemloft.net>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH net-next + leds v2 1/7] dt-bindings: leds: document binding for HW controlled LEDs
Date: Wed, 9 Sep 2020 15:15:52 -0600	[thread overview]
Message-ID: <20200909211552.GA3066273@bogus> (raw)
In-Reply-To: <20200909162552.11032-2-marek.behun@nic.cz>

On Wed, Sep 09, 2020 at 06:25:46PM +0200, Marek Behún wrote:
> Document binding for LEDs connected to and controlled by various chips
> (such as ethernet PHY chips).

If they are h/w controlled, then why are they in DT?

> 
> Signed-off-by: Marek Behún <marek.behun@nic.cz>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> ---
>  .../leds/linux,hw-controlled-leds.yaml        | 99 +++++++++++++++++++
>  1 file changed, 99 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/linux,hw-controlled-leds.yaml
> 
> diff --git a/Documentation/devicetree/bindings/leds/linux,hw-controlled-leds.yaml b/Documentation/devicetree/bindings/leds/linux,hw-controlled-leds.yaml
> new file mode 100644
> index 0000000000000..eaf6e5d80c5f5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/linux,hw-controlled-leds.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/linux,hw-controlled-leds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: LEDs that can be controlled by hardware (eg. by an ethernet PHY chip)
> +
> +maintainers:
> +  - Marek Behún <marek.behun@nic.cz>
> +
> +description:
> +  Many an ethernet PHY (and other chips) supports various HW control modes
> +  for LEDs connected directly to them. With this binding such LEDs can be
> +  described.
> +
> +properties:
> +  compatible:
> +    const: linux,hw-controlled-leds

What makes this linux specific?

Unless you're going to make this h/w specific, then it probably should 
just be dropped. 

The phy schema will need:

leds:
  type: object
  $ref: /schemas/leds/hw-controlled-leds.yaml#

> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0
> +
> +patternProperties:
> +  "^led@[0-9a-f]+$":
> +    type: object
> +    allOf:
> +      - $ref: common.yaml#
> +    description:
> +      This node represents a LED device connected to a chip that can control
> +      the LED in various HW controlled modes.
> +
> +    properties:
> +      reg:
> +        maxItems: 1
> +        description:
> +          This property identifies the LED to the chip the LED is connected to
> +          (eg. an ethernet PHY chip can have multiple LEDs connected to it).
> +
> +      enable-active-high:
> +        description:
> +          Polarity of LED is active high. If missing, assumed default is active
> +          low.
> +        type: boolean
> +
> +      led-tristate:
> +        description:
> +          LED pin is tristate type. If missing, assumed false.
> +        type: boolean
> +
> +      linux,default-hw-mode:

How is this linux specific? It sounds device specific. Your choice is 
make this a device specific property with device specific values or come 
up with generic modes.

Perhaps 'function' should be expanded.

> +        description:
> +          This parameter, if present, specifies the default HW triggering mode
> +          of the LED when LED trigger is set to `dev-hw-mode`.
> +          Available values are specific per device the LED is connected to and
> +          per LED itself.
> +        $ref: /schemas/types.yaml#definitions/string
> +
> +    required:
> +      - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +
> +    #include <dt-bindings/leds/common.h>
> +
> +    ethernet-phy@0 {
> +        compatible = "ethernet-phy-ieee802.3-c45";
> +        reg = <0>;
> +
> +        leds {
> +            compatible = "linux,hw-controlled-leds";
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            led@0 {
> +                reg = <0>;
> +                color = <LED_COLOR_ID_GREEN>;
> +                function = <LED_FUNCTION_STATUS>;

Reading the description of LED_FUNCTION_STATUS doesn't align with how 
you are using it. Think of it as user alert/notification.

> +                linux,default-trigger = "dev-hw-mode";

This is deprecated in favor of 'function'.

> +                linux,default-hw-mode = "1Gbps";
> +            };
> +
> +            led@1 {
> +                reg = <1>;
> +                color = <LED_COLOR_ID_YELLOW>;
> +                function = <LED_FUNCTION_ACTIVITY>;
> +                linux,default-trigger = "dev-hw-mode";
> +                linux,default-hw-mode = "activity";
> +            };
> +        };
> +    };
> +
> +...
> -- 
> 2.26.2
> 

  parent reply	other threads:[~2020-09-09 21:16 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 16:25 [PATCH net-next + leds v2 0/7] PLEASE REVIEW: Add support for LEDs on Marvell PHYs Marek Behún
2020-09-09 16:25 ` [PATCH net-next + leds v2 1/7] dt-bindings: leds: document binding for HW controlled LEDs Marek Behún
2020-09-09 18:27   ` Andrew Lunn
2020-09-09 18:33     ` Marek Behún
2020-09-09 20:59       ` Rob Herring
2020-09-09 21:07         ` Marek Behun
2020-09-09 21:31           ` Rob Herring
2020-09-09 21:43             ` Marek Behun
2020-09-09 20:56   ` Rob Herring
2020-09-09 21:15   ` Rob Herring [this message]
2020-09-09 21:58     ` Marek Behun
2020-09-09 16:25 ` [PATCH net-next + leds v2 2/7] leds: add generic API for LEDs that can be controlled by hardware Marek Behún
2020-09-09 18:20   ` Randy Dunlap
2020-09-09 18:31     ` Marek Behún
2020-09-09 18:43       ` Randy Dunlap
2020-09-09 20:48   ` Pavel Machek
2020-09-09 21:20     ` Marek Behun
2020-09-09 21:40       ` Pavel Machek
2020-09-09 22:15         ` Marek Behun
2020-09-09 22:20           ` Pavel Machek
2020-09-09 16:25 ` [PATCH net-next + leds v2 3/7] net: phy: add simple incrementing phyindex member to phy_device struct Marek Behún
2020-09-10 12:20   ` Pavel Machek
2020-09-09 16:25 ` [PATCH net-next + leds v2 4/7] dt-bindings: net: ethernet-phy: add description for PHY LEDs Marek Behún
2020-09-09 16:25 ` [PATCH net-next + leds v2 5/7] net: phy: add support for LEDs controlled by ethernet PHY chips Marek Behún
2020-09-10 12:22   ` Pavel Machek
2020-09-09 16:25 ` [PATCH net-next + leds v2 6/7] net: phy: marvell: add support for LEDs controlled by Marvell PHYs Marek Behún
2020-09-10 12:23   ` Pavel Machek
2020-09-10 13:15     ` Andrew Lunn
2020-09-10 14:15       ` Marek Behún
2020-09-10 14:46         ` Andrew Lunn
2020-09-10 15:00         ` Andrew Lunn
2020-09-11  7:12           ` Matthias Schiffer
2020-09-11 12:42             ` Andrew Lunn
2020-09-11 12:52             ` Marek Behún
2020-09-10 20:23         ` Pavel Machek
2020-09-10 20:31           ` Andrew Lunn
2020-09-10 20:39             ` Pavel Machek
2020-09-10 20:41           ` Marek Behun
2020-09-10 18:24       ` Pavel Machek
2020-09-10 18:31         ` Andrew Lunn
2020-09-10 18:34           ` Russell King - ARM Linux admin
2020-09-10 20:31             ` Marek Behun
2020-09-10 21:44               ` Russell King - ARM Linux admin
2020-09-11 12:53                 ` Marek Behún
2020-09-09 16:25 ` [PATCH net-next + mvebu v2 7/7] arm64: dts: armada-3720-turris-mox: add nodes for ethernet PHY LEDs Marek Behún
2020-09-10 12:25   ` Pavel Machek
2020-09-09 21:42 ` [PATCH net-next + leds v2 0/7] PLEASE REVIEW: Add support for LEDs on Marvell PHYs Andrew Lunn
2020-09-09 22:11   ` Marek Behun
2020-09-09 22:39     ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200909211552.GA3066273@bogus \
    --to=robh@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dmurphy@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marek.behun@nic.cz \
    --cc=matthias.schiffer@ew.tq-group.com \
    --cc=megous@megous.com \
    --cc=netdev@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.