Linux下ACPI驱动开发问题：驱动加载正常但Add函数未被调用

Got it, let's break down why your ACPI driver's Add function isn't firing—this is a super common snag when adapting older examples, so let's walk through the key checks you might have missed:

1. Double-Check ACPI Device Matching #

ACPI IDs are case-sensitive, so even a tiny mismatch here will prevent your driver from binding to the device:

• Verify that the acpi_device_id array in your driver exactly matches the HID/UID from your DSDT. For example, if your DSDT lists the device as MYDEV123, your driver's ID list needs to mirror that:

  static const struct acpi_device_id my_acpi_ids[] = {
      {"MYDEV123", 0},
      {"", 0}, // Terminator required
  };
  MODULE_DEVICE_TABLE(acpi, my_acpi_ids);
  

• Don't skip the MODULE_DEVICE_TABLE macro—this tells the kernel how to associate your driver with ACPI devices. Without it, the bus won't know to trigger your Add function.

2. Validate Driver Registration & Bus Attachment #

Older examples might use outdated registration patterns, so make sure you're doing this right for your kernel version:

• Confirm you're using acpi_driver_register(&your_acpi_driver) in your module's init function, and check that it returns 0 (no error). If it fails, check dmesg for error codes.
• After loading the driver, check if it shows up in the ACPI bus directory: ls /sys/bus/acpi/drivers/[your-driver-name]. If it's missing, your registration failed—dmesg will tell you why.

3. Confirm the ACPI Device Is Actually Enumerated #

If the kernel hasn't detected the device at all, your driver can't bind to it:

• Use cat /sys/bus/acpi/devices/[device-path]/hid to check if the device exists in the ACPI device tree. You can find the device path from your acpidump output.
• Check the device's _STA method in the DSDT. ACPI devices only show up if _STA returns 0x0F (fully present and enabled). If it returns something else, you might need to initialize the device first (e.g., via another ACPI method) or adjust your driver to handle it.

4. Fix Driver Structure Initialization #

Modern kernels use a nested ops structure for ACPI driver callbacks—older examples might have skipped this:

• Make sure your struct acpi_driver correctly points to your ops, which include the Add function:

  static struct acpi_driver_ops my_acpi_ops = {
      .add = my_acpi_device_add, // Your Add function here
  };
  
  static struct acpi_driver my_acpi_driver = {
      .name = "my-custom-acpi-driver",
      .ids = my_acpi_ids,
      .ops = &my_acpi_ops,
      .owner = THIS_MODULE,
  };
  

• If you directly placed add in the acpi_driver struct without the ops wrapper, that's probably why it's not being called—kernel versions after 4.x or so require the nested ops structure.

5. Use Kernel Logs to Pinpoint the Issue #

Don't sleep on dmesg—it's your best friend here:

• Run dmesg -w in a terminal before loading your module, then watch for logs related to your driver. Look for lines like "ACPI driver my-custom-acpi-driver registered" or "No matching ACPI device found".
• Add debug prints to your init function and Add function (using pr_info("My driver init ran!\n") or dev_info(dev, "Device added!\n")) to confirm which parts of your code are executing.

Start with these checks—9 times out of 10, the issue is a mismatched ID, missing device table macro, or incorrect driver structure setup.

内容的提问来源于stack exchange，提问作者Brian Stark