<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/scsi, branch v4.14.217</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.217</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.217'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-01-12T19:09:05+00:00</updated>
<entry>
<title>scsi: ufs-pci: Ensure UFS device is in PowerDown mode for suspend-to-disk -&gt;poweroff()</title>
<updated>2021-01-12T19:09:05+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2020-12-07T08:31:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b2980ba3de656de3df185c9a47d99789aabc974b'/>
<id>urn:sha1:b2980ba3de656de3df185c9a47d99789aabc974b</id>
<content type='text'>
[ Upstream commit af423534d2de86cd0db729a5ac41f056ca8717de ]

The expectation for suspend-to-disk is that devices will be powered-off, so
the UFS device should be put in PowerDown mode. If spm_lvl is not 5, then
that will not happen. Change the pm callbacks to force spm_lvl 5 for
suspend-to-disk poweroff.

Link: https://lore.kernel.org/r/20201207083120.26732-3-adrian.hunter@intel.com
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&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: fnic: Fix error return code in fnic_probe()</title>
<updated>2020-12-29T12:47:00+00:00</updated>
<author>
<name>Zhang Changzhong</name>
<email>zhangchangzhong@huawei.com</email>
</author>
<published>2020-12-04T07:47:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ee7c2a9d451e13680144e91634b45787b6f7373d'/>
<id>urn:sha1:ee7c2a9d451e13680144e91634b45787b6f7373d</id>
<content type='text'>
[ Upstream commit d4fc94fe65578738ded138e9fce043db6bfc3241 ]

Return a negative error code from the error handling case instead of 0 as
done elsewhere in this function.

Link: https://lore.kernel.org/r/1607068060-31203-1-git-send-email-zhangchangzhong@huawei.com
Fixes: 5df6d737dd4b ("[SCSI] fnic: Add new Cisco PCI-Express FCoE HBA")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Reviewed-by: Karan Tilak Kumar &lt;kartilak@cisco.com&gt;
Signed-off-by: Zhang Changzhong &lt;zhangchangzhong@huawei.com&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: pm80xx: Fix error return in pm8001_pci_probe()</title>
<updated>2020-12-29T12:46:59+00:00</updated>
<author>
<name>Zhang Qilong</name>
<email>zhangqilong3@huawei.com</email>
</author>
<published>2020-12-05T11:55:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bd9f0b38718ab2116d906c466f3b9151a009cb94'/>
<id>urn:sha1:bd9f0b38718ab2116d906c466f3b9151a009cb94</id>
<content type='text'>
[ Upstream commit 97031ccffa4f62728602bfea8439dd045cd3aeb2 ]

The driver did not return an error in the case where
pm8001_configure_phy_settings() failed.

Use rc to store the return value of pm8001_configure_phy_settings().

Link: https://lore.kernel.org/r/20201205115551.2079471-1-zhangqilong3@huawei.com
Fixes: 279094079a44 ("[SCSI] pm80xx: Phy settings support for motherboard controller.")
Acked-by: Jack Wang &lt;jinpu.wang@cloud.ionos.com&gt;
Signed-off-by: Zhang Qilong &lt;zhangqilong3@huawei.com&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: qedi: Fix missing destroy_workqueue() on error in __qedi_probe</title>
<updated>2020-12-29T12:46:59+00:00</updated>
<author>
<name>Qinglang Miao</name>
<email>miaoqinglang@huawei.com</email>
</author>
<published>2020-11-09T09:15:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=00fc83950a1d80a02414b0b6cb7e1798ac44da4e'/>
<id>urn:sha1:00fc83950a1d80a02414b0b6cb7e1798ac44da4e</id>
<content type='text'>
[ Upstream commit 62eebd5247c4e4ce08826ad5995cf4dd7ce919dd ]

Add the missing destroy_workqueue() before return from __qedi_probe in the
error handling case when fails to create workqueue qedi-&gt;offload_thread.

