- 01 Jul, 2020 1 commit
-
-
Bart Van Assche authored
Since struct fcp_hdr is used to exchange data with the firmware, check its size at compile time. Link: https://lore.kernel.org/r/20200629225454.22863-2-bvanassche@acm.org Cc: Nilesh Javali <njavali@marvell.com> Cc: Quinn Tran <qutran@marvell.com> Cc: Himanshu Madhani <himanshu.madhani@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by:
Daniel Wagner <dwagner@suse.de> Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 30 Jun, 2020 2 commits
-
-
Bodo Stroesser authored
If tcmu_handle_completions() has to process a padding shorter than sizeof(struct tcmu_cmd_entry), the current call to tcmu_flush_dcache_range() with sizeof(struct tcmu_cmd_entry) as length param is wrong and causes crashes on e.g. ARM, because tcmu_flush_dcache_range() in this case calls flush_dcache_page(vmalloc_to_page(start)); with start being an invalid address above the end of the vmalloc'ed area. The fix is to use the minimum of remaining ring space and sizeof(struct tcmu_cmd_entry) as the length param. The patch was tested on kernel 4.19.118. See https://bugzilla.kernel.org/show_bug.cgi?id=208045#c10 Link: https://lore.kernel.org/r/20200629093756.8947-1-bstroesser@ts.fujitsu.comTested-by:
JiangYu <lnsyyj@hotmail.com> Acked-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by:
-
Dan Carpenter authored
The "head" pointer can't be NULL because it points to an address in the middle of a ufs_hba struct. Looking at this code, probably someone would wonder if the intent was to check whether "hba" is NULL, but "hba" isn't NULL and the check can just be removed. Link: https://lore.kernel.org/r/20200626105133.GF314359@mwandaAcked-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 27 Jun, 2020 5 commits
-
-
Flavio Suligoi authored
Fix typo: "trigerred" --> "triggered" Link: https://lore.kernel.org/r/20200624135600.14274-1-f.suligoi@asem.itSigned-off-by:
Flavio Suligoi <f.suligoi@asem.it> Signed-off-by:
-
Stanley Chu authored
If a UFS device is not qualified to use WriteBooster, either due to wrong UFS version or device-specific quirks, then the capability in host shall be disabled to prevent any WriteBooster operations in the future. Link: https://lore.kernel.org/r/20200625030430.25048-1-stanley.chu@mediatek.com Fixes: 3d17b9b5 ("scsi: ufs: Add write booster feature support") Tested-by:
Steev Klimaszewski <steev@kali.org> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Javed Hasan authored
Removed all the unused variables. Link: https://lore.kernel.org/r/20200622093814.3250-1-jhasan@marvell.comReported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Javed Hasan <jhasan@marvell.com> Signed-off-by:
-
Christophe JAILLET authored
The dev_id used in request_irq() and free_irq() should match. Use 'info' in both cases. Link: https://lore.kernel.org/r/20200625204730.943520-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Alim Akhtar authored
While building for x86_64 allmodconfig, the following warning was reported: WARNING: modpost: missing MODULE_LICENSE() in drivers/scsi/ufs/ufs-exynos.o Add the missing license/author/description tags. Link: https://lore.kernel.org/r/20200625154405.60448-1-alim.akhtar@samsung.com Fixes: 55f4b1f7 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 24 Jun, 2020 2 commits
-
-
Wei Yongjun authored
In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Link: https://lore.kernel.org/r/20200618133837.127274-1-weiyongjun1@huawei.com Fixes: 55f4b1f7 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Reported-by:
Hulk Robot <hulkci@huawei.com> Acked-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Alim Akhtar authored
Allow Exynos UFS driver to build as a module. This patch fixes the followin build issue reported by kernel build robot. drivers/scsi/ufs/ufs-exynos.o: in function `exynos_ufs_probe': drivers/scsi/ufs/ufs-exynos.c:1231: undefined reference to `ufshcd_pltfrm_init' drivers/scsi/ufs/ufs-exynos.o: in function `exynos_ufs_pre_pwr_mode': drivers/scsi/ufs/ufs-exynos.c:635: undefined reference to `ufshcd_get_pwr_dev_param' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_shutdown' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_suspend' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_resume' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_runtime_suspend' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_runtime_resume' drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_runtime_idle' Link: https://lore.kernel.org/r/20200620173232.52521-1-alim.akhtar@samsung.com Fixes: 55f4b1f7 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Reported-by:
-
- 20 Jun, 2020 8 commits
-
-
Bodo Stroesser authored
This patch fixes the following crash (see https://bugzilla.kernel.org/show_bug.cgi?id=208045) Process iscsi_trx (pid: 7496, stack limit = 0x0000000010dd111a) CPU: 0 PID: 7496 Comm: iscsi_trx Not tainted 4.19.118-0419118-generic #202004230533 Hardware name: Greatwall QingTian DF720/F601, BIOS 601FBE20 Sep 26 2019 pstate: 80400005 (Nzcv daif +PAN -UAO) pc : flush_dcache_page+0x18/0x40 lr : is_ring_space_avail+0x68/0x2f8 [target_core_user] sp : ffff000015123a80 x29: ffff000015123a80 x28: 0000000000000000 x27: 0000000000001000 x26: ffff000023ea5000 x25: ffffcfa25bbe08b8 x24: 0000000000000078 x23: ffff7e0000000000 x22: ffff000023ea5001 x21: ffffcfa24b79c000 x20: 0000000000000fff x19: ffff7e00008fa940 x18: 0000000000000000 x17: 0000000000000000 x16: ffff2d047e709138 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: ffff2d047fbd0a40 x11: 0000000000000000 x10: 0000000000000030 x9 : 0000000000000000 x8 : ffffc9a254820a00 x7 : 00000000000013b0 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffcfa25bbe08e8 x3 : 0000000000001000 x2 : 0000000000000078 x1 : ffffcfa25bbe08b8 x0 : ffff2d040bc88a18 Call trace: flush_dcache_page+0x18/0x40 is_ring_space_avail+0x68/0x2f8 [target_core_user] queue_cmd_ring+0x1f8/0x680 [target_core_user] tcmu_queue_cmd+0xe4/0x158 [target_core_user] __target_execute_cmd+0x30/0xf0 [target_core_mod] target_execute_cmd+0x294/0x390 [target_core_mod] transport_generic_new_cmd+0x1e8/0x358 [target_core_mod] transport_handle_cdb_direct+0x50/0xb0 [target_core_mod] iscsit_execute_cmd+0x2b4/0x350 [iscsi_target_mod] iscsit_sequence_cmd+0xd8/0x1d8 [iscsi_target_mod] iscsit_process_scsi_cmd+0xac/0xf8 [iscsi_target_mod] iscsit_get_rx_pdu+0x404/0xd00 [iscsi_target_mod] iscsi_target_rx_thread+0xb8/0x130 [iscsi_target_mod] kthread+0x130/0x138 ret_from_fork+0x10/0x18 Code: f9000bf3 aa0003f3 aa1e03e0 d503201f (f9400260) ---[ end trace 1e451c73f4266776 ]--- The solution is based on patch: "scsi: target: tcmu: Optimize use of flush_dcache_page" which restricts the use of tcmu_flush_dcache_range() to addresses from vmalloc'ed areas only. This patch now replaces the virt_to_page() call in tcmu_flush_dcache_range() - which is wrong for vmalloced addrs - by vmalloc_to_page(). The patch was tested on ARM with kernel 4.19.118 and 5.7.2 Link: https://lore.kernel.org/r/20200618131632.32748-3-bstroesser@ts.fujitsu.comTested-by:
Daniel Meyerholt <dxm523@gmail.com> Acked-by:
-
Bodo Stroesser authored
(scatter|gather)_data_area() need to flush dcache after writing data to or before reading data from a page in uio data area. The two routines are able to handle data transfer to/from such a page in fragments and flush the cache after each fragment was copied by calling the wrapper tcmu_flush_dcache_range(). That means: 1) flush_dcache_page() can be called multiple times for the same page. 2) Calling flush_dcache_page() indirectly using the wrapper does not make sense, because each call of the wrapper is for one single page only and the calling routine already has the correct page pointer. Change (scatter|gather)_data_area() such that, instead of calling tcmu_flush_dcache_range() before/after each memcpy, it now calls flush_dcache_page() before unmapping a page (when writing is complete for that page) or after mapping a page (when starting to read the page). After this change only calls to tcmu_flush_dcache_range() for addresses in vmalloc'ed command ring are left over. The patch was tested on ARM with kernel 4.19.118 and 5.7.2 Link: https://lore.kernel.org/r/20200618131632.32748-2-bstroesser@ts.fujitsu.comTested-by:
-
Asutosh Das authored
Adds sysfs documentation for WriteBooster entries. Link: https://lore.kernel.org/r/1591723067-22998-1-git-send-email-asutoshd@codeaurora.orgAcked-by:
Asutosh Das <asutoshd@codeaurora.org> Signed-off-by:
-
Bean Huo authored
Delete trailing whitespace, multiple blank lines, and make switch/case be at the same indentation. Link: https://lore.kernel.org/r/20200619154117.10262-3-huobean@gmail.comSigned-off-by:
-
Bean Huo authored
After commit f664a3cc ("scsi: kill off the legacy IO path"), scsi_sdb_cache is not used anymore. Remove it. Link: https://lore.kernel.org/r/20200619154117.10262-2-huobean@gmail.comReviewed-by:
-
Bodo Stroesser authored
Since commit 61fb2482 ("scsi: target: tcmu: Userspace must not complete queued commands") tcmu_cmd bit TCMU_CMD_BIT_INFLIGHT is set but never checked. So we can remove it safely. [mkp: fixed Mike's email address] Link: https://lore.kernel.org/r/20200619173806.5016-1-bstroesser@ts.fujitsu.comSigned-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_warn message. Fix it. Link: https://lore.kernel.org/r/20200617084911.167359-1-colin.king@canonical.comReviewed-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Stanley Chu authored
Fix build warning reported by kernel test robot: Warning: >> drivers/scsi/ufs/ufs-mediatek.c:181:5: warning: no previous prototype >> for 'ufs_mtk_wait_link_state' [-Wmissing-prototypes] Link: https://lore.kernel.org/r/20200616095120.14570-1-stanley.chu@mediatek.comReported-by:
-
- 16 Jun, 2020 18 commits
-
-
Stanley Chu authored
The UFS load calculation is based on "total_time" and "busy_time" in a devfreq window. However, the source of time is different for both parameters: "busy_time" is assigned from "jiffies" thus has different accuracy from "total_time" which is assigned from ktime_get(). In addition, the time of window boundary is not exactly the same as the starting busy time in this window if UFS is actually busy in the beginning of the window. A similar accuracy error may also happen for the end of busy time in current window. To guarantee the precision of load calculation, we need to 1. Align time accuracy of both devfreq_dev_status.total_time and devfreq_dev_status.busy_time. For example, use "ktime_get()" directly. 2. Align the following timelines: - The beginning time of devfreq windows - The beginning of busy time in a new window - The end of busy time in the current window Link: https://lore.kernel.org/r/20200611101043.6379-1-stanley.chu@mediatek.com Fixes: a3cd5ec5 ("scsi: ufs: add load based scaling of UFS gear") Reviewed-by:
-
Stanley Chu authored
Use the ftrace infrastructure to conditionally trace UFS UIC command events. New trace event "ufshcd_uic_command" is created, which samples the following UFS UIC command data: - Device name - Optional identification string - UIC command opcode - UIC command argument1 - UIC command argument2 - UIC command argement3 Usage: echo 1 > /sys/kernel/debug/tracing/events/ufs/enable cat /sys/kernel/debug/tracing/trace_pipe Link: https://lore.kernel.org/r/20200615072235.23042-3-stanley.chu@mediatek.comAcked-by:
-
Stanley Chu authored
Remove unused fields "cmd_active" and "result" in struct ufs_command. Link: https://lore.kernel.org/r/20200615072235.23042-2-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Clean up the following items: - Sort vendor names in alphabetical order - Squash quirks as compact as possible in device table to enhance performance of the lookup - Sort device quirks in alphabetical order Link: https://lore.kernel.org/r/20200612012625.6615-3-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
It is confirmed that Micron device needs DELAY_BEFORE_LPM quirk to have a delay before VCC is powered off. Sdd Micron vendor ID and this quirk for Micron devices. Link: https://lore.kernel.org/r/20200612012625.6615-2-stanley.chu@mediatek.comReviewed-by:
-
Flavio Suligoi authored
Fix typo: "tigger" --> "trigger" Link: https://lore.kernel.org/r/20200609161313.32098-1-f.suligoi@asem.itSigned-off-by:
-
Kieran Bingham authored
The word 'descriptor' is misspelled throughout the tree. Fix it up accordingly: decriptors -> descriptors Link: https://lore.kernel.org/r/20200609124610.3445662-7-kieran.bingham+renesas@ideasonboard.comSigned-off-by:Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Bean Huo authored
Add SPDX GPL-2.0 to UFS driver files that specified the GPL version 2 license, remove the full boilerplate text. Link: https://lore.kernel.org/r/20200605200520.20831-2-huobean@gmail.comReviewed-by:
Tomas Winkler <tomas.winkler@intel.com> Reviewed-by:
-
Bean Huo authored
For UFS 3.1, the normal unit descriptor is 10 bytes larger than the RPMB unit. However, both descriptors share the same desc_idn, to cover both unit descriptors with one length, we choose the normal unit descriptor length by desc_index. Link: https://lore.kernel.org/r/20200603091959.27618-6-huobean@gmail.comReviewed-by:
-
Bean Huo authored
At UFS initialization stage, to get the length of the descriptor, ufshcd_read_desc_length() was being called 6 times. Instead, we will capture the descriptor size the first time we'll read it. Delete unnecessary redundant code, remove ufshcd_read_desc_length(), ufshcd_init_desc_sizes(), and boost UFS initialization. Link: https://lore.kernel.org/r/20200603091959.27618-5-huobean@gmail.comAcked-by:
-
Bean Huo authored
If param_offset is not 0, the memcpy length shouldn't be the true descriptor length. Link: https://lore.kernel.org/r/20200603091959.27618-4-huobean@gmail.comAcked-by:
-
Bean Huo authored
Delete ufshcd_read_desc(). Instead, let caller directly call ufshcd_read_desc_param(). Link: https://lore.kernel.org/r/20200603091959.27618-3-huobean@gmail.comReviewed-by:
-
Bean Huo authored
For the UFS device, the maximum descriptor size is 255, max_t called on ufs_get_device_desc() is useless. Link: https://lore.kernel.org/r/20200603091959.27618-2-huobean@gmail.comReviewed-by:
-
Stanley Chu authored
Allow unbound MPHY module since not every MediaTek UFS platform needs specific MPHY control. Link: https://lore.kernel.org/r/20200601104646.15436-6-stanley.chu@mediatek.comReviewed-by:
Peter Wang <peter.wang@mediatek.com> Signed-off-by:
-
Stanley Chu authored
MediaTek UFS clocks are separated to two parts and controlled by different modules: ufs-mediatek and phy-ufs-mediatek. If both Auto-Hibern8 and clk-gating feature are enabled, mphy power control is not balanced thus unbalanced control also happens to the clocks probed by phy-ufs-mediatek module. Fix this issue by: - Promise usage of phy_power_on/off balanced - Remove phy_power_on/off control in suspend/resume vops since both can be handled in setup_clock vops only Link: https://lore.kernel.org/r/20200601104646.15436-5-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Allow device power supply to enter low-power mode. Link: https://lore.kernel.org/r/20200601104646.15436-4-stanley.chu@mediatek.comReviewed-by:
Pengshun Zhao <pengshun.zhao@mediatek.com> Signed-off-by:
-
Stanley Chu authored
There is a chance that link enters hibern8 via auto-hibern8 scheme during the clock-gating flow. Clocks shall not be gated if link is still active otherwise host or device may hang. Fix this by returning error code to the caller __ufshcd_setup_clocks() to skip gating clocks there if link is not confirmed in hibern8 state yet. Also allow some waiting time for the hibern8 state transition. Link: https://lore.kernel.org/r/20200601104646.15436-3-stanley.chu@mediatek.comReviewed-by:
Andy Teng <andy.teng@mediatek.com> Signed-off-by:
-
Stanley Chu authored
Currently ref-clk control timeout is implemented by jiffies. However jiffies is not accurate enough thus "false timeout" may happen. Use more accurate delay mechanism instead, i.e. ktime. Link: https://lore.kernel.org/r/20200601104646.15436-2-stanley.chu@mediatek.comReviewed-by:
-
- 15 Jun, 2020 4 commits
-
-
Alim Akhtar authored
This patch introduces Exynos UFS host controller driver which mainly handles vendor-specific operations including link startup, power mode change and hibernation/unhibernation. [robot: drivers/scsi/ufs/ufs-exynos.c:931:8-10: WARNING: possible condition with no effect (if == else) ] Link: https://lore.kernel.org/r/20200528011658.71590-10-alim.akhtar@samsung.comReported-by:
Julia Lawall <julia.lawall@lip6.fr> Tested-by:
Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Reviewed-by:
Kiwoong Kim <kwmad.kim@samsung.com> Reviewed-by:
Seungwon Jeon <essuuj@gmail.com> Signed-off-by:
-
Kiwoong Kim authored
Some controller like Exynos determines if FATAL ERROR (0x7) in OCS field in UTRD occurs for values other than GOOD (0x0) in STATUS field in response upiu as well as errors that a host controller can't cover. This patch is to prevent from reporting command results in those cases. Link: https://lore.kernel.org/r/20200528011658.71590-6-alim.akhtar@samsung.comReviewed-by:
-
Alim Akhtar authored
Some UFS host controllers like Exynos uses granularities of PRDT length and offset as bytes, whereas others use actual segment count. Link: https://lore.kernel.org/r/20200528011658.71590-5-alim.akhtar@samsung.comReviewed-by:
-
Alim Akhtar authored
Some host controllers don't support host controller enable via HCE. Link: https://lore.kernel.org/r/20200528011658.71590-4-alim.akhtar@samsung.comReviewed-by:
Can Guo <cang@codeaurora.org> Reviewed-by:
-
