linux-kernel - Re: [PATCH v2 1/2] dt-bindings: thermal: generic-adc: Add optional io-channel-cells property

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]

Message-ID: <CAPVz0n11um0ebY8_fn9owxo_pp+jbykFFYxhDA=BwZccvcJZgw@mail.gmail.com>
Date: Sat, 22 Feb 2025 09:12:32 +0200
From: Svyatoslav Ryhel <clamor95@...il.com>
To: Rob Herring <robh@...nel.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Daniel Lezcano <daniel.lezcano@...aro.org>, 
	Zhang Rui <rui.zhang@...el.com>, Lukasz Luba <lukasz.luba@....com>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Laxman Dewangan <ldewangan@...dia.com>, linux-pm@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: thermal: generic-adc: Add optional
 io-channel-cells property

пт, 21 лют. 2025 р. о 23:13 Rob Herring <robh@...nel.org> пише:
>
> On Wed, Feb 19, 2025 at 10:28:16AM +0200, Svyatoslav Ryhel wrote:
> > Since device is a thermal sensor it needs '#io-channel-cells' to allow
> > exposure of thermal data via IIO means.
>
> This looks odd. The consumer is also a producer? What in DT would be the
> 2nd consumer. If you don't have a consumer in the DT, then you don't
> need '#io-channel-cells'.
>

No, this binding in general describes converting of iio adc data into
thermal data, using device specific conversion table. Resulting
thermal data is exposed as thermal sensor cell for thermal zone
binding. What I did is that I just exposed thermal data as temp iio
channel (processed). Real use case: I own an embedded device which has
a dedicated sensor for battery temperature control, but to indicate
the temperature is used adc channel of that sensor and adc data is
converted using a device specific table into temperature. Basically
this fits existing generic-adc-thermal setup to create a thermal zone,
but along with all that, the fuel gauge which monitors battery can
accept iio temp channel to expose battery temperature. This is what I
am adding here.

adc sensor > generic-adc-thermal > temp channel > battery gauge

> I would like to see Jonathan's buy in on this.
>
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@...il.com>
> > ---
> >  .../devicetree/bindings/thermal/generic-adc-thermal.yaml      | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml b/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml
> > index 12e6418dc24d..4bc2cff0593c 100644
> > --- a/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml
> > +++ b/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml
> > @@ -30,6 +30,9 @@ properties:
> >    io-channel-names:
> >      const: sensor-channel
> >
> > +  '#io-channel-cells':
> > +    const: 1
>
> You have to document what is in the cells.
>
> > +
> >    temperature-lookup-table:
> >      description: |
> >        Lookup table to map the relation between ADC value and temperature.
> > @@ -60,6 +63,7 @@ examples:
> >          #thermal-sensor-cells = <0>;
> >          io-channels = <&ads1015 1>;
> >          io-channel-names = "sensor-channel";
> > +        #io-channel-cells = <1>;
> >          temperature-lookup-table = <
> >                (-40000) 2578
> >                (-39000) 2577
> > --
> > 2.43.0
> >