| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20251008015210.GA1925508-robh@kernel.org>
Date: Tue, 7 Oct 2025 20:52:10 -0500
From: Rob Herring <robh@...nel.org>
To: Harrison Carter <hcarter@...goodpenguin.co.uk>
Cc: Lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Jonas Gorski <jonas.gorski@...il.com>, linux-leds@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: leds: bcm6358: Convert to DT Schema
On Tue, Sep 30, 2025 at 11:27:26AM +0100, Harrison Carter wrote:
> Convert the brcm,bcm6358 LEDs to DT Schema format
>
> Signed-off-by: Harrison Carter <hcarter@...goodpenguin.co.uk>
> ---
> .../bindings/leds/brcm,bcm6358-leds.yaml | 187 +++++++++++++++++++++
> .../devicetree/bindings/leds/leds-bcm6358.txt | 143 ----------------
> 2 files changed, 187 insertions(+), 143 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/brcm,bcm6358-leds.yaml b/Documentation/devicetree/bindings/leds/brcm,bcm6358-leds.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..a9052a29aa7bd6ddc252258bfe4982325499713f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/brcm,bcm6358-leds.yaml
> @@ -0,0 +1,187 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/brcm,bcm6358-leds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: LEDs connected to Broadcom BCM6358 controller
> +
> +description: This controller is present on BCM6358 and
Start paragraph on new line.
> + BCM6368. In these SoCs there are Serial LEDs (LEDs
> + connected to a 74x164 controller), which can either be
> + controlled by software (exporting the 74x164 as spi-gpio)
> + or by hardware using this driver. See example at
> + Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml.
Wrap lines at 80 chars.
> +
> +maintainers:
> + - Jonas Gorski <jonas.gorski@...il.com>
> +
> +properties:
> + compatible:
> + const: brcm,bcm6358-leds
> +
> + reg:
> + maxItems: 1
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + brcm,clk-div:
> + description: SCK signal Divider. Default 1
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [1, 2, 4, 8]
default: 1
And drop it from the description.
> +
> + brcm,clk-dat-low:
> + description: Makes clock and data signals active low.
> + Default false.
Default false makes no sense. That's always the case for a boolean. The
only way it can't be is if it is required, but then what is the point of
a required boolean property.
> + type: boolean
> +
> +patternProperties:
> + "^led@[0,1]?([0-9]|[a-z])$":
This should be 0-0x1f. So '^led@(0|1?[0-9a-f])$'
> + type: object
> + $ref: common.yaml
unevaluatedProperties: false
(which will make your example fail)
> + description: Each LED is represented as a sub-node of
> + this device.
> +
> + properties:
> + reg:
> + description: LED pin number
> + maximum: 31
> + minimum: 0
> +
> + required:
> + - reg
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties: true
Cannot be true. Only false is allowed.
> +
> +examples:
> + - |
> + #include <dt-bindings/leds/common.h>
> +
> + /* The bcm6358 SOC */
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
Drop this node. Unnecessary for the example.
> +
> + led-controller@...e00d0 {
> + compatible = "brcm,bcm6358-leds";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xfffe00d0 0x8>;
> +
> + alarm_white@0 {
> + reg = <0>;
> + active-low;
> + label = "white:alarm";
> + };
> + tv_white@2 {
> + reg = <2>;
> + active-low;
> + label = "white:tv";
> + };
> + tel_white@3 {
> + reg = <3>;
> + active-low;
> + label = "white:tel";
> + };
> + adsl_white@4 {
> + reg = <4>;
> + active-low;
> + label = "white:adsl";
> + };
> + };
> + };
> + - |
> + /* The bcm6368 SOC */
> + led-controller@...000d0 {
> + compatible = "brcm,bcm6358-leds";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x100000d0 0x8>;
> +
> + brcm,pol-low;
> + brcm,clk-div = <4>;
> +
> + power_red@0 {
> + reg = <0>;
> + active-low;
> + label = "red:power";
> + };
> + power_green@1 {
> + reg = <1>;
> + active-low;
> + label = "green:power";
> + default-state = "on";
> + };
> + power_blue@2 {
> + reg = <2>;
> + label = "blue:power";
> + };
> + broadband_red@3 {
> + reg = <3>;
> + active-low;
> + label = "red:broadband";
> + };
> + broadband_green@4 {
> + reg = <4>;
> + label = "green:broadband";
> + };
> + broadband_blue@5 {
> + reg = <5>;
> + active-low;
> + label = "blue:broadband";
> + };
> + wireless_red@6 {
> + reg = <6>;
> + active-low;
> + label = "red:wireless";
> + };
> + wireless_green@7 {
> + reg = <7>;
> + active-low;
> + label = "green:wireless";
> + };
> + wireless_blue@8 {
> + reg = <8>;
> + label = "blue:wireless";
> + };
> + phone_red@9 {
> + reg = <9>;
> + active-low;
> + label = "red:phone";
> + };
> + phone_green@10 {
> + reg = <10>;
> + active-low;
> + label = "green:phone";
> + };
> + phone_blue@11 {
> + reg = <11>;
> + label = "blue:phone";
> + };
> + upgrading_red@12 {
> + reg = <12>;
> + active-low;
> + label = "red:upgrading";
> + };
> + upgrading_green@13 {
> + reg = <13>;
> + active-low;
> + label = "green:upgrading";
> + };
> + upgrading_blue@14 {
> + reg = <14>;
> + label = "blue:upgrading";
> + };
> + };
I don't think we need 2 examples.
Rob
Powered by blists - more mailing lists