linux-kernel - Re: [PATCH v3 1/3] dt-bindings: thermal: sophgo,cv1800-thermal: Add Sophgo CV1800 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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SEYPR01MB4221C23C14DB53299E2E2F12D7DE2@SEYPR01MB4221.apcprd01.prod.exchangelabs.com>
Date: Thu, 4 Jul 2024 08:25:10 +0000
From: Haylen Chu <heylenay@...look.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Conor Dooley <conor@...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>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Chen Wang <unicorn_wang@...look.com>,
	Inochi Amaoto <inochiama@...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 v3 1/3] dt-bindings: thermal: sophgo,cv1800-thermal: Add
 Sophgo CV1800 thermal

On Tue, Jul 02, 2024 at 05:09:35PM +0200, Krzysztof Kozlowski wrote:
> >> +
> >> +properties:
> >> +  compatible:
> >> +    enum:
> >> +      - sophgo,cv1800-thermal
> >> +
> >> +  reg:
> >> +    maxItems: 1
> >> +
> >> +  clocks:
> >> +    description: The thermal sensor clock
> >> +
> >> +  interrupts:
> >> +    maxItems: 1
> >> +
> >> +  accumulation-period:
> >> +    $ref: /schemas/types.yaml#/definitions/uint32
> >> +    description: Accumulation period for a sample
> >> +    enum:
> >> +      - 512
> >> +      - 1024
> >> +      - 2048
> >> +      - 4096
> >> +    default: 2048
> >> +
> >> +  chop-period:
> 
> period in what sort of units? Sounds like time to me, so this would
> require proper unit suffix.

In clock ticks.

When setting to 1024, a time of sample takes (1024 + 2 + 64) clock
ticks. The clock runs at (25MHz / divider) and the divider is
configurable.

> > 
> >> +    description: Period between samples. Should be greater than 524us.
> > 
> > The constraint here should be "minimum: 524". What's the upper limit?
> > 
> >> +    default: 1000000
> > 
> > Rob/Krzysztof, could you comment on the suitability of the three custom
> > properties here? I know if this was an IIO device, these kinds of things
> > would be controllable from userspace, and not in the binding. I
> > mentioned this on the previous version, but I'm not really sure if
> > thermal devices are somehow different:
> > https://lore.kernel.org/all/SEYPR01MB4221A739D0645EF0255336EBD7CE2@SEYPR01MB4221.apcprd01.prod.exchangelabs.com/
> > 
> 
> Why would different boards have different values here? Does it affect
> accuracy? If so, how much?
> 
> I doubt there are any boards with different values, thus it sounds like
> unnecessary tuning parameter.

Theses values affect accuracy in a minor way (about 1 Celsius degree in
my test) and could be shared between CV18xx/SG20xx SoCs as they have the
same design.

In the first revision, fixed values are used, and I was asked to add
support for all possible configuration[1]. Now I think this introduces
extra unnecessary complexity and should be avoided, since this is a
simple thermal sensor, tuning seems to be useless.

I suggest renaming "sample-cycle-us" to "sample-rate-hz" and dropping
other parameters for simplicity.

Best regards,
Haylen Chu

[1]: https://lore.kernel.org/all/IA1PR20MB49533177BEFC431FC16D1AB8BBF32@IA1PR20MB4953.namprd20.prod.outlook.com/