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: <0b3979d6-895f-4c8a-8251-d3c793385bf4@roeck-us.net>
Date: Tue, 3 Feb 2026 11:15:44 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: victor.duicu@...rochip.com
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
	corbet@....net, marius.cristea@...rochip.com,
	linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: hwmon: add support for MCP998X

On Tue, Jan 27, 2026 at 05:18:21PM +0200, victor.duicu@...rochip.com wrote:
> From: Victor Duicu <victor.duicu@...rochip.com>
> 
> This is the devicetree schema for Microchip MCP998X/33 and
> MCP998XD/33D Multichannel Automotive Temperature Monitor Family.
> 
> Acked-by: Conor Dooley <conor.dooley@...rochip.com>
> Signed-off-by: Victor Duicu <victor.duicu@...rochip.com>

Some AI generated feedback inline, generated using Gemini 3 and Chris Mason's
prompts as base. I don't know much if anything about devicetree properties,
but it does seem to me that the AI has a point.

> ---
>  .../bindings/hwmon/microchip,mcp9982.yaml     | 205 ++++++++++++++++++
>  MAINTAINERS                                   |   6 +
>  2 files changed, 211 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/microchip,mcp9982.yaml
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/microchip,mcp9982.yaml b/Documentation/devicetree/bindings/hwmon/microchip,mcp9982.yaml
> new file mode 100644
> index 000000000000..05ea3c6a5618
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/microchip,mcp9982.yaml
> @@ -0,0 +1,205 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/microchip,mcp9982.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip MCP998X/33 and MCP998XD/33D Temperature Monitor
> +
> +maintainers:
> +  - Victor Duicu <victor.duicu@...rochip.com>
> +
> +description: |
> +  The MCP998X/33 and MCP998XD/33D family is a high-accuracy 2-wire
> +  multichannel automotive temperature monitor.
> +  The datasheet can be found here:
> +    https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/MCP998X-Family-Data-Sheet-DS20006827.pdf
> +
> +properties:
> +  compatible:
> +    enum:
> +      - microchip,mcp9933
> +      - microchip,mcp9933d
> +      - microchip,mcp9982
> +      - microchip,mcp9982d
> +      - microchip,mcp9983
> +      - microchip,mcp9983d
> +      - microchip,mcp9984
> +      - microchip,mcp9984d
> +      - microchip,mcp9985
> +      - microchip,mcp9985d
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    items:
> +      - description: Signal coming from ALERT/THERM pin.
> +      - description: Signal coming from THERM/ADDR pin.
> +      - description: Signal coming from SYS_SHDN pin.
> +
> +  interrupt-names:
> +    items:
> +      - const: alert-therm
> +      - const: therm-addr
> +      - const: sys-shutdown

The top-level definition of interrupt-names specifies exactly 3 items.
How does this interact with variants that only have 2 interrupts?

> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0
> +
> +  microchip,enable-anti-parallel:
> +    description:
> +      Enable anti-parallel diode mode operation.
> +      MCP9984/84D/85/85D and MCP9933/33D support reading two external diodes
> +      in anti-parallel connection on the same set of pins.
> +    type: boolean
> +
> +  microchip,parasitic-res-on-channel1-2:
> +    description:
> +      Indicates that the chip and the diodes/transistors are sufficiently far
> +      apart that a parasitic resistance is added to the wires, which can affect
> +      the measurements. Due to the anti-parallel diode connections, channels
> +      1 and 2 are affected together.
> +    type: boolean
> +
> +  microchip,parasitic-res-on-channel3-4:
> +    description:
> +      Indicates that the chip and the diodes/transistors are sufficiently far
> +      apart that a parasitic resistance is added to the wires, which can affect
> +      the measurements. Due to the anti-parallel diode connections, channels
> +      3 and 4 are affected together.
> +    type: boolean
> +
> +  microchip,power-state:
> +    description:
> +      The chip can be set in Run state or Standby state. In Run state the ADC
> +      is converting on all channels at the programmed conversion rate.
> +      In Standby state the host must initiate a conversion cycle by writing
> +      to the One-Shot register.
> +      True value sets Run state.
> +      Chips with "D" in the name can only be set in Run mode.
> +    type: boolean
> +
> +  vdd-supply: true
> +
> +patternProperties:
> +  "^channel@[1-4]$":
> +    description:
> +      Represents the external temperature channels to which
> +      a remote diode is connected.
> +    type: object
> +
> +    properties:
> +      reg:
> +        items:
> +          minItems: 1
> +          maxItems: 4

