On Fri, 2016-10-21 at 13:13 +0200, Yegor Yefremov wrote:
> 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:
> > > @@ -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"?
Consider 'rxd-gpios' and / or 'cts-gpios'. And answer is 'yes, it does'.
> What would you suggest to fix the ACPI related issue with RX console
> pin?
Maybe you have to allocate a new compatible device string for such
UARTs. I dunno what is the best solution here.
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy
--
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