Link: https://lore.kernel.org/r/20201109091518.55941-1-miaoqinglang@huawei.com
Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.")
Reviewed-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Qinglang Miao &lt;miaoqinglang@huawei.com&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: core: Fix VPD LUN ID designator priorities</title>
<updated>2020-12-29T12:46:53+00:00</updated>
<author>
<name>Martin Wilck</name>
<email>mwilck@suse.com</email>
</author>
<published>2020-10-29T17:08:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29f360c2807e9a27ea6da3453b16770dbf54bf8e'/>
<id>urn:sha1:29f360c2807e9a27ea6da3453b16770dbf54bf8e</id>
<content type='text'>
[ Upstream commit 2e4209b3806cda9b89c30fd5e7bfecb7044ec78b ]

The current implementation of scsi_vpd_lun_id() uses the designator length
as an implicit measure of priority. This works most of the time, but not
always. For example, some Hitachi storage arrays return this in VPD 0x83:

VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 24
    designator_type: T10 vendor identification,  code_set: ASCII
    associated with the Addressed logical unit
      vendor id: HITACHI
      vendor specific: 5030C3502025
  Designation descriptor number 2, descriptor length: 6
    designator_type: vendor specific [0x0],  code_set: Binary
    associated with the Target port
      vendor specific: 08 03
  Designation descriptor number 3, descriptor length: 20
    designator_type: NAA,  code_set: Binary
    associated with the Addressed logical unit
      NAA 6, IEEE Company_id: 0x60e8
      Vendor Specific Identifier: 0x7c35000
      Vendor Specific Identifier Extension: 0x30c35000002025
      [0x60060e8007c350000030c35000002025]

The current code would use the first descriptor because it's longer than
the NAA descriptor. But this is wrong, the kernel is supposed to prefer NAA
descriptors over T10 vendor ID. Designator length should only be used to
compare designators of the same type.

This patch addresses the issue by separating designator priority and
length.

Link: https://lore.kernel.org/r/20201029170846.14786-1-mwilck@suse.com
Fixes: 9983bed3907c ("scsi: Add scsi_vpd_lun_id()")
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Martin Wilck &lt;mwilck@suse.com&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: mpt3sas: Increase IOCInit request timeout to 30s</title>
<updated>2020-12-29T12:46:48+00:00</updated>
<author>
<name>Sreekanth Reddy</name>
<email>sreekanth.reddy@broadcom.com</email>
</author>
<published>2020-11-30T08:27:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b3c6894d18da3975267cf9da8fa7d67af3ff7f41'/>
<id>urn:sha1:b3c6894d18da3975267cf9da8fa7d67af3ff7f41</id>
<content type='text'>
[ Upstream commit 85dad327d9b58b4c9ce08189a2707167de392d23 ]

Currently the IOCInit request message timeout is set to 10s. This is not
sufficient in some scenarios such as during HBA FW downgrade operations.

Increase the IOCInit request timeout to 30s.

Link: https://lore.kernel.org/r/20201130082733.26120-1-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy &lt;sreekanth.reddy@broadcom.com&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: bnx2i: Requires MMU</title>
<updated>2020-12-29T12:46:47+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2020-11-29T07:09:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e851f16a2d741179b63b4e011b260861a3672c63'/>
<id>urn:sha1:e851f16a2d741179b63b4e011b260861a3672c63</id>
<content type='text'>
[ Upstream commit 2d586494c4a001312650f0b919d534e429dd1e09 ]

The SCSI_BNX2_ISCSI kconfig symbol selects CNIC and CNIC selects UIO, which
depends on MMU.

Since 'select' does not follow dependency chains, add the same MMU
dependency to SCSI_BNX2_ISCSI.

Quietens this kconfig warning:

WARNING: unmet direct dependencies detected for CNIC
  Depends on [n]: NETDEVICES [=y] &amp;&amp; ETHERNET [=y] &amp;&amp; NET_VENDOR_BROADCOM [=y] &amp;&amp; PCI [=y] &amp;&amp; (IPV6 [=m] || IPV6 [=m]=n) &amp;&amp; MMU [=n]
  Selected by [m]:
  - SCSI_BNX2_ISCSI [=m] &amp;&amp; SCSI_LOWLEVEL [=y] &amp;&amp; SCSI [=y] &amp;&amp; NET [=y] &amp;&amp; PCI [=y] &amp;&amp; (IPV6 [=m] || IPV6 [=m]=n)

