All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: "Álvaro Fernández Rojas" <noltari@gmail.com>
Cc: linux-leds@vger.kernel.org, cooloney@gmail.com, jogo@openwrt.org,
	f.fainelli@gmail.com, cernekee@gmail.com,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] leds: add DT binding for BCM6328 LED controller
Date: Thu, 16 Apr 2015 16:39:48 +0200	[thread overview]
Message-ID: <552FC9B4.3030303@samsung.com> (raw)
In-Reply-To: <1428246485-32305-2-git-send-email-noltari@gmail.com>

Hi Alvaro,

On 04/05/2015 05:08 PM, Álvaro Fernández Rojas wrote:
> This adds device tree binding documentation for the Broadcom BCM6328 LED
> controller.
>
> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
> Signed-off-by: Jonas Gorski <jogo@openwrt.org>
> ---
> v2: Introduce changes suggested by Florian and Jonas.
>   - Change compatible string to "brcm,bcm6328-leds-ctrl".
>   - Make valid LEDs statement more strict.
>   - Remove compatible strings from LED subnodes.
>   - Clarify that LEDs are active high by default.
>   - Add a better description for brcm,link-signal-sources and brcm,activity-signal-sources.
>
>   .../devicetree/bindings/leds/leds-bcm6328.txt      | 162 +++++++++++++++++++++
>   1 file changed, 162 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/leds/leds-bcm6328.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt
> new file mode 100644
> index 0000000..6e4f5563a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt
> @@ -0,0 +1,162 @@
> +LEDs connected to Broadcom BCM6328 controller

Part of description from the cover letter could find its way here.
It could be more precise though. I am wondering who controls the LEDs
through spi-gpio interface.

> +
> +Required properties:
> +- compatible: should be : "brcm,bcm6328-leds-ctrl".

I liked brcm,bcm6328-leds more. It is obvious that all LED subsystem
drivers are for LED *controllers*.

> +- #address-cells: must be 1
> +- #size-cells: must be 0
> +- reg: BCM6328 LED controller address and size.
> +
> +Optional properties:
> +- brcm,serial-leds: boolean which enables Serial LEDs.
> +
> +Each LED is represented as a sub-node of the brcm,bcm6328-leds device.
> +
> +LED sub-node properties:
> +- reg: LED pin number (only LEDs 0 to 23 are valid).
> +
> +Normal LED:

Please give it more meaningful description. Software controlled?

> +LEDs are active high by default.

This should be put next to active-low property, like:

active-low: boolean that makes LED active low.
             Default: false

> +- label (optional): see Documentation/devicetree/bindings/leds/common.txt
> +- active-low (optional): boolean that makes LED active low.
> +- default-state (optional): see
> +  Documentation/devicetree/bindings/leds/leds-gpio.txt
> +- linux,default-trigger (optional): see
> +  Documentation/devicetree/bindings/leds/common.txt
> +
> +Hardware controlled LED:
> +- brcm,hardware-controlled (optional): boolean that makes this LED hardware
> +  controlled.
> +- brcm,link-signal-sources (optional): An array of hardware link
> +  signal sources. Up to four link hardware signals can get muxed into
> +  these LEDs. Only valid for LEDs 0 to 7, where LED signals 0 to 3 may
> +  be muxed to LEDs 0 to 3, and signals 4 to 7 may be muxed to LEDs
> +  4 to 7. A signal can be muxed to more than one LED, and one LED can
> +  have more than one source signal.
> +- brcm,activity-signal-sources (optional): An array of hardware activity
> +  signal sources. Up to four activity hardware signals can get muxed into
> +  these LEDs. Only valid for LEDs 0 to 7, where LED signals 0 to 3 may
> +  be muxed to LEDs 0 to 3, and signals 4 to 7 may be muxed to LEDs
> +  4 to 7. A signal can be muxed to more than one LED, and one LED can
> +  have more than one source signal.

It is more common to group properties in sections - in this case:
"Required properties for child nodes" and "Optional properties for
child nodes".


