tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems

tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems

[Mika Westerberg]

Hi,

I noticed that with v4.8-rc1 serial console of some of our Broxton
systems does not work properly anymore. I'm able to see output but input
does not work.

I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
("tty/serial/8250: use mctrl_gpio helpers").

The reason why it fails is that in ACPI we do not have names for GPIOs
(except when _DSD is used) so we use the "idx" to index into _CRS GPIO
resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The
UART device in Broxton has following (simplified) ACPI description:

    Device (URT4)
    {
        ...
        Name (_CRS, ResourceTemplate () {
            GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                    "\\_SB.GPO0", 0x00, ResourceConsumer)
            {
                0x003A
            }
            GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                    "\\_SB.GPO0", 0x00, ResourceConsumer)
            {
                0x003D
            }
        })

In this case it finds the first GPIO (0x003A which happens to be RX pin
for that UART), turns it into GPIO which then breaks input for the UART
device. This also breaks systems with bluetooth connected to UART (those
typically have some GPIOs in their _CRS).

Any ideas how to fix this?

We cannot just drop the _CRS index lookup fallback because that would
break many existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).

Re: tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems

[Andy Shevchenko]

+Peter

On Tue, 2016-08-09 at 16:02 +0300, Mika Westerberg wrote:
> Hi,
> 
> I noticed that with v4.8-rc1 serial console of some of our Broxton
> systems does not work properly anymore. I'm able to see output but
> input
> does not work.
> 
> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
> ("tty/serial/8250: use mctrl_gpio helpers").

Mika, thanks for the detailed analysis. 
Yegor, consider this mail as a follow up to [1].

[1] http://www.spinics.net/lists/linux-serial/msg23071.html

> 
> The reason why it fails is that in ACPI we do not have names for GPIOs
> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each.
> The
> UART device in Broxton has following (simplified) ACPI description:
> 
>     Device (URT4)
>     {
>         ...
>         Name (_CRS, ResourceTemplate () {
>             GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
> IoRestrictionOutputOnly,
>                     "\\_SB.GPO0", 0x00, ResourceConsumer)
>             {
>                 0x003A
>             }
>             GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
> IoRestrictionOutputOnly,
>                     "\\_SB.GPO0", 0x00, ResourceConsumer)
>             {
>                 0x003D
>             }
>         })
> 
> In this case it finds the first GPIO (0x003A which happens to be RX
> pin
> for that UART), turns it into GPIO which then breaks input for the
> UART
> device. This also breaks systems with bluetooth connected to UART
> (those
> typically have some GPIOs in their _CRS).
> 
> Any ideas how to fix this?
> 
> We cannot just drop the _CRS index lookup fallback because that would
> break many existing machines out there so maybe we can limit this to
> only DT enabled machines. Or alternatively probe if the property first
> exists before trying to acquire the GPIOs (using
> device_property_present()).

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems

[Yegor Yefremov]

Hi Uwe,

On Tue, Aug 9, 2016 at 6:07 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> +Peter
>
> On Tue, 2016-08-09 at 16:02 +0300, Mika Westerberg wrote:
>> Hi,
>>
>> I noticed that with v4.8-rc1 serial console of some of our Broxton
>> systems does not work properly anymore. I'm able to see output but
>> input
>> does not work.
>>
>> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
>> ("tty/serial/8250: use mctrl_gpio helpers").
>
> Mika, thanks for the detailed analysis.
> Yegor, consider this mail as a follow up to [1].
>
> [1] http://www.spinics.net/lists/linux-serial/msg23071.html

Do you have any idea on how to fix this issue?

>> The reason why it fails is that in ACPI we do not have names for GPIOs
>> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
>> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
>> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each.
>> The
>> UART device in Broxton has following (simplified) ACPI description:
>>
>>     Device (URT4)
>>     {
>>         ...
>>         Name (_CRS, ResourceTemplate () {
>>             GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
>> IoRestrictionOutputOnly,
>>                     "\\_SB.GPO0", 0x00, ResourceConsumer)
>>             {
>>                 0x003A
>>             }
>>             GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
>> IoRestrictionOutputOnly,
>>                     "\\_SB.GPO0", 0x00, ResourceConsumer)
>>             {
>>                 0x003D
>>             }
>>         })
>>
>> In this case it finds the first GPIO (0x003A which happens to be RX
>> pin
>> for that UART), turns it into GPIO which then breaks input for the
>> UART
>> device. This also breaks systems with bluetooth connected to UART
>> (those
>> typically have some GPIOs in their _CRS).
>>
>> Any ideas how to fix this?
>>
>> We cannot just drop the _CRS index lookup fallback because that would
>> break many existing machines out there so maybe we can limit this to
>> only DT enabled machines. Or alternatively probe if the property first
>> exists before trying to acquire the GPIOs (using
>> device_property_present()).
>
> --
> Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Intel Finland Oy