On Thu, Mar 29, 2018 at 6:34 AM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote: > On Mon, 26 Mar 2018 20:56:45 -0600 > Aaron Durbin <adur...@chromium.org> wrote: > >> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox <gno...@lxorguk.ukuu.org.uk> >> wrote: >> >> Sadly, this situation >> >> is not unique to this hardware. There is hardware all over that does >> >> not meet the current assumptions being made in the early uart drivers >> >> within the kernel. >> > >> > Is there any fundamental reason you can't just embed dt entries in the >> > ACPI table to describe the other features you need. I appreciate it >> > doesn't solve the generic PC case but it ought to help for anything where >> > the firmware cares about Linux ? >> >> What's the method for doing that? Using _DSD methods? Or have a >> pointer to examples? Sorry, I haven't spelunked into the current state >> of bridging ACPI and devicetree in a while. > > ACPI 5.1 adds an _DSD method UUID for device properties. > > The kernel device_property_* interface will pick them up just as if they > came from DT tables etc.
But we don't have the full ACPI interpreter up in the early part of the kernel. All these 'early' devices have their own setup/config which is the source of the issue. Or maybe I am wrong about the full interpreter and the early drivers are just not taking advantage of the ACPI device binding? -Aaron
