<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/scsi/ufs, 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-19T08:29:43+00:00</updated>
<entry>
<title>scsi: ufs: core: Narrow down fast path in system suspend path</title>
<updated>2021-05-19T08:29:43+00:00</updated>
<author>
<name>Can Guo</name>
<email>cang@codeaurora.org</email>
</author>
<published>2021-04-26T03:48:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5f359c4c2d5fbffee87592dfc01d29cadfaba856'/>
<id>urn:sha1:5f359c4c2d5fbffee87592dfc01d29cadfaba856</id>
<content type='text'>
[ Upstream commit ce4f62f9dd8cf43ac044045ed598a0b80ef33890 ]

If spm_lvl is set to 0 or 1, when system suspend kicks start and HBA is
runtime active, system suspend may just bail without doing anything (the
fast path), leaving other contexts still running, e.g., clock gating and
clock scaling. When system resume kicks start, concurrency can happen
between ufshcd_resume() and these contexts, leading to various stability
issues.

Add a check against HBA's runtime state and allowing fast path only if HBA
is runtime suspended, otherwise let system suspend go ahead call
ufshcd_suspend(). This will guarantee that these contexts are stopped by
either runtime suspend or system suspend.

Link: https://lore.kernel.org/r/1619408921-30426-4-git-send-email-cang@codeaurora.org
Fixes: 0b257734344a ("scsi: ufs: optimize system suspend handling")
Reviewed-by: Daejun Park &lt;daejun7.park@samsung.com&gt;
Signed-off-by: Can Guo &lt;cang@codeaurora.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: core: Cancel rpm_dev_flush_recheck_work during system suspend</title>
<updated>2021-05-19T08:29:43+00:00</updated>
<author>
<name>Can Guo</name>
<email>cang@codeaurora.org</email>
</author>
<published>2021-04-26T03:48:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3ac330861f99baced78813914bfc9f3e7ea6f04e'/>
<id>urn:sha1:3ac330861f99baced78813914bfc9f3e7ea6f04e</id>
<content type='text'>
[ Upstream commit 637822e63b79ee8a729f7ba2645a26cf5a524ee4 ]

During ufs system suspend, leaving rpm_dev_flush_recheck_work running or
pending is risky because concurrency may happen between system
suspend/resume and runtime resume routine. Fix this by cancelling
rpm_dev_flush_recheck_work synchronously during system suspend.

Link: https://lore.kernel.org/r/1619408921-30426-3-git-send-email-cang@codeaurora.org
Fixes: 51dd905bd2f6 ("scsi: ufs: Fix WriteBooster flush during runtime suspend")
Reviewed-by: Daejun Park &lt;daejun7.park@samsung.com&gt;
Signed-off-by: Can Guo &lt;cang@codeaurora.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: core: Do not put UFS power into LPM if link is broken</title>
<updated>2021-05-19T08:29:43+00:00</updated>
<author>
<name>Can Guo</name>
<email>cang@codeaurora.org</email>
</author>
<published>2021-04-26T03:48:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bd7e06d6d711bd22292d1caab1880e2636f67772'/>
<id>urn:sha1:bd7e06d6d711bd22292d1caab1880e2636f67772</id>
<content type='text'>
[ Upstream commit 23043dd87b153d02eaf676e752d32429be5e5126 ]

During resume, if link is broken due to AH8 failure, make sure
ufshcd_resume() does not put UFS power back into LPM.

Link: https://lore.kernel.org/r/1619408921-30426-2-git-send-email-cang@codeaurora.org
Fixes: 4db7a2360597 ("scsi: ufs: Fix concurrency of error handler and other error recovery paths")
Reviewed-by: Daejun Park &lt;daejun7.park@samsung.com&gt;
Signed-off-by: Can Guo &lt;cang@codeaurora.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: ufshcd-pltfrm: Fix deferred probing</title>
<updated>2021-05-14T08:49:57+00:00</updated>
<author>
<name>Sergey Shtylyov</name>
<email>s.shtylyov@omprussia.ru</email>
</author>
<published>2021-03-29T20:50:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bf75de10a269feda636ff793210855e5c0d6ec8a'/>
<id>urn:sha1:bf75de10a269feda636ff793210855e5c0d6ec8a</id>
<content type='text'>
[ Upstream commit 339c9b63cc7ce779ce45c675bf709cb58b807fc3 ]

