On Tue, Jul 25, 2017 at 11:18 AM, Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> On Tue, 2017-07-25 at 07:43 +0200, Yegor Yefremov wrote:
>> On Mon, Jul 24, 2017 at 8:48 PM, Yegor Yefremov
>> <yegorslists@xxxxxxxxxxxxxx> wrote:
>> > Hi Andy,
>> >
>> > On Mon, Jul 24, 2017 at 8:39 PM, Andy Shevchenko
>> > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>> > > Hi!
>> > >
>> > > Since my big ACPI GPIO fix made the vanilla, I think we may return
>> > > back
>> > > the commit 4ef03d328769 ("tty/serial/8250: use mctrl_gpio
>> > > helpers").
>> > >
>> > > I just have tested it on two x86 boards:
>> > > 1) Broxton (without _DSD properties)
>> > > 2) ApolloLake (with _DSD properties for RX and CTS pins)
>> > >
>> > > Opinions, more testing?
>
> Alas, I did more deep testing and the patch breaks the console.
>
> It looks like we need to distinguish what those GPIOs are used for:
> a) modem control lines, or
> b) wakeup source.
>
> There are few options to distinguish:
> 1) check if GPIO resource is marked as wakeup source (ACPI only)
> 2) use "wakeup-source" device property, for now looks like there is no
> serial driver is using it (might be collision with the real wake capable
> serial drivers)
> 3) similar to 2), though introduce another property like "oob-wakeup-
> source" or any variations of that
> 4) something else?
>
>> > >
>> > > I would like to have more independent testing (Mika? Others?).
>> > >
>> > > Btw, Yegor, do we still need it?
>> >
>> > Yes, I do. Thanks for looking at it again. This is almost the only
>> > part missing before Baltos systems could be copletely upstreamed.
>> >
>> > Yegor
>> >
>> > > P.S. I cherry-picked it on top of recent linux-next and tried. I
>> > > can
>> > > send a formal patch, but I think it's not needed (it applies
>> > > smoothly).
>>
>> Btw have you also tested this patch [1]?
>>
>> [1] http://www.spinics.net/lists/linux-serial/msg24053.html
>
> See above. This patch basically is not needed anymore, we need something
> else.
AFAIK this patch was needed in order to avoid serial port breakage,
where some modem signals were defined in ACPI tables. Mika and some
other devs reported the issue as "tty/serial/8250: use mctrl_gpio
helpers" was part of the kernel.
Perhaps I should just augment my patch like this?
diff --git a/drivers/tty/serial/serial_mctrl_gpio.c
b/drivers/tty/serial/serial_mctrl_gpio.c
index d2da6aa..a6245efb 100644
--- a/drivers/tty/serial/serial_mctrl_gpio.c
+++ b/drivers/tty/serial/serial_mctrl_gpio.c
@@ -19,6 +19,8 @@
#include <linux/irq.h>
#include <linux/gpio/consumer.h>
#include <linux/termios.h>
+#include <linux/of_device.h>
+#include <linux/property.h>
#include <linux/serial_core.h>
#include <linux/module.h>
@@ -124,6 +126,12 @@ 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) ||
+ of_property_read_bool(dev->of_node,
"wakeup-source"))
+ continue;
if (mctrl_gpios_desc[i].dir_out)
flags = GPIOD_OUT_LOW;
Yegor
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
