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: <CAF3aWvFc5ZZo3VaJSr68FwGuCFYJU=tXsJ6Fm1vmNLs4B=+8dg@mail.gmail.com>
Date: Thu, 23 Oct 2025 18:27:23 +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 v3 2/6] ACPI: DPTF: Move INT340X device IDs to header

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?