linux-kernel - Re: [PATCH v1 1/4] dt-bindings: iio: light: add apds990x binding

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230311193426.5b1b7e53@jic23-huawei>
Date:   Sat, 11 Mar 2023 19:34:26 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Svyatoslav Ryhel <clamor95@...il.com>
Cc:     Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Derek Kiernan <derek.kiernan@...inx.com>,
        Dragan Cvetic <dragan.cvetic@...inx.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dmitry Osipenko <dmitry.osipenko@...labora.com>,
        linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/4] dt-bindings: iio: light: add apds990x binding

On Wed,  8 Mar 2023 11:02:16 +0200
Svyatoslav Ryhel <clamor95@...il.com> wrote:

> Add dt-binding for apds990x ALS/proximity sensor.
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@...il.com>
> ---
>  .../bindings/iio/light/avago,apds990x.yaml    | 76 +++++++++++++++++++
I'm not a fan of wild cards. It breaks far too often.  Can we name this
instead after a particular supported part - same for compatible.
I'm not sure what parts are supported by this, but you may want multiple
compatibles.


>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/avago,apds990x.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/light/avago,apds990x.yaml b/Documentation/devicetree/bindings/iio/light/avago,apds990x.yaml
> new file mode 100644
> index 000000000000..9b47e13f88e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/avago,apds990x.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/light/avago,apds990x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Avago APDS990x ALS and proximity sensor
> +
> +maintainers:
> +  - Samu Onkalo <samu.p.onkalo@...ia.com>
> +
> +description: |
> +  APDS990x is a combined ambient light and proximity sensor. ALS and
> +  proximity functionality are highly connected. ALS measurement path
> +  must be running while the proximity functionality is enabled.
> +
> +properties:
> +  compatible:
> +    const: avago,apds990x
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  vdd-supply: true
> +  vled-supply: true
> +
> +  avago,pdrive:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 32
> +    description: |
> +      Drive value used in configuring control register.

Is this something where there is a reasonable default?
If so I'd prefer it was optional so that the device is easier to
use without needing firmware description.

> +
> +  avago,ppcount:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 32
> +    description: |
> +      Number of pulses used for proximity sensor calibration.
Same for this - if there is a reasonable default it would be good to
have that specified.

> +
> +additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupt
It would nice to relax the need for an interrupt if the device is still useable
with timeouts etc.  Board folk have a habit of deciding they don't need to wire
up interrupts.  We can relax that a later date though if you prefer not to do
it now.
> +  - vdd-supply
> +  - vled-supply

Whilst true that the supplies need to be connected, that doesn't
mean they need to provided in the device tree binding.  If they are
always powered up I think we can fallback to stub regulators.

> +  - avago,pdrive
> +  - avago,ppcount
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        light-sensor@39 {
> +            compatible = "avago,apds990x";
> +            reg = <0x39>;
> +
> +            interrupt-parent = <&gpio>;
> +            interrupts = <82 IRQ_TYPE_EDGE_RISING>;
> +
> +            vdd-supply = <&vdd_3v0_proxi>;
> +            vled-supply = <&vdd_1v8_sen>;
> +
> +            avago,pdrive = <0x00>;
> +            avago,ppcount = <0x03>;
> +        };
> +    };
> +...