Vladimir Oltean <vladimir.oltean@nxp.com>:

From: Vladimir Oltean <vladimir.oltean@nxp.com>

This series aims to remove the most inefficient transfer method from the
NXP DSPI driver.

TCFQ (Transfer Complete Flag) mode works by transferring one word,
waiting for its TX confirmation interrupt (or polling on the equivalent
status bit), sending the next word, etc, until the buffer is complete.

The issue with this mode is that it's fundamentally incompatible with
any sort of batching such as writing to a FIFO. But actually, due to
previous patchset ("Compatible string consolidation for NXP DSPI driver"):

https://patchwork.kernel.org/cover/11414593/

all existing users of TCFQ mode today already support a more advanced
feature set, in the form of XSPI (extended SPI). XSPI brings 2 extra
features:

- Word sizes up to 32 bits. This is sub-utilized today, and acceleration
  of smaller-than-32 bpw values is provided.
- "Command cycling", basically the ability to write multiple words in a
  row and receiving an interrupt only after the completion of the last
  one. This is what enables us to make use of the full FIFO depth of
  this controller.

Series was tested on the NXP LS1021A-TSN and LS1043A-RDB boards, both
functionally as well as from a performance standpoint.

The command used to benchmark the increased throughput was:

spidev_test --device /dev/spidev1.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000

where spidev1.0 is a dummy spidev node, using a chip select that no
peripheral responds to.

On LS1021A, which has a 4-entry-deep FIFO and a less powerful CPU, the
performance increase brought by this patchset is from 2700 kbps to 5800
kbps.

On LS1043A, which has a 16-entry-deep FIFO and a more powerful CPU, the
performance increases from 4100 kbps to 13700 kbps.

On average, SPI software timestamping is not adversely affected by the
extra batching, due to the extra patches.

There is one extra patch which clarifies why the TCFQ users were not
converted to the "other" mode in this driver that makes use of the FIFO,
which would be EOQ mode.

My request to the many people on CC (known users and/or contributors) is
to give this series a test to ensure there are no regressions, and for
the Coldfire maintainers to clarify whether the EOQ limitation is
acceptable for them in the long run.

Vladimir Oltean (12):
  spi: spi-fsl-dspi: Simplify bytes_per_word gymnastics
  spi: spi-fsl-dspi: Remove unused chip->void_write_data
  spi: spi-fsl-dspi: Don't mask off undefined bits
  spi: spi-fsl-dspi: Add comments around dspi_pop_tx and dspi_push_rx
    functions
  spi: spi-fsl-dspi: Rename fifo_{read,write} and {tx,cmd}_fifo_write
  spi: spi-fsl-dspi: Implement .max_message_size method for EOQ mode
  spi: Do spi_take_timestamp_pre for as many times as necessary
  spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
  spi: spi-fsl-dspi: Accelerate transfers using larger word size if
    possible
  spi: spi-fsl-dspi: Optimize dspi_setup_accel for lowest interrupt
    count
  spi: spi-fsl-dspi: Use EOQ for last word in buffer even for XSPI mode
  spi: spi-fsl-dspi: Take software timestamp in dspi_fifo_write

 drivers/spi/spi-fsl-dspi.c | 421 ++++++++++++++++++++++++-------------
 drivers/spi/spi.c          |  19 +-
 include/linux/spi/spi.h    |   3 +-
 3 files changed, 288 insertions(+), 155 deletions(-)

--
2.17.1

The description below is already in use for rk3328.dtsi,
but was somehow never added to a document, so add
"rockchip,rk3328-spi", "rockchip,rk3066-spi"
for spi nodes on a rk3328 platform to spi-rockchip.yaml.
Signed-off-by: NJohan Jonker <jbx6244@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200304184203.9548-3-jbx6244@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The description below is already in use for rk3308.dtsi,
but was somehow never added to a document, so add
"rockchip,rk3308-spi", "rockchip,rk3066-spi"
for spi nodes on a rk3308 platform to spi-rockchip.yaml.
Signed-off-by: NJohan Jonker <jbx6244@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200304184203.9548-2-jbx6244@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Current dts files with 'spi' nodes are manually verified.
In order to automate this process spi-rockchip.txt
has to be converted to yaml. In the new setup
spi-rockchip.yaml will inherit properties from
spi-controller.yaml.

