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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0g72U3+u_KedKpZh2TuN-iYbXPcnZhN16oDvi4UqUTr7Q@mail.gmail.com>
Date: Thu, 23 Oct 2025 17:11:17 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Sławomir Rosek <srosek@...gle.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, 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 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.