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: <20200315105834.7a5f4475@archlinux>
Date:   Sun, 15 Mar 2020 10:58:34 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Nishant Malpani <nish.malpani25@...il.com>
Cc:     robh+dt@...nel.org, knaack.h@....de, lars@...afoo.de,
        pmeerw@...erw.net, mark.rutland@....com, sre@...nel.org,
        linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: iio: tsl2563: convert bindings to YAML

On Sat, 14 Mar 2020 19:12:37 +0530
Nishant Malpani <nish.malpani25@...il.com> wrote:

> Convert the TSL2563 device tree bindings to the new YAML format.
> 
> Signed-off-by: Nishant Malpani <nish.malpani25@...il.com>
> ---
> 
> The link for the datasheet is not attached in the binding document
> because it was not available on the manufacturer's (AMS) website [1].

Very old part now, though plenty of them in circulation or least there
used to be.  I have though not powered up that board for a while.

When doing these conversions, do sanity check them against the driver
as the old docs aren't always entirely accurate ;)

Jonathan

> 
> [1] https://ams.com/ambient-light-sensors
> ---
>  .../devicetree/bindings/iio/light/tsl2563.txt | 19 --------
>  .../bindings/iio/light/tsl2563.yaml           | 46 +++++++++++++++++++
>  2 files changed, 46 insertions(+), 19 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iio/light/tsl2563.txt
>  create mode 100644 Documentation/devicetree/bindings/iio/light/tsl2563.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/light/tsl2563.txt b/Documentation/devicetree/bindings/iio/light/tsl2563.txt
> deleted file mode 100644
> index f91e809e736e..000000000000
> --- a/Documentation/devicetree/bindings/iio/light/tsl2563.txt
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -* AMS TAOS TSL2563 ambient light sensor
> -
> -Required properties:
> -
> -  - compatible : should be "amstaos,tsl2563"
> -  - reg : the I2C address of the sensor
> -
> -Optional properties:
> -
> -  - amstaos,cover-comp-gain : integer used as multiplier for gain
> -                              compensation (default = 1)
> -
> -Example:
> -
> -tsl2563@29 {
> -	compatible = "amstaos,tsl2563";
> -	reg = <0x29>;
> -	amstaos,cover-comp-gain = <16>;
> -};
> diff --git a/Documentation/devicetree/bindings/iio/light/tsl2563.yaml b/Documentation/devicetree/bindings/iio/light/tsl2563.yaml
> new file mode 100644
> index 000000000000..2a70b8d62760
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/tsl2563.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/light/tsl2563.yaml#

Convention is now to name files and this with the manufacturer part
as well.

light/amstaos,tsl2563.yaml

> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AMS TAOS TSL2563 ambient light sensor
> +
> +maintainers:
> +  - Sebastian Reichel <sre@...nel.org>
> +
> +description: |
> +  Ambient light sensor with an i2c interface.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - amstaos,tsl2563

The original binding was wrong on this.   Check the driver :)
I'm a bit embarrassed I never noticed during review as I have
a tsl2561, be it on a board that was never converted to DT.

> +
> +  reg:
> +    maxItems: 1
> +
> +  amstaos,cover-comp-gain:
> +    description: Multiplier for gain compensation
> +    allOf:
> +      - $ref: /schemas/types.yaml#/definitions/uint32
> +      - enum: [1, 16]

Not sure it's that restricted...  or to be honest what
that is for at all.  Superficially it looks like
a multiplier to change the 'range' of the the sysfs control.

I wonder if anyone cares or if we can just start ignoring that going
forwards?  Sebastian, anyone else?

> +
> +required:
> +  - compatible
> +  - reg
> +
> +examples:
> +  - |
> +    i2c {
> +
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      light-sensor@29 {
> +        compatible = "amstaos,tsl2563";
> +        reg = <0x29>;
> +        amstaos,cover-comp-gain = <16>;
> +      };
> +    };
> +...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