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] [day] [month] [year] [list]
Date:   Tue, 20 Dec 2022 13:06:44 -0600
From:   Rob Herring <robh@...nel.org>
To:     Corentin Labbe <clabbe@...libre.com>
Cc:     jdelvare@...e.com, krzysztof.kozlowski+dt@...aro.org,
        linux@...ck-us.net, devicetree@...r.kernel.org,
        linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
        conor@...nel.org
Subject: Re: [PATCH v2] dt-bindings: hwmon: gpio-fan: convert to YAML

On Sat, Dec 17, 2022 at 09:04:23PM +0000, Corentin Labbe wrote:
> Converts hwmon/gpio-fan.txt to YAML

s/YAML/DT schema\./

> 
> Signed-off-by: Corentin Labbe <clabbe@...libre.com>
> ---
> Changes since v1:
> - Keeped only one example and simplified it
> 
>  .../devicetree/bindings/hwmon/gpio-fan.txt    | 41 -------------
>  .../devicetree/bindings/hwmon/gpio-fan.yaml   | 59 +++++++++++++++++++
>  2 files changed, 59 insertions(+), 41 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/hwmon/gpio-fan.txt
>  create mode 100644 Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
> deleted file mode 100644
> index f4cfa350f6a1..000000000000
> --- a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -Bindings for fan connected to GPIO lines
> -
> -Required properties:
> -- compatible : "gpio-fan"
> -
> -Optional properties:
> -- gpios: Specifies the pins that map to bits in the control value,
> -  ordered MSB-->LSB.
> -- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
> -  control value that should be set to achieve them. This array
> -  must have the RPM values in ascending order.
> -- alarm-gpios: This pin going active indicates something is wrong with
> -  the fan, and a udev event will be fired.
> -- #cooling-cells: If used as a cooling device, must be <2>
> -  Also see:
> -  Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
> -  min and max states are derived from the speed-map of the fan.
> -
> -Note: At least one the "gpios" or "alarm-gpios" properties must be set.
> -
> -Examples:
> -
> -	gpio_fan {
> -		compatible = "gpio-fan";
> -		gpios = <&gpio1 14 1
> -			 &gpio1 13 1>;
> -		gpio-fan,speed-map = <0    0
> -				      3000 1
> -				      6000 2>;
> -		alarm-gpios = <&gpio1 15 1>;
> -	};
> -	gpio_fan_cool: gpio_fan {
> -		compatible = "gpio-fan";
> -		gpios = <&gpio2 14 1
> -			 &gpio2 13 1>;
> -		gpio-fan,speed-map =	<0    0>,
> -					<3000 1>,
> -					<6000 2>;
> -		alarm-gpios = <&gpio2 15 1>;
> -		#cooling-cells = <2>; /* min followed by max */
> -	};
> diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
> new file mode 100644
> index 000000000000..c522072c0d07
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/gpio-fan.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bindings for fan connected to GPIO lines

Drop 'Bindings for'. Really, just 'GPIO controlled Fan' is good.

> +
> +maintainers:
> +  - OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@...r.kernel.org>

Should be a person. You can put me.

> +
> +properties:
> +  compatible:
> +    const: gpio-fan
> +
> +  gpios:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array

Already has a type. Perhaps 'maxItems: N' where N is 'should be enough'. 
I'd guess 4 is more than enough. Any sane design would go with a PWM 
controlled fan if that much control is needed.

> +    description: Specifies the pins that map to bits in the control value,
> +      ordered MSB-->LSB.
> +
> +  gpio-fan,speed-map:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +    description: A mapping of possible fan RPM speeds and the
> +      control value that should be set to achieve them. This array
> +      must have the RPM values in ascending order.

Needs some constraints and the entries can be better described:

minItems: 2  (I would assume there is no point in 1 entry?)
maxItems: N
items:
  items:
    - description: Speed in RPM
    - description: GPIO Control value

> +
> +  alarm-gpios:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array

Drop.

maxItems: 1

> +    description: This pin going active indicates something is wrong with
> +      the fan, and a udev event will be fired.

'udev event' is way outside the scope of a binding.

> +
> +  "#cooling-cells":
> +    const: 2
> +    description: If used as a cooling device, must be <2>

If not used as a cooling device can be any number of cells? 

Don't repeat constraints in free form text.

> +      Also see Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml

No need to reference schema for common properties.

> +      min and max states are derived from the speed-map of the fan.

This IS unique to this binding, so it should stay.

> +
> +anyOf:
> +  - required:
> +      - gpios
> +  - required:
> +      - alarm-gpios
> +
> +additionalProperties: False
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/clock/cortina,gemini-clock.h>
> +    #include <dt-bindings/reset/cortina,gemini-reset.h>
> +    #include <dt-bindings/gpio/gpio.h>
> +    gpio_fan {
> +      compatible = "gpio-fan";
> +        gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
> +        gpio-fan,speed-map = <0    0>,
> +                             <3000 1>,
> +                             <6000 2>;

How does a single GPIO encode 3 states?

> +        alarm-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
> +    };
> -- 
> 2.37.4
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