linux-kernel - Re: [PATCH v3 2/6] ACPI: DPTF: Move INT340X device IDs to header

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: <CAF3aWvGN2ipXNPs_3UNppJppwo+2J1uvjVTD2tyXoQ6ATdkuPQ@mail.gmail.com>
Date: Mon, 3 Nov 2025 17:30:22 +0100
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 v3 2/6] ACPI: DPTF: Move INT340X device IDs to header

On Thu, Oct 23, 2025 at 6:30 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Thu, Oct 23, 2025 at 6:27 PM Sławomir Rosek <srosek@...gle.com> wrote:
> >
> > On Thu, Oct 23, 2025 at 5:11 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
> > >
> > > On Thu, Oct 23, 2025 at 4:41 PM Sławomir Rosek <srosek@...gle.com> wrote:
> > > >
> > > > On Wed, Oct 22, 2025 at 8:46 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
> > > > >
> > > > > On Thu, Oct 2, 2025 at 1:34 PM Slawomir Rosek <srosek@...gle.com> wrote:
> > > > > >
> > > > > > The ACPI INT340X device IDs are shared between the DPTF core
> > > > > > and thermal drivers, thus they are moved to the common header.
> > > > > >
> > > > > > Signed-off-by: Slawomir Rosek <srosek@...gle.com>
> > > > >
> > > > > I've actually started to wonder if int340x_thermal_handler is needed at all.
> > > > >
> > > > > It just creates a platform device if the given ACPI device ID is in
> > > > > its list,
> > > >
> > > > That's true. It creates platform device for the given ACPI device ID,
> > > > but only if CONFIG_INT340X_THERMAL is enabled.
> > > >
> > > > > but acpi_default_enumeration() would do that too with the
> > > > > caveat that it would also be done for CONFIG_INT340X_THERMAL unset.
> > > >
> > > > Not exactly. scan handler returns ret=1, so device is marked as enumerated
> > > > https://elixir.bootlin.com/linux/v6.18-rc2/source/drivers/acpi/scan.c#L2314
> > > >
> > > > > That should not be a problem though because if CONFIG_INT340X_THERMAL,
> > > > > there are no drivers that will bind to those platform devices, so the
> > > > > net outcome should be the same.
> > > >
> > > > If CONFIG_INT340X_THERMAL is not set and there are no drivers to attach
> > > > to platform devices and int340x_thermal_handler is removed then you are
> > > > right, acpi_default_enumeration() will enumerate ACPI bus anyway and
> > > > create platform devices for all ACPI device IDs. However, for me it looks
> > > > like it was intentional to prevent this behaviour unless INT340X drivers
> > > > are "present" in the system (were enabled for build so should be).
> > > > I am not sure how DPTF works and what may happen if platform devices are
> > > > visible in sysfs while drivers are not loaded.
> > >
> > > Such a dependency would be unexpected and confusing.
> > >
> > > Also, I'm not sure why it would be useful because the lack of drivers
> > > means that the devices in question are not handled, so no
> > > functionality related to them is provided by the kernel.
> > >
> > > > >
> > > > > Thus I'm wondering if the way to go might be to drop
> > > > > int340x_thermal_handler and simply keep the device IDs in the drivers
> > > > > that use them for device binding.
> > > >
> > > > Even better. If it's not required for DPTF to prevent enumeration
> > > > on the platform bus I can simply remove the scan handler.
> > >
> > > I would at least try to do that.
> >
> > Makes sense, so I'll give it a try. Removing handler will result with
> > only two patches, one to update dts_doc_thermal kconfig and second
> > to remove the dptf scan handler, the rest won't be needed for a new
> > patchset. Should I send it as v4?
>
> Yes, please!

I removed the scan handler and tested it on i7-9750H using Ubuntu
24.04, Linux 6.12.56
and DPTF 9.0.11402. With CONFIG_INT340X_THERMAL enabled DPTF daemon
starts without
errors, with CONFIG_INT340X_THERMAL disabled the int340x devices are enumerated
on the platform bus and DPTF fails to retrieve TCC Offset on initialization:

2025-11-03T09:03:07.108038+01:00 localhost kernel: Consider using
thermal netlink events interface
2025-11-03T09:03:07.109139+01:00 localhost DPTF[4098]:
ERROR:[<ACTION>ActionSysfsGet@...f_uf_action_sysfs_os_lin.c#1205]<1762156987108
ms>: Error retrieving TCC Offset value from sysfs.

For comparison, with CONFIG_INT340X_THERMAL disabled on the pure Linux 6.12.56
the int340x are not enumerated on the platform bus and DPTF initialization fails
as follow:

2025-11-03T08:43:31.725514+01:00 localhost kernel: Consider using
thermal netlink events interface
2025-11-03T08:43:31.727119+01:00 localhost DPTF[4046]:
ERROR:[<LINUX>GetManagerSysfsPath@...f_uf_sysfs_enumerate_os_lin.c#1004]<1762155811726
ms>: GetManagerSysfsPathFromAcpiId failed
2025-11-03T08:43:31.727934+01:00 localhost DPTF[4046]:
ERROR:[<ACTION>ActionSysfsGet@...f_uf_action_sysfs_os_lin.c#1205]<1762155811727
ms>: Error retrieving TCC Offset value from sysfs.
2025-11-03T08:43:31.729027+01:00 localhost DPTF[4046]:
ERROR:[<ACTION>GetGddvData@...f_uf_action_sysfs_os_lin.c#2818]<1762155811728
ms>: g_ManagerSysfsPath Invalid

Link to v4: https://lore.kernel.org/all/20251103162516.2606158-1-srosek@google.com/

Thanks!