Setting an Acpi Field in Linux

How to configure ACPI *.asl for a virtual mdio-gpio device connected to a I2C gpio expander

First of all let's see the main architecture of the design:

+-------------------+
|  HOST             |       +------+
|              MDIO <------>+ MDIO |
|              Intf |       | Phy  |
|                   |       +--^---+
| +------+          |          |       +-----+
| | I²C  |          |          |       | LED |
| | host |          |          |       +--^--+
| +--^---+          |          |          |
|    |              |       +--+---+      |
+-------------------+       | I²C  |      |
     +----------------------> GPIO +------+
                            +------+

From this schematic we see how devices are related to each other. Now let's move to ACPI representation. At the beginning we need to define I²C GPIO expander. From the examples in meta-acpi project we can find how PCA9535 can be described. Assuming we found the I²C host controller device (\_SB_.PCI0.D01D as per your post) and the fact that you have expander without latching IRQ events, the following is the mix between original ASL excerpt and how to match it with proper configuration in the driver:

Device (ABC0)
{

    Name (_HID, "PRP0001")
    Name (_DDN, "NXP PCA9575 GPIO expander")

    Name (RBUF, ResourceTemplate()
    {
        I2cSerialBusV2(0x0020, ControllerInitiated, 400000,
            AddressingMode7Bit, "\\_SB.PCI0.D01D",
            0x00, ResourceConsumer, , Exclusive, )
    })

    Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () {"compatible", "nxp,pca9575"},
            Package () {"gpio-line-names", Package () {
                "LED_Red",
                "",
                "MDC",
                "MDIO",
            }},
        }
    })

    Method (_CRS, 0, NotSerialized)
    {
        Return (RBUF)
    }

    Method (_STA, 0, NotSerialized)
    {
        Return (0x0F)
    }
}

This excerpt provides us a new GPIO chip in the system, resources of which can be consumed by others.

For example, in your Virtual MDIO Phy case (see _DSD Device Properties Related to GPIO as well)

Device (MD00)
{
    Name (_HID, "PRP0001")

    Name (_CRS, ResourceTemplate () {
        GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
            "\\_SB.PCI0.D01D.ABC0", 0, ResourceConsumer) {2} // pin 2
        GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
            "\\_SB.PCI0.D01D.ABC0", 0, ResourceConsumer) {3} // pin 3
    })

    Name (_DSD, Package() {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () { "compatible", "virtual,mdio-gpio" },
            Package () {
                "gpios", Package () {
                    ^MD00, 0, 0, 0, // index 0 in _CRS -> pin 2
                    ^MD00, 1, 0, 0, // index 1 in _CRS -> pin 3
                }
            },
        }
    })
}

Now it is a time to look at the LED binding code. For the sake of clarification hogging is when you want a GPIO provider to consume a resource itself. And it is quite likely not your case. Better is to connect this with the LED GPIO driver:

Device (LEDS)
{
    Name (_HID, "PRP0001")
    Name (_DDN, "GPIO LEDs device")

    Name (_CRS, ResourceTemplate () {
        GpioIo (
            Exclusive,                  // Not shared
            PullUp,                     // Default off
            0,                          // Debounce timeout
            0,                          // Drive strength
            IoRestrictionOutputOnly,    // Only used as output
            "\\_SB.PCI0.D01D.ABC0",     // GPIO controller
            0)                          // Must be 0
        {
            0,                          // LED_Red
        }
    })

    Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () { "compatible", Package() { "gpio-leds" } },
        },
        ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
        Package () {
            Package () { "led-0", "LED0" },
        }
    })

    /*
     * For more information about these bindings see:
     * Documentation/devicetree/bindings/leds/common.yaml,
     * Documentation/devicetree/bindings/leds/leds-gpio.yaml and
     * Documentation/firmware-guide/acpi/gpio-properties.rst.
     */
    Name (LED0, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () { "label", "red" },
            Package () { "default-state", "on" },
            Package () { "gpios", Package () { ^LEDS, 0, 0, 1 } }, // active low
        }
    })
}

Also you may look into similar questions (starting from the given link and there are references to the rest) on StackOverflow site.

ACPI event not triggering associated action

Welp, figured it out. Reading other posts on this site, I realized that I needed to restart acpid. After trying sudo /etc/init.d/acpid reload, everything is working as it should.

ACPI Error: Field [CDW3] at 96 exceeds Buffer

From bugzilla

HP's \SB._OSC method violates the ACPI spec. \SB._OSC is documented
as taking an 8-byte argument, while the HP firmware is attempting to
interpret it as a 12-byte one. HP have ignored the spec for this
method and implemented their own as part of the Processor Clocking
Control specification. We can't work around this without risking
breaking spec-compliant machines. Nothing will actually be broken as a
result of this error.

Where's the catalog of objects in the ACPI namespace?

The best place to look for specific variables is the ACPI specification (www.acpi.info/spec.htm). Reserved names start with an underscore '_', and all of those will be described in the spec.

All of the other variables are specific to a particular BIOS, although there tends to be some naming consistency within a given vendor's BIOSs, and the name itself can give a hint, although the 4 character naming limit is an unfortunate problem!

If you grab the DSDT from a given BIOS and decompile it, you can get a good idea for the structure and flow of ASL. If you have more specific questions though, I'd be more than glad to answer them!

---

Related Topics