mmc: spi: Toggle SPI polarity, do not hardcode it

Message ID 20191204152749.12652-1-linus.walleij@linaro.org
State New
Headers show
Series
  • mmc: spi: Toggle SPI polarity, do not hardcode it
Related show

Commit Message

Linus Walleij Dec. 4, 2019, 3:27 p.m.
The code in mmc_spi_initsequence() tries to send a burst with
high chipselect and for this reason hardcodes the device into
SPI_CS_HIGH.

This is not good because the SPI_CS_HIGH flag indicates
logical "asserted" CS not always the physical level. In
some cases the signal is inverted in the GPIO library and
in that case SPI_CS_HIGH is already set, and enforcing
SPI_CS_HIGH again will actually drive it low.

Instead of hard-coding this, toggle the polarity so if the
default is LOW it goes high to assert chipselect but if it
is already high then toggle it low instead.

Cc: Phil Elwell <phil@raspberrypi.org>
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

---
 drivers/mmc/host/mmc_spi.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

-- 
2.23.0

Comments

Mark Brown Dec. 4, 2019, 5:20 p.m. | #1
On Wed, Dec 04, 2019 at 04:27:49PM +0100, Linus Walleij wrote:
> The code in mmc_spi_initsequence() tries to send a burst with

> high chipselect and for this reason hardcodes the device into

> SPI_CS_HIGH.


Reviewed-by: Mark Brown <broonie@kernel.org>
Ulf Hansson Dec. 10, 2019, 9:51 a.m. | #2
On Wed, 4 Dec 2019 at 16:29, Linus Walleij <linus.walleij@linaro.org> wrote:
>

> The code in mmc_spi_initsequence() tries to send a burst with

> high chipselect and for this reason hardcodes the device into

> SPI_CS_HIGH.

>

> This is not good because the SPI_CS_HIGH flag indicates

> logical "asserted" CS not always the physical level. In

> some cases the signal is inverted in the GPIO library and

> in that case SPI_CS_HIGH is already set, and enforcing

> SPI_CS_HIGH again will actually drive it low.

>

> Instead of hard-coding this, toggle the polarity so if the

> default is LOW it goes high to assert chipselect but if it

> is already high then toggle it low instead.

>

> Cc: Phil Elwell <phil@raspberrypi.org>

> Reported-by: Mark Brown <broonie@kernel.org>

> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>


Seems like we should add a stable tag, right?

In any case, I have applied this for next to let it cook for a while, thanks!

Kind regards
Uffe



> ---

>  drivers/mmc/host/mmc_spi.c | 11 ++++++++---

>  1 file changed, 8 insertions(+), 3 deletions(-)

>

> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c

> index 74c6cfbf9172..1f02f54f09c0 100644

> --- a/drivers/mmc/host/mmc_spi.c

> +++ b/drivers/mmc/host/mmc_spi.c

> @@ -1134,17 +1134,22 @@ static void mmc_spi_initsequence(struct mmc_spi_host *host)

>          * SPI protocol.  Another is that when chipselect is released while

>          * the card returns BUSY status, the clock must issue several cycles

>          * with chipselect high before the card will stop driving its output.

> +        *

> +        * SPI_CS_HIGH means "asserted" here. In some cases like when using

> +        * GPIOs for chip select, SPI_CS_HIGH is set but this will be logically

> +        * inverted by gpiolib, so if we want to ascertain to drive it high

> +        * we should toggle the default with an XOR as we do here.

>          */

> -       host->spi->mode |= SPI_CS_HIGH;

> +       host->spi->mode ^= SPI_CS_HIGH;

