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: <CAJZ5v0gJYOcTCACj6jKYL6juAYpUvJUf89kZ6ZxU3fMOpBjFzQ@mail.gmail.com>
Date: Thu, 23 Oct 2025 18:30:08 +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 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!