Merge branch 'acpi-driver'

.. SPDX-License-Identifier: GPL-2.0

.. include:: <isonum.txt>

=========================================

Why using ACPI drivers is not a good idea

=========================================

:Copyright: |copy| 2026, Intel Corporation

:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Even though binding drivers directly to struct acpi_device objects, also

referred to as "ACPI device nodes", allows basic functionality to be provided

at least in some cases, there are problems with it, related to general

consistency, sysfs layout, power management operation ordering, and code

cleanliness.

First of all, ACPI device nodes represent firmware entities rather than

hardware and in many cases they provide auxiliary information on devices

enumerated independently (like PCI devices or CPUs).  It is therefore generally

questionable to assign resources to them because the entities represented by

them do not decode addresses in the memory or I/O address spaces and do not

generate interrupts or similar (all of that is done by hardware).

Second, as a general rule, a struct acpi_device can only be a parent of another

struct acpi_device.  If that is not the case, the location of the child device

in the device hierarchy is at least confusing and it may not be straightforward

to identify the piece of hardware providing functionality represented by it.

However, binding a driver directly to an ACPI device node may cause that to

happen if the given driver registers input devices or wakeup sources under it,

for example.

Next, using system suspend and resume callbacks directly on ACPI device nodes

is also questionable because it may cause ordering problems to appear.  Namely,

ACPI device nodes are registered before enumerating hardware corresponding to

them and they land on the PM list in front of the majority of other device

objects.  Consequently, the execution ordering of their PM callbacks may be

different from what is generally expected.  Also, in general, dependencies

returned by _DEP objects do not affect ACPI device nodes themselves, but the

"physical" devices associated with them, which potentially is one more source

of inconsistency related to treating ACPI device nodes as "real" device

representation.

All of the above means that binding drivers to ACPI device nodes should

generally be avoided and so struct acpi_driver objects should not be used.

Moreover, a device ID is necessary to bind a driver directly to an ACPI device

node, but device IDs are not generally associated with all of them.  Some of

them contain alternative information allowing the corresponding pieces of

hardware to be identified, for example represeted by an _ADR object return

value, and device IDs are not used in those cases.  In consequence, confusingly

enough, binding an ACPI driver to an ACPI device node may even be impossible.

When that happens, the piece of hardware corresponding to the given ACPI device

node is represented by another device object, like a struct pci_dev, and the

ACPI device node is the "ACPI companion" of that device, accessible through its

fwnode pointer used by the ACPI_COMPANION() macro.  The ACPI companion holds

additional information on the device configuration and possibly some "recipes"

on device manipulation in the form of AML (ACPI Machine Language) bytecode

provided by the platform firmware.  Thus the role of the ACPI device node is

similar to the role of a struct device_node on a system where Device Tree is

used for platform description.

For consistency, this approach has been extended to the cases in which ACPI

device IDs are used.  Namely, in those cases, an additional device object is

created to represent the piece of hardware corresponding to a given ACPI device

node.  By default, it is a platform device, but it may also be a PNP device, a

CPU device, or another type of device, depending on what the given piece of

hardware actually is.  There are even cases in which multiple devices are

"backed" or "accompanied" by one ACPI device node (e.g. ACPI device nodes

corresponding to GPUs that may provide firmware interfaces for backlight

brightness control in addition to GPU configuration information).

This means that it really should never be necessary to bind a driver directly to

an ACPI device node because there is a "proper" device object representing the

corresponding piece of hardware that can be bound to by a "proper" driver using

the given ACPI device node as the device's ACPI companion.  Thus, in principle,

there is no reason to use ACPI drivers and if they all were replaced with other

driver types (for example, platform drivers), some code could be dropped and

