Re: [PATCH 1/2] dt-bindings: iio: light: Add ROHM BH1730FVC binding

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Low] The regulator supply properties `als-vdd-supply` and `als-vid-supply` use a redundant and non-standard `als-` prefix.
- [Low] The description for `als-vid-supply` incorrectly claims it is for an "LED indicator supply (VID)".
- [Low] The description for `rohm,opt-win-coeff` contradicts its schema definition by asking for a "flat list".
--

commit 54cb92717c1eb05d5ed9e2a6d74a2b1e27c4482c
Author: CTCaer <ctcaer@gmail.com>

dt-bindings: iio: light: Add ROHM BH1730FVC binding

Adds a YAML binding for the ROHM BH1730FVC ambient light sensor,
documenting required properties, regulators, and calibration coefficients.

> diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bh1730fvc.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bh1730fvc.yaml
> new file mode 100644
> index 0000000000000..6273b69e82ab2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/rohm,bh1730fvc.yaml
[ ... ]
> +  reg:
> +    maxItems: 1
> +
> +  als-vdd-supply:
> +    description: Regulator for the analog/digital supply (VDD).
> +
> +  als-vid-supply:
> +    description: Regulator for the LED indicator supply (VID).

This isn't a bug, but should the als- prefix be dropped from these supply
properties? Standard device tree conventions typically use vdd-supply and
vid-supply directly unless the hardware pins are explicitly named with the
prefix.

Also, is the description for the VID supply accurate? The ROHM BH1730FVC is
an ambient light sensor without an LED. VID typically stands for Voltage for
Interface/Digital. Does this description need to be updated to reflect the
hardware?

[ ... ]
> +  rohm,opt-win-coeff:
> +    description:
> +      Optical-window calibration coefficients. Specified as a flat list of
> +      triplets <rc cv ci>, one triplet per window region, where rc is the
> +      visible/IR ratio cutoff and cv/ci are the visible and IR weighting
> +      factors used in that region.
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix

This isn't a bug, but does the description contradict the schema definition?

The text instructs users to provide a flat list, but the property is defined
as a uint32-matrix. If a flat list is provided, schema validation will fail
the maxItems constraint.

Should the description specify an array of matrices instead, to match the
example below?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511-bh1730-v1-0-e0df1f499135@gmail.com?part=1