IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Pull SCSI updates from James Bottomley:
"The usual driver updates (ufs, qla2xxx, tcmu, ibmvfc, lpfc, smartpqi,
hisi_sas, qedi, qedf, mpt3sas) and minor bug fixes.
There are only three core changes: adding sense codes, cleaning up
noretry and adding an option for limitless retries"
* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (226 commits)
scsi: hisi_sas: Recover PHY state according to the status before reset
scsi: hisi_sas: Filter out new PHY up events during suspend
scsi: hisi_sas: Add device link between SCSI devices and hisi_hba
scsi: hisi_sas: Add check for methods _PS0 and _PR0
scsi: hisi_sas: Add controller runtime PM support for v3 hw
scsi: hisi_sas: Switch to new framework to support suspend and resume
scsi: hisi_sas: Use hisi_hba->cq_nvecs for calling calling synchronize_irq()
scsi: qedf: Remove redundant assignment to variable 'rc'
scsi: lpfc: Remove unneeded variable 'status' in lpfc_fcp_cpu_map_store()
scsi: snic: Convert to use DEFINE_SEQ_ATTRIBUTE macro
scsi: qla4xxx: Delete unneeded variable 'status' in qla4xxx_process_ddb_changed
scsi: sun_esp: Use module_platform_driver to simplify the code
scsi: sun3x_esp: Use module_platform_driver to simplify the code
scsi: sni_53c710: Use module_platform_driver to simplify the code
scsi: qlogicpti: Use module_platform_driver to simplify the code
scsi: mac_esp: Use module_platform_driver to simplify the code
scsi: jazz_esp: Use module_platform_driver to simplify the code
scsi: mvumi: Fix error return in mvumi_io_attach()
scsi: lpfc: Drop nodelist reference on error in lpfc_gen_req()
scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()
...
For older versions of gcc, the array = {0}; will cause warnings:
drivers/scsi/ufs/ufshcd-crypto.c: In function 'ufshcd_crypto_keyslot_program':
drivers/scsi/ufs/ufshcd-crypto.c:62:8: warning: missing braces around initializer [-Wmissing-braces]
union ufs_crypto_cfg_entry cfg = { 0 };
^
drivers/scsi/ufs/ufshcd-crypto.c:62:8: warning: (near initialization for 'cfg.reg_val') [-Wmissing-braces]
drivers/scsi/ufs/ufshcd-crypto.c: In function 'ufshcd_clear_keyslot':
drivers/scsi/ufs/ufshcd-crypto.c:103:8: warning: missing braces around initializer [-Wmissing-braces]
union ufs_crypto_cfg_entry cfg = { 0 };
^
2 warnings generated
Link: https://lore.kernel.org/r/20201002063538.1250-1-shipujin.t@gmail.com
Fixes: 70297a8ac7 ("scsi: ufs: UFS crypto API")
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Pujin Shi <shipujin.t@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some MediaTek UFS platforms support high-performance mode that inline
encryption engine can be boosted while UFS is not clock-gated.
The high-performance mode will be enabled if all below conditions are
well-declaired in device tree,
- Proper platform-specific compatible string which enables the host
capability "UFS_MTK_CAP_BOOST_CRYPT_ENGINE".
- "dvfsrc-vcore" node is available in this platform.
- Required minimum vcore voltage for high-performance mode.
- Clock mux and clock parents of inline encryption engine for both
"low-power mode" and "high-performance mode".
Link: https://lore.kernel.org/r/20200914050052.3974-2-stanley.chu@mediatek.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Boot occasionally fails with some Samsung low-power UFS devices. The reason
is that these devices have a little bit higher latency for NOP OUT
responses. This causes boot to fail because the NOP OUT command is issued
during initialization to check whether the device transport protocol is
ready or not. Increase NOP_OUT_TIMEOUT value from 30 to 50ms.
Link: https://lore.kernel.org/r/231786897.01599016081767.JavaMail.epsvc@epcpadp2
Acked-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Daejun Park <daejun7.park@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
With !CONFIG_OF and SCSI_UFS_EXYNOS selected, the below warning is given:
WARNING: unmet direct dependencies detected for PHY_SAMSUNG_UFS
Depends on [n]: OF [=n] && (ARCH_EXYNOS || COMPILE_TEST [=y])
Selected by [y]:
- SCSI_UFS_EXYNOS [=y] && SCSI_LOWLEVEL [=y] && SCSI [=y] && SCSI_UFSHCD_PLATFORM [=y] && (ARCH_EXYNOS || COMPILE_TEST [=y])
Fix it by removing PHY_SAMSUNG_UFS dependency.
Link: https://lore.kernel.org/r/20200721172021.28922-1-alim.akhtar@samsung.com
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Fix build warnings with make W=1 as below,
1.
>> drivers/scsi/ufs/ufs-mediatek.c:116:22: warning: format '%d' expects
>> argument of type 'int', but argument 4 has type 'long int'
2.
CC [M] drivers/scsi/ufs/ufs-mediatek.o
../drivers/scsi/ufs/ufs-mediatek.c:749: error: Cannot parse struct or union!
/** is used specifically with kernel-doc tool.
As a quick fix by removing dubious /** in the comment block of
struct ufs_hba_variant_ops ufs_hba_mtk_vops.
Link: https://lore.kernel.org/r/20200910013756.11385-1-stanley.chu@mediatek.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
PA Layer issues a LINERESET to the PHY at the recovery step in the Power
Mode change operation. If it happens during auto or manual hibern8 enter,
even if hibern8 enter succeeds, UFS power mode shall be set to PWM-G1 mode
and kept in that mode after exit from hibern8, leading to bad performance.
Handle the LINERESET in the eh_work by restoring power mode to HS mode
after all pending reqs and tasks are cleared from doorbell.
Link: https://lore.kernel.org/r/1598321228-21093-3-git-send-email-cang@codeaurora.org
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
To recover non-fatal errors, no full reset is required, err_handler only
clears those pending TRs/TMRs so that SCSI layer can re-issue them. In
current err_handler, TRs are directly cleared from UFS host's doorbell but
not aborted from device side. However, according to the UFSHCI JEDEC spec,
the host software shall use UTP Transfer Request List Clear Register to
clear a task from UFS host's doorbell only when a UTP Transfer Request is
expected to not be completed, e.g. when the host software receives a
“FUNCTION COMPLETE” Task Management response which means a Transfer Request
was aborted. To follow the UFSHCI JEDEC spec, in err_handler, abort one TR
before clearing it from doorbell.
Link: https://lore.kernel.org/r/1598321228-21093-2-git-send-email-cang@codeaurora.org
Acked-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
We have two knobs to control flush for write booster,
fWriteBoosterBufferFlushDuringHibernate and fWriteBoosterBufferFlushEn.
Some vendors use only fWriteBoosterBufferFlushDuringHibernate because this
can reportedly cover most scenarios. Also, there have been some reports
that flush by fWriteBoosterBufferFlushEn could lead to increased power
consumption thanks to unexpected internal operations. Consequently, we need
a way to enable or disable fWriteBoosterEn operations. Add quirk to bypass
manual flush.
Link: https://lore.kernel.org/r/ffdb0eda30515809f0ad9ee936b26917ee9b4593.1598319701.git.kwmad.kim@samsung.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
MSM bus scaling has moved on to use interconnect framework and downstream
bus scaling APIs like msm_bus_scale*() do not exist anymore in the
kernel. Currently they are guarded by a config which also does not exist
and hence there are no build failures reported. Remove these unused
interfaces as they are currently no-ops and the scaling support that may be
added in future will use interconnect API.
Link: https://lore.kernel.org/r/20200804161033.15586-1-saiprakash.ranjan@codeaurora.org
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In current UFS task abort hook, namely ufshcd_abort(), if one task is
aborted successfully, clk_gating.active_reqs held by this task is not
decreased, which makes clk_gating.active_reqs stay above zero forever, thus
clock gating would never happen. Instead of releasing resources of one task
"manually", use the existing func __ufshcd_transfer_req_compl(). This
change also eliminates a possible race of scsi_dma_unmap() from the real
completion in IRQ handler path.
Link: https://lore.kernel.org/r/1596975355-39813-10-git-send-email-cang@codeaurora.org
Fixes: 1ab27c9cf8 ("ufs: Add support for clock gating")
CC: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If somehow no interrupt notification is raised for a completed request and
its doorbell bit is cleared by host, UFS driver needs to cleanup its
outstanding bit in ufshcd_abort(). Otherwise, system may behave abnormally
in the following scenario:
After ufshcd_abort() returns, this request will be requeued by SCSI layer
with its outstanding bit set. Any future completed request will trigger
ufshcd_transfer_req_compl() to handle all "completed outstanding bits". At
this time the "abnormal outstanding bit" will be detected and the "requeued
request" will be chosen to execute request post-processing flow. This is
wrong because this request is still "alive".
Link: https://lore.kernel.org/r/20200811141859.27399-2-huobean@gmail.com
Reviewed-by: Can Guo <cang@codeaurora.org>
Acked-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In ufshcd_suspend(), after clk-gating is suspended and link is set
as Hibern8 state, ufshcd_hold() is still possibly invoked before
ufshcd_suspend() returns. For example, MediaTek's suspend vops may
issue UIC commands which would call ufshcd_hold() during the command
issuing flow.
Now if UFSHCD_CAP_HIBERN8_WITH_CLK_GATING capability is enabled,
then ufshcd_hold() may enter infinite loops because there is no
clk-ungating work scheduled or pending. In this case, ufshcd_hold()
shall just bypass, and keep the link as Hibern8 state.
Link: https://lore.kernel.org/r/20200809050734.18740-1-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Co-developed-by: Andy Teng <andy.teng@mediatek.com>
Signed-off-by: Andy Teng <andy.teng@mediatek.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The current IRQ handler blocks SCSI requests before scheduling eh_work,
when error handler calls pm_runtime_get_sync, if ufshcd_suspend/resume
sends a SCSI cmd, most likely the SSU cmd, since SCSI requests are blocked,
pm_runtime_get_sync() will never return because ufshcd_suspend/resume is
blocked by the SCSI cmd.
- In queuecommand path, hba->ufshcd_state check and ufshcd_send_command
should stay under the same spin lock. This is to make sure that no more
commands leak into doorbell after hba->ufshcd_state is changed.
- Don't block SCSI requests before error handler starts to run, let error
handler block SCSI requests when it is ready to start error recovery.
- Don't let SCSI layer keep requeuing the SCSI cmds sent from HBA runtime
PM ops, let them pass or fail them. Let them pass if eh_work is
scheduled due to non-fatal errors. Fail them if eh_work is scheduled due
to fatal errors, otherwise the cmds may eventually time out since UFS is
in bad state, which gets error handler blocked for too long. If we fail
the SCSI cmds sent from HBA runtime PM ops, HBA runtime PM ops fails
too, but it does not hurt since error handler can recover HBA runtime PM
error.
Link: https://lore.kernel.org/r/1596975355-39813-9-git-send-email-cang@codeaurora.org
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The current error handler can not recover HBA runtime PM error if
ufshcd_suspend/resume has failed due to UFS errors, e.g. hibern8 enter/exit
error or SSU cmd error. When this happens, error handler may fail
performing a full reset and restore because error handler always assumes
that power, IRQs and clocks are ready after pm_runtime_get_sync returns,
but actually they are not if ufshcd_resume fails[1].
If ufschd_suspend/resume fails due to UFS errors, runtime PM framework
saves the error value to dev.power.runtime_error. After that, HBA dev
runtime suspend/resume would not be invoked anymore unless runtime_error is
cleared[2].
In case of ufshcd_suspend/resume fails due to UFS errors, for scenario [1],
error handler cannot assume anything of pm_runtime_get_sync, meaning error
handler should explicitly turn ON powers, IRQs and clocks again. To get the
HBA runtime PM work as regard for scenario [2], error handler can clear the
runtime_error by calling pm_runtime_set_active() if full reset and restore
succeeds. And, more important, if pm_runtime_set_active() returns no error,
which means runtime_error has been cleared, we also need to resume those
scsi devices under HBA in case any of them has failed to be resumed due to
HBA runtime resume failure. This is to unblock blk_queue_enter in case
there are bios waiting inside it.
Link: https://lore.kernel.org/r/1596975355-39813-7-git-send-email-cang@codeaurora.org
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Error recovery can be invoked from multiple code paths, including hibern8
enter/exit (from ufshcd_link_recovery), ufshcd_eh_host_reset_handler() and
eh_work scheduled from IRQ context. Ultimately, these paths are all trying
to invoke ufshcd_reset_and_restore() in either a synchronous or
asynchronous manner. This causes problems:
- If link recovery happens during ungate work, ufshcd_hold() would be
called recursively. Although commit 53c12d0ef6 ("scsi: ufs: fix error
recovery after the hibern8 exit failure") fixed a deadlock due to
recursive calls of ufshcd_hold() by adding a check of eh_in_progress
into ufshcd_hold, this check allows eh_work to run in parallel while
link recovery is running.
- Similar concurrency can also happen when error recovery is invoked from
ufshcd_eh_host_reset_handler and ufshcd_link_recovery.
- Concurrency can even happen between eh_works. eh_work, currently queued
on system_wq, is allowed to have multiple instances running in parallel,
but we don't have proper protection for that.
If any of above concurrency scenarios happen, error recovery would fail and
lead ufs device and host into bad states. To fix the concurrency problem,
this change queues eh_work on a single threaded workqueue and removes link
recovery calls from the hibern8 enter/exit path. In addition, make use of
eh_work in eh_host_reset_handler instead of calling
ufshcd_reset_and_restore. This unifies the UFS error recovery mechanism.
According to the UFSHCI JEDEC spec, hibern8 enter/exit error occurs when
the link is broken. This essentially applies to any power mode change
operations (since they all use PACP_PWR cmds in UniPro layer). So, if a
power mode change operation (including AH8 enter/exit) fails, mark link
state as UIC_LINK_BROKEN_STATE and schedule the eh_work. In this case,
error handler needs to do a full reset and restore to recover the link back
to active. Before the link state is recovered to active,
ufshcd_uic_pwr_ctrl simply returns -ENOLINK to avoid more errors.
Link: https://lore.kernel.org/r/1596975355-39813-6-git-send-email-cang@codeaurora.org
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Pull SCSI updates from James Bottomley:
"This consists of the usual driver updates (ufs, qla2xxx, tcmu, lpfc,
hpsa, zfcp, scsi_debug) and minor bug fixes.
We also have a huge docbook fix update like most other subsystems and
no major update to the core (the few non trivial updates are either
minor fixes or removing an unused feature [scsi_sdb_cache])"
* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (307 commits)
scsi: scsi_transport_srp: Sanitize scsi_target_block/unblock sequences
scsi: ufs-mediatek: Apply DELAY_AFTER_LPM quirk to Micron devices
scsi: ufs: Introduce device quirk "DELAY_AFTER_LPM"
scsi: virtio-scsi: Correctly handle the case where all LUNs are unplugged
scsi: scsi_debug: Implement tur_ms_to_ready parameter
scsi: scsi_debug: Fix request sense
scsi: lpfc: Fix typo in comment for ULP
scsi: ufs-mediatek: Prevent LPM operation on undeclared VCC
scsi: iscsi: Do not put host in iscsi_set_flashnode_param()
scsi: hpsa: Correct ctrl queue depth
scsi: target: tcmu: Make TMR notification optional
scsi: target: tcmu: Implement tmr_notify callback
scsi: target: tcmu: Fix and simplify timeout handling
scsi: target: tcmu: Factor out new helper ring_insert_padding
scsi: target: tcmu: Do not queue aborted commands
scsi: target: tcmu: Use priv pointer in se_cmd
scsi: target: Add tmr_notify backend function
scsi: target: Modify core_tmr_abort_task()
scsi: target: iscsi: Fix inconsistent debug message
scsi: target: iscsi: Fix login error when receiving
...
Fixes the following W=1 kernel build warning(s):
drivers/scsi/ufs/ufs-qcom.c:253: warning: Function parameter or member 'hba' not described in 'ufs_qcom_host_reset'
drivers/scsi/ufs/ufs-qcom.c:383: warning: Function parameter or member 'hba' not described in 'ufs_qcom_cfg_timers'
drivers/scsi/ufs/ufs-qcom.c:383: warning: Function parameter or member 'gear' not described in 'ufs_qcom_cfg_timers'
drivers/scsi/ufs/ufs-qcom.c:383: warning: Function parameter or member 'hs' not described in 'ufs_qcom_cfg_timers'
drivers/scsi/ufs/ufs-qcom.c:383: warning: Function parameter or member 'rate' not described in 'ufs_qcom_cfg_timers'
drivers/scsi/ufs/ufs-qcom.c:383: warning: Function parameter or member 'update_link_startup_timer' not described in 'ufs_qcom_cfg_timers'
drivers/scsi/ufs/ufs-qcom.c:1738: error: Cannot parse struct or union!
Link: https://lore.kernel.org/r/20200723122446.1329773-4-lee.jones@linaro.org
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: Avri Altman <avri.altman@wdc.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add support for Qualcomm Inline Crypto Engine (ICE) to ufs-qcom.
The standards-compliant parts, such as querying the crypto capabilities and
enabling crypto for individual UFS requests, are already handled by
ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
However, ICE requires vendor-specific init, enable, and resume logic, and
it requires that keys be programmed and evicted by vendor-specific SMC
calls. Make the ufs-qcom driver handle these details.
I tested this on Dragonboard 845c, which is a publicly available
development board that uses the Snapdragon 845 SoC and runs the upstream
Linux kernel. This is the same SoC used in the Pixel 3 and Pixel 3 XL
phones. This testing included (among other things) verifying that the
expected ciphertext was produced, both manually using ext4 encryption and
automatically using a block layer self-test I've written.
I've also tested that this driver works nearly as-is on the Snapdragon 765
and Snapdragon 865 SoCs. And others have tested it on Snapdragon 850,
Snapdragon 855, and Snapdragon 865 (see the Tested-by tags).
This is based very loosely on the vendor-provided driver in the kernel
source code for the Pixel 3, but I've greatly simplified it. Also, for now
I've only included support for major version 3 of ICE, since that's all I
have the hardware to test with the mainline kernel. Plus it appears that
version 3 is easier to use than older versions of ICE.
For now, only allow using AES-256-XTS. The hardware also declares support
for AES-128-XTS, AES-{128,256}-ECB, and AES-{128,256}-CBC (BitLocker
variant). But none of these others are really useful, and they'd need to
be individually tested to be sure they worked properly.
This commit also changes the name of the loadable module from "ufs-qcom" to
"ufs_qcom", as this is necessary to compile it from multiple source files
(unless we were to rename ufs-qcom.c).
Link: https://lore.kernel.org/r/20200710072013.177481-6-ebiggers@kernel.org
Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Tested-by: Thara Gopinath <thara.gopinath@linaro.org> # db845c, sm8150-mtp, sm8250-mtp
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
