The u32 variable csgpio is being checked for an error return
from the call to of_get_named_gpio, however, since this is unsigned
this comparison will always be false. Fix this by making csgpio an
int and fix up the %u format specifiers to %d accordingly.

Detected by CoverityScan, CID#1475476 ("Unsigned compared against 0")

Fixes: 2a22f1b3 ("spi: npcm: add NPCM PSPI controller driver")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add Nuvoton NPCM BMC Peripheral SPI controller driver.
Signed-off-by: NTomer Maimon <tmaimon77@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Added device tree binding documentation for Nuvoton BMC
NPCM Peripheral SPI controller.
Signed-off-by: NTomer Maimon <tmaimon77@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Do not deselect cs when cs_change is set for the last transfer in the
message. In this case, cs_change indicates that cs should stay selected
until the next transfer.
Signed-off-by: NFredrik Ternerot <fredrikt@axis.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

There doesn't seem to be a way to empty TXFIFO on MMP2. The datasheet is
super-secret and the method described in Armada 16x manual won't work:

  "The TXFIFO and RXFIFO are cleared to 0b0 when the SSPx port is reset or
  disabled (by writing a 0b0 to the <Synchronous Serial Port Enable> field
  in the SSP Control Register 0)."

  # devmem 0xd4037008           # read SSSR
  0x0000F204
  # devmem 0xd4037000 32 0x07   # SSE off in SSCR0
  # devmem 0xd4037000 32 0x87   # SSE on
  # devmem 0xd4037008
  0x0000F204
         ^ TXFIFO level is still 2. Sigh.

The OLPC 1.75 boot firmware leaves two bytes in the TXFIFO. Those are
basically throwaway bytes used in response to the messages from the EC.
The OLPC kernel copes with this by power-cycling the hardware. Perhaps
the firmware should do this instead.

Other than that, there's not much we can do other than complain loudly
until the garbage gets drained and discard the actual data... For the
OLPC EC this will work just fine and pushing more data to TXFIFO would
break further transactions.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NMark Brown <broonie@kernel.org>

Strobe a GPIO line when the slave TX FIFO is filled. This is how the
Embedded Controller on an OLPC XO-1.75 machine, that happens to be a SPI
master, learns that it can initiate a transaction.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Tested-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>

This this is used to let the SPI master know that our FIFO is filled and
we're ready to service a transfer. Only useful in slave mode.

A signal like this is used by an embedded controller on a OLPC XO 1.75
machine, that happens to be a SPI master.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>

Tested on an OLPC XO-1.75 machine, where the Embedded Controller happens
to be a SPI master.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some drivers, such as spi-pxa2xx return from the transfer_one callback
immediately, idicating that the transfer will be finished asynchronously.

Normally, spi_transfer_one_message() synchronously waits for the
transfer to finish with wait_for_completion_timeout(). For slaves, we
don't want the transaction to time out as it can complete in a long time
in future. Use wait_for_completion_interruptible() instead.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is used to indicate that the chip attached to this controller is a SPI
master.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add r8a77470 to the list of examples with soctypes.
No driver change is needed as "renesas,qspi" will activate
the right code within the corresponding driver.
Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Enable McSPI driver to be built for K3 platforms, to support McSPI on
AM654 SoC of K3 family.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

AM654 SoC has same McSPI IP as OMAP2+ platforms. Add new compatible to
support McSPI on AM654 SoC.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Document the bindings used by the Macronix controller.
Signed-off-by: NMason Yang <masonccyang@mxic.com.tw>
Reviewed-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add a driver for Macronix SPI controller IP.
Signed-off-by: NMason Yang <masonccyang@mxic.com.tw>
Reviewed-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In commit 7662d1dc17d4 ("spi: uniphier: fix incorrect property items")
addressing properties of #address-cells and #size-cells were removed.
Since it is not necessary to remove them, they are back again.
Signed-off-by: NKeiji Hayashibara <hayashibara.keiji@socionext.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This commit fixes incorrect property because it was different
from the actual.
The parameters of '#address-cells' and '#size-cells' were removed,
and 'interrupts', 'pinctrl-names' and 'pinctrl-0' were added.

