Hi Wolfgang, On Fri, 31 Jan 2020 at 01:18, Wolfgang Wallner <wolfgang.wall...@br-automation.com> wrote: > > 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"
OK thank you, will fix. I am trying to write things out in full since it is very hard to find out what all these different things mean. > > > + - 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". Yes we could do that. So is that true for all devices that use this i2c driver? > 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. Are you suggesting renaming acpi,hid-desc-reg-offset to hid-descr-addr? Regards, Simon