Messages in this thread | | | Date | Mon, 29 Jul 2013 17:59:08 +0200 | Subject | Re: [PATCH v3] gpio: add GPIO support for F71882FG and F71889F | From | Linus Walleij <> |
| |
On Mon, Jul 22, 2013 at 11:50 AM, Simon Guinot <simon.guinot@sequanux.org> wrote:
> This patch adds support for the GPIOs found on the Fintek super-I/O > chips F71882FG and F71889F. > > A super-I/O is a legacy I/O controller embedded on x86 motherboards. It > is used to connect the low-bandwidth devices. Among others functions the > F71882FG/F71889F provides: a parallel port, two serial ports, a keyboard > controller, an hardware monitoring controller and some GPIO pins. > > Note that this super-I/Os are embedded on some Atom-based LaCie NASes. > The GPIOs are used to control the LEDs and the hard drive power. > > Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> > --- > Changes since v2: > - Remove useless NULL setters for driver data.
Given the recent discussion with Rafael I want to have an extended discussion of this patch.
It is my current understanding that:
- It is possible to define the whereabouts of the SuperIO chips using ACPI - It is possible for developers to influence the source AML for the DSDT tables of these systems. - It is the proper thing to do. - So we should atleast support ACPI probing with the port-based detection as a final fallback if all else fails.
Why can I not get something like:
#include <linux/acpi.h> (...) static const struct acpi_device_id gpio_acpi_match[] = { { "FOOBAR", 0 }, { } }; MODULE_DEVICE_TABLE(acpi, gpio_acpi_match);
static struct platform_driver gpio_driver = { (...) .driver = { (...) .acpi_match_table = ACPI_PTR(gpio_acpi_match), }, };
?
If there is something wrong in my reasoning above, please share it!
Yours, Linus Walleij
| |