> +example 1) BCM6328
> +
> +leds0: led-controller@10000800 {
> +	compatible = "brcm,bcm6328-leds-ctrl";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	reg = <0x10000800 0x24>;
> +
> +	alarm_red@2 {
> +		reg = <2>;
> +		active-low;
> +		label = "red:alarm";
> +	};
> +	inet_green@3 {
> +		reg = <3>;
> +		active-low;
> +		label = "green:inet";
> +	};
> +	power_green@4 {
> +		reg = <4>;
> +		active-low;
> +		label = "green:power";
> +		default-state = "on";
> +	};
> +	ephy0_spd@17 {
> +		reg = <17>;
> +		brcm,hardware-controlled;

If there is no LED class device created for hardware controlled LED,
then why does it need the node if has no brcm,link-signal-sources
or brcm,activity-signal-sources properties? There seems to be nothing
to configure then.

> +	};
> +	ephy1_spd@18 {
> +		reg = <18>;
> +		brcm,hardware-controlled;
> +	};
> +	ephy2_spd@19 {
> +		reg = <19>;
> +		brcm,hardware-controlled;
> +	};
> +	ephy3_spd@20 {
> +		reg = <20>;
> +		brcm,hardware-controlled;
> +	};
> +};
> +
> +example 2) BCM63268
> +
> +leds0: led-controller@10001900 {
> +	compatible = "brcm,bcm6328-leds-ctrl";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	reg = <0x10001900 0x24>;
> +	brcm,serial-leds;
> +
> +	gphy0_spd0@0 {
> +		reg = <0>;
> +		brcm,hardware-controlled;
> +		brcm,link-signal-sources = <0>;

More valid examples with brcm,link-signal-sources and
brcm,activity-signal-sources properties would be useful. This is
especially vital taking into account limitations mentioned in the
description of these properties. The examples should be as
comprehensive as possible, i.e. the lists should contain more than
one element.

> +	};
> +	gphy0_spd1@1 {
> +		reg = <1>;
> +		brcm,hardware-controlled;
> +		brcm,link-signal-sources = <1>;
> +	};
> +	inet_red@2 {
> +		reg = <2>;
> +		active-low;
> +		label = "red:inet";
> +	};
> +	dsl_green@3 {
> +		reg = <3>;
> +		active-low;
> +		label = "green:dsl";
> +	};
> +	usb_green@4 {
> +		reg = <4>;
> +		active-low;
> +		label = "green:usb";
> +	};
> +	wps_green@7 {
> +		reg = <7>;
> +		active-low;
> +		label = "green:wps";
> +	};
> +	inet_green@8 {
> +		reg = <8>;
> +		active-low;
> +		label = "green:inet";
> +	};
> +	ephy0_act@9 {
> +		reg = <9>;
> +		brcm,hardware-controlled;
> +	};
> +	ephy1_act@10 {
> +		reg = <10>;
> +		brcm,hardware-controlled;
> +	};
> +	ephy2_act@11 {
> +		reg = <11>;
> +		brcm,hardware-controlled;
> +	};
> +	gphy0_act@12 {
> +		reg = <12>;
> +		brcm,hardware-controlled;
> +	};
> +	ephy0_spd@13 {
> +		reg = <13>;
> +		brcm,hardware-controlled;
> +	};
> +	ephy1_spd@14 {
> +		reg = <14>;
> +		brcm,hardware-controlled;
> +	};
> +	ephy2_spd@15 {
> +		reg = <15>;
> +		brcm,hardware-controlled;
> +	};
> +	power_green@20 {
> +		reg = <20>;
> +		active-low;
> +		label = "green:power";
> +		default-state = "on";
> +	};
> +};
>


-- 
Best Regards,
Jacek Anaszewski

  reply	other threads:[~2015-04-16 14:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-02 11:54 [PATCH 0/2] BCM6328 LED driver Álvaro Fernández Rojas
2015-04-02 11:54 ` [PATCH 1/2] leds: add DT binding for BCM6328 LED controller Álvaro Fernández Rojas
2015-04-03  2:06   ` Florian Fainelli
2015-04-03 12:19     ` Álvaro Fernández Rojas
2015-04-03 14:46       ` Jonas Gorski
2015-04-02 11:54 ` [PATCH 2/2] leds: add BCM6328 LED driver Álvaro Fernández Rojas
2015-04-05 15:08 ` [PATCH v2 0/2] " Álvaro Fernández Rojas
2015-04-05 15:08   ` [PATCH v2 1/2] leds: add DT binding for BCM6328 LED controller Álvaro Fernández Rojas
2015-04-16 14:39     ` Jacek Anaszewski [this message]
2015-04-05 15:08   ` [PATCH 2/2] leds: add BCM6328 LED driver Álvaro Fernández Rojas
2015-04-16 14:37     ` Jacek Anaszewski
2015-04-18  9:14       ` Jonas Gorski
2015-04-20  7:12         ` Jacek Anaszewski
2015-04-24 17:06   ` [PATCH v3 0/2] " Álvaro Fernández Rojas
2015-04-24 17:06     ` [PATCH v3 1/2] leds: add DT binding for BCM6328 LED controller Álvaro Fernández Rojas
2015-04-26 11:09       ` Jacek Anaszewski
2015-04-24 17:06     ` [PATCH v3 2/2] leds: add BCM6328 LED driver Álvaro Fernández Rojas
2015-04-26 12:15     ` [PATCH v4 0/2] " Álvaro Fernández Rojas
2015-04-26 12:15       ` [PATCH v4 1/2] leds: add DT binding for BCM6328 LED controller Álvaro Fernández Rojas
2015-04-28  8:18         ` Jacek Anaszewski
2015-04-26 12:15       ` [PATCH v4 2/2] leds: add BCM6328 LED driver Álvaro Fernández Rojas
2015-04-28  8:18         ` Jacek Anaszewski
2015-04-28 16:50       ` [PATCH v5 0/2] " Álvaro Fernández Rojas
2015-04-28 16:50         ` [PATCH v5 1/2] leds: add DT binding for BCM6328 LED controller Álvaro Fernández Rojas
2015-04-28 16:50         ` [PATCH v5 2/2] leds: add BCM6328 LED driver Álvaro Fernández Rojas
     [not found]         ` <1430239850-26120-1-git-send-email-noltari-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-04-29  0:46           ` [PATCH v5 0/2] " Bryan Wu

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=552FC9B4.3030303@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=cernekee@gmail.com \
    --cc=cooloney@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=jogo@openwrt.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=noltari@gmail.com \
    /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.