Add document to MAINTAINERS.

Also rk3188.dtsi, rk3288.dtsi, rk3368.dtsi and rk3399.dtsi
use an extra fallback string, so change this in the documentation.

Changed:
"rockchip,rk3188-spi", "rockchip,rk3066-spi"
"rockchip,rk3288-spi", "rockchip,rk3066-spi"
"rockchip,rk3368-spi", "rockchip,rk3066-spi"
"rockchip,rk3399-spi", "rockchip,rk3066-spi"
Signed-off-by: NJohan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200304184203.9548-1-jbx6244@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The SPI bus number is completely optional to Linux, so make the
corresponding device tree property optional as well.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20200305115546.31814-1-s.hauer@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for nxp,imx8qxp-fspi and nxp,imx8mm-fspi do the bindings
document.
Signed-off-by: NAdam Ford <aford173@gmail.com>

Link: https://lore.kernel.org/r/20200126140913.2139260-4-aford173@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Apply patch from NXP upstream repo to
Enable the octal combination mode in MCR0
Signed-off-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NHan Xu <han.xu@nxp.com>

Link: https://lore.kernel.org/r/20200126140913.2139260-3-aford173@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Apply patch from NXP upstream repo to
dynamically allocate AHB memory as needed.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NHan Xu <han.xu@nxp.com>

Link: https://lore.kernel.org/r/20200126140913.2139260-2-aford173@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Pull in this patch from NXP's upstream repo to
enable fspi on imx8qxp and imx8mm
Signed-off-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NHan Xu <han.xu@nxp.com>

Link: https://lore.kernel.org/r/20200126140913.2139260-1-aford173@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Although the SPI system timestamps are supposed to reflect the moment
that the peripheral has received a word rather than the moment when the
CPU has enqueued that word to the FIFO, in practice it is easier to just
record the latter time than the former (with a smaller error).

With the recent migration of TCFQ users from poll back to interrupt mode
(this time for XSPI FIFO), it's wiser to keep the interrupt latency
outside of the measurement of the PTP system timestamp itself. If there
proves to be any constant offset that requires static compensation, that
can always be added later. So far that does not appear to be the case at
least on the LS1021A-TSN board, where testing shows that the phc2sys
offset is able to remain within +/- 200 ns even after 68 hours of
testing.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-13-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The EOQ mode has a hardware limitation in that it stops the transmission
(including the deassertion of the chip select signal) once the host CPU
requests end-of-queue for a particular word in the TX FIFO.

And XSPI mode has a limitation in that we need a separate CMD FIFO entry
for the last byte in the buffer, where the chip select signal needs to
be deasserted. It's not a functional limitation, but it's rather clunky
and the fact that we need to halt the pipeline and write a single entry
to the TX FIFO whenever a buffer ends brings the throughput down when
transmitting small buffers.

So the idea here is to use EOQ's limitation in our favor when using XSPI
mode. Stop special-casing that final word in the buffer, and just kill
the chip select signal by issuing an EOQ for that last word. Now it can
be mixed in with all the other words in the current TX FIFO train.

A small trick here is that we still keep using the XSPI-specific
signaling via the CMDTCFQ interrupt in RSER, and not enabling the EOQ
interrupt, in order to avoid hardware weirdness (potential races with
separate interrupts being raised for CMDTCFQ and EOQ for what is in fact
the end of the same transmission). That is just theoretical, but it's
good to be cautious, and the EOQ interrupt isn't needed.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-12-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Currently, a SPI transfer that is not multiple of the highest supported
word width (e.g. 4 bytes) will be transmitted as follows (assume a
30-byte buffer transmitted through a 32-bit wide FIFO that is 32 bytes
deep):

 - First 28 bytes are sent as 7 words of 32 bits each
 - Last 2 bytes are sent as 1 word of 16 bits size

But if the dspi_setup_accel function had decided to use a lower
oper_bits_per_word value (16 instead of 32), there would have been
enough space in the TX FIFO to fit the entire buffer in one go (15 words
of 16 bits each).

What we're actually trying to avoid is mixing word sizes within the same
run with the TX FIFO, since there is an erratum surrounding this, and
invalid data might get transmitted.