Fixes: 4dcd5c27 ("spi: add DT bindings for UniPhier SPI controller")
Signed-off-by: NKeiji Hayashibara <hayashibara.keiji@socionext.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Re-arrange existing APIs in probe function to
avoid using goto and remove redundant variables.
Signed-off-by: NAlok Chauhan <alokc@codeaurora.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

fixed the nitpicks.
Signed-off-by: NAlok Chauhan <alokc@codeaurora.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some SoC share one irq number between DSPI controllers.
For example, on the LX2160 board, DSPI0 and DSPI1 share one irq number.
In this case, only one DSPI controller can register successfully,
and others will fail.
Signed-off-by: NChuanhua Han <chuanhua.han@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

this patch add support for mt8183 IC.
Signed-off-by: NLeilk Liu <leilk.liu@mediatek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch adds a DT binding documentation for the MT8183 soc.
Signed-off-by: NLeilk Liu <leilk.liu@mediatek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Intel LPSS private register restoring in spi-pxa2xx.c: pxa2xx_spi_resume()
was added before there was no any other code restoring them. This was
changed after following commits for previous and current LPSS platforms:

c78b0830 ("ACPI / LPSS: custom power domain for LPSS")
41a3da2b ("mfd: intel-lpss: Save register context on suspend")

However there is one caveat: There is no LPSS private register context
save/restore for the Intel Lynxpoint in the Linux kernel code.

I did some debugging on one Lynxpoint based device I have and on it the
LPSS register context is not lost over suspend/resume cycle (s2idle).
Which happens for instance on Intel Braswell. I'm speculating but I guess
either firmware does it or the LPSS is kept always on Lynxpoint.

Given that we haven't needed to implement Lynxpoint LPSS I2C or UART
private register context save/restore over four years time I think we are
safe to remove this LPSS private register restoring during resume here.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add missing support for lsb-first mode.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The hardware supports 4, 8 and 16bit spi words,
so add the missing support for 4bit words.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Register an interrupt handler to fill/empty the
tx and rx fifos rather than busy-looping.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Now that we no longer potentially change spi clock
at runtime we can precompute the rx sample delay
at probe time rather than for each transfer.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The driver previously checked each transfer if the
requested speed was higher than possible with the
current spi clock rate and raised the clock rate
accordingly.

However, there is no check to see if the spi clock
was actually set that high and no way to dynamically
lower the spi clock rate again.

So it seems any potiential users of this functionality
are better off just setting the spi clock rate at init
using the assigned-clock-rates devicetree property.

Removing this dynamic spi clock rate raising allows
us let the spi framework handle min/max speeds
for us.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

We only need to know if we're using dma when setting
up the transfer, so just use a local variable for
that.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

In almost all cases we already have a pointer to the
spi master structure where we have the driver data.

The only exceptions are the dma callbacks which are
easily fixed by passing them the master and using
spi_master_get_devdata to retrieve the driver data.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The spi master (aka spi controller) structure already
has two fields for storing the rx and tx dma channels.
Just use them rather than duplicating them in driver data.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Just read transfer info directly from the spi device
and transfer structures rather than storing it in
driver data first.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Successful transfers leave the spi disabled, so if
we just make sure to disable the spi on error
there should be no need to disable the spi from
master->unprepare_message.

This also flushes the tx and rx fifos,
so no need to do that manually.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The state field is currently only used to make sure
only the last of the tx and rx dma callbacks issue
an spi_finalize_current_transfer.
Rather than using a spinlock we can get away
with just turning the state field into an atomic_t.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The hardware supports 3 different variants of SPI
and there were some code around it, but nothing
to actually set it to anything but "Motorola SPI".
Just drop that code and always use that mode.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Use C99 designated initializers for dma slave config
structures. This also makes sure uninitialized fields
are zeroed so we don't need an explicit memset.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@kernel.org>