some complexity would go away.

   linuxized-acpica

   scan_handlers

   acpi-drivers

	struct platform_device *pdev = NULL;

	struct platform_device_info pdevinfo;

	const struct acpi_device_id *match;

	struct resource_entry *rentry;

	struct list_head resource_list;

	struct resource *resources = NULL;

	int count;

	int count = 0;

	/* If the ACPI node already has a physical device attached, skip it. */

	if (adev->physical_node_count)

	if (adev->physical_node_count && !adev->pnp.type.backlight)

		return NULL;

	match = acpi_match_acpi_device(forbidden_id_list, adev);

		}

	}

	INIT_LIST_HEAD(&resource_list);

	if (adev->device_type == ACPI_BUS_TYPE_DEVICE && !adev->pnp.type.backlight) {

		LIST_HEAD(resource_list);

		count = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);

		if (count < 0)

		return NULL;

			return ERR_PTR(-ENODATA);

		if (count > 0) {

			struct resource_entry *rentry;

			resources = kcalloc(count, sizeof(*resources), GFP_KERNEL);

			if (!resources) {

				acpi_dev_free_resource_list(&resource_list);

			acpi_dev_free_resource_list(&resource_list);

		}

	}

	memset(&pdevinfo, 0, sizeof(pdevinfo));

	/*

#include <linux/sort.h>

#include <linux/pci.h>

#include <linux/pci_ids.h>

#include <linux/platform_device.h>

#include <linux/slab.h>

#include <linux/dmi.h>

#include <linux/suspend.h>

static DEFINE_MUTEX(register_count_mutex);

static DEFINE_MUTEX(video_list_lock);

static LIST_HEAD(video_bus_head);

static int acpi_video_bus_add(struct acpi_device *device);

static void acpi_video_bus_remove(struct acpi_device *device);

static int acpi_video_bus_probe(struct platform_device *pdev);

static void acpi_video_bus_remove(struct platform_device *pdev);

static void acpi_video_bus_notify(acpi_handle handle, u32 event, void *data);

/*

};

MODULE_DEVICE_TABLE(acpi, video_device_ids);

static struct acpi_driver acpi_video_bus = {

	.name = "video",

	.class = ACPI_VIDEO_CLASS,

	.ids = video_device_ids,

	.ops = {

		.add = acpi_video_bus_add,

static struct platform_driver acpi_video_bus = {

	.probe = acpi_video_bus_probe,

	.remove = acpi_video_bus_remove,

	.driver = {

		.name = "acpi-video",

		.acpi_match_table = video_device_ids,

	},

};

	struct acpi_video_bus *video = arg;

	struct acpi_video_device_attrib *attribute;

	struct acpi_video_device *data;

	unsigned long long device_id;

	acpi_status status;

	int device_type;

	u64 device_id;

	status = acpi_evaluate_integer(device->handle, "_ADR", NULL, &device_id);

	/* Skip devices without _ADR instead of failing. */

	if (ACPI_FAILURE(status))

	if (acpi_get_local_u64_address(device->handle, &device_id))

		goto exit;

	data = kzalloc(sizeof(struct acpi_video_device), GFP_KERNEL);

static void acpi_video_bus_notify(acpi_handle handle, u32 event, void *data)

{

	struct acpi_device *device = data;

	struct acpi_video_bus *video = acpi_driver_data(device);

	struct acpi_video_bus *video = data;

	struct acpi_device *device = video->device;

	struct input_dev *input;

	int keycode = 0;

	if (!video || !video->input)

		return;

	input = video->input;

	switch (event) {

		device->flags.notify = 1;

}

static int acpi_video_bus_add_notify_handler(struct acpi_video_bus *video)

static int acpi_video_bus_add_notify_handler(struct acpi_video_bus *video,

					     struct platform_device *pdev)

{

	struct input_dev *input;

	struct acpi_video_device *dev;

	input->phys = video->phys;

	input->id.bustype = BUS_HOST;

	input->id.product = 0x06;

	input->dev.parent = &video->device->dev;

	input->dev.parent = &pdev->dev;

	input->evbit[0] = BIT(EV_KEY);

	set_bit(KEY_SWITCHVIDEOMODE, input->keybit);

	set_bit(KEY_VIDEO_NEXT, input->keybit);

static int instance;

static int acpi_video_bus_add(struct acpi_device *device)

static int acpi_video_bus_probe(struct platform_device *pdev)

{

	struct acpi_device *device = ACPI_COMPANION(&pdev->dev);

	struct acpi_video_bus *video;

	bool auto_detect;

	int error;

		instance++;

	}

	platform_set_drvdata(pdev, video);

	video->device = device;

	strscpy(acpi_device_name(device), ACPI_VIDEO_BUS_NAME);

	strscpy(acpi_device_class(device), ACPI_VIDEO_CLASS);

	    !auto_detect)

		acpi_video_bus_register_backlight(video);

	error = acpi_video_bus_add_notify_handler(video);

	error = acpi_video_bus_add_notify_handler(video, pdev);

	if (error)

		goto err_del;

	error = acpi_dev_install_notify_handler(device, ACPI_DEVICE_NOTIFY,

						acpi_video_bus_notify, device);

						acpi_video_bus_notify, video);

	if (error)

		goto err_remove;

	return error;

}

static void acpi_video_bus_remove(struct acpi_device *device)

static void acpi_video_bus_remove(struct platform_device *pdev)

{

	struct acpi_video_bus *video = NULL;

	if (!device || !acpi_driver_data(device))

		return;

	video = acpi_driver_data(device);

	struct acpi_video_bus *video = platform_get_drvdata(pdev);

	struct acpi_device *device = ACPI_COMPANION(&pdev->dev);

	acpi_dev_remove_notify_handler(device, ACPI_DEVICE_NOTIFY,

				       acpi_video_bus_notify);

	dmi_check_system(video_dmi_table);

	ret = acpi_bus_register_driver(&acpi_video_bus);

	ret = platform_driver_register(&acpi_video_bus);

	if (ret)

		goto leave;

{

	mutex_lock(&register_count_mutex);

	if (register_count) {

		acpi_bus_unregister_driver(&acpi_video_bus);

		platform_driver_unregister(&acpi_video_bus);

		register_count = 0;

		may_report_brightness_keys = false;

	}

	if (list_empty(&adev->pnp.ids))

		return NULL;

	if (adev->pnp.type.backlight)

		return adev;

	return acpi_primary_dev_companion(adev, dev);

}