On Sat, Aug 08, 2015 at 02:06:56PM +0200, Vincent Pelletier wrote: > On Fri, 7 Aug 2015 13:57:45 +0300, Mika Westerberg > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > Ah, this is different GPIO controller that is listed in the DSDT (the > > Baytrail GPIO host controller). > > > > In order to get ACPI GPIO stuff work here you would need to first add > > the GPIO device to the ACPI namespace and then modify gpio-f7188x.c to > > probe it from there. You would also need to invent a _HID to the device > > in order to get it matched. Unfortunately using random _HID will make > > upstreaming the changes difficult. > > I gave a shot at writing a module. I got to the point where it builds > and loads, but it does not appear to do anything (no error > returned modprobe, nothing in dmesg). > > I have no idea if the ~4 lines of "actual" code (ie, not just data > definition) are even in the good direction actually. I took > http://www.armadeus.com/wiki/index.php?title=GPIO_LEDS > as an example. This is for a platform definition for a devboard > (arm ?), so it may be a wrong example. I took a look at other led > drivers, and their complexity varies a lot. > > Would you mind taking a look ? > https://github.com/vpelletier/linux/commits/ts651 One thing I noticed: qnap_tsx51_leds_platform_device = platform_device_register_resndata(NULL, "led-gpio", -1, NULL, 0, &qnap_tsx51_led_data, sizeof(qnap_tsx51_led_data)); The driver expects "leds-gpio" not "led-gpio". -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
