linux-kernel - Re: [PATCH v2 1/6] ACPI: DPTF: Ignore SoC DTS thermal while scanning

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: <CAJZ5v0hCZ0FqS7ehm_Y21=q73CcOxYmYz0z-JRk2t_96HQ+TZQ@mail.gmail.com>
Date: Wed, 1 Oct 2025 21:33:11 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Sławomir Rosek <srosek@...gle.com>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>, Daniel Lezcano <daniel.lezcano@...aro.org>, 
	AceLan Kao <acelan.kao@...onical.com>, Ilpo Jarvinen <ilpo.jarvinen@...ux.intel.com>, 
	Hans de Goede <hansg@...nel.org>, Alex Hung <alexhung@...il.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Zhang Rui <rui.zhang@...el.com>, 
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, Tomasz Nowicki <tnowicki@...gle.com>, 
	Stanislaw Kardach <skardach@...gle.com>, Michal Krawczyk <mikrawczyk@...gle.com>, 
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org, 
	platform-driver-x86@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 1/6] ACPI: DPTF: Ignore SoC DTS thermal while scanning

Hi,

Sorry for the delay.

On Tue, Sep 23, 2025 at 2:16 PM Sławomir Rosek <srosek@...gle.com> wrote:
>
> Hi Rafael
>
> On Wed, Sep 17, 2025 at 2:07 PM Slawomir Rosek <srosek@...gle.com> wrote:
> >
> > The Intel SoC DTS thermal driver on Baytrail platform uses IRQ 86 for
> > critical overheating notification. The IRQ 86 is described in the _CRS
> > control method of INT3401 device, thus Intel SoC DTS thermal driver
> > requires INT3401 device to be enumerated.
> >
> > Since dependency on INT3401 device is unrelated to DPTF the IS_ENABLE()
> > macro is removed from ACPI DPTF INT340X scan handler, instead Kconfig
> > is updated to ensure proper enumeration of INT3401 device.
> >
> > Fixes: 014d9d5d0cc1 ("ACPI/int340x_thermal: enumerate INT3401 for Intel SoC DTS thermal driver")
> > Signed-off-by: Slawomir Rosek <srosek@...gle.com>
> > ---
> >  drivers/acpi/dptf/int340x_thermal.c | 7 +------
> >  drivers/thermal/intel/Kconfig       | 1 +
> >  2 files changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/acpi/dptf/int340x_thermal.c b/drivers/acpi/dptf/int340x_thermal.c
> > index a222df059a16..947fe50c2ef6 100644
> > --- a/drivers/acpi/dptf/int340x_thermal.c
> > +++ b/drivers/acpi/dptf/int340x_thermal.c
> > @@ -11,10 +11,9 @@
> >
> >  #include "../internal.h"
> >
> > -#define INT3401_DEVICE 0X01
> >  static const struct acpi_device_id int340x_thermal_device_ids[] = {
> >         {"INT3400"},
> > -       {"INT3401", INT3401_DEVICE},
> > +       {"INT3401"},
> >         {"INT3402"},
> >         {"INT3403"},
> >         {"INT3404"},
> > @@ -76,10 +75,6 @@ static int int340x_thermal_handler_attach(struct acpi_device *adev,
> >  {
> >         if (IS_ENABLED(CONFIG_INT340X_THERMAL))
> >                 acpi_create_platform_device(adev, NULL);
> > -       /* Intel SoC DTS thermal driver needs INT3401 to set IRQ descriptor */
> > -       else if (IS_ENABLED(CONFIG_INTEL_SOC_DTS_THERMAL) &&
> > -                id->driver_data == INT3401_DEVICE)
> > -               acpi_create_platform_device(adev, NULL);
> >         return 1;
> >  }
> >
> > diff --git a/drivers/thermal/intel/Kconfig b/drivers/thermal/intel/Kconfig
> > index e0268fac7093..47950859b790 100644
> > --- a/drivers/thermal/intel/Kconfig
> > +++ b/drivers/thermal/intel/Kconfig
> > @@ -45,6 +45,7 @@ config INTEL_SOC_DTS_IOSF_CORE
> >  config INTEL_SOC_DTS_THERMAL
> >         tristate "Intel SoCs DTS thermal driver"
> >         depends on X86 && PCI && ACPI
> > +       select INT340X_THERMAL
>
> This selection does not meet INT340X_THERMAL requirements so
> kernel tests are failing for randomly generated i386 config
> https://lore.kernel.org/all/202509181359.fLTuROj6-lkp@intel.com/
> I am considering two options:
>
> 1) Align SoC DTS thermal driver dependencies to match INT340X.
> Currently X86_64 and NET are missing. This is quite simple fix
> but after that enabling a SoC DTS thermal won't be possible
> for i386. From the other hand the driver requires ATOM Silvermont
> https://elixir.bootlin.com/linux/v6.17-rc7/source/drivers/thermal/intel/intel_soc_dts_thermal.c#L39
> which is a 64bit architecture, so I am not sure if support
> for i386 is really required.

I wouldn't worry about this.  I'd just make SoC DTS thermal explicitly
depend on X86_64.

> 2) Don't select INT340X driver (the original patch does not)
> and use acpi_walk_namespace to enumerate INT3401 on the platform
> bus just before intel_soc_dts_iosf_init is called
> https://elixir.bootlin.com/linux/v6.17-rc7/source/drivers/thermal/intel/intel_soc_dts_thermal.c#L54

I'm not a big fan of using acpi_walk_namespace() for such things.

Those namespace walks usually end up being quite expensive.

> The code would be cleaned up later with next version of patch 5/6
> and direct call to acpi_walk_namespace would be replaced with
> dedicated function exported by acpi platform core. Eventually,
> after the the last patch, there would be two drivers enumerating
> INT3401 which shouldn't be an issue since the acpi_walk_namespace
> uses global mutex while traversing the acpi device tree

Well, this doesn't sound really straightforward.

> Please let me know your comment so I can prepare the next version.

I'd go for option 1).

Thanks!