On Mon, 10 Jun 2019 at 10:55, Lee Jones <lee.jones@xxxxxxxxxx> wrote: > > On Mon, 10 Jun 2019, Ard Biesheuvel wrote: > > > On Mon, 10 Jun 2019 at 10:42, Lee Jones <lee.jones@xxxxxxxxxx> wrote: > > > > > > This patch provides basic support for booting with ACPI instead > > > of the currently supported Device Tree. When doing so there are a > > > couple of differences which we need to taken into consideration. > > > > > > Firstly, the SDM850 ACPI tables omit information pertaining to the > > > 4 reserved GPIOs on the platform. If Linux attempts to touch/ > > > initialise any of these lines, the firmware will restart the > > > platform. > > > > > > Secondly, when booting with ACPI, it is expected that the firmware > > > will set-up things like; Regulators, Clocks, Pin Functions, etc in > > > their ideal configuration. Thus, the possible Pin Functions > > > available to this platform are not advertised when providing the > > > higher GPIOD/Pinctrl APIs with pin information. > > > > > > Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx> > > > > For the ACPI probing boilerplate: > > Acked-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > > > *However*, I really don't like hardcoding reserved GPIOs like this. > > What guarantee do we have that each and every ACPI system > > incorporating the QCOM0217 device has the exact same list of reserved > > GPIOs? > > This is SDM845 specific, so the chances are reduced. > You don't know that. > However, if another SDM845 variant does crop up, also lacking the > "gpios" property, we will have to find another differentiating factor > between them and conduct some matching. What else can you do with > platforms supporting non-complete/non-forthcoming ACPI tables? > Either we don't touch any pins at all if they are not referenced explicitly anywhere, or we parse the PEP tables, which seem to cover some of this information (if Bjorn's analysis is correct)
