Re: [PATCH v2] dt-bindings: leds: lacie,netxbig-leds: Convert to DT schema

[email protected]
Newsgroups org.kernel.vger.linux-leds,org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The YAML binding schema for LED child nodes explicitly forbids standard LED properties by using 'additionalProperties: false' without referencing the common LED schema.
- [Medium] The regular expression used in `patternProperties` to match child nodes is brittle: it arbitrarily rejects valid single-word node names and would erroneously match hyphenated top-level properties.
--

--- Patch [1]: [PATCH v2] dt-bindings: leds: lacie,netxbig-leds: Convert to DT schema ---
commit a7a7b0d43884f0f2164a9d243e2d08d00c94a010
Author: Udaya Kiran Challa <[email protected]>

dt-bindings: leds: lacie,netxbig-leds: Convert to DT schema

This commit converts the LaCie/Seagate netxbig CPLD LEDs devicetree
binding from the legacy text format to the YAML DT schema.

Link to v1:https://lore.kernel.org/all/[email protected]/

> diff --git a/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml b/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml
> new file mode 100644
> index 0000000000000..02759ecb32d04
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml
[ ... ]
> +patternProperties:
> +  "^(?!gpio-ext$|pinctrl-[0-9]+$)[a-z][a-z0-9]*(-[a-z0-9]+)+$":

[Severity: Medium]
Does this regular expression arbitrarily reject valid single-word node
names like led or sata?

The regex requires at least one hyphen. A child node simply named led
would fail to match here, fall through to the top-level
additionalProperties: false, and be completely rejected. 

It could also erroneously match future standard hyphenated properties like
power-domains and expect them to contain LED properties.

> +    type: object
> +    additionalProperties: false
> +
> +    properties:
> +      label:

[Severity: Medium]
Does setting additionalProperties: false here without referencing the
common LED schema prevent the use of standard properties like color and
function?

Because the schema validator will reject any unlisted properties, device
trees cannot be modernized to use standard LED subsystem properties, which
are explicitly recommended over the deprecated label property.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.