Re: [PATCH 1/2] dt-bindings: iio: temperature: add support for EMC1812

[David Lechner <dlechner@baylibre.com>]

On 9/17/25 7:21 AM, Marius Cristea wrote:
> This is the devicetree schema for Microchip EMC1812/13/14/15/33
> Multichannel Low-Voltage Remote Diode Sensor Family.
> 
> Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
> ---
>  .../iio/temperature/microchip,emc1812.yaml         | 223 +++++++++++++++++++++
>  MAINTAINERS                                        |   6 +
>  2 files changed, 229 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/temperature/microchip,emc1812.yaml b/Documentation/devicetree/bindings/iio/temperature/microchip,emc1812.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..898d6d246746e229cb004f447872ee6bd5a65074
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/temperature/microchip,emc1812.yaml
> @@ -0,0 +1,223 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/temperature/microchip,emc1812.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip EMC1812/13/14/15/33 multichannel temperature sensor
> +
> +maintainers:
> +  - Marius Cristea <marius.cristea@microchip.com>
> +
> +description: |
> +  The Microchip EMC1812/13/14/15/33 is a high-accuracy 2-wire multichannel
> +  low-voltage remote diode temperature monitor.
> +
> +  The datasheet can be found here:
> +    https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/EMC1812-3-4-5-33-Data-Sheet-DS20005751.pdf

The pinouts of these chips look nearly identical to MCP998X.
Would it make sense to share a single bindings document for these?
Or maybe there would be too many if: blocks and keeping it separate
is fine.

https://lore.kernel.org/linux-iio/20250829143447.18893-2-victor.duicu@microchip.com/

> +
> +properties:
> +  compatible:
> +    enum:
> +      - microchip,emc1812
> +      - microchip,emc1813
> +      - microchip,emc1814
> +      - microchip,emc1815
> +      - microchip,emc1833
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 2
> +
> +  interrupt-names:
> +    description:
> +      -alert-therm2 asserts when a diode temperature exceeds the ALERT
> +      threshold.
> +      -therm-addr asserts low when the hardware-set THERM limit threshold is
> +      exceeded by one of the temperature sensors.
> +    items:
> +      - const: alert-therm2
> +      - const: therm-addr
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0
> +
> +  microchip,beta1:
> +    description:
> +      Set beta compensation value for external channel 1.
> +      <0> 0.050
> +      <1> 0.066
> +      <2> 0.087
> +      <3> 0.114
> +      <4> 0.150
> +      <5> 0.197
> +      <6> 0.260
> +      <7> 0.342
> +      <8> 0.449
> +      <9> 0.591
> +      <10> 0.778
> +      <11> 1.024
> +      <12> 1.348
> +      <13> 1.773
> +      <14> 2.333
> +      <15> Diode_Mode
> +      <16> Auto
> +      - Diode_Mode is used when measuring a discrete thermal diode
> +      or a CPU diode that functions like a discrete thermal diode.
> +      - Auto enables beta auto-detection. The chip monitors
> +      external diode/transistor and determines the optimum
> +      setting.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 16
> +    default: 16
> +
> +  microchip,beta2:
> +    description:
> +      Set beta compensation value for external channel 2.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 16
> +    default: 16

This beta value sounds like something that might not belong in the
devicetree.

The datasheet says that auto is always the best. So that makes me
wonder when would we want to use something else?

Also, it says that in auto mode, that the value is recalculated
on every conversion, so even if manually selecting a value, it
sounds like something that could change at runtime, so having a
fixed value might not cover all use cases.

Having a boolean flag to say this is wired to a discrete thermal diode
makes sense though (the driver would use this info to select diode mode).

And if we can make the case that the beta value should be in the
devicetree, then having the actual value instead of a lookup table
would be preferred. There is a "basis points" standards unit (suffix
"-bp") that can be used for non-integer values like this (assuming it
is a unit-less value). It is 1/10,000 so it would make the property
an enum with 15 values between 500 and 23330.

Both properties would not be allowed at the same time and if both
properties are omitted, the driver would know to use auto mode.

Also, it would make more sense to have these as channel properties
if they only apply to 1 channel each.

> +
> +  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
> +
> +  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:
> +          minimum: 1
> +          maximum: 4
> +

I.e. beta-related properties would go here.

> +      microchip,ideality-factor:
> +        description:
> +          Each channel has an ideality factor.
> +          Beta compensation and resistance error correction automatically
> +          correct for most ideality errors. So ideality factor does not need
> +          to be adjusted in general.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 8
> +        maximum: 55
> +        default: 18
> +