- 04 Jun, 2018 1 commit
-
-
Mark Brown authored
-
- 31 May, 2018 1 commit
-
-
Fabio Estevam authored
The correct form is "a high-level", so fix it accordingly. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 24 May, 2018 1 commit
-
-
Geert Uytterhoeven authored
According to section 59.2.4 MSIOF Receive Mode Register 1 (SIRMDR1) in the R-Car Gen3 datasheet Rev.1.00, the value of the SIRMDR1.SYNCAC bit must match the value of the SITMDR1.SYNCAC bit. However, sh_msiof_spi_setup() changes only the latter. Fix this by updating the SIRMDR1 register like the SITMDR1 register, taking into account register bits that exist in SITMDR1 only. Reported-by: Renesas BSP team via Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Fixes: 7ff0b53c ("spi: sh-msiof: Avoid writing to registers from spi_master.setup()") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 22 May, 2018 1 commit
-
-
Boris Brezillon authored
SPI mem drivers should use spi_mem_set_drvdata() not spi_set_drvdata() to store their private data. Using spi_set_drvdata() will mess the spi -> spi-mem link up and cause a kernel panic at shutdown or device removal time. Fixes: 4120f8d1 ("mtd: spi-nor: Use the spi_mem_xx() API") Reported-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Marek Vasut <marek.vasut+renesas@gmail.com> on R8A7791 Porter Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 21 May, 2018 2 commits
-
-
Tony Lindgren authored
Commit 5a686b2c ("spi: omap2-mcspi: Idle hardware during suspend and resume") added calls for pm_runtime_force_suspend() and pm_runtime_force_resume() to make sure spi is idled between device_prepare() and device_complete(). But testing Linux next, I now noticed that we will get the following: spi_master spi0: Failed to power device: -13 Looking at things more turns out we can just remove this non-standard code. I was probably testing with some extra experimental patches earlier when I thought we need pm_runtime_force_suspend() and pm_runtime_force_resume(). Fixes: 5a686b2c ("spi: omap2-mcspi: Idle hardware during suspend and resume") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Tony Lindgren authored
If pm_runtime_get_sync() fails we should call pm_runtime_put_noidle(). This is probably not a critical fix as we should only hit this when things are broken elsewhere. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 17 May, 2018 2 commits
-
-
Boris Brezillon authored
resource_size() is dereferencing the res without checking that it is not NULL, so we need to do the check before calling resource_size(). Fixes: b95cb394 ("spi: ti-qspi: Implement the spi_mem interface") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Marek Szyprowski authored
Since Linux v4.10 release (commit 1d9174fb "PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()"), pm_runtime_force_resume() function doesn't runtime resume device if it was not runtime active before system suspend. Thus, driver should not do any register access after pm_runtime_force_resume() without checking the runtime status of the device. To fix this issue, simply move s3c64xx_spi_hwinit() call to s3c64xx_spi_runtime_resume() to ensure that hardware is always properly initialized. This fixes Synchronous external abort issue on system suspend/resume cycle on newer Exynos SoCs. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
- 13 May, 2018 1 commit
-
-
Boris Brezillon authored
Patch http://patchwork.ozlabs.org/patch/905205/ has been partially applied, and changes to the bcm-qspi driver have been lost somehow (probably due to a conflict when applying the patch). Remove the ->spi_flash_read() bits from this driver to fix the build error. Fixes: c1f5ba70 ("spi: Get rid of the spi_flash_read() API") Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 11 May, 2018 6 commits
-
-
Boris Brezillon authored
This API has been replaced by the spi_mem_xx() one, its only user (spi-nor) has been converted to spi_mem_xx() and all SPI controller drivers that were implementing the ->spi_flash_xxx() hooks are also implementing the spi_mem ones. So we can safely get rid of this API. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@exceet.de> Tested-by: Frieder Schrempf <frieder.schrempf@exceet.de> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Boris Brezillon authored
The spi_mem_xxx() API has been introduced to replace the spi_flash_read() one. Make use of it so we can get rid of spi_flash_read(). Note that using spi_mem_xx() also simplifies the code because this API takes care of using the regular spi_sync() interface when the optimized ->mem_ops interface is not implemented by the controller. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@exceet.de> Tested-by: Frieder Schrempf <frieder.schrempf@exceet.de> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Boris Brezillon authored
The spi_mem interface is meant to replace the spi_flash_read() one. Implement the ->exec_op() method so that we can smoothly get rid of the old interface. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Vignesh R <vigneshr@ti.com> Tested-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Boris Brezillon authored
The spi_mem interface is meant to replace the ->spi_flash_read() one. Implement the ->exec_op() method to ease removal of the old interface. Not that ->spi_flash_read() is now implemented as a wrapper around the new bcm_qspi_exec_mem_op() function so that we can easily get rid of it when ->spi_flash_read() is removed. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Kamal Dasu <kdasu.kdev@gmail.com> Tested-by: Kamal Dasu <kdasu.kdev@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Boris Brezillon authored
Some SPI/QuadSPI controllers only expose a high-level SPI memory interface, thus preventing any regular SPI transfers from being done. In that case, SPI controller drivers can leave all ->transfer_xxx() hooks empty and only implement the spi_mem_ops interface. Adjust the core to allow such situations: - extend spi_controller_check_ops() to accept situations where all ->transfer_xxx() pointers are NULL only if ->mem_ops != NULL - make sure we do not initialize the SPI message queue if ctlr->transfer_one and ctlr->transfer_one_message are missing - return -ENOTSUPP if someone tries to do a regular SPI transfer on a controller that does not support it Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@exceet.de> Tested-by: Frieder Schrempf <frieder.schrempf@exceet.de> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Boris Brezillon authored
Some controllers are exposing high-level interfaces to access various kind of SPI memories. Unfortunately they do not fit in the current spi_controller model and usually have drivers placed in drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI memories in general. This is an attempt at defining a SPI memory interface which works for all kinds of SPI memories (NORs, NANDs, SRAMs). Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@exceet.de> Tested-by: Frieder Schrempf <frieder.schrempf@exceet.de> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 10 May, 2018 1 commit
-
-
Rafał Miłecki authored
I accidentally sent an early version of patch removing spi-bcm53xx driver which got rid of .c and .h files *only*. I amended local commit but forgot to re-format the patch. This commit removes leftovers of dropped driver. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 09 May, 2018 1 commit
-
-
Rafał Miłecki authored
This driver was added by commit 0fc6a323 ("spi: bcm53xx: driver for SPI controller on Broadcom bcma SoC") back in 2014. It was needed to provide a minimal support for SPI controller on BCM5301X (AKA Northstar) devices. An alternative driver was added by Kamal in commit fa236a7e ("spi: bcm-qspi: Add Broadcom MSPI driver") 2 years later. It supports the same hardware but for some reason a new driver has been developed for it. At this point the new driver supports: more modes, setting a speed, setting bits per word and uses IRQs instead of polling. DTS file for BCM5301X has also been updated in the commit 1c8f4065 ("ARM: dts: BCM5301X: convert to iProc QSPI") - over a year ago. That explained I see no reason to keep the old driver alive. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 03 May, 2018 5 commits
-
-
Tobias Jordan authored
clk_prepare_enable() can fail, so its return value should be checked and acted upon. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 3343b7a6 ("spi/pxa2xx: convert to the common clk framework") Signed-off-by: Tobias Jordan <Tobias.Jordan@elektrobit.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Rob Herring authored
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART). Downstream fixes this with an AUX irqchip to demux the IRQ sources and a DT change which breaks compatibility with older kernels. The AUX irqchip was already rejected for upstream[1] and the DT change would break working systems if the DTB is updated to a newer one. The latter issue was brought to my attention by Alex Graf. The root cause however is a bug in the shared handler. Shared handlers must check that interrupts are actually enabled before servicing the interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled. [1] https://patchwork.kernel.org/patch/9781221/ Cc: Alexander Graf <agraf@suse.de> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Mark Brown <broonie@kernel.org> Cc: Eric Anholt <eric@anholt.net> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-spi@vger.kernel.org Cc: linux-rpi-kernel@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Fabio Estevam authored
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Fabio Estevam authored
Adopt the SPDX license identifier headers to ease license compliance management. Cc: Marek Vasut <marex@denx.de> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Fabio Estevam authored
Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 01 May, 2018 5 commits
-
-
Tony Lindgren authored
We currently are calling mcspi suspend and resume without considering that mcspi might provide resources for other device driver such as regulators. This means resume can fail and will produce -EACCES if errors if anything calls mcspi functions between device_prepare() and device_complete(). To fix the issue, let's do the following changes: 1. Let's add checking for return values for pm_runtime_get calls, and call pm_runtime_put_noidle() on errors. Things still fail after this change, but at least we see something is wrong as we now see -EACCES errors on resume. 2. Let's use noirq level for suspend and resume as other drivers can still call SPI related functions on suspend and resume. This still won't fix the -EACCES issue, but gets us to something a bit saner. 3. Finally, let's modify suspend and resume to call to make sure the device is idled properly on suspend. We have device_prepare() call pm_runtime_get_noresume() that won't get released until in device_complete() when it calls pm_runtime_put(). So if SPI is still active on entering suspend, it will never get idled unless we add calls to pm_runtime_force_suspend() and resume. This also fixes the -EACCES errors on resume together with changes 1 and 2 above. And since we're already rewriting suspend resume functions, let's arrange the order of suspend and resume functions to be like they usually are with suspend first. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Tony Lindgren authored
We can have the SoC enter off mode also during idle, not just during suspend. Currently we are handling the CS restore properly for unused CS only for resume and not for runtime resume. Let's just move all the context related restore to runtime_resume(). Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Alexey Khoroshilov authored
If devm_spi_register_master() fails in meson_spicc_probe(), spicc->core is left undisabled. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Kamal Dasu authored
Always confirm the BSPI_MAST_N_BOOT_CTRL bit when enabling or disabling BSPI transfers. Fixes: 4e3b2d23 ("spi: bcm-qspi: Add BSPI spi-nor flash controller driver") Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
Kamal Dasu authored
Added fix for probing of spi-nor device non-zero chip selects. Set MSPI_CDRAM_PCS (peripheral chip select) with spi master for MSPI controller and not for MSPI/BSPI spi-nor master controller. Ensure setting of cs bit in chip select register on chip select change. Fixes: fa236a7e ("spi: bcm-qspi: Add Broadcom MSPI driver") Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
- 27 Apr, 2018 1 commit
-
-
Arvind Yadav authored
Replace the manual validity checks for the GPIO with the gpio_is_valid(). Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 26 Apr, 2018 2 commits
-
-
Boris Brezillon authored
Right now, no checks are done on the presence of a ->transfer[_xxx]() method, which can lead to a NULL pointer dereference when someone starts sending something on the bus. Do the check at registration time and refuse to add the controller if all ->transfer[_xxx]() pointers are NULL. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Stefan Potyra authored
Enable the clock prior to calling clk_get_rate(), because clk_get_rate() should only be called if the clock is enabled. Additionally, prepare/enable the pll_clk before calling clk_get_rate() for the same reason. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 142168eb ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver") Signed-off-by: Stefan Potyra <Stefan.Potyra@elektrobit.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 25 Apr, 2018 1 commit
-
-
Krzysztof Kozlowski authored
The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 24 Apr, 2018 1 commit
-
-
Andy Shevchenko authored
Currently the 32-bit device address only is supported for DMA. However, starting from Intel Sunrisepoint PCH the DMA address of the device FIFO can be 64-bit. Change the respective variable to be compatible with DMA engine expectations, i.e. to phys_addr_t. Fixes: 34cadd9c ("spi: pxa2xx: Add support for Intel Sunrisepoint") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
- 23 Apr, 2018 2 commits
-
-
Boris Brezillon authored
This is needed by the spi-mem logic to force all messages that have been queued before a memory operation to be sent before we start the memory operation. We do that in order to guarantee that spi-mem operations do not preempt regular SPI transfers. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Boris Brezillon authored
spi_{map,unmap}_buf() are needed by the spi-mem logic that is about to be introduced to prepare data buffer for DMA operations. Remove the static specifier on these functions and add their prototypes to drivers/spi/internals.h. We do not export the symbols here because both SPI_MEM and SPI can't be enabled as modules and we'd like to prevent controller/device drivers from using these functions. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 20 Apr, 2018 1 commit
-
-
Wolfram Sang authored
We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 19 Apr, 2018 1 commit
-
-
Andy Shevchenko authored
Currently the 32-bit device address only is supported for DMA. However, starting from Intel Sunrisepoint PCH the DMA address of the device FIFO can be 64-bit. Change the respective variable to be compatible with DMA engine expectations, i.e. to phys_addr_t. Fixes: 34cadd9c ("spi: pxa2xx: Add support for Intel Sunrisepoint") Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 18 Apr, 2018 4 commits
-
-
Sylwester Nawrocki authored
Some variants of the SPI controller have no DMA support, in such case SPI transfers longer than the FIFO length are not currently properly handled by the driver. Fix it by doing multiple transfers in the s3c64xx_spi_transfer_one() function if the SPI transfer length exceeds the FIFO size. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Andi Shyti <andi@etezian.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Sylwester Nawrocki authored
More references to fifo_len are added in subsequent patch. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Andi Shyti <andi@etezian.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-
kbuild test robot authored
Fixes: d5898e19 ("spi: pxa2xx: Use core message processing loop") Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Sylwester Nawrocki authored
Add a s3c64xx_ prefix to remaining generic function names so it is clear the code is part of the driver when grepping or looking at debug logs. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Andi Shyti <andi@etezian.org> Signed-off-by: Mark Brown <broonie@kernel.org>
-