<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/spi, branch linux-5.11.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-5.11.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-5.11.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-05-14T08:49:50+00:00</updated>
<entry>
<title>spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails</title>
<updated>2021-05-14T08:49:50+00:00</updated>
<author>
<name>Quanyang Wang</name>
<email>quanyang.wang@windriver.com</email>
</author>
<published>2021-04-16T00:46:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c26c026eb496261dbc0adbf606cc81989cd2038c'/>
<id>urn:sha1:c26c026eb496261dbc0adbf606cc81989cd2038c</id>
<content type='text'>
[ Upstream commit 126bdb606fd2802454e6048caef1be3e25dd121e ]

The spi controller supports 44-bit address space on AXI in DMA mode,
so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.
In addition, if dma_map_single fails, it should return immediately
instead of continuing doing the DMA operation which bases on invalid
address.

This fixes the following crash which occurs in reading a big block
from flash:

[  123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots)
[  123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped
[  123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0
[  123.792536] Mem abort info:
[  123.795313]   ESR = 0x96000145
[  123.798351]   EC = 0x25: DABT (current EL), IL = 32 bits
[  123.803655]   SET = 0, FnV = 0
[  123.806693]   EA = 0, S1PTW = 0
[  123.809818] Data abort info:
[  123.812683]   ISV = 0, ISS = 0x00000145
[  123.816503]   CM = 1, WnR = 1
[  123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000
[  123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000
[  123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang &lt;quanyang.wang@windriver.com&gt;
Link: https://lore.kernel.org/r/20210416004652.2975446-6-quanyang.wang@windriver.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op</title>
<updated>2021-05-14T08:49:50+00:00</updated>
<author>
<name>Quanyang Wang</name>
<email>quanyang.wang@windriver.com</email>
</author>
<published>2021-04-16T00:46:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d67e0d6bd92ebbb0294e7062bbf5cdc773764e62'/>
<id>urn:sha1:d67e0d6bd92ebbb0294e7062bbf5cdc773764e62</id>
<content type='text'>
[ Upstream commit a2c5bedb2d55dd27c642c7b9fb6886d7ad7bdb58 ]

When handling op-&gt;addr, it is using the buffer "tmpbuf" which has been
freed. This will trigger a use-after-free KASAN warning. Let's use
temporary variables to store op-&gt;addr.val and op-&gt;cmd.opcode to fix
this issue.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang &lt;quanyang.wang@windriver.com&gt;
Link: https://lore.kernel.org/r/20210416004652.2975446-5-quanyang.wang@windriver.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-zynqmp-gqspi: fix hang issue when suspend/resume</title>
<updated>2021-05-14T08:49:50+00:00</updated>
<author>
<name>Quanyang Wang</name>
<email>quanyang.wang@windriver.com</email>
</author>
<published>2021-04-16T00:46:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=afa2ae2bc135563c3e352501349528918b2024ff'/>
<id>urn:sha1:afa2ae2bc135563c3e352501349528918b2024ff</id>
<content type='text'>
[ Upstream commit 799f923f0a66a9c99f0a3eaa078b306db7a8b33a ]

After calling platform_set_drvdata(pdev, xqspi) in probe, the return
value of dev_get_drvdata(dev) is a pointer to struct zynqmp_qspi but
not struct spi_controller. A wrong structure type passing to the
functions spi_controller_suspend/resume will hang the system.

And we should check the return value of spi_controller_suspend, if
an error is returned, return it to PM subsystem to stop suspend.

Also, GQSPI_EN_MASK should be written to GQSPI_EN_OFST to enable
the spi controller in zynqmp_qspi_resume since it was disabled in
zynqmp_qspi_suspend before.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang &lt;quanyang.wang@windriver.com&gt;
Link: https://lore.kernel.org/r/20210416004652.2975446-3-quanyang.wang@windriver.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-zynqmp-gqspi: fix clk_enable/disable imbalance issue</title>
<updated>2021-05-14T08:49:49+00:00</updated>
<author>
<name>Quanyang Wang</name>
<email>quanyang.wang@windriver.com</email>
</author>
<published>2021-04-16T00:46:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=914563f99eef659ad74babb1fe0230cb08df6997'/>
<id>urn:sha1:914563f99eef659ad74babb1fe0230cb08df6997</id>
<content type='text'>
[ Upstream commit c6bdae08012b2ca3e94f3a41ef4ca8cfe7c9ab6f ]

The clks "pclk" and "ref_clk" are enabled twice during the probe. The
first time is in the function zynqmp_qspi_probe and the second time is
in zynqmp_qspi_setup_op which is called by devm_spi_register_controller.
Then calling zynqmp_qspi_remove (rmmod this module) to disable these clks
will trigger a warning as below:

[  309.124604] Unpreparing enabled qspi_ref
[  309.128641] WARNING: CPU: 1 PID: 537 at drivers/clk/clk.c:824 clk_core_unprepare+0x108/0x110

Since pm_runtime works now, clks can be enabled/disabled by calling
zynqmp_runtime_suspend/resume. So we don't need to enable these clks
explicitly in zynqmp_qspi_setup_op. Remove them to fix this issue.

And remove clk enabling/disabling in zynqmp_qspi_resume because there is
no spi transfer operation so enabling ref_clk is redundant meanwhile pclk
is not disabled for it is shared with other peripherals.

Furthermore replace clk_enable/disable with clk_prepare_enable and
clk_disable_unprepare in runtime_suspend/resume functions.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang &lt;quanyang.wang@windriver.com&gt;
Link: https://lore.kernel.org/r/20210416004652.2975446-2-quanyang.wang@windriver.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-zynqmp-gqspi: Fix missing unlock on error in zynqmp_qspi_exec_op()</title>
<updated>2021-05-14T08:49:49+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>weiyongjun1@huawei.com</email>
</author>
<published>2021-04-12T16:00:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=93b6939ac51a478743280648594ea8e5ce94ea6a'/>
<id>urn:sha1:93b6939ac51a478743280648594ea8e5ce94ea6a</id>
<content type='text'>
[ Upstream commit 6043357263fbe2df0bf0736d971ad5dce7d19dc1 ]

Add the missing unlock before return from function zynqmp_qspi_exec_op()
in the error handling case.

Fixes: a0f65be6e880 ("spi: spi-zynqmp-gqspi: add mutex locking for exec_op")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Wei Yongjun &lt;weiyongjun1@huawei.com&gt;
Link: https://lore.kernel.org/r/20210412160025.194171-1-weiyongjun1@huawei.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware()</title>
<updated>2021-05-14T08:49:48+00:00</updated>
<author>
<name>Wang Li</name>
<email>wangli74@huawei.com</email>
</author>
<published>2021-04-09T09:54:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b8207bfc539cd07d15e753ff2d179c5b61c673b1'/>
<id>urn:sha1:b8207bfc539cd07d15e753ff2d179c5b61c673b1</id>
<content type='text'>
[ Upstream commit a03675497970a93fcf25d81d9d92a59c2d7377a7 ]

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Fixes: 944c01a889d9 ("spi: lpspi: enable runtime pm for lpspi")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Wang Li &lt;wangli74@huawei.com&gt;
Link: https://lore.kernel.org/r/20210409095430.29868-1-wangli74@huawei.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-zynqmp-gqspi: fix incorrect operating mode in zynqmp_qspi_read_op</title>
<updated>2021-05-14T08:49:47+00:00</updated>
<author>
<name>Quanyang Wang</name>
<email>quanyang.wang@windriver.com</email>
</author>
<published>2021-04-08T04:02:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8abf26e27b46690a1cf4224d3e0ecd7c7f79b6b'/>
<id>urn:sha1:c8abf26e27b46690a1cf4224d3e0ecd7c7f79b6b</id>
<content type='text'>
[ Upstream commit 41d310930084502433fcb3c4baf219e7424b7734 ]

When starting a read operation, we should call zynqmp_qspi_setuprxdma
first to set xqspi-&gt;mode according to xqspi-&gt;bytes_to_receive and
to calculate correct xqspi-&gt;dma_rx_bytes. Then in the function
zynqmp_qspi_fillgenfifo, generate the appropriate command with
operating mode and bytes to transfer, and fill the GENFIFO with
the command to perform the read operation.

Calling zynqmp_qspi_fillgenfifo before zynqmp_qspi_setuprxdma will
result in incorrect transfer length and operating mode. So change
the calling order to fix this issue.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang &lt;quanyang.wang@windriver.com&gt;
Reviewed-by: Amit Kumar Mahapatra &lt;amit.kumar-mahapatra@xilinx.com&gt;
Link: https://lore.kernel.org/r/20210408040223.23134-5-quanyang.wang@windriver.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-zynqmp-gqspi: transmit dummy circles by using the controller's internal functionality</title>
<updated>2021-05-14T08:49:47+00:00</updated>
<author>
<name>Quanyang Wang</name>
<email>quanyang.wang@windriver.com</email>
</author>
<published>2021-04-08T04:02:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39c04fdadb3a52cc0828dc224dd68c1bdb70ef6c'/>
<id>urn:sha1:39c04fdadb3a52cc0828dc224dd68c1bdb70ef6c</id>
<content type='text'>
[ Upstream commit 8ad07d79bd56a531990a1a3f3f1c0eb19d2de806 ]

There is a data corruption issue that occurs in the reading operation
(cmd:0x6c) when transmitting common data as dummy circles.

The gqspi controller has the functionality to send dummy clock circles.
When writing data with the fields [receive, transmit, data_xfer] = [0,0,1]
to the Generic FIFO, and configuring the correct SPI mode, the controller
will transmit dummy circles.

So let's switch to hardware dummy cycles transfer to fix this issue.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang &lt;quanyang.wang@windriver.com&gt;
Reviewed-by: Amit Kumar Mahapatra &lt;amit.kumar-mahapatra@xilinx.com&gt;
Link: https://lore.kernel.org/r/20210408040223.23134-4-quanyang.wang@windriver.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-zynqmp-gqspi: add mutex locking for exec_op</title>
<updated>2021-05-14T08:49:47+00:00</updated>
<author>
<name>Quanyang Wang</name>
<email>quanyang.wang@windriver.com</email>
</author>
<published>2021-04-08T04:02:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1b2ae6024b0e0b6e3be3ebadb8c7cac1b190d015'/>
<id>urn:sha1:1b2ae6024b0e0b6e3be3ebadb8c7cac1b190d015</id>
<content type='text'>
[ Upstream commit a0f65be6e880a14d3445b75e7dc03d7d015fc922 ]

The spi-mem framework has no locking to prevent ctlr-&gt;mem_ops-&gt;exec_op
from concurrency. So add the locking to zynqmp_qspi_exec_op.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang &lt;quanyang.wang@windriver.com&gt;
Reviewed-by: Amit Kumar Mahapatra &lt;amit.kumar-mahapatra@xilinx.com&gt;
Link: https://lore.kernel.org/r/20210408040223.23134-3-quanyang.wang@windriver.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-zynqmp-gqspi: use wait_for_completion_timeout to make zynqmp_qspi_exec_op not interruptible</title>
<updated>2021-05-14T08:49:47+00:00</updated>
<author>
<name>Quanyang Wang</name>
<email>quanyang.wang@windriver.com</email>
</author>
<published>2021-04-08T04:02:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9dfc6283685c120beb74a893db9dad55364c4331'/>
<id>urn:sha1:9dfc6283685c120beb74a893db9dad55364c4331</id>
<content type='text'>
[ Upstream commit a16bff68b75fd082d36aa0b14b540bd7a3ebebbd ]

When Ctrl+C occurs during the process of zynqmp_qspi_exec_op, the function
wait_for_completion_interruptible_timeout will return a non-zero value
-ERESTARTSYS immediately. This will disrupt the SPI memory operation
because the data transmitting may begin before the command or address
transmitting completes. Use wait_for_completion_timeout to prevent
the process from being interruptible.

This patch fixes the error as below:
root@xilinx-zynqmp:~# flash_erase /dev/mtd3 0 0
Erasing 4 Kibyte @ 3d000 --  4 % complete
    (Press Ctrl+C)
[  169.581911] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  170.585907] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  171.589910] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  172.593910] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  173.597907] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  173.603480] spi-nor spi0.0: Erase operation failed.
[  173.608368] spi-nor spi0.0: Attempted to modify a protected sector.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang &lt;quanyang.wang@windriver.com&gt;
Reviewed-by: Amit Kumar Mahapatra &lt;amit.kumar-mahapatra@xilinx.com&gt;
Link: https://lore.kernel.org/r/20210408040223.23134-2-quanyang.wang@windriver.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