Link: https://lore.kernel.org/r/20201129070916.3919-1-rdunlap@infradead.org
Fixes: cf4e6363859d ("[SCSI] bnx2i: Add bnx2i iSCSI driver.")
Cc: linux-scsi@vger.kernel.org
Cc: Nilesh Javali &lt;njavali@marvell.com&gt;
Cc: Manish Rangankar &lt;mrangankar@marvell.com&gt;
Cc: GR-QLogic-Storage-Upstream@marvell.com
Cc: "James E.J. Bottomley" &lt;jejb@linux.ibm.com&gt;
Cc: "Martin K. Petersen" &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.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: be2iscsi: Revert "Fix a theoretical leak in beiscsi_create_eqs()"</title>
<updated>2020-12-29T12:46:44+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-12-03T12:18:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bb4ee532e955c8d3c66e57ce5dd72027994664bd'/>
<id>urn:sha1:bb4ee532e955c8d3c66e57ce5dd72027994664bd</id>
<content type='text'>
commit eeaf06af6f87e1dba371fbe42674e6f963220b9c upstream.

My patch caused kernel Oopses and delays in boot.  Revert it.

The problem was that I moved the "mem-&gt;dma = paddr;" before the call to
be_fill_queue().  But the first thing that the be_fill_queue() function
does is memset the whole struct to zero which overwrites the assignment.

Link: https://lore.kernel.org/r/X8jXkt6eThjyVP1v@mwanda
Fixes: 38b2db564d9a ("scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()")
Cc: stable &lt;stable@vger.kernel.org&gt;
Reported-by: Thomas Lamprecht &lt;t.lamprecht@proxmox.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.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: Make sure clk scaling happens only when HBA is runtime ACTIVE</title>
<updated>2020-12-29T12:46:43+00:00</updated>
<author>
<name>Can Guo</name>
<email>cang@codeaurora.org</email>
</author>
<published>2020-09-22T07:09:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29ad0fa9733c27f8497d16fd4fa003f13ec751df'/>
<id>urn:sha1:29ad0fa9733c27f8497d16fd4fa003f13ec751df</id>
<content type='text'>
[ Upstream commit 73cc291c270248567245f084dcdf5078069af6b5 ]

If someone plays with the UFS clk scaling devfreq governor through sysfs,
ufshcd_devfreq_scale may be called even when HBA is not runtime ACTIVE.
This can lead to unexpected error. We cannot just protect it by calling
pm_runtime_get_sync() because that may cause a race condition since HBA
runtime suspend ops need to suspend clk scaling. To fix this call
pm_runtime_get_noresume() and check HBA's runtime status. Only proceed if
HBA is runtime ACTIVE, otherwise just bail.

governor_store
 devfreq_performance_handler
  update_devfreq
   devfreq_set_target
    ufshcd_devfreq_target
     ufshcd_devfreq_scale

Link: https://lore.kernel.org/r/1600758548-28576-1-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: Fix race between shutdown and runtime resume flow</title>
<updated>2020-12-02T07:34:42+00:00</updated>
<author>
<name>Stanley Chu</name>
<email>stanley.chu@mediatek.com</email>
</author>
<published>2020-11-19T06:29:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8541087975223fa664c1e1fb263e8446509ef725'/>
<id>urn:sha1:8541087975223fa664c1e1fb263e8446509ef725</id>
<content type='text'>
[ Upstream commit e92643db514803c2c87d72caf5950b4c0a8faf4a ]

If UFS host device is in runtime-suspended state while UFS shutdown
callback is invoked, UFS device shall be resumed for register
accesses. Currently only UFS local runtime resume function will be invoked
to wake up the host.  This is not enough because if someone triggers
runtime resume from block layer, then race may happen between shutdown and
runtime resume flow, and finally lead to unlocked register access.

To fix this, in ufshcd_shutdown(), use pm_runtime_get_sync() instead of
resuming UFS device by ufshcd_runtime_resume() "internally" to let runtime
PM framework manage the whole resume flow.

Link: https://lore.kernel.org/r/20201119062916.12931-1-stanley.chu@mediatek.com
Fixes: 57d104c153d3 ("ufs: add UFS power management support")
Reviewed-by: Can Guo &lt;cang@codeaurora.org&gt;
Signed-off-by: Stanley Chu &lt;stanley.chu@mediatek.com&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>
