All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Lee Jones <lee.jones@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Sebastian Reichel <sre@kernel.org>
Subject: Re: [PATCH] mfd: motorola-cpcap: Do not hardcode SPI mode flags
Date: Tue, 7 Jan 2020 10:57:10 +0100	[thread overview]
Message-ID: <CACRpkdYm2b7G6dvmY5VCSSQCK6DMEYMYRqnoMpH6jaumkQL3Xg@mail.gmail.com> (raw)
In-Reply-To: <20191219170409.GH35479@atomide.com>

On Thu, Dec 19, 2019 at 6:04 PM Tony Lindgren <tony@atomide.com> wrote:

> * Linus Walleij <linus.walleij@linaro.org> [700101 00:00]:
> > The current use of mode flags to us SPI_MODE_0 and
> > SPI_CS_HIGH is fragile: it overwrites anything already
> > assigned by the SPI core. Change it thusly:
> >
> > - Just |= the SPI_MODE_0 so we keep other flags
> > - Assign ^= SPI_CS_HIGH since we might be active high
> >   already, and that is usually the case with GPIOs used
> >   for chip select, even if they are in practice active low.
> >
> > Add a comment clarifying why ^= SPI_CS_HIGH is the right
> > choice here.
>
> Looks like this breaks booting for droid4 with a cpcap
> PMIC, probably as regulators won't work. There's no GPIO
> controller involved in this case for the chip select, the
> pins are directly controlled by the spi-omap2-mcspi.c
> driver.
>
> From the pin muxing setup we see there's a pull-down on
> mcspi1_cs0 pin meaning it's active high:
>
> /* 0x4a100138 mcspi1_cs0.mcspi1_cs0 ae23 */
> OMAP4_IOPAD(0x138, PIN_INPUT_PULLDOWN | MUX_MODE0)
>
> My guess a similar issue is with similar patches for
> all non-gpio spi controllers?
>
> Let me know if you want me to test some other changes,
> or if this patch depends on some other changes.

So this must mean that something else is setting SPI_CS_HIGH
for this driver, such as the device tree, right?

And the |= SPI_CS_HIGH assignment in the driver is just
surplus and we should just delete this code instead.

Would that be right?

Yours,
Linus Walleij

  reply	other threads:[~2020-01-07  9:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 23:19 [PATCH] mfd: motorola-cpcap: Do not hardcode SPI mode flags Linus Walleij
2019-12-19 17:04 ` Tony Lindgren
2020-01-07  9:57   ` Linus Walleij [this message]
2020-01-07 18:24     ` Tony Lindgren
2020-01-07 18:37       ` Tony Lindgren

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=CACRpkdYm2b7G6dvmY5VCSSQCK6DMEYMYRqnoMpH6jaumkQL3Xg@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=broonie@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sre@kernel.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.