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: <20230905170010.GA3505375-robh@kernel.org>
Date:   Tue, 5 Sep 2023 12:00:10 -0500
From:   Rob Herring <robh@...nel.org>
To:     Billy Tsai <billy_tsai@...eedtech.com>
Cc:     jdelvare@...e.com, linux@...ck-us.net,
        krzysztof.kozlowski+dt@...aro.org, joel@....id.au, andrew@...id.au,
        corbet@....net, thierry.reding@...il.com,
        u.kleine-koenig@...gutronix.de, p.zabel@...gutronix.de,
        naresh.solanki@...ements.com, linux-hwmon@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-aspeed@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-pwm@...r.kernel.org,
        BMC-SW@...eedtech.com, patrick@...cx.xyz
Subject: Re: [PATCH v8 1/3] dt-bindings: hwmon: fan: Add fan binding to schema

On Wed, Aug 30, 2023 at 08:32:00PM +0800, Billy Tsai wrote:
> From: Naresh Solanki <naresh.solanki@...ements.com>
> 
> Add common fan properties bindings to a schema.
> 
> Bindings for fan controllers can reference the common schema for the
> fan
> 
> child nodes:
> 
>   patternProperties:
>     "^fan@[0-2]":
>       type: object
>       $ref: fan-common.yaml#

        unevaluatedProperties: false


> 
> Signed-off-by: Naresh Solanki <naresh.solanki@...ements.com>
> Signed-off-by: Billy Tsai <billy_tsai@...eedtech.com>
> ---
>  .../devicetree/bindings/hwmon/fan-common.yaml | 63 +++++++++++++++++++
>  1 file changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/fan-common.yaml
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/fan-common.yaml b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
> new file mode 100644
> index 000000000000..a69b4d553e45
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause

Drop 'or-later'. It's GPL2 only.

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/fan-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common Fan Properties
> +
> +maintainers:
> +  - Naresh Solanki <naresh.solanki@...ements.com>
> +  - Billy Tsai <billy_tsai@...eedtech.com>
> +
> +properties:
> +  max-rpm:
> +    description:
> +      Max RPM supported by fan.
> +    $ref: /schemas/types.yaml#/definitions/uint32

Physics will limit this to something much less than 2^32. Add some 
constraints. 10000?

> +
> +  min-rpm:
> +    description:
> +      Min RPM supported by fan.
> +    $ref: /schemas/types.yaml#/definitions/uint32

ditto

> +
> +  pulses-per-revolution:
> +    description:
> +      The number of pulse from fan sensor per revolution.
> +    $ref: /schemas/types.yaml#/definitions/uint32

Needs constraints. I assume this is never more than 4 (or 2 even)?

> +  div:

Too generic of a name.

> +    description:
> +      Fan clock divisor

But what is a fan clock?

> +    $ref: /schemas/types.yaml#/definitions/uint32
> +
> +  target-rpm:
> +    description:
> +      Target RPM the fan should be configured during driver probe.

What driver? By the time the OS driver runs, a bunch of other boot 
software has already run on modern systems. So this value would likely 
be used much earlier. The point is that when exactly is outside the 
scope of DT. This is "what RPM do I use in case of no other information 
(e.g. temperature)".

> +    $ref: /schemas/types.yaml#/definitions/uint32
> +
> +  mode:

Too generic.

> +    description:
> +      Select the operational mode of the fan.

What are modes? Spin and don't spin?

> +    $ref: /schemas/types.yaml#/definitions/uint32
> +
> +  pwms:
> +    description:
> +      PWM provider.

maxItems: 1

I don't think there are fans with more than 1 PWM input?

> +
> +  tach-ch:
> +    description:
> +      The tach channel used for the fan.
> +    $ref: /schemas/types.yaml#/definitions/uint32

The existing ASpeed version of this property allows more than 1 entry. I 
don't understand how a fan would have 2 tach signals, but if so, the 
generic property should allow for that.

Perhaps 'reg' should be defined in here with some text saying 'reg' 
corresponds to the fan controller specific id which may be the PWM+TACH 
channel, PWM channel (deprecated), or TACH channel. I think there are 
examples of all 3 of these cases.

> +
> +  label:
> +    description:
> +      Optional fan label
> +
> +  fan-supply:
> +    description:
> +      Power supply for fan.
> +
> +additionalProperties: true
> +
> +...
> -- 
> 2.25.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