The driver overrides the error codes returned by platform_get_irq() to
-ENODEV, so if it returns -EPROBE_DEFER, the driver would fail the probe
permanently instead of the deferred probing.  Propagate the error code
upstream as it should have been done from the start...

Link: https://lore.kernel.org/r/420364ca-614a-45e3-4e35-0e0653c7bc53@omprussia.ru
Fixes: 2953f850c3b8 ("[SCSI] ufs: use devres functions for ufshcd")
Signed-off-by: Sergey Shtylyov &lt;s.shtylyov@omprussia.ru&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: core: Fix wrong Task Tag used in task management request UPIUs</title>
<updated>2021-04-14T06:47:21+00:00</updated>
<author>
<name>Can Guo</name>
<email>cang@codeaurora.org</email>
</author>
<published>2021-04-01T07:39:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3b365c0d2c05ac535607f60eb08383c701201dc3'/>
<id>urn:sha1:3b365c0d2c05ac535607f60eb08383c701201dc3</id>
<content type='text'>
[ Upstream commit 4b42d557a8add52b9a9924fb31e40a218aab7801 ]

In __ufshcd_issue_tm_cmd(), it is not correct to use hba-&gt;nutrs + req-&gt;tag
as the Task Tag in a TMR UPIU. Directly use req-&gt;tag as the Task Tag.

Fixes: e293313262d3 ("scsi: ufs: Fix broken task management command implementation")
Link: https://lore.kernel.org/r/1617262750-4864-3-git-send-email-cang@codeaurora.org
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Can Guo &lt;cang@codeaurora.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: core: Fix task management request completion timeout</title>
<updated>2021-04-14T06:47:21+00:00</updated>
<author>
<name>Can Guo</name>
<email>cang@codeaurora.org</email>
</author>
<published>2021-04-01T07:39:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c00f57e62b9a0c339c85dbae84cfaa47648ef39'/>
<id>urn:sha1:4c00f57e62b9a0c339c85dbae84cfaa47648ef39</id>
<content type='text'>
[ Upstream commit 1235fc569e0bf541ddda0a1224d4c6fa6d914890 ]

ufshcd_tmc_handler() calls blk_mq_tagset_busy_iter(fn = ufshcd_compl_tm()),
but since blk_mq_tagset_busy_iter() only iterates over all reserved tags
and requests which are not in IDLE state, ufshcd_compl_tm() never gets a
chance to run. Thus, TMR always ends up with completion timeout. Fix it by
calling blk_mq_start_request() in __ufshcd_issue_tm_cmd().

Link: https://lore.kernel.org/r/1617262750-4864-2-git-send-email-cang@codeaurora.org
Fixes: 69a6c269c097 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs")
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Can Guo &lt;cang@codeaurora.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: ufs-qcom: Disable interrupt in reset path</title>
<updated>2021-03-30T12:30:07+00:00</updated>
<author>
<name>Nitin Rawat</name>
<email>nitirawa@codeaurora.org</email>
</author>
<published>2021-02-24T05:36:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fe39c84038b51627e91291eb3fda05e362efd93f'/>
<id>urn:sha1:fe39c84038b51627e91291eb3fda05e362efd93f</id>
<content type='text'>
[ Upstream commit 4a791574a0ccf36eb3a0a46fbd71d2768df3eef9 ]

Disable interrupt in reset path to flush pending IRQ handler in order to
avoid possible NoC issues.

