linux-stable.git/drivers, branch v5.13.2 Linux kernel stable tree iommu/dma: Fix compile warning in 32-bit builds 2021-07-14T15:07:52+00:00 Joerg Roedel jroedel@suse.de 2021-06-07T12:49:05+00:00 51189a3c6e5417491382e7c5b58d9ff126c2e193 commit 7154cbd31c2069726cf730b0ed94e2e79a221602 upstream. Compiling the recent dma-iommu changes under 32-bit x86 triggers this compile warning: drivers/iommu/dma-iommu.c:249:5: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ {aka ‘unsigned int’} [-Wformat=] The reason is that %llx is used to print a variable of type phys_addr_t. Fix it by using the correct %pa format specifier for phys_addr_t. Cc: Srinath Mannam <srinath.mannam@broadcom.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Oza Pawandeep <poza@codeaurora.org> Fixes: 571f316074a20 ("iommu/dma: Fix IOVA reserve dma ranges") Signed-off-by: Joerg Roedel <jroedel@suse.de> Link: https://lore.kernel.org/r/20210607124905.27525-1-joro@8bytes.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7154cbd31c2069726cf730b0ed94e2e79a221602 upstream.

Compiling the recent dma-iommu changes under 32-bit x86 triggers this
compile warning:

drivers/iommu/dma-iommu.c:249:5: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ {aka ‘unsigned int’} [-Wformat=]

The reason is that %llx is used to print a variable of type
phys_addr_t. Fix it by using the correct %pa format specifier for
phys_addr_t.

Cc: Srinath Mannam <srinath.mannam@broadcom.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Oza Pawandeep <poza@codeaurora.org>
Fixes: 571f316074a20 ("iommu/dma: Fix IOVA reserve dma ranges")
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20210607124905.27525-1-joro@8bytes.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
crypto: qce - fix error return code in qce_skcipher_async_req_handle() 2021-07-14T15:07:51+00:00 Wei Yongjun weiyongjun1@huawei.com 2021-06-02T11:36:45+00:00 fbbd050e05d10035293a080dc70c303caa9263d7 commit a8bc4f5e7a72e4067f5afd7e98b61624231713ca upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 1339a7c3ba05 ("crypto: qce: skcipher: Fix incorrect sg count for dma transfers") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a8bc4f5e7a72e4067f5afd7e98b61624231713ca upstream.

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 1339a7c3ba05 ("crypto: qce: skcipher: Fix incorrect sg count for dma transfers")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Thara Gopinath <thara.gopinath@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scsi: core: Retry I/O for Notify (Enable Spinup) Required error 2021-07-14T15:07:51+00:00 Quat Le quat.le@oracle.com 2021-06-29T15:58:26+00:00 bd619678f6745c714ff490989037ccf2554ca7b1 commit 104739aca4488909175e9e31d5cd7d75b82a2046 upstream. If the device is power-cycled, it takes time for the initiator to transmit the periodic NOTIFY (ENABLE SPINUP) SAS primitive, and for the device to respond to the primitive to become ACTIVE. Retry the I/O request to allow the device time to become ACTIVE. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210629155826.48441-1-quat.le@oracle.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Quat Le <quat.le@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 104739aca4488909175e9e31d5cd7d75b82a2046 upstream.

If the device is power-cycled, it takes time for the initiator to transmit
the periodic NOTIFY (ENABLE SPINUP) SAS primitive, and for the device to
respond to the primitive to become ACTIVE. Retry the I/O request to allow
the device time to become ACTIVE.

Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210629155826.48441-1-quat.le@oracle.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Quat Le <quat.le@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: exynos4-is: remove a now unused integer 2021-07-14T15:07:51+00:00 Mauro Carvalho Chehab mchehab+huawei@kernel.org 2021-05-11T15:03:21+00:00 d7c62923708bca62d5a4a5dfc6b2c330b985f75e commit 29dd19e3ac7b2a8671ebeac02859232ce0e34f58 upstream. The usage of pm_runtime_resume_and_get() removed the need of a temporary integer. So, drop it. Fixes: 59f96244af94 ("media: exynos4-is: fix pm_runtime_get_sync() usage count") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 29dd19e3ac7b2a8671ebeac02859232ce0e34f58 upstream.

The usage of pm_runtime_resume_and_get() removed the need of a
temporary integer. So, drop it.