Should the reg property in a channel node allow up to 4 items? Since the
node naming ^channel@[1-4]$ implies a single channel per node, it seems
reg should have maxItems: 1.

Second feedback:

Is this reg schema correct? For a single cell index (e.g. reg = <1>), the
items are integers, and minItems/maxItems are not valid constraints on
integers. Did you mean to use minimum/maximum here, or just maxItems: 1
on the reg itself?

> +
> +      label:
> +        description: Unique name to identify which channel this is.
> +
> +    required:
> +      - reg
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - vdd-supply
> +
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - microchip,mcp9982d
> +              - microchip,mcp9983d
> +              - microchip,mcp9984d
> +              - microchip,mcp9985d
> +              - microchip,mcp9933d
> +    then:
> +      properties:
> +        interrupts-names:

Is "interrupts-names" a typo for "interrupt-names"? The plural form
does not match the property defined at the top level.

Also, if the top-level interrupt-names requires 3 items, will a 2-item
override here conflict during validation?

> +          items:
> +            - const: alert-therm
> +            - const: sys-shutdown
> +      required:
> +        - microchip,power-state
> +    else:
> +      properties:
> +        interrupts-names:

Same question here regarding the typo; should this be interrupt-names?

> +          items:
> +            - const: alert-therm
> +            - const: therm-addr
> +        microchip,power-state: true
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            pattern: '^microchip,mcp998(2|3)$'
> +    then:
> +      properties:
> +        microchip,enable-anti-parallel: false

If "D" variants only support Run mode as described in the property
description, why is this property required in the devicetree?

Second feedback:

Since the description says "D" versions can only be set in Run mode
(where True sets Run state), should this property also have a const: true
constraint here?

> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            pattern: '^microchip,mcp998(2|3)d$'
> +    then:
> +      properties:
> +        microchip,enable-anti-parallel: false
> +      required:
> +        - microchip,parasitic-res-on-channel1-2
> +        - microchip,parasitic-res-on-channel3-4

Should the parasitic resistance compensation properties be required? These
represent board-specific parasitics and may not be present on all
designs using these chip variants.

> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            pattern: '^microchip,mcp99(33|8[4-5])d$'
> +    then:
> +      required:
> +        - microchip,parasitic-res-on-channel1-2
> +        - microchip,parasitic-res-on-channel3-4
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        temperature-sensor@4c {
> +            compatible = "microchip,mcp9985";
> +            reg = <0x4c>;
> +
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            microchip,enable-anti-parallel;
> +            microchip,parasitic-res-on-channel1-2;
> +            microchip,parasitic-res-on-channel3-4;
> +
> +            vdd-supply = <&vdd>;
> +
> +            channel@1 {
> +                reg = <1>;
> +                label = "Room Temperature";
> +            };
> +
> +            channel@2 {
> +                reg = <2>;
> +                label = "GPU Temperature";
> +            };
> +        };
> +    };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0d044a58cbfe..f88d837cb586 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17149,6 +17149,12 @@ S:	Maintained
>  F:	Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
>  F:	drivers/iio/adc/mcp3911.c
>  
> +MICROCHIP MCP9982 TEMPERATURE DRIVER
> +M:	Victor Duicu <victor.duicu@...rochip.com>
> +L:	linux-hwmon@...r.kernel.org
> +S:	Supported
> +F:	Documentation/devicetree/bindings/hwmon/microchip,mcp9982.yaml
> +
>  MICROCHIP MMC/SD/SDIO MCI DRIVER
>  M:	Aubin Constans <aubin.constans@...rochip.com>
>  S:	Maintained

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