>         if (spi_setup(host->spi) != 0) {

>                 /* Just warn; most cards work without it. */

>                 dev_warn(&host->spi->dev,

>                                 "can't change chip-select polarity\n");

> -               host->spi->mode &= ~SPI_CS_HIGH;

> +               host->spi->mode ^= SPI_CS_HIGH;

>         } else {

>                 mmc_spi_readbytes(host, 18);

>

> -               host->spi->mode &= ~SPI_CS_HIGH;

> +               host->spi->mode ^= SPI_CS_HIGH;

>                 if (spi_setup(host->spi) != 0) {

>                         /* Wot, we can't get the same setup we had before? */

>                         dev_err(&host->spi->dev,

> --

> 2.23.0

>
Linus Walleij Dec. 10, 2019, 11:10 p.m. | #3
On Tue, Dec 10, 2019 at 10:52 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On Wed, 4 Dec 2019 at 16:29, Linus Walleij <linus.walleij@linaro.org> wrote:

> >

> > The code in mmc_spi_initsequence() tries to send a burst with

> > high chipselect and for this reason hardcodes the device into

> > SPI_CS_HIGH.

> >

> > This is not good because the SPI_CS_HIGH flag indicates

> > logical "asserted" CS not always the physical level. In

> > some cases the signal is inverted in the GPIO library and

> > in that case SPI_CS_HIGH is already set, and enforcing

> > SPI_CS_HIGH again will actually drive it low.

> >

> > Instead of hard-coding this, toggle the polarity so if the

> > default is LOW it goes high to assert chipselect but if it

> > is already high then toggle it low instead.

> >

> > Cc: Phil Elwell <phil@raspberrypi.org>

> > Reported-by: Mark Brown <broonie@kernel.org>

> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

>

> Seems like we should add a stable tag, right?


Yeah I agree.

> In any case, I have applied this for next to let it cook for a while, thanks!


Good, thanks!

Yours,
Linus Walleij
Ulf Hansson Dec. 16, 2019, 12:09 p.m. | #4
On Wed, 11 Dec 2019 at 00:11, Linus Walleij <linus.walleij@linaro.org> wrote:
>

> On Tue, Dec 10, 2019 at 10:52 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:

> > On Wed, 4 Dec 2019 at 16:29, Linus Walleij <linus.walleij@linaro.org> wrote:

> > >

> > > The code in mmc_spi_initsequence() tries to send a burst with

> > > high chipselect and for this reason hardcodes the device into

> > > SPI_CS_HIGH.

> > >

> > > This is not good because the SPI_CS_HIGH flag indicates

> > > logical "asserted" CS not always the physical level. In

> > > some cases the signal is inverted in the GPIO library and

> > > in that case SPI_CS_HIGH is already set, and enforcing

> > > SPI_CS_HIGH again will actually drive it low.

> > >

> > > Instead of hard-coding this, toggle the polarity so if the

> > > default is LOW it goes high to assert chipselect but if it

> > > is already high then toggle it low instead.

> > >

> > > Cc: Phil Elwell <phil@raspberrypi.org>

> > > Reported-by: Mark Brown <broonie@kernel.org>

> > > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

> >

> > Seems like we should add a stable tag, right?

>

> Yeah I agree.


Alright. I have amended the patch to add the tag.

Kind regards
Uffe

Patch

diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 74c6cfbf9172..1f02f54f09c0 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1134,17 +1134,22 @@  static void mmc_spi_initsequence(struct mmc_spi_host *host)
 	 * SPI protocol.  Another is that when chipselect is released while
 	 * the card returns BUSY status, the clock must issue several cycles
 	 * with chipselect high before the card will stop driving its output.
+	 *
+	 * SPI_CS_HIGH means "asserted" here. In some cases like when using
+	 * GPIOs for chip select, SPI_CS_HIGH is set but this will be logically
+	 * inverted by gpiolib, so if we want to ascertain to drive it high
+	 * we should toggle the default with an XOR as we do here.
 	 */
-	host->spi->mode |= SPI_CS_HIGH;
+	host->spi->mode ^= SPI_CS_HIGH;
 	if (spi_setup(host->spi) != 0) {
 		/* Just warn; most cards work without it. */
 		dev_warn(&host->spi->dev,
 				"can't change chip-select polarity\n");
-		host->spi->mode &= ~SPI_CS_HIGH;
+		host->spi->mode ^= SPI_CS_HIGH;
 	} else {
 		mmc_spi_readbytes(host, 18);
 
-		host->spi->mode &= ~SPI_CS_HIGH;
+		host->spi->mode ^= SPI_CS_HIGH;
 		if (spi_setup(host->spi) != 0) {
 			/* Wot, we can't get the same setup we had before? */
 			dev_err(&host->spi->dev,