Hi Simon, > +Devices > +======= > + > +Device bindings are described by their own individual binding files. > + > +U-Boot provides for some optional properties which are documented here. > + > + - acpi,has-power-resource : (boolean) true if this device has a power > resource. > + This causes a PRIC (ACPI PowerResource) to be written containing the > + properties provided by this binding, to describe how to handle powering > the > + device up and down using GPIOs > + - acpi,cid : Contains the string to use as the compatible ID (_CID) > + - acpi,compatible : compatible string to report > + - acpi,desc : Contains the string to use as the _DDN (DOS (Disk Operating > + System) Device Name) > + - acpi,hid : Contains the string to use as the HID (Human Interface Device) > + identifier _HID
Nit: "_HID" in ACPI stands for "Hardware ID" > + - acpi,hid-desc-reg-offset : HID register offset (for Human Interface > Devices) > + - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so > that > + Linux will not re-init the device > + - acpi,uid : _UID value for device Would it make sense to automatically infer ACPI properties from existing device tree properties? E.g. if the compatible string contains "hid-over-i2c", then _CID could be set to "PNP0C50". And a "hid-over-i2c" device would also have a "hid-descr-addr" device tree property for the offset of the HID descriptor register which could be passed on in ACPI as part of the _DSM method. > + > + > +Example > +------- > + > +synaptics_touchpad: synaptics-touchpad@2c { > + compatible = "i2c-chip"; > + reg = <0x2c>; > + acpi,hid = "PNP0C50"; > + acpi,cid = "PNP0C50"; > + acpi,desc = "Synaptics Touchpad"; > + interrupts-extended = <&acpi_gpe GPIO_18_IRQ > + IRQ_TYPE_EDGE_FALLING>; > + acpi,probed; > + acpi,hid-desc-reg-offset = <0x20>; regards, Wolfgang