linux-kernel - Re: [PATCH v2 1/3] dt-bindings: thermal: sophgo,cv180x-thermal: Add Sophgo CV180x thermal

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:
 <SEYPR01MB4221A739D0645EF0255336EBD7CE2@SEYPR01MB4221.apcprd01.prod.exchangelabs.com>
Date: Tue, 18 Jun 2024 07:56:43 +0000
From: Haylen Chu <heylenay@...look.com>
To: Conor Dooley <conor@...nel.org>
Cc: Inochi Amaoto <inochiama@...look.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Zhang Rui <rui.zhang@...el.com>, Lukasz Luba <lukasz.luba@....com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Chen Wang <unicorn_wang@...look.com>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>,
	Jisheng Zhang <jszhang@...nel.org>, linux-pm@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 1/3] dt-bindings: thermal: sophgo,cv180x-thermal: Add
 Sophgo CV180x thermal

On Thu, Jun 06, 2024 at 06:05:30PM +0100, Conor Dooley wrote:
> On Thu, Jun 06, 2024 at 01:32:46PM +0000, Haylen Chu wrote:
> > Both accumulation-period and chop-period specify how the sensor
> > measures temperature. Making these parameters up to end users brings
> > extra unnecessary code complexity. Being configurable for each board
> > should be enough and other thermal drivers have been doing things in
> > this way.
> 
> Other systems may well have properties for this, but something being
> done in the past doesn't mean it might be the right thing to do now.
> I don't really buy that this is something you set to a fixed value per
> board, but rather the use case of a particular board would factor into
> whether or not you would want to use a shorter or longer accumulation
> period.

Accumulation period and chop period do only affect the accuracy of its
result, in a range about 1 Celsius degree. Changing these parameters
does not mean much to end users, as this is only a thermal sensor and
1 Celsius is quite good for its usage. And users could always switch to
another configuration with a dt-overlay.

> > I do not catch your idea. These values directly map to raw register
> > configuration, which simplify the implementation a lot.
> 
> It should be trivial to convert them to register values in your driver.

Okay, I will do this.

> > > > > +    default: 3
> > > > > +
> > > > > +  sample-cycle-us:
> > > > > +    description: Period between samples
> > > > > +    default: 1000000
> > > No constraints?
> > 
> > Sample cycle is more flexible because of hardware designing.
> 
> It quite likely has constraints, flexible or not. Is the hardware
> capable of both 1 us and uint32_max us?

It should be a value between 524 and 2^24 - 1. Will document this in
next revision.

> Thanks,
> Conor.

Best regards,
Haylen Chu