So this patch adds special cases for when the remaining length of the
buffer can be sent in one go as 8-bit or 16-bit words, otherwise it
falls back to the standard logic of sending as many bytes as possible at
the highest oper_bits_per_word value possible.

The benefit is that there will be one less CMDFQ/EOQ interrupt to
service when the entire buffer is transmitted during a single go, and
that will improve the overall latency of the transfer.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-11-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch adds logic in the driver to transmit SPI buffers that use
bits_per_word=8 with a higher bits_per_word count (multiple of 8).

Currently the following (most common) modes are implemented:
 - 8 bits_per_word on 32-bit capable controllers
 - 8 bits_per_word on 16-bit capable controllers
 - 16 bits_per_word on 32-bit capable controllers

Transfers which are not accelerated are transferred with a hardware
bits_per_word value equal to the one of the SPI transfer.

The difference from just extending bits_per_word=32 at the spi_device
driver level is that endianness is different - the SPI core wants to
treat bits_per_word=32 buffers as arrays of u32 (i.e. words in host CPU
endianness). So to preserve endianness when clumping 8x4 bits into
32-bit words, one must perform conversion between CPU and standard (big)
endianness.

All appearances (both on the wire as well as in the buffers presented to
the peripheral driver) are preserved, just that accesses to the PUSHR
and POPR registers are now more efficient, since the same number of
reads/writes can now carry more data (2x more data on TX, 4x more data
on RX).
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-10-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).

On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).

Other changes brought by this patch:
 - The dspi->rx_end variable has been removed, since now the
   dspi_fifo_write function sets up dspi->words_in_flight, so
   dspi_fifo_read knows how much to read without overrunning the RX
   buffer.
 - Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
   is a little less efficient than that, and so, poll mode doesn't bring
   as many improvements for XSPI.
 - Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
   instead increment the message->actual_length based on the newly
   introduced dspi->words_in_flight variable.
 - The CTARE register is now written in the hotpath instead of just at
   transfer init time, since it contains the DTCP field (transfer
   preload - the counter indicating how many txdata words will follow),
   which is a dynamic value.

Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

When dealing with a SPI controller driver that is sending more than 1
byte at once (or the entire buffer at once), and the SPI peripheral
driver has requested timestamping for a byte in the middle of the
buffer, we find that spi_take_timestamp_pre never records a "pre"
timestamp.

This happens because the function currently expects to be called with
the "progress" argument >= to what the peripheral has requested to be
timestamped. But clearly there are cases when that isn't going to fly.

And since we can't change the past when we realize that the opportunity
to take a "pre" timestamp has just passed and there isn't going to be
another one, the approach taken is to keep recording the "pre" timestamp
on each call, overwriting the previously recorded one until the "post"
timestamp is also taken.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-8-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

When it gets set, End Of Queue Flag halts the DSPI controller and forces
the chip select signal to deassert.

This operating mode is not ideal, but it is used for the DSPI
instantiations where there is no other notification from the controller
that the data in the FIFO has finished transmission. So in practice, it
means that transmitting buffers larger than the FIFO size will yield
unpredictable results.

The only controller that operates in EOQ mode is MCF5441X (Coldfire). I
would say that the way EOQ is used (and documented in the reference
manual, too) on this chip is incorrect, and I would personally migrate
it to TCFQ, but that's notably worse in terms of performance (it can
only use 1 entry of the 16-deep FIFO) and if this limitation didn't
bother any Coldfire DSPI user so far, it's likely that we just need to
throw an error for larger buffers to make sure that callers are aware
their transfers are getting truncated/split.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-7-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

These function names are very generic and it is easy to get confused.
Rename them after the hardware register that they are accessing.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-6-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Their names are confusing, since dspi_pop_tx prepares a word to be
written to the PUSHR register, and dspi_push_rx gets a word from the
POPR register.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-5-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This is a useless operation, and if the driver needs to do that, there's
something deeply wrong going on.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-4-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This variable has been present since the initial submission of the
driver, and held, for some reason, the value of zero, to be sent on the
wire in the case there wasn't any TX buffer for the current transfer.

