linux-kernel - Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver

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: <17758610.geO5KgaWL5@diego>
Date: Tue, 11 Feb 2025 11:19:36 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Kever Yang <kever.yang@...k-chips.com>,
 Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: linux-rockchip@...ts.infradead.org,
 Shaohan Yao <shaohan.yao@...k-chips.com>, linux-pm@...r.kernel.org,
 Lukasz Luba <lukasz.luba@....com>, linux-kernel@...r.kernel.org,
 Zhang Rui <rui.zhang@...el.com>, "Rafael J. Wysocki" <rafael@...nel.org>,
 linux-arm-kernel@...ts.infradead.org
Subject:
 Re: [PATCH 2/2] thermal: rockchip: Support the rk3562 SoC in thermal driver

Hey Daniel,

Am Dienstag, 11. Februar 2025, 10:36:09 MEZ schrieb Daniel Lezcano:
> On 24/12/2024 10:40, Kever Yang wrote:
> > From: Shaohan Yao <shaohan.yao@...k-chips.com>
> > 
> > There are one Temperature Sensor on rk3562, channel 0 is for chip.
> 
> A bit stingy in terms of description, no ?
> 
> 
> > Signed-off-by: Shaohan Yao <shaohan.yao@...k-chips.com>
> > Signed-off-by: Kever Yang <kever.yang@...k-chips.com>
[...]
> > +static const struct tsadc_table rk3562_code_table[] = {
> > +	{0, -40000},
> > +	{1419, -40000},
> > +	{1428, -35000},
> > +	{1436, -30000},
> > +	{1445, -25000},
> > +	{1453, -20000},
> > +	{1462, -15000},
> > +	{1470, -10000},
> > +	{1479, -5000},
> > +	{1487, 0},
> > +	{1496, 5000},
> > +	{1504, 10000},
> > +	{1512, 15000},
> > +	{1521, 20000},
> > +	{1529, 25000},
> > +	{1538, 30000},
> > +	{1546, 35000},
> > +	{1555, 40000},
> > +	{1563, 45000},
> > +	{1572, 50000},
> > +	{1580, 55000},
> > +	{1589, 60000},
> > +	{1598, 65000},
> > +	{1606, 70000},
> > +	{1615, 75000},
> > +	{1623, 80000},
> > +	{1632, 85000},
> > +	{1640, 90000},
> > +	{1648, 95000},
> > +	{1657, 100000},
> > +	{1666, 105000},
> > +	{1674, 110000},
> > +	{1682, 115000},
> > +	{1691, 120000},
> > +	{1699, 125000},
> > +	{TSADCV2_DATA_MASK, 125000},
> > +};
> 
> May be it is time to optimize all these tables out of the memory driver?
> 
> It is the 9th table introduced.

just to see if we think differently, what do you have in mind?

For me the adc-to-temperature conversion _is_ part of the hw-block itself,
so should likely not spill into the devicetree, but you're right, defining
a big table for each soc also isn't really great.

For the rk3562 in question, the stepping seems to be 8,9,8,9,....
where for the rk3568 the value stepping seems to be 32,36,32,36,...
and it looks similar for the other socs too, with the driver is already
interpolating between values it seems.

So even just halving (or more) all the big tables (dropping every second
entry for example) should not really loose us real granularity.

Heiko