Fixes: 59f96244af94 ("media: exynos4-is: fix pm_runtime_get_sync() usage count")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: vub3000: fix control-request direction 2021-07-14T15:07:51+00:00 Johan Hovold johan@kernel.org 2021-05-21T13:30:26+00:00 8d3433ec89ccd6f7bc3e994ebd5181351a575b5c commit 3c0bb3107703d2c58f7a0a7a2060bb57bc120326 upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the SET_ROM_WAIT_STATES request which erroneously used usb_rcvctrlpipe(). Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") Cc: stable@vger.kernel.org # 3.0 Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210521133026.17296-1-johan@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3c0bb3107703d2c58f7a0a7a2060bb57bc120326 upstream.

The direction of the pipe argument must match the request-type direction
bit or control requests may fail depending on the host-controller-driver
implementation.

Fix the SET_ROM_WAIT_STATES request which erroneously used
usb_rcvctrlpipe().

Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
Cc: stable@vger.kernel.org      # 3.0
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210521133026.17296-1-johan@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: block: Disable CMDQ on the ioctl path 2021-07-14T15:07:51+00:00 Bean Huo beanhuo@micron.com 2021-05-04T20:32:09+00:00 165d6c32f8d070addb3057be8b3491e11db7307a commit 70b52f09080565030a530a784f1c9948a7f48ca3 upstream. According to the eMMC Spec: "When command queuing is enabled (CMDQ Mode En bit in CMDQ_MODE_EN field is set to ‘1’) class 11 commands are the only method through which data transfer tasks can be issued. Existing data transfer commands, namely CMD18/CMD17 and CMD25/CMD24, are not supported when command queuing is enabled." which means if CMDQ is enabled, the FFU commands will not be supported. To fix this issue, just simply disable CMDQ on the ioctl path, and re-enable CMDQ once ioctl request is completed. Tested-by: Michael Brunner <Michael.Brunner@kontron.com> Signed-off-by: Bean Huo <beanhuo@micron.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: 1e8e55b67030 (mmc: block: Add CQE support) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210504203209.361597-1-huobean@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 70b52f09080565030a530a784f1c9948a7f48ca3 upstream.

According to the eMMC Spec:
"When command queuing is enabled (CMDQ Mode En bit in CMDQ_MODE_EN
field is set to ‘1’) class 11 commands are the only method through
which data transfer tasks can be issued. Existing data transfer
commands, namely CMD18/CMD17 and CMD25/CMD24, are not supported when
command queuing is enabled."
which means if CMDQ is enabled, the FFU commands will not be supported.
To fix this issue, just simply disable CMDQ on the ioctl path, and
re-enable CMDQ once ioctl request is completed.

Tested-by: Michael Brunner <Michael.Brunner@kontron.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 1e8e55b67030 (mmc: block: Add CQE support)
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210504203209.361597-1-huobean@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tpm: Replace WARN_ONCE() with dev_err_once() in tpm_tis_status() 2021-07-14T15:07:50+00:00 Jarkko Sakkinen jarkko@kernel.org 2021-06-09T13:26:19+00:00 9d2da0b8863a207c2f3d8a97b2b038ea8c6592b1 commit 0178f9d0f60ba07e09bab57381a3ef18e2c1fd7f upstream. Do not tear down the system when getting invalid status from a TPM chip. This can happen when panic-on-warn is used. Instead, introduce TPM_TIS_INVALID_STATUS bitflag and use it to trigger once the error reporting per chip. In addition, print out the value of TPM_STS for improved forensics. Link: https://lore.kernel.org/keyrings/YKzlTR1AzUigShtZ@kroah.com/ Fixes: 55707d531af6 ("tpm_tis: Add a check for invalid status") Cc: stable@vger.kernel.org Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 0178f9d0f60ba07e09bab57381a3ef18e2c1fd7f upstream.

Do not tear down the system when getting invalid status from a TPM chip.
This can happen when panic-on-warn is used.

Instead, introduce TPM_TIS_INVALID_STATUS bitflag and use it to trigger
once the error reporting per chip. In addition, print out the value of
TPM_STS for improved forensics.

Link: https://lore.kernel.org/keyrings/YKzlTR1AzUigShtZ@kroah.com/
Fixes: 55707d531af6 ("tpm_tis: Add a check for invalid status")
Cc: stable@vger.kernel.org
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mailbox: qcom-ipcc: Fix IPCC mbox channel exhaustion 2021-07-14T15:07:49+00:00 Sibi Sankar sibis@codeaurora.org 2021-06-16T17:42:58+00:00 2f2d7dc088c37ffa857fd83d13ac27eda74b5fc5 commit d6fbfdbc12745ce24bcd348dbf7e652353b3e59c upstream. Fix IPCC (Inter-Processor Communication Controller) channel exhaustion by setting the channel private data to NULL on mbox shutdown. Err Logs: remoteproc: MBA booted without debug policy, loading mpss remoteproc: glink-edge: failed to acquire IPC channel remoteproc: failed to probe subdevices for remoteproc: -16 Fixes: fa74a0257f45 ("mailbox: Add support for Qualcomm IPCC") Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Cc: stable@vger.kernel.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d6fbfdbc12745ce24bcd348dbf7e652353b3e59c upstream.

