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: <f13f480aae41e7d893bc6b285e3ad95c@manjaro.org>
Date: Thu, 27 Feb 2025 18:01:00 +0100
From: Dragan Simic <dsimic@...jaro.org>
To: Lukasz Luba <lukasz.luba@....com>
Cc: rafael@...nel.org, daniel.lezcano@...aro.org,
 linux-rockchip@...ts.infradead.org, rui.zhang@...el.com, heiko@...ech.de,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Kever
 Yang <kever.yang@...k-chips.com>, Diederik de Haas <didi.debian@...ow.org>,
 linux-pm@...r.kernel.org
Subject: Re: [PATCH] thermal: rockchip: Extract TSADC conversion tables into a
 header file

Hello Lukasz,

On 2025-02-27 15:42, Lukasz Luba wrote:
> On 2/26/25 13:42, Dragan Simic wrote:
>> Move the TSADC code-to-temperature mapping tables from the Rockchip 
>> thermal
>> driver to a separate header file, to no longer have the somewhat 
>> cluttering
>> mapping data as part of the driver itself. [1]
>> 
>> These mapping tables come verbatim from the SoC technical reference 
>> manuals
>> (TRMs) and the downstream kernel code, [2] and may be updated at some 
>> point
>> in the future, according to the manufacturer test results, [3] so 
>> extracting
>> the tables into a separate header file not just improves the 
>> readability of
>> the driver code, but introduces a clear separation.
>> 
>> Improve the wording of the moved comment block, sprinkle a few short 
>> comments
>> over the newly introduced header file, and move the already existing 
>> single
>> stray #include directive in the driver code to its beginning.
>> 
>> [1] 
>> https://lore.kernel.org/linux-rockchip/7f17cc55-a741-4bb8-9513-0580ca6fedd3@linaro.org/T/#u
>> [2] 
>> https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/drivers/thermal/rockchip_thermal.c
>> [3] 
>> https://lore.kernel.org/linux-rockchip/b4ab86b56177a234f3738c477693e858@manjaro.org/T/#u
> 
> I think Daniel was more thinking something about saving the
> memory in the kernel. I see how this patch can help the readability
> of the driver code, but that doesn't help much to not occupy the kernel
> data. The driver will be built with that memory and the distro would
> run on some platform with particular chip. The other chips data won't
> be needed.

Thanks for your response!  Yes, carrying all that data in the kernel
memory, out of which only one variant actually gets used at runtime,
is far from optimal.

> Why not to have that information in the DT?
> That would save the memory and be configurable for only needed 
> platform.
> Please have a look into the generic thermal ADC driver and related
> DT entry, which is used e.g. here [1].
> That table looks similar to your info.

Let me have a detailed look into all that, please, and I'll come back
with some further thoughts.

> [1] 
> https://elixir.bootlin.com/linux/v6.13.4/source/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi#L136

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