linux-kernel - Re: [PATCH v6 0/4] Exynos Thermal code improvement

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANAwSgSA-JHMRD7-19wijOY=TSWD-sv6yyrT=mH+wkUJuvxFAw@mail.gmail.com>
Date: Thu, 15 May 2025 16:40:27 +0530
From: Anand Moon <linux.amoon@...il.com>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>, Krzysztof Kozlowski <krzk@...nel.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Zhang Rui <rui.zhang@...el.com>, 
	Lukasz Luba <lukasz.luba@....com>, Alim Akhtar <alim.akhtar@...sung.com>, 
	Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <nick.desaulniers+lkml@...il.com>, 
	Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, 
	"open list:SAMSUNG THERMAL DRIVER" <linux-pm@...r.kernel.org>, 
	"open list:SAMSUNG THERMAL DRIVER" <linux-samsung-soc@...r.kernel.org>, 
	"moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" <linux-arm-kernel@...ts.infradead.org>, 
	open list <linux-kernel@...r.kernel.org>, 
	"open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b" <llvm@...ts.linux.dev>
Subject: Re: [PATCH v6 0/4] Exynos Thermal code improvement

Hi Daniel,

On Wed, 14 May 2025 at 16:53, Daniel Lezcano <daniel.lezcano@...aro.org> wrote:
>
> On Wed, Apr 30, 2025 at 06:02:56PM +0530, Anand Moon wrote:
> > Hi All,
>
> Hi Anand,
>
> if the goal of the changes is to do cleanups, I recommend to rework
> how the code is organized. Instead of having the data->soc check all
> around the functions, write per platform functions and store them in
> struct of_device_id data field instead of the soc version.
>
> Basically get rid of exynos_map_dt_data by settings the different ops
> in a per platform structure.
>
> Then the initialization routine would be simpler to clean.
>

Thanks, I had previously attempted this approach.
The goal is to split the exynos_tmu_data structure to accommodate
SoC-specific callbacks for initialization and configuration.

In my earlier attempt, I tried to refactor the code to achieve this.
However, the main challenge I encountered was that the
exynos_sensor_ops weren’t being correctly mapped for each SoC.

Some SoC have multiple sensor
exynos4x12
                    tmu: tmu@...c0000
exynos5420
                tmu_cpu0: tmu@...60000
                tmu_cpu1: tmu@...64000
                tmu_cpu2: tmu@...68000
                tmu_cpu3: tmu@...6c000
                tmu_gpu: tmu@...a0000
 exynos5433
                tmu_atlas0: tmu@...60000
                tmu_atlas1: tmu@...68000
                tmu_g3d: tmu@...70000
exynos7
                tmu@...60000

It could be a design issue of the structure.or some DTS issue.
So what I found in debugging it is not working correctly.

static const struct thermal_zone_device_ops exynos_sensor_ops = {
        .get_temp = exynos_get_temp,
        .set_emul_temp = exynos_tmu_set_emulation,
        .set_trips = exynos_set_trips,
};

The sensor callback will not return a valid pointer and soc id for the get_temp.

Here is my earlier version of local changes.
[1] https://pastebin.com/bbEP04Zh exynos_tmu.c
[2] https://pastebin.com/PzNz5yve Odroid U3 dmesg.log
[3] https://pastebin.com/4Yjt2d2u    Odroid Xu4 dmesg.log

I want to re-model the structure to improve the code.
Once Its working condition I will send this for review.

If you have some suggestions please let me know.

Thanks
-Anand