On Wed, Nov 8, 2017 at 6:03 PM, Mika Westerberg
<mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> On Wed, Nov 08, 2017 at 06:35:46PM +0200, Andy Shevchenko wrote:
>> +Cc: Mika
>>
>> On Sat, 2017-11-04 at 03:20 +0000, Jonathan Cameron wrote:
>> > On Fri, 3 Nov 2017 15:03:38 +0200
>> > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>> >
>> > > With the new more strict ACPI gpio code the DSDT's IoRestriction
>> > > flags
>> > > are honored on gpiod_get(), but in some DSDT's it is wrong, so
>> > > explicitly call gpiod_direction_input() on the IRQ GPIO if
>> > > necessary.
>> > >
>> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
>> >
>> > Again, I really really don't like filling driver code with fixes
>> > for broken firmware. I appreciate we have to cope with this, but
>> > it does rather seem like this should be moved into the core code
>> > for say gpiod_get_irq.
>>
>> I would love to fix in general, though it looks not so trivial:
>>
>> - gpiod_get() doesn't know if GPIO is going to be used as IRQ
>> - gpiod_to_irq() doesn't know if descriptor in question comes from
>> GpioIo() ACPI resource
>
> One idea is to allow this strict mode to be relaxed by drivers perhaps
> by passing quirks through struct acpi_gpio_mapping:
>
> static const struct acpi_gpio_mapping acpi_foo_gpios[] = {
> /*
> * This platform has a bug in ACPI GPIO description making IRQ
> * GPIO to be output only. Ask the GPIO core to ignore this
> * limit.
> */
> { "foobar-gpios", &foobar_gpios, 1, ACPI_QUIRK_IGNORE_IO_RESTRICTION },
> {},
> };
>
> or something like that. Not sure if I missed something obvious, though.
This looks like an elegant solution to me.
Can it be done?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
