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: <CANAwSgTBzpL+XMJGhG=38A7GOzeayZaG_2LTvsaE2=mF-pn5mg@mail.gmail.com>
Date: Sat, 21 Jun 2025 12:47:17 +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 Thu, 19 Jun 2025 at 11:15, Anand Moon <linux.amoon@...il.com> wrote:
>
> Hi Mateusz,
>
> On Wed, 18 Jun 2025 at 18:28, Mateusz Majewski <m.majewski2@...sung.com> wrote:
> >
> > >       /* On exynos5420 the triminfo register is in the shared space */
> > > -     if (data->soc == SOC_ARCH_EXYNOS5420_TRIMINFO)
> > > -             trim_info = readl(data->base_second + EXYNOS_TMU_REG_TRIMINFO);
> > > -     else
> > > +     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);
> > > +             sanitize_temp_error(data, trim_info);
> > > +     }
> >
> > If I understand correctly, this means that the triminfo will no longer
> > be read on other SoCs calling this function (3250, 4412, 5250, 5260). Is
> > this intended?
> >
> Thanks for your feedback.
> I will remove the data->soc check for Exynos5420 in the next patch.

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);
 }
>
> > By the way, are we sure that data->base_second really is unnecessary?
> > According to the bindings documentation (in
> > Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml),
> > the different address is necessary because the triminfo registers are
> > misplaced on 5420.
>
> 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.
>
> Well, we are using tmu_triminfo_apbif to configure clk_sec, which is
> using the data->base to enable the clk.
> So, data->base_second is not used any further in the code after we set triminfo

Thanks
Anand

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