Since quite a while now, however, it isn't doing anything at all.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-3-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Reduce the if-then-else-if-then-else sequence to:
 - a simple division in the case of bytes_per_word calculation
 - a memcpy command with a variable size. The semantics of larger-than-8
   xfer->bits_per_word is that those words are to be interpreted and
   transmitted in CPU native endianness.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-2-olteanv@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Merge series "Compatible string consolidation for NXP DSPI driver" from Vladimir Oltean <olteanv@gmail.com>:

This series makes room in the driver for differentiation between the
controllers which currently operate in TCFQ mode. Most of these are
actually capable of a lot more in terms of throughput. This is in
preparation of a second series which will convert the remaining users of
TCFQ mode altogether to XSPI mode with command cycling.

Vladimir Oltean (6):
  doc: spi-fsl-dspi: Add specific compatibles for all Layerscape SoCs
  spi: spi-fsl-dspi: Use specific compatible strings for all SoC
    instantiations
  spi: spi-fsl-dspi: Parameterize the FIFO size and DMA buffer size
  spi: spi-fsl-dspi: LS2080A and LX2160A support XSPI mode
  spi: spi-fsl-dspi: Support SPI software timestamping in all non-DMA
    modes
  spi: spi-fsl-dspi: Convert the instantiations that support it to DMA

 .../devicetree/bindings/spi/spi-fsl-dspi.txt  |  17 +-
 drivers/spi/spi-fsl-dspi.c                    | 162 +++++++++++++-----
 2 files changed, 128 insertions(+), 51 deletions(-)

--
2.17.1

Make the second compatible string optional for LS1012A, LS1088A and
LS2080A. Old versions of the spi-fsl-dspi.c driver still need to probe
on the old, generic compatible string for these controllers (such as
"fsl,ls1021a-v1.0-dspi") which provides less functionality.

Document the device tree bindings for LS1043A and LS1046A, whose
bindings are already in use in fsl-ls1043a.dtsi and fsl-ls1046a.dtsi.

Introduce new compatible strings for LS1028A and LX2160A. There will be
no second compatible string for these.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-2-olteanv@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The A-011218 eDMA/DSPI erratum affects most of the older Layerscape SoCs
with DSPI, and its workaround is a bit intrusive.

After this patch, there are no users of TCFQ mode that don't also
support XSPI (previously there was LS2085A).
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-7-olteanv@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

There's no reason to keep this .ptp_sts_supported property explicitly in
devtype_data, since it can be deduced from the operating mode alone.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-6-olteanv@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

XSPI allows for 2 extra features:
- Command cycling (use a single TX command with more than 1 word in the
  TX FIFO).
- Increased word size (from 16 bits to 32 bits)
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-5-olteanv@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Get rid of the ifdef for Coldfire and make these hardware
characteristics part of dspi->devtype_data.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-4-olteanv@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:

LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";

LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";

LS2085A:
compatible = "fsl,ls2085a-dspi";

LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";

LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";

LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";

LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";

Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.

They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Pull cifs fixes from Steve French:
 "Five small cifs/smb3 fixes, two for stable (one for a reconnect
  problem and the other fixes a use case when renaming an open file)"

* tag '5.6-rc4-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: Use #define in cifs_dbg
  cifs: fix rename() by ensuring source handle opened with DELETE bit
  cifs: add missing mount option to /proc/mounts
  cifs: fix potential mismatch of UNC paths
  cifs: don't leak -EAGAIN for stat() during reconnect

Merge series "trivial fixes for fsl-spi and spidev" from Oleksandr Suvorov <oleksandr.suvorov@toradex.com>:

- the memory optimization in fsl-spi
- the fix of the max speed setting bug in spidev

Oleksandr Suvorov (2):
  spi: fsl-lpspi: remove unneeded array
  spi: spidev: fix a max speed setting

 drivers/spi/spi-fsl-lpspi.c |  7 ++-----
 drivers/spi/spidev.c        | 10 ++++++----
 2 files changed, 8 insertions(+), 9 deletions(-)

--
2.24.1

- replace the array with the shift operation
- remove the extra comparing operation.
Signed-off-by: NOleksandr Suvorov <oleksandr.suvorov@toradex.com>
Link: https://lore.kernel.org/r/20200220141143.3902922-2-oleksandr.suvorov@toradex.comSigned-off-by: NMark Brown <broonie@kernel.org>

