On Thu, Oct 20, 2016 at 11:51 AM, Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> On Thu, 2016-10-20 at 11:34 +0200, yegorslists@xxxxxxxxxxxxxx wrote:
>> From: Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx>
>>
>> Don't initialize particular GPIO pins, if they are not declared as
>> device property.
>
>> @@ -124,6 +125,11 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct
>> device *dev, unsigned int idx)
>>
>> for (i = 0; i < UART_GPIO_MAX; i++) {
>> enum gpiod_flags flags;
>> + char mctrl_property[10];
>> +
>> + sprintf(mctrl_property, "%s-gpios",
>> mctrl_gpios_desc[i].name);
>> + if (!device_property_present(dev, mctrl_property))
>> + continue;
>
> I wouldn't think this is right check. There is an activity [1] to enable
> runtime PM for UART devices which on some cases relies on GPIOs defined
> (as wake sources).
>
> [1] http://www.spinics.net/lists/linux-serial/msg24025.html
But why should both approaches collide? If RTS pin is used as RTS, it
won't be handled by mctrl_gpios framework. And if it is defined as
GPIO in ACPI, does device then provide such a property as "rts-gpios"?
What would you suggest to fix the ACPI related issue with RX console pin?
Yegor
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
