From: sashiko-bot@kernel.org
To: "Jose A. Perez de Azpillaga" <azpijr@gmail.com>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: iio: light: add Broadcom APDS9999
Date: Tue, 19 May 2026 09:34:30 +0000 [thread overview]
Message-ID: <20260519093430.B2748C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <12b145839a1a9c5381946a9e5237bfe6fe0ae9a7.1779181370.git.azpijr@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unnecessary schema split and contradiction regarding the vled-supply property.
--
commit 16ae176ed1deb8d1509cb369a4821fa40c4b1e66
Author: Jose A. Perez de Azpillaga <azpijr@gmail.com>
dt-bindings: iio: light: add Broadcom APDS9999
This commit adds a new device tree binding for the Broadcom APDS9999 ambient
light and proximity sensor. The commit message states that a separate binding
file is used rather than merging with the existing APDS9300 binding due to
the addition of a vled-supply property.
> A separate binding file is used rather
> than merging with avago,apds9300.yaml because the APDS9999
> has an additional vled-supply for the VCSEL.
Does the implementation match this justification?
> diff --git a/Documentation/devicetree/bindings/iio/light/brcm,apds9999.yaml b/Documentation/devicetree/bindings/iio/light/brcm,apds9999.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/brcm,apds9999.yaml
[ ... ]
> +properties:
[ ... ]
> + vled-supply:
> + description: VCSEL power supply
> +
> + interrupts:
> + maxItems: 1
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - vdd-supply
> +
> +examples:
If the vled-supply property is the primary hardware difference that warrants a
separate schema file, should it be included in the required properties list?
Alternatively, if the supply is genuinely optional, could this have been
handled with a simple conditional in the existing avago,apds9300.yaml schema
instead of splitting into a new file? The device tree binding guidelines
recommend splitting bindings into separate files only when the conditionals
become too unwieldy.
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1779181370.git.azpijr@gmail.com?part=1
next prev parent reply other threads:[~2026-05-19 9:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 9:21 [PATCH v3 0/2] iio: light: add support for Broadcom APDS9999 Jose A. Perez de Azpillaga
2026-05-19 9:23 ` [PATCH v3 1/2] dt-bindings: iio: light: add " Jose A. Perez de Azpillaga
2026-05-19 9:34 ` sashiko-bot [this message]
2026-05-19 17:30 ` Conor Dooley
2026-05-20 8:56 ` Jose A. Perez de Azpillaga
2026-05-20 15:17 ` Conor Dooley
2026-05-19 9:23 ` [PATCH v3 2/2] iio: light: add support for APDS9999 sensor Jose A. Perez de Azpillaga
2026-05-20 18:49 ` Jonathan Cameron
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=20260519093430.B2748C2BCB3@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=azpijr@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.