archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <>
To: Lukas Wunner <lukas-JFq808J9C/>
Cc: Mark Brown <>,
	linux-spi <>,
	Simon Han <>
Subject: Re: [PATCH] spi: spidev: Fix CS polarity if GPIO descriptors are used
Date: Fri, 21 Feb 2020 14:20:41 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20200220061122.srkb663imntm4c6a-JFq808J9C/>

On Thu, Feb 20, 2020 at 7:11 AM Lukas Wunner <lukas-JFq808J9C/> wrote:
> On Wed, Feb 19, 2020 at 04:47:50PM +0100, Linus Walleij wrote:

> > > +                       if (ctlr->use_gpio_descriptors && ctlr->cs_gpiods &&
> > > +                           ctlr->cs_gpiods[spi->chip_select])
> > > +                               tmp |= SPI_CS_HIGH;
> >
> > Should this be tmp ^= SPI_CS_HIGH?
> >
> > If the device tree node for cs-gpios is actually active high, which
> > happens, then you probably want the opposite of what was
> > requested, right?
> I don't quite follow.  Using an XOR here would seem to be inconsistent
> with what you added to of_spi_parse_dt():  In that function, you
> *always* set SPI_CS_HIGH if gpio_descs are used.  So if the polarity
> is specified in the cs-gpios property, anything else is considered
> irrelevant and ignored.

It's not just cs-gpios though: if you look in drivers/gpio/gpiolib-of.c
in the function of_gpio_flags_quirks() you see that the bool property
spi-cs-high in the consumer node will take precedence over the
cs-gpios property and that will also be handled transparently by gpiolib.
(commit 6953c57ab1721 with fixes on top).

But I guess that is what you mean.

Yes as far as I can see this solves the problem of double-specifying
(both in device tree and from userspace) that we want CS high,
so after some thinking:
Reviewed-by: Linus Walleij <>

> TBH the way commit f3186dd87669 abuses SPI_CS_HIGH seems clumsy to me.

Clumsy programmer, that's me, yeah sometimes :/

> Would it not have been possible to just amend spi_set_cs() like this:
> -       if (spi->mode & SPI_CS_HIGH)
> +       if (spi->mode & SPI_CS_HIGH || (ctlr->use_gpio_descriptors &&
> +                                        ctlr->cs_gpiods &&
> +                                        ctlr->cs_gpiods[spi->chip_select]))
>                 enable = !enable;
> This would have avoided the regression fixed by my patch.

There is way too much double inversion going on for sure (some
of it dating back before any attempts to use gpiolib for polarity
handling and I just feel partially responsible) but I just haven't
figured out how to properly fix the problem. Maybe it was just
stupid of me to try to move polarity inversion semantics over to
gpiolib before fixing that though.

Patches like the above are also welcome!

Linus Walleij

  parent reply	other threads:[~2020-02-21 13:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-18 12:08 Lukas Wunner
     [not found] ` <fca3ba7cdc930cd36854666ceac4fbcf01b89028.1582027457.git.lukas-JFq808J9C/>
2020-02-19 15:47   ` Linus Walleij
     [not found]     ` <>
2020-02-20  6:11       ` Lukas Wunner
     [not found]         ` <20200220061122.srkb663imntm4c6a-JFq808J9C/>
2020-02-20  6:18           ` Lukas Wunner
2020-02-21 13:20           ` Linus Walleij [this message]
2020-02-21 14:21   ` Applied "spi: spidev: Fix CS polarity if GPIO descriptors are used" to the spi tree Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --cc=lukas-JFq808J9C/ \ \
    --subject='Re: [PATCH] spi: spidev: Fix CS polarity if GPIO descriptors are used' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).