aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/spi/spi-mem.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2020-11-04spi: spi-mem: fix reference leak in spi_mem_access_startZhang Qilong1-0/+1
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in spi_mem_access_start, so we should fix it. Fixes: f86c24f479530 ("spi: spi-mem: Split spi_mem_exec_op() code") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201103140910.3482-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-02spi: spi-mem: Fix passing zero to 'PTR_ERR' warningYueHaibing1-1/+1
Fix smatch warning: drivers/spi/spi-mem.c:746 spi_mem_probe() warn: passing zero to 'PTR_ERR' Fixes: 5d27a9c8ea9e ("spi: spi-mem: Extend the SPI mem interface to set a custom memory name") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20201031033042.42892-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-14spi: spi-mem: allow specifying a command's extensionPratyush Yadav1-6/+7
In xSPI mode, flashes expect 2-byte opcodes. The second byte is called the "command extension". There can be 3 types of extensions in xSPI: repeat, invert, and hex. When the extension type is "repeat", the same opcode is sent twice. When it is "invert", the second byte is the inverse of the opcode. When it is "hex" an additional opcode byte based is sent with the command whose value can be anything. So, make opcode a 16-bit value and add a 'nbytes', similar to how multiple address widths are handled. Some places use sizeof(op->cmd.opcode). Replace them with op->cmd.nbytes The spi-mxic and spi-zynq-qspi drivers directly use op->cmd.opcode as a buffer. Now that opcode is a 2-byte field, this can result in different behaviour depending on if the machine is little endian or big endian. Extract the opcode in a local 1-byte variable and use that as the buffer instead. Both these drivers would reject multi-byte opcodes in their supports_op() hook anyway, so we only need to worry about single-byte opcodes for now. The above two changes are put in this commit to keep the series bisectable. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200623183030.26591-3-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-14spi: spi-mem: allow specifying whether an op is DTR or notPratyush Yadav1-0/+3
Each phase is given a separate 'dtr' field so mixed protocols like 4S-4D-4D can be supported. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200623183030.26591-2-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-23spi: spi-mem: Fix Dual/Quad modes on Octal-capable devicesGeert Uytterhoeven1-4/+6
Currently buswidths 2 and 4 are rejected for a device that advertises Octal capabilities. Allow these buswidths, just like is done for buswidth 2 and Quad-capable devices. Fixes: b12a084c8729ef42 ("spi: spi-mem: add support for octal mode I/O data transfer") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200416101418.14379-1-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-28spi: spi-mem: Compute length only when neededTudor Ambarus1-2/+3
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>
2020-02-17spi: spi-mem: Fix typo, s/fallback/falls backTudor Ambarus1-1/+1
"Fallback" in one word is a noun. "Fall back" is two separate words, a verb and an adverb. Use the latter. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200216214012.1106658-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-07spi: spi-mem: fallback to using transfers when CS gpios are usedChris Packham1-1/+1
Devices with chip selects driven via GPIO are not compatible with the spi-mem operations. Fallback to using standard spi transfers when the device is connected with a gpio CS. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20191107044235.4864-3-chris.packham@alliedtelesis.co.nz Signed-off-by: Mark Brown <broonie@kernel.org>
2019-04-08spi-mem: fix kernel-doc for spi_mem_dirmap_{read|write}()Sergei Shtylyov1-2/+2
The function names in the kernel-doc comments were mistyped, with a word "dirmap" being repeated twice, so fix them. Fixes: aa167f3fed0c ("spi: spi-mem: Add a new API to support direct mapping") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-04-03spi: spi-mem: export spi_mem_default_supports_op()Naga Sureshkumar Relli1-2/+2
Export spi_mem_default_supports_op(), so that controller drivers can use this. spi-mem driver already exports this using EXPORT_SYMBOL, but not declared it in spi-mem.h. This patch declares spi_mem_default_supports_op() in spi-mem.h and also removes the static from the function prototype. Signed-off-by: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-02-20Merge branch 'for-5.0' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.1Mark Brown1-1/+2
2019-01-21spi: spi-mem: Add devm_spi_mem_dirmap_{create,destroy}()Boris Brezillon1-0/+69
Since direct mapping descriptors usually the same lifetime as the SPI MEM device adding devm_ variants of the spi_mem_dirmap_{create,destroy}() should greatly simplify error/remove path of spi-mem drivers making use of the direct mapping API. Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-21spi: spi-mem: Fix a memory leak in spi_mem_dirmap_destroy()Boris Brezillon1-0/+2
The dirmap descriptor object allocated in spi_mem_dirmap_create is never freed. Add a kfree(desc) in spi_mem_dirmap_destroy(). Fixes: aa167f3fed0c ("spi: spi-mem: Add a new API to support direct mapping") Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-21spi: spi-mem: Fix spi_mem_dirmap_destroy() kerneldocBoris Brezillon1-1/+0
spi_mem_dirmap_destroy() takes a single argument, remove the @info entry in the doc. Fixes: aa167f3fed0c ("spi: spi-mem: Add a new API to support direct mapping") Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-20Merge remote-tracking branches 'spi/topic/mem' and 'spi/topic/mtd' into spi-nextMark Brown1-22/+247
2018-12-03spi: spi-mem: add support for octal mode I/O data transferYogesh Narayan Gaur1-1/+8
Add support for octal mode I/O data transfer in spi-mem framework. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-20spi: spi-mem: Add a new API to support direct mappingBoris Brezillon1-0/+204
Most modern SPI controllers can directly map a SPI memory (or a portion of the SPI memory) in the CPU address space. Most of the time this brings significant performance improvements as it automates the whole process of sending SPI memory operations every time a new region is accessed. This new API allows SPI memory drivers to create direct mappings and then use them to access the memory instead of using spi_mem_exec_op(). Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-20spi: spi-mem: Split spi_mem_exec_op() codeBoris Brezillon1-21/+42
The logic surrounding the ->exec_op() call applies to direct mapping accessors. Move this code to separate functions to avoid duplicating code. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-20spi: spi-mem: Add SPI_MEM_NO_DATA to the spi_mem_data_dir enumBoris Brezillon1-1/+1
When defining spi_mem_op templates we don't necessarily know the size that will be passed when the template is actually used, and basing the supports_op() check on op->data.nbytes to know whether there will be data transferred for a specific operation is this not possible. Add SPI_MEM_NO_DATA to the spi_mem_data_dir enum so that we can base our checks on op->data.dir instead of op->data.nbytes. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-27spi: spi-mem: Fix inverted logic in op sanity checkGeert Uytterhoeven1-4/+4
On r8a7791/koelsch: m25p80 spi0.0: error -22 reading 9f m25p80: probe of spi0.0 failed with error -22 Apparently the logic in spi_mem_check_op() is wrong, rejecting the spi-mem operation if any buswidth is valid, instead of invalid. Fixes: 380583227c0c7f52 ("spi: spi-mem: Add extra sanity checks on the op param") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-20spi: spi-mem: Add extra sanity checks on the op paramBoris Brezillon1-6/+48
Some combinations are simply not valid and should be rejected before the op is passed to the SPI controller driver. Add an spi_mem_check_op() helper and use it in spi_mem_exec_op() and spi_mem_supports_op() to make sure the spi-mem operation is valid. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-10spi: spi-mem: Adjust op len based on message/transfer size limitationsChuanhua Han1-0/+15
We need that to adjust the len of the 2nd transfer (called data in spi-mem) if it's too long to fit in a SPI message or SPI transfer. Fixes: c36ff266dc82 ("spi: Extend the core to ease integration of SPI memory controllers") Cc: <stable@vger.kernel.org> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-08-02spi: spi-mem: Extend the SPI mem interface to set a custom memory nameFrieder Schrempf1-0/+28
When porting (Q)SPI controller drivers from the MTD layer to the SPI layer, the naming scheme for the memory devices changes. To be able to keep compatibility with the old drivers naming scheme, a name field is added to struct spi_mem and a hook is added to let controller drivers set a custom name for the memory device. Example for the FSL QSPI driver: Name with the old driver: 21e0000.qspi, or with multiple devices: 21e0000.qspi-0, 21e0000.qspi-1, ... Name with the new driver without spi_mem_get_name: spi4.0 Suggested-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-11spi: Extend the core to ease integration of SPI memory controllersBoris Brezillon1-0/+410
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>