linux-kernel - Re: [BUG] SPI broken for SPI based panel drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <FF708A45-7325-49D5-B41E-7D54942F5E23@goldelico.com>
Date:   Tue, 1 Dec 2020 17:46:56 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Sven Van Asbroeck <thesven73@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [BUG] SPI broken for SPI based panel drivers


> Am 01.12.2020 um 16:52 schrieb Sven Van Asbroeck <thesven73@...il.com>:
> 
> Nikolaus,
> 
> On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller <hns@...delico.com> wrote:
>> 
>> Let's work on a fix for the fix now.
> 
> I tested spi-gpio on my system, by converting a built-in or hardware spi,
> to a spi-gpio. Interestingly, the patch has the opposite effect on my system:
> before the patch, spi-gpio did not work, but after it's applied, it does work.
> 
> Can you tell me the idle status of your chip-select gpio in debugfs?
> # mount -t debugfs none /sys/kernel/debug
> # cat /sys/kernel/debug/gpio
> Look for something like this:
> gpiochip0: GPIOs 0-31, parent: platform/209c000.gpio, 209c000.gpio:
> gpio-17  (                    |spi5 CS0            ) out hi ACTIVE LOW

root@...ux:~# mount -t debugfs none /sys/kernel/debug
root@...ux:~# cat /sys/kernel/debug/gpio|fgrep spi
 gpio-179 (                    |spi4 CS0            ) out lo 
root@...ux:~# 

That is after the panel driver did send the commands.

> 
> Also, apply the following patch, and tell me
> a) does this dev_err() get called on your system, and

yes. Many times. 

> b) what is the value when your chip is de-selected

root@...ux:~# dmesg|fgrep td028
[   14.530456] panel-tpo-td028ttec1 spi4.0: spi->mode = 00000003
[   14.599212] panel-tpo-td028ttec1 spi4.0: gpiod disable
[   14.817871] panel-tpo-td028ttec1 spi4.0: spi->mode = 00000003
[   14.817871] panel-tpo-td028ttec1 spi4.0: gpiod enable

So it is disabled first and then enabled. Which appears to be the opposite
of what it should be.

BTW: I have added another dev_err to print the spi->mode and like
you describe it is (overwritten? by SPI_MODE_3.

I can check what value it has in the driver before it is set to SPI_MODE_3.

Maybe, there the spi-cs-high gets lost?

BR and thanks,
Nikolaus


> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 7e8804b02be9..b2f4cf5c9ffb 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -813,11 +813,12 @@ static void spi_set_cs(struct spi_device *spi,
> bool enable)
> 
>        if (spi->cs_gpiod || gpio_is_valid(spi->cs_gpio)) {
>                if (!(spi->mode & SPI_NO_CS)) {
> -                       if (spi->cs_gpiod)
> +                       if (spi->cs_gpiod) {
> +                               dev_err(&spi->dev, "gpiod %s", enable1
> ? "enable" : "disable");
>                                /* polarity handled by gpiolib */
>                                gpiod_set_value_cansleep(spi->cs_gpiod,
>                                                         enable1);
> -                       else
> +                       } else
>                                /*
>                                 * invert the enable line, as active low is
>                                 * default for SPI.