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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANAwSgQ=G1yJXOg1LdeEf-J56epyNiohCSdNYUvs2AHNv90Hkg@mail.gmail.com>
Date: Sat, 21 Jun 2025 12:46:53 +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 2/3] thermal/drivers/exynos: Handle temperature threshold
 interrupts and clear corresponding IRQs

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 17:22, Mateusz Majewski <m.majewski2@...sung.com> wrote:
> >
> > Hello :)
> >
> > > +#define INTSTAT_FALL2        BIT(24)
> > > +#define INTSTAT_FALL1        BIT(20)
> > > +#define INTSTAT_FALL0        BIT(16)
> > > +#define INTSTAT_RISE2        BIT(8)
> > > +#define INTSTAT_RISE1        BIT(4)
> > > +#define INTSTAT_RISE0        BIT(0)
> > > +
> > > +#define INTCLEAR_FALL2       BIT(24)
> > > +#define INTCLEAR_FALL1       BIT(20)
> > > +#define INTCLEAR_FALL0       BIT(16)
> > > +#define INTCLEAR_RISE2       BIT(8)
> > > +#define INTCLEAR_RISE1       BIT(4)
> > > +#define INTCLEAR_RISE0       BIT(0)
> >
> > > +     /* Map INTSTAT bits to INTCLEAR bits */
> > > +     if (val_irq & INTSTAT_FALL2)
> > > +             clearirq |= INTCLEAR_FALL2;
> > > +     else if (val_irq & INTSTAT_FALL1)
> > > +             clearirq |= INTCLEAR_FALL1;
> > > +     else if (val_irq & INTSTAT_FALL0)
> > > +             clearirq |= INTCLEAR_FALL0;
> > > +     else if (val_irq & INTSTAT_RISE2)
> > > +             clearirq |= INTCLEAR_RISE2;
> > > +     else if (val_irq & INTSTAT_RISE1)
> > > +             clearirq |= INTCLEAR_RISE1;
> > > +     else if (val_irq & INTSTAT_RISE0)
> > > +             clearirq |= INTCLEAR_RISE0;
> >
> > This implies that only these 6 bits are used. Is this true for all SoCs
> > supported by this driver? My understanding is that Exynos 5433 in particular
> > uses bits 7:0 for rise interrupts and 23:16 for fall interrupts. When I tested
> > this patch (both alone and the whole series) on 5433 by running some CPU load,
> > the interrupt seemed to not fire consistently:
> > /sys/class/thermal/cooling_device1/cur_state would never go above 1 (which is
> > consistent with the interrupt firing once, not getting cleared and never firing
> > again; without this patch, it consistently went up to 6) and I got a quick
> > reboot every time.
> >
> Thanks for the feedback,
>
> As per the user manual Exynos4412
> INTSTAT and INTCLEAR have a clear mapping with bits
> falling 20, 16, 12 and rising 8 4 0
>
> whereas Exyno5422 has
> INTSTAT and INTCLEAR have a clear mapping with bits
> falling 24, 20, 16, and rising 8 4 0
>
> Yes, it could differ for all the SoCs,
> I don't have the user manual or TRM for these SoCs
> to configure correctly.
>
> I tried to configure this, referring to the comment in the driver
>         /*
>          * Clear the interrupts.  Please note that the documentation for
>          * Exynos3250, Exynos4412, Exynos5250 and Exynos5260 incorrectly
>          * states that INTCLEAR register has a different placing of bits
>          * responsible for FALL IRQs than INTSTAT register.  Exynos5420
>          * and Exynos5440 documentation is correct (Exynos4210 doesn't
>          * support FALL IRQs at all).
>          */
>
> By the way, I don't see Exynos5433 and Exynos7 support
> INTSTAT and INTCLEAR registers. We are using TMU_REG_INTPEND
>  to read and update the same register.
>
>         if (data->soc == SOC_ARCH_EXYNOS5260) {
>                 tmu_intstat = EXYNOS5260_TMU_REG_INTSTAT;
>                 tmu_intclear = EXYNOS5260_TMU_REG_INTCLEAR;
>         } else if (data->soc == SOC_ARCH_EXYNOS7) {
>                 tmu_intstat = EXYNOS7_TMU_REG_INTPEND;
>                 tmu_intclear = EXYNOS7_TMU_REG_INTPEND;
>         } else if (data->soc == SOC_ARCH_EXYNOS5433) {
>                 tmu_intstat = EXYNOS5433_TMU_REG_INTPEND;
>                 tmu_intclear = EXYNOS5433_TMU_REG_INTPEND;
>         } else {
>                 tmu_intstat = EXYNOS_TMU_REG_INTSTAT;
>                 tmu_intclear = EXYNOS_TMU_REG_INTCLEAR;
>         }
>
I don't have Exynos  Arm64 boards to test on

I believe the Exynos5433 and Exynos7 also use the same
register addresses for INTSTAT and INTCLEAR.

[1] https://github.com/universal5433/android_kernel_samsung_universal5433/blob/lineage-18.1/drivers/thermal/exynos_thermal.c#L854-L892
[2] https://github.com/enesuzun2002/android_kernel_samsung_exynos7420/blob/nx-9.0/drivers/thermal/cal_tmu7420.c#L14-L221

If you have details on how INTSTAT and INTCLEAR are used
particularly regarding the update bits, please share them.
Specifically, I'm interested in how bits [7:0] correspond to rising edge
interrupts and bits [23:16] to falling edge interrupts
I feel it's the same as Exynos54222.

Can you test with these changes? If you have any suggestions,
please feel free to share them

Thanks
-Anand

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