devm_regulator_register() could return -EPROBE_DEFER when trying to
get init data and NOT all resources are available at that time, for
this case, error message is better to be present for debug level ONLY.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/1583243052-1930-1-git-send-email-Anson.Huang@nxp.comSigned-off-by: NMark Brown <broonie@kernel.org>

Merge series "spi: spidev: Fix messages in spidev" from Oleksandr Suvorov <oleksandr.suvorov@toradex.com>:

- fix the values source for the xfer debug message.
- fix the "max speed setting" message showing.

Oleksandr Suvorov (2):
  spi: spidev: fix a debug message value
  spi: spidev: fix speed setting message

 drivers/spi/spidev.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

--
2.24.1

The message of max device speed setting is shown when
an error in spi_setup() occurs.
Instead, it should be shown when the setup call succeeds.
Signed-off-by: NOleksandr Suvorov <oleksandr.suvorov@toradex.com>
Link: https://lore.kernel.org/r/20200229161841.89144-3-oleksandr.suvorov@toradex.comSigned-off-by: NMark Brown <broonie@kernel.org>

The debug message in spidev_message() can show wrong xfer speed.
It happens if the initial (came from DT) and set with ioctl call spidev
speeds are different (spidev->speed_hz != spi->max_speed_hz) and one
sends a message with ioctl call and the field of speed is uninitialized
(u_tmp->speed_hz == 0).

In this case the kernel shows the spi->max_speed_hz value instead of
correct spidev->speed_hz.
...
set the max speed with an ioctl call:
[ 1227.702714] spidev spi0.0: setup mode 0, 32 bits/w, 20000000 Hz max --> 0
(real speed sets to 20000000Hz)
send a message with an ioctl call:
[ 1227.731801] spidev spi0.0:   xfer len 4096 tx 32bits 0 usec 10000000Hz
(debug message shows 10000000Hz that is the original max speed of this
spidev came from DT)
...

Fix the data source for the debug message.
Signed-off-by: NOleksandr Suvorov <oleksandr.suvorov@toradex.com>
Link: https://lore.kernel.org/r/20200229161841.89144-2-oleksandr.suvorov@toradex.comSigned-off-by: NMark Brown <broonie@kernel.org>

The purpose of commit 0fd85869 ("spi/bcm63xx-hsspi: keep pll clk enabled")
was to keep the pll clk enabled through the lifetime of the device.

In order to do that, some 'clk_prepare_enable()'/'clk_disable_unprepare()'
calls have been added in the error handling path of the probe function, in
the remove function and in the suspend and resume functions.

However, a 'clk_disable_unprepare()' call has been unfortunately left in
the probe function. So the commit seems to be more or less a no-op.

Axe it now, so that the pll clk is left enabled through the lifetime of
the device, as described in the commit.

Fixes: 0fd85869 ("spi/bcm63xx-hsspi: keep pll clk enabled")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: NJonas Gorski <jonas.gorski@gmail.com>
Link: https://lore.kernel.org/r/20200228213838.7124-1-christophe.jaillet@wanadoo.frSigned-off-by: NMark Brown <broonie@kernel.org>

Deferred probe is an expected return value for devm_pwm_get(). Given
that the driver deals with it properly, rather than warn on probe
deferral, only output a message on probe deferral if debug level
prints are enabled.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20200302141428.14119-1-jonathanh@nvidia.comSigned-off-by: NMark Brown <broonie@kernel.org>

ANATOP regulator should depend on ARCH_MXC or COMPILE_TEST.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/1583150118-8014-1-git-send-email-Anson.Huang@nxp.comSigned-off-by: NMark Brown <broonie@kernel.org>

Pull x86 fixes from Ingo Molnar:
 "Misc fixes: a pkeys fix for a bug that triggers with weird BIOS
  settings, and two Xen PV fixes: a paravirt interface fix, and
  pagetable dumping fix"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mm: Fix dump_pagetables with Xen PV
  x86/ioperm: Add new paravirt function update_io_bitmap()
  x86/pkeys: Manually set X86_FEATURE_OSPKE to preserve existing changes

Pull scheduler fix from Ingo Molnar:
 "Fix a scheduler statistics bug"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/fair: Fix statistics for find_idlest_group()