Fix IPCC (Inter-Processor Communication Controller) channel exhaustion by
setting the channel private data to NULL on mbox shutdown.

Err Logs:
remoteproc: MBA booted without debug policy, loading mpss
remoteproc: glink-edge: failed to acquire IPC channel
remoteproc: failed to probe subdevices for remoteproc: -16

Fixes: fa74a0257f45 ("mailbox: Add support for Qualcomm IPCC")
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Cc: stable@vger.kernel.org
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scsi: libfc: Correct the condition check and invalid argument passed 2021-07-14T15:07:49+00:00 Javed Hasan jhasan@marvell.com 2021-06-03T10:14:04+00:00 610de611adaeea765857985f72278e58f7fe061b commit 8f70328c068f9f5c5db82848724cb276f657b9cd upstream. Incorrect condition check was leading to data corruption. Link: https://lore.kernel.org/r/20210603101404.7841-3-jhasan@marvell.com Fixes: 8fd9efca86d0 ("scsi: libfc: Work around -Warray-bounds warning") CC: stable@vger.kernel.org Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Javed Hasan <jhasan@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8f70328c068f9f5c5db82848724cb276f657b9cd upstream.

Incorrect condition check was leading to data corruption.

Link: https://lore.kernel.org/r/20210603101404.7841-3-jhasan@marvell.com
Fixes: 8fd9efca86d0 ("scsi: libfc: Work around -Warray-bounds warning")
CC: stable@vger.kernel.org
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Javed Hasan <jhasan@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scsi: lpfc: Fix Node recovery when driver is handling simultaneous PLOGIs 2021-07-14T15:07:49+00:00 James Smart jsmart2021@gmail.com 2021-05-14T19:55:53+00:00 17902d3eb4ddba18ff807c0c5bff38bb2a824d8e commit 4012baeab6ca22b7f7beb121b6d0da0a62942fdd upstream. When lpfc is handling a solicited and unsolicited PLOGI with another initiator, the remote initiator is never recovered. The node for the initiator is erroneouosly removed and all resources released. In lpfc_cmpl_els_plogi(), when lpfc_els_retry() returns a failure code, the driver is calling the state machine with a device remove event because the remote port is not currently registered with the SCSI or NVMe transports. The issue is that on a PLOGI "collision" the driver correctly aborts the solicited PLOGI and allows the unsolicited PLOGI to complete the process, but this process is interrupted with a device_rm event. Introduce logic in the PLOGI completion to capture the PLOGI collision event and jump out of the routine. This will avoid removal of the node. If there is no collision, the normal node removal will occur. Fixes: 52edb2caf675 ("scsi: lpfc: Remove ndlp when a PLOGI/ADISC/PRLI/REG_RPI ultimately fails") Cc: <stable@vger.kernel.org> # v5.11+ Link: https://lore.kernel.org/r/20210514195559.119853-6-jsmart2021@gmail.com Co-developed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4012baeab6ca22b7f7beb121b6d0da0a62942fdd upstream.

When lpfc is handling a solicited and unsolicited PLOGI with another
initiator, the remote initiator is never recovered. The node for the
initiator is erroneouosly removed and all resources released.

In lpfc_cmpl_els_plogi(), when lpfc_els_retry() returns a failure code, the
driver is calling the state machine with a device remove event because the
remote port is not currently registered with the SCSI or NVMe
transports. The issue is that on a PLOGI "collision" the driver correctly
aborts the solicited PLOGI and allows the unsolicited PLOGI to complete the
process, but this process is interrupted with a device_rm event.

Introduce logic in the PLOGI completion to capture the PLOGI collision
event and jump out of the routine.  This will avoid removal of the node.
If there is no collision, the normal node removal will occur.

Fixes: 	52edb2caf675 ("scsi: lpfc: Remove ndlp when a PLOGI/ADISC/PRLI/REG_RPI ultimately fails")
Cc: <stable@vger.kernel.org> # v5.11+
Link: https://lore.kernel.org/r/20210514195559.119853-6-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>