| 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
| ||
|
Message-ID: <CAF3aWvHTXiODVE72Q33KDS51j4QA7gXVSsvdRnvsHdBv4NzCfw@mail.gmail.com>
Date: Mon, 15 Sep 2025 19:13:07 +0200
From: Sławomir Rosek <srosek@...gle.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Alex Hung <alexhung@...il.com>, Hans de Goede <hansg@...nel.org>,
Ilpo Jarvinen <ilpo.jarvinen@...ux.intel.com>, AceLan Kao <acelan.kao@...onical.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>, 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 v1 00/12] ACPI: DPTF: Move INT340X enumeration from DPTF
core to thermal drivers
Hi Rafael,
First of all I would like to apologize for the late reply and thank
you for your comments.
On Mon, Sep 1, 2025 at 10:49 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Sat, Aug 30, 2025 at 7:34 AM Slawomir Rosek <srosek@...gle.com> wrote:
> >
> > The Intel Dynamic Platform and Thermal Framework (DPTF) relies on
> > the INT340X ACPI device objects. The temperature information and
> > cooling ability are exposed to the userspace via those objects.
> >
> > Since kernel v3.17 the ACPI bus scan handler is introduced to prevent
> > enumeration of INT340X ACPI device objects on the platform bus unless
> > related thermal drivers are enabled. However, using the IS_ENABLED()
> > macro in the ACPI scan handler forces the kernel to be recompiled
> > when thermal drivers are enabled or disabled, which is a significant
> > limitation of its modularity. The IS_ENABLED() macro is particularly
> > problematic for the Android Generic Kernel Image (GKI) project which
> > uses unified core kernel while SoC/board support is moved to loadable
> > vendor modules.
> >
> > This patch set moves enumeration of INT340X ACPI device objects on
> > the platform bus from DPTF core to thermal drivers. It starts with
> > some code cleanup and reorganization to eventually remove IS_ENABLED()
> > macro from the ACPI bus scan handler. Brief list of changes is listed
> > below:
> >
> > 1) Remove SOC DTS thermal driver case from the ACPI scan handler
> > since its dependency on INT340X driver is unrelated to DPTF
> > 2) Move all INT340X ACPI device ids to the common header and update
> > the DPTF core and thermal drivers accordingly
> > 3) Move dynamic enumeration of ACPI device objects on the platform bus
> > from the intel-hid and intel-vbtn drivers to the ACPI platform core
> > 4) Move enumeration of INT340X ACPI device objects on the platform bus
> > from DPTF core to thermal drivers using ACPI platform core methods
> >
> >
> > Slawomir Rosek (12):
> > ACPI: DPTF: Ignore SoC DTS thermal while scanning
> > ACPI: DPTF: Move INT3400 device IDs to header
> > ACPI: DPTF: Move INT3401 device IDs to header
> > ACPI: DPTF: Move INT3402 device IDs to header
> > ACPI: DPTF: Move INT3403 device IDs to header
> > ACPI: DPTF: Move INT3404 device IDs to header
> > ACPI: DPTF: Move INT3406 device IDs to header
> > ACPI: DPTF: Move INT3407 device IDs to header
>
> Please avoid sending multiple patches with the same subject,
> especially in one patch series.
>
> Thanks!
>
The subjects are quite similar but they are not exactly the same.
Originally the ACPI bus scan handler was added in 3230bbfce8a9
("ACPI: introduce ACPI int340x thermal scan handler") to prevent
enumeration of ACPI device objects in range INT3401~INT340B
and only the INT3400 master device had their platform driver added
in 816cab931f28 ("Thermal: introduce int3400 thermal driver").
These days, however, each of INT3400~INT3407 device ID, representing
a different kind of thermal device, has its own platform driver.
Most of them, depending on X Lake generation, can also be enumerated
on the ACPI bus using INTC1XXXX device ID. In addition INT3408~INT340B
and some of The Wildcat Lake device IDs are not supported by any
platform driver.
To make the review process easier and minimize the risk of mistakes
I decided to create separe patch for each ID in range INT3400~INT3407.
The INT3400, INT3404 and INT3407 device ID can probably be renamed to
Thermal Core, Fan and Power device ID, respectively, but I am not sure
about the others.
Alternatively they can be squashed into a single patch which moves
all INT340X device IDs to the common header.
Please let me know which way is better.
Thanks, regards
Slawek
> > ACPI: DPTF: Move PCH FIVR device IDs to header
> > ACPI: DPTF: Remove not supported INT340X IDs
> > ACPI: platform: Add macro for acpi platform driver
> > ACPI: DPTF: Move INT340X enumeration to modules
> >
> > drivers/acpi/acpi_platform.c | 27 +++++++
> > drivers/acpi/dptf/dptf_pch_fivr.c | 10 +--
> > drivers/acpi/dptf/dptf_power.c | 20 +----
> > drivers/acpi/dptf/int340x_thermal.c | 76 ++++---------------
> > drivers/acpi/fan.h | 10 +--
> > drivers/acpi/fan_core.c | 2 +-
> > drivers/acpi/int340x_thermal.h | 76 +++++++++++++++++++
> > drivers/platform/x86/intel/hid.c | 41 +---------
> > drivers/platform/x86/intel/vbtn.c | 30 +-------
> > drivers/thermal/intel/Kconfig | 1 +
> > .../intel/int340x_thermal/int3400_thermal.c | 12 +--
> > .../intel/int340x_thermal/int3401_thermal.c | 5 +-
> > .../intel/int340x_thermal/int3402_thermal.c | 5 +-
> > .../intel/int340x_thermal/int3403_thermal.c | 12 +--
> > .../intel/int340x_thermal/int3406_thermal.c | 5 +-
> > include/linux/platform_device.h | 17 +++++
> > 16 files changed, 161 insertions(+), 188 deletions(-)
> > create mode 100644 drivers/acpi/int340x_thermal.h
> >
> > --
Powered by blists - more mailing lists