| Age | Commit message (Collapse) | Author |
|---|
|
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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-12-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-11-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-10-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-8-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-7-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-6-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-5-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-4-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-3-olteanv@gmail.com
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-2-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
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
|
|
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: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-7-olteanv@gmail.com>
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-6-olteanv@gmail.com>
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-5-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Get rid of the ifdef for Coldfire and make these hardware
characteristics part of dspi->devtype_data.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-4-olteanv@gmail.com>
Signed-off-by: Mark 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: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
<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: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Link: https://lore.kernel.org/r/20200220141143.3902922-2-oleksandr.suvorov@toradex.com
Signed-off-by: Mark 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: Anson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/1583243052-1930-1-git-send-email-Anson.Huang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
<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: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Link: https://lore.kernel.org/r/20200229161841.89144-3-oleksandr.suvorov@toradex.com
Signed-off-by: Mark 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: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Link: https://lore.kernel.org/r/20200229161841.89144-2-oleksandr.suvorov@toradex.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The purpose of commit 0fd85869c2a9 ("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: 0fd85869c2a9 ("spi/bcm63xx-hsspi: keep pll clk enabled")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Jonas Gorski <jonas.gorski@gmail.com>
Link: https://lore.kernel.org/r/20200228213838.7124-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Mark 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: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20200302141428.14119-1-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ANATOP regulator should depend on ARCH_MXC or COMPILE_TEST.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/1583150118-8014-1-git-send-email-Anson.Huang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull EFI fixes from Ingo Molnar:
"Three fixes to EFI mixed boot mode, mostly related to x86-64 vmap
stacks activated years ago, bug-fixed recently for EFI, which had
knock-on effects of various 1:1 mapping assumptions in mixed mode.
There's also a READ_ONCE() fix for reading an mmap-ed EFI firmware
data field only once, out of caution"
* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi: READ_ONCE rng seed size before munmap
efi/x86: Handle by-ref arguments covering multiple pages in mixed mode
efi/x86: Remove support for EFI time and counter services in mixed mode
efi/x86: Align GUIDs to their size in the mixed mode runtime wrapper
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"I2C has three driver bugfixes for you. We agreed on the Mac regression
to go in via I2C"
* 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
macintosh: therm_windtunnel: fix regression when instantiating devices
i2c: altera: Fix potential integer overflow
i2c: jz4780: silence log flood on txabrt
|
|
Removing attach_adapter from this driver caused a regression for at
least some machines. Those machines had the sensors described in their
DT, too, so they didn't need manual creation of the sensor devices. The
old code worked, though, because manual creation came first. Creation of
DT devices then failed later and caused error logs, but the sensors
worked nonetheless because of the manually created devices.
When removing attach_adaper, manual creation now comes later and loses
the race. The sensor devices were already registered via DT, yet with
another binding, so the driver could not be bound to it.
This fix refactors the code to remove the race and only manually creates
devices if there are no DT nodes present. Also, the DT binding is updated
to match both, the DT and manually created devices. Because we don't
know which device creation will be used at runtime, the code to start
the kthread is moved to do_probe() which will be called by both methods.
Fixes: 3e7bed52719d ("macintosh: therm_windtunnel: drop using attach_adapter")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Tested-by: Erhard Furtner <erhard_f@mailbox.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org # v4.19+
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Four small fixes.
Three are in drivers for fairly obvious bugs. The fourth is a set of
regressions introduced by the compat_ioctl changes because some of the
compat updates wrongly replaced .ioctl instead of .compat_ioctl"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: compat_ioctl: cdrom: Replace .ioctl with .compat_ioctl in four appropriate places
scsi: zfcp: fix wrong data and display format of SFP+ temperature
scsi: sd_sbc: Fix sd_zbc_report_zones()
scsi: libfc: free response frame from GPN_ID
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fixes from Bjorn Helgaas:
- Fix build issue on 32-bit ARM with old compilers (Marek Szyprowski)
- Update MAINTAINERS for recent Cadence driver file move (Lukas
Bulwahn)
* tag 'pci-v5.6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
MAINTAINERS: Correct Cadence PCI driver path
PCI: brcmstb: Fix build on 32bit ARM platforms with older compilers
|
|
Pull block fixes from Jens Axboe:
- Passthrough insertion fix (Ming)
- Kill off some unused arguments (John)
- blktrace RCU fix (Jan)
- Dead fields removal for null_blk (Dongli)
- NVMe polled IO fix (Bijan)
* tag 'block-5.6-2020-02-28' of git://git.kernel.dk/linux-block:
nvme-pci: Hold cq_poll_lock while completing CQEs
blk-mq: Remove some unused function arguments
null_blk: remove unused fields in 'nullb_cmd'
blktrace: Protect q->blk_trace with RCU
blk-mq: insert passthrough request into hctx->dispatch directly
|
|
Introduce is_mmp2_ssp() helper to be consistent with the rest
helper function to distinguish SSP type.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200227162556.3152-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
quirks" from John Garry <john.garry@huawei.com>:
As discussed during the original HiSilicon v3xx SPI driver upstreaming,
currently there is no method for the ACPI SPI Serial Bus Connection
Resource Descriptor to define the data buswidth [0], [1].
So we can look to get the ACPI spec updated for this, and I have
submitted a proposal for a new feature here:
https://bugzilla.tianocore.org/show_bug.cgi?id=2557
However I am not sure how successful that will be.
In the meantime, as an alternate approach, this RFC proposes to allow the
SPI controller driver override the device buswidth. In this example,
the driver uses DMI quirks to discover the host machine and set the
buswidth override accordingly when the machine is known to support
dual or quad mode of operation.
I also have included a fix for dual and quad modes in the driver.
Comments welcome. thanks.
[0] https://lore.kernel.org/linux-mtd/20200109212842.GK3702@sirena.org.uk/
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf,
19.6.126
John Garry (3):
spi: Allow SPI controller override device buswidth
spi: HiSilicon v3xx: Properly set CMD_CONFIG for Dual/Quad modes
spi: HiSilicon v3xx: Use DMI quirk to set controller buswidth override
bits
drivers/spi/spi-hisi-sfc-v3xx.c | 99 ++++++++++++++++++++++++++++++++-
drivers/spi/spi.c | 4 +-
include/linux/spi/spi.h | 3 +
3 files changed, 104 insertions(+), 2 deletions(-)
--
2.17.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
|
|
When adjust_op_size is defined, len is never used. Move the len
computation where it's actually used.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20200228160735.1565047-1-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The Huawei D06 board (and variants) can support Quad mode of operation.
Since we have no current method in ACPI SPI bus device resource description
to describe this information, use DMI to detect the board, and set the
controller buswidth override bits.
Signed-off-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1582903131-160033-4-git-send-email-john.garry@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The CMD_CONFIG register memory interface type field is not set configured
for Dual and Quad modes, so set appropriately.
This was not detected previously as we only ever operated in standard SPI
mode.
Signed-off-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1582903131-160033-3-git-send-email-john.garry@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently ACPI firmware description for a SPI device does not have any
method to describe the data buswidth on the board.
So even through the controller and device may support higher modes than
standard SPI, it cannot be assumed that the board does - as such, that
device is limited to standard SPI in such a circumstance.
As a workaround, allow the controller driver supply buswidth override bits,
which are used inform the core code that the controller driver knows the
buswidth supported on that board for that device.
A host controller driver might know this info from DMI tables, for example.
Signed-off-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1582903131-160033-2-git-send-email-john.garry@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The QSPI controller memory space is limited to 128MB:
0x9000_00000-0x9800_00000/0XD000_0000--0XD800_0000.
There are nor flashes that are bigger in size than the memory size
supported by the controller: Micron MT25QL02G (256 MB).
Check if the address exceeds the MMIO window size. An improvement
would be to add support for regular SPI mode and fall back to it
when the flash memories overrun the controller's memory space.
Fixes: 0e6aae08e9ae ("spi: Add QuadSPI driver for Atmel SAMA5D2")
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20200228155437.1558219-1-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"Fix a couple of configuration issues in the ACPI watchdog (WDAT)
driver (Mika Westerberg) and make it possible to disable that driver
at boot time in case it still does not work as expected (Jean
Delvare)"
* tag 'acpi-5.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: watchdog: Set default timeout in probe
ACPI: watchdog: Fix gas->access_width usage
ACPICA: Introduce ACPI_ACCESS_BYTE_WIDTH() macro
ACPI: watchdog: Allow disabling WDAT at boot
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"Fix a recent cpufreq initialization regression (Rafael Wysocki),
revert a devfreq commit that made incompatible changes and broke user
land on some systems (Orson Zhai), drop a stale reference to a
document that has gone away recently (Jonathan Neuschäfer), and fix a
typo in a hibernation code comment (Alexandre Belloni)"
* tag 'pm-5.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: Fix policy initialization for internal governor drivers
Revert "PM / devfreq: Modify the device name as devfreq(X) for sysfs"
PM / hibernate: fix typo "reserverd_size" -> "reserved_size"
Documentation: power: Drop reference to interface.rst
|
|
* pm-sleep:
PM / hibernate: fix typo "reserverd_size" -> "reserved_size"
Documentation: power: Drop reference to interface.rst
* pm-devfreq:
Revert "PM / devfreq: Modify the device name as devfreq(X) for sysfs"
|
|
Pull drm fixes from Dave Airlie:
"Just some fixes for this week: amdgpu, radeon and i915.
The main i915 one is a regression Gen7 (Ivybridge/Haswell), this moves
them back from trying to use the full-ppgtt support to the aliasing
version it used to use due to gpu hangs. Otherwise it's pretty quiet.
amdgpu:
- Drop DRIVER_USE_AGP
- Fix memory leak in GPU reset
- Resume fix for raven
radeon:
- Drop DRIVER_USE_AGP
i915:
- downgrade gen7 back to aliasing-ppgtt to avoid GPU hangs
- shrinker fix
- pmu leak and double free fixes
- gvt user after free and virtual display reset fixes
- randconfig build fix"
* tag 'drm-fixes-2020-02-28' of git://anongit.freedesktop.org/drm/drm:
drm/radeon: Inline drm_get_pci_dev
drm/amdgpu: Drop DRIVER_USE_AGP
drm/i915: Avoid recursing onto active vma from the shrinker
drm/i915/pmu: Avoid using globals for PMU events
drm/i915/pmu: Avoid using globals for CPU hotplug state
drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgtt
drm/i915: fix header test with GCOV
amdgpu/gmc_v9: save/restore sdpif regs during S3
drm/amdgpu: fix memory leak during TDR test(v2)
drm/i915/gvt: Fix orphan vgpu dmabuf_objs' lifetime
drm/i915/gvt: Separate display reset from ALL_ENGINES reset
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
drm/i915 fixes for v5.6-rc4:
- downgrade gen7 back to aliasing-ppgtt to avoid GPU hangs
- shrinker fix
- pmu leak and double free fixes
- gvt user after free and virtual display reset fixes
- randconfig build fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/874kvcsh00.fsf@intel.com
|
|
git://people.freedesktop.org/~agd5f/linux into drm-fixes
amd-drm-fixes-5.6-2020-02-26:
amdgpu:
- Drop DRIVER_USE_AGP
- Fix memory leak in GPU reset
- Resume fix for raven
radeon:
- Drop DRIVER_USE_AGP
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227034106.3912-1-alexander.deucher@amd.com
|
|
Pull networking fixes from David Miller:
1) Fix leak in nl80211 AP start where we leak the ACL memory, from
Johannes Berg.
2) Fix double mutex unlock in mac80211, from Andrei Otcheretianski.
3) Fix RCU stall in ipset, from Jozsef Kadlecsik.
4) Fix devlink locking in devlink_dpipe_table_register, from Madhuparna
Bhowmik.
5) Fix race causing TX hang in ll_temac, from Esben Haabendal.
6) Stale eth hdr pointer in br_dev_xmit(), from Nikolay Aleksandrov.
7) Fix TX hash calculation bounds checking wrt. tc rules, from Amritha
Nambiar.
8) Size netlink responses properly in schedule action code to take into
consideration TCA_ACT_FLAGS. From Jiri Pirko.
9) Fix firmware paths for mscc PHY driver, from Antoine Tenart.
10) Don't register stmmac notifier multiple times, from Aaro Koskinen.
11) Various rmnet bug fixes, from Taehee Yoo.
12) Fix vsock deadlock in vsock transport release, from Stefano
Garzarella.
* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (61 commits)
net: dsa: mv88e6xxx: Fix masking of egress port
mlxsw: pci: Wait longer before accessing the device after reset
sfc: fix timestamp reconstruction at 16-bit rollover points
vsock: fix potential deadlock in transport->release()
unix: It's CONFIG_PROC_FS not CONFIG_PROCFS
net: rmnet: fix packet forwarding in rmnet bridge mode
net: rmnet: fix bridge mode bugs
net: rmnet: use upper/lower device infrastructure
net: rmnet: do not allow to change mux id if mux id is duplicated
net: rmnet: remove rcu_read_lock in rmnet_force_unassociate_device()
net: rmnet: fix suspicious RCU usage
net: rmnet: fix NULL pointer dereference in rmnet_changelink()
net: rmnet: fix NULL pointer dereference in rmnet_newlink()
net: phy: marvell: don't interpret PHY status unless resolved
mlx5: register lag notifier for init network namespace only
unix: define and set show_fdinfo only if procfs is enabled
hinic: fix a bug of rss configuration
hinic: fix a bug of setting hw_ioctxt
hinic: fix a irq affinity bug
net/smc: check for valid ib_client_data
...
|
|
Add missing ~ to the usage of the mask.
Reported-by: Kevin Benson <Kevin.Benson@zii.aero>
Reported-by: Chris Healy <Chris.Healy@zii.aero>
Fixes: 5c74c54ce6ff ("net: dsa: mv88e6xxx: Split monitor port configuration")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
During initialization the driver issues a reset to the device and waits
for 100ms before checking if the firmware is ready. The waiting is
necessary because before that the device is irresponsive and the first
read can result in a completion timeout.
While 100ms is sufficient for Spectrum-1 and Spectrum-2, it is
insufficient for Spectrum-3.
Fix this by increasing the timeout to 200ms.
Fixes: da382875c616 ("mlxsw: spectrum: Extend to support Spectrum-3 ASIC")
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We can't just use the top bits of the last sync event as they could be
off-by-one every 65,536 seconds, giving an error in reconstruction of
65,536 seconds.
This patch uses the difference in the bottom 16 bits (mod 2^16) to
calculate an offset that needs to be applied to the last sync event to
get to the current time.
Signed-off-by: Alexandru-Mihai Maftei <amaftei@solarflare.com>
Acked-by: Martin Habets <mhabets@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Packet forwarding is not working in rmnet bridge mode.
Because when a packet is forwarded, skb_push() for an ethernet header
is needed. But it doesn't call skb_push().
So, the ethernet header will be lost.
Test commands:
modprobe rmnet
ip netns add nst
ip netns add nst2
ip link add veth0 type veth peer name veth1
ip link add veth2 type veth peer name veth3
ip link set veth1 netns nst
ip link set veth3 netns nst2
ip link add rmnet0 link veth0 type rmnet mux_id 1
ip link set veth2 master rmnet0
ip link set veth0 up
ip link set veth2 up
ip link set rmnet0 up
ip a a 192.168.100.1/24 dev rmnet0
ip netns exec nst ip link set veth1 up
ip netns exec nst ip a a 192.168.100.2/24 dev veth1
ip netns exec nst2 ip link set veth3 up
ip netns exec nst2 ip a a 192.168.100.3/24 dev veth3
ip netns exec nst2 ping 192.168.100.2
Fixes: 60d58f971c10 ("net: qualcomm: rmnet: Implement bridge mode")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