Link: https://lore.kernel.org/r/1614145010-36079-3-git-send-email-cang@codeaurora.org
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Signed-off-by: Nitin Rawat &lt;nitirawa@codeaurora.org&gt;
Signed-off-by: Can Guo &lt;cang@codeaurora.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: ufs-mediatek: Correct operator &amp; -&gt; &amp;&amp;</title>
<updated>2021-03-24T10:54:08+00:00</updated>
<author>
<name>dongjian</name>
<email>dongjian@yulong.com</email>
</author>
<published>2021-03-16T12:15:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5551638dc7a5117470b61896df598375a49206ac'/>
<id>urn:sha1:5551638dc7a5117470b61896df598375a49206ac</id>
<content type='text'>
commit 0fdc7d5d8f3719950478cca452cf7f0f1355be10 upstream.

The "lpm" and "-&gt;enabled" are all boolean. We should be using &amp;&amp;
rather than the bit operator.

Link: https://lore.kernel.org/r/1615896915-148864-1-git-send-email-dj0227@163.com
Fixes: 488edafb1120 ("scsi: ufs-mediatek: Introduce low-power mode for device power supply")
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Signed-off-by: dongjian &lt;dongjian@yulong.com&gt;
Signed-off-by: Yue Hu &lt;huyue2@yulong.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: Protect some contexts from unexpected clock scaling</title>
<updated>2021-03-17T16:11:30+00:00</updated>
<author>
<name>Can Guo</name>
<email>cang@codeaurora.org</email>
</author>
<published>2021-01-20T10:04:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=69c732112b069c3fa8d8e5ee697d7a471be2c0fc'/>
<id>urn:sha1:69c732112b069c3fa8d8e5ee697d7a471be2c0fc</id>
<content type='text'>
[ Upstream commit 0e9d4ca43ba8112821397f56a26d20682001c011 ]

In contexts like suspend, shutdown, and error handling we need to
suspend devfreq to make sure these contexts won't be disturbed by
clock scaling.  However, suspending devfreq is not enough since users
can still trigger a clock scaling by manipulating the devfreq sysfs
nodes like min/max_freq and governor even after devfreq is
suspended. Moreover, mere suspending devfreq cannot synchroinze a
clock scaling which has already been invoked through these sysfs
nodes. Add one more flag in struct clk_scaling and wrap the entire
func ufshcd_devfreq_scale() with the clk_scaling_lock, so that we can
use this flag and clk_scaling_lock to control and synchronize clock
scaling invoked through devfreq sysfs nodes.

Link: https://lore.kernel.org/r/1611137065-14266-2-git-send-email-cang@codeaurora.org
Reviewed-by: Stanley Chu &lt;stanley.chu@mediatek.com&gt;
Signed-off-by: Can Guo &lt;cang@codeaurora.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: WB is only available on LUN #0 to #7</title>
<updated>2021-03-17T16:11:30+00:00</updated>
<author>
<name>Jaegeuk Kim</name>
<email>jaegeuk@kernel.org</email>
</author>
<published>2021-01-11T09:59:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a35887ef14630fa3eaef600fa35aab217b19a45d'/>
<id>urn:sha1:a35887ef14630fa3eaef600fa35aab217b19a45d</id>
<content type='text'>
[ Upstream commit a2fca52ee640a04112ed9d9a137c940ea6ad288e ]

Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units from
rpmb LUN. The reason is that the unit descriptor length is different per
LU.

The length of Normal LU is 45 while the one of rpmb LU is 35.

int ufshcd_read_desc_param(struct ufs_hba *hba, ...)
{
	param_offset=41;
	param_size=4;
	buff_len=45;
	...
	buff_len=35 by rpmb LU;

	if (is_kmalloc) {
		/* Make sure we don't copy more data than available */
		if (param_offset + param_size &gt; buff_len)
			param_size = buff_len - param_offset;
			--&gt; param_size = 250;
		memcpy(param_read_buf, &amp;desc_buf[param_offset], param_size);
		--&gt; memcpy(param_read_buf, desc_buf+41, 250);

[  141.868974][ T9174] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: wb_buf_alloc_units_show+0x11c/0x11c
	}
}

Link: https://lore.kernel.org/r/20210111095927.1830311-1-jaegeuk@kernel.org
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Signed-off-by: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
