[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF3aWvHStokULYuGj9rZ4v9dESTxWYtzrx5H6FDP1kdjzfbjYw@mail.gmail.com>
Date: Tue, 23 Sep 2025 14:16:08 +0200
From: Sławomir Rosek <srosek@...gle.com>
To: "Rafael J . Wysocki" <rafael@...nel.org>
Cc: 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 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.
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
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
Please let me know your comment so I can prepare the next version.
Thanks, Regards,
Slawek
> select INTEL_SOC_DTS_IOSF_CORE
> help
> Enable this to register Intel SoCs (e.g. Bay Trail) platform digital
> --
> 2.51.0.384.g4c02a37b29-goog
>
Powered by blists - more mailing lists