On Sun, Mar 27, 2016 at 12:28 PM, Mark Kettenis <[email protected]> wrote:
> The diff below is a first stab at adding support for GPIOs as defined
> in ACPI 5.0. The primary target for this new ACPI feature is hardware
> reduced platforms like those based on Intel's Bay Trail SoC. The diff
> adds a bytgpio(4) driver for the hardware found on that SoC. This
> driver registers itself with the acpi framework by setting the struct
> acpi_gpio pointer on the AML node for the device. Then this gets used
> by the acpi sdhc(4) frontend to use the appropriate gpio as the card
> detect signal. This makes it possible to detectwhether a card is
> inserted when the kernel boots. Support for GPIO-based interrupts is
> still missing, so hotplugging SD cards doesn't work yet.
>
> There are some debug printfs here that will disappear eventually.
>
> ok?
Not really specific to this driver, but should we be using letoh16()
and similar when accessing the fields like pin_off? We do so in a few
acpi drivers, but many do not and I'm not aware of any big-endian
archs that are looking to use ACPI ("here, have another albatross!").
...
> +/*
> + * The pads for the pins are randomly ordered.
> + */
> +
> +const int byt_score_pins[] = {
These values from some Intel doc?
...
> + switch (uid) {
> + case 1:
> + sc->sc_pins = byt_score_pins;
> + sc->sc_npins = nitems(byt_score_pins);
ok...
> + break;
> + case 2:
> + sc->sc_pins = byt_score_pins;
> + sc->sc_npins = nitems(byt_ncore_pins);
Uh, mismatch here and on the next. Shouldn't sc_pins be set to
byt_ncore_pins and byt_sus_pins?
> + break;
> + case 3:
> + sc->sc_pins = byt_score_pins;
> + sc->sc_npins = nitems(byt_sus_pins);
Philip Guenther
