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: <CANAwSgTdOyOxhBuFypyJpwjBVa+uKO9R3+6DMYOrnjsC5xvUZw@mail.gmail.com>
Date: Thu, 26 Jun 2025 23:52:38 +0530
From: Anand Moon <linux.amoon@...il.com>
To: Mateusz Majewski <m.majewski2@...sung.com>
Cc: alim.akhtar@...sung.com, bzolnier@...il.com, daniel.lezcano@...aro.org, 
	krzk@...nel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, 
	linux-samsung-soc@...r.kernel.org, lukasz.luba@....com, rafael@...nel.org, 
	rui.zhang@...el.com
Subject: Re: [RRC v1 1/3] thermal/drivers/exynos: Remove unused base_second
 mapping and references

Hi Mateusz,

On Wed, 25 Jun 2025 at 20:08, Mateusz Majewski <m.majewski2@...sung.com> wrote:
>
> > Can you check with with following changes
> >
> > diff --git a/drivers/thermal/samsung/exynos_tmu.c
> > b/drivers/thermal/samsung/exynos_tmu.c
> > index 9fc085f4ea1a..0776801fafea 100644
> > --- a/drivers/thermal/samsung/exynos_tmu.c
> > +++ b/drivers/thermal/samsung/exynos_tmu.c
> > @@ -469,14 +469,11 @@ static void exynos4412_tmu_initialize(struct
> > platform_device *pdev)
> >         ctrl = readl(data->base + EXYNOS_TMU_TRIMINFO_CON2);
> >         ctrl = EXYNOS_TRIMINFO_RELOAD_ENABLE;
> >         writel(ctrl, data->base + EXYNOS_TMU_TRIMINFO_CON2);
> > +       return;
> >     }
> >
> > -   /* On exynos5420 the triminfo register is in the shared space */
> > -   if (data->soc == SOC_ARCH_EXYNOS5420
> > -           data->soc == SOC_ARCH_EXYNOS5420_TRIMINFO) {
> > -       trim_info = readl(data->base + EXYNOS_TMU_REG_TRIMINFO);
> > -       sanitize_temp_error(data, trim_info);
> > -   }
> > +   trim_info = readl(data->base + EXYNOS_TMU_REG_TRIMINFO);
> > +   sanitize_temp_error(data, trim_info);
> > }
>
Thanks for the feedback,
> This does seem to work (tested on 3250 and on 5420) in the sense that I
> can read the temperatures, when they increase the state of the cooling
> device gets increased, and the values look reasonable and stay in a
> reasonable range. Hard to say if the trim and the temperature values are
> correct, though.
>
The driver should read the EXYNOS_TMU_REG_TRIMINFO register
after setting the RELOAD bit to 0x1 in the TRIMINFO_CONTROL (0x14) register.

RELOAD Trim information
Before read TRIMINFO, you shall set RELOAD to 1.
1 = Reload

> (FYI I will probably have a harder time regarding the drivers from
> GitHub you linked in 2/3, so no promises on testing them.)
>
It's just a reference point for gathering information - a few things
are missing in the driver.

> > As per my Exynos5422 user manual and DTS mapping
> > thermal-sensor tmu@...60000 is mapped to CPU0 with tmu_apbif clock
> > thermal-sensor tmu@...64000 is mapped to CPU1 with tmu_apbif clock
> > thermal-sensor tmu@...68000 is mapped to CPU2 with tmu_apbif clock
> > thermal-sensor tmu@...6c000 is mapped to CPU3 with tmu_apbif clock
> > thermal-sensor tmu@...a0000 is mapped to GPU with tmu_triminfo_apbif clock.
>
> Hmm, I might be missing something, but I think the DTS does link to two
> adresses and two clocks, for instance for GPU (in
> arch/arm/boot/dts/samsung/exynos5420.dtsi):
>
>                 tmu_gpu: tmu@...a0000 {
>                         compatible = "samsung,exynos5420-tmu-ext-triminfo";
>                         reg = <0x100a0000 0x100>, <0x10068000 0x4>;
>                         interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
>                         clocks = <&clock CLK_TMU_GPU>, <&clock CLK_TMU>;
>                         clock-names = "tmu_apbif", "tmu_triminfo_apbif";
>                         #thermal-sensor-cells = <0>;
>                 };
>
> The manual does indeed not say anything about this, but I feel like the
> current code in essence states that the manual is not correct. We
> probably should have some evidence that the current code is wrong and
> the manual was correct all along?
Well, I tried to fix the DTS, but it didn't work.
>
> Thank you,
> Mateusz Majewski

Thanks
-Anand

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