- 12 Apr, 2024 1 commit
-
-
Avri Altman authored
UFS spec version 2.1 was published more than 10 years ago. It is vanishingly unlikely that even there are out there platforms that uses earlier host controllers, let alone that those ancient platforms will ever run a V6.10 kernel. To be extra cautious, leave out removal of UFSHCI 2.0 support from this patch, and just remove support of host controllers prior to UFS2.0. This patch removes some legacy tuning calls that no longer apply. Signed-off-by:
Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20240410183720.908-2-avri.altman@wdc.comAcked-by:
Bean Huo <beanhuo@micron.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 09 Apr, 2024 17 commits
-
-
Martin K. Petersen authored
Bart Van Assche <bvanassche@acm.org> says: Hi Martin, The SCSI debugfs code may show information in debugfs that is invalid. Hence this patch series that makes sure only valid information is shown in debugfs. Please consider this patch series for the next merge window. Thanks, Bart. Link: https://lore.kernel.org/r/20240325224755.1477910-1-bvanassche@acm.orgSigned-off-by:
-
Martin K. Petersen authored
Randy Dunlap <rdunlap@infradead.org> says: Clean up some SCSI doc files and fix kernel-doc in 6 header files in include/scsi/. Link: https://lore.kernel.org/r/20240408025425.18778-1-rdunlap@infradead.orgSigned-off-by:
-
Bart Van Assche authored
Some but not all command information is cleared by scsi_end_request(). As an example, if scsi_show_rq() is called after a SCSI command has been allocated and before SCMD_INITIALIZED is set, .cmnd holds the CDB of a previous command. Showing that information in debugfs is confusing. Hence this patch that restricts the information shown in debugfs to valid information. Signed-off-by:
-
Bart Van Assche authored
Slightly improve code readability by introducing a helper function for deriving the list information and by using guard() + return instead of goto + explicit unlock + return. Signed-off-by:
-
Randy Dunlap authored
Add a struct short description and a function return value to prevent kernel-doc warnings: scsi_transport_srp.h:77: warning: missing initial short description on line: * struct srp_function_template scsi_transport_srp.h:132: warning: No description found for return value of 'srp_chkready' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20240408025425.18778-9-rdunlap@infradead.orgReviewed-by:
-
Randy Dunlap authored
Add function return value to prevent a kernel-doc warning: scsi_transport_fc.h:780: warning: No description found for return value of 'fc_remote_port_chkready' Signed-off-by:
-
Randy Dunlap authored
Add missing function return values to prevent kernel-doc warnings: scsi.h:75: warning: No description found for return value of 'scsi_status_is_check_condition' scsi.h:202: warning: No description found for return value of 'scsi_status_is_good' Signed-off-by:
-
Randy Dunlap authored
Fix all kernel-doc warnings in <scsi/libfcoe.h>: libfcoe.h:163: warning: Function parameter or struct member 'ctlr' not described in 'fcoe_ctlr_priv' libfcoe.h:163: warning: Excess function parameter 'cltr' description in 'fcoe_ctlr_priv' libfcoe.h:163: warning: No description found for return value of 'fcoe_ctlr_priv' libfcoe.h:218: warning: Function parameter or struct member 'fd_flags' not described in 'fcoe_fcf' libfcoe.h:218: warning: Excess struct member 'event' description in 'fcoe_fcf' libfcoe.h:240: warning: Function parameter or struct member 'rdata' not described in 'fcoe_rport' libfcoe.h:273: warning: No description found for return value of 'is_fip_mode' libfcoe.h:332: warning: Function parameter or struct member 'crc_eof_page' not described in 'fcoe_percpu_s' libfcoe.h:332: warning: Function parameter or struct member 'lock' not described in 'fcoe_percpu_s' libfcoe.h:332: warning: Excess struct member 'page' description in 'fcoe_percpu_s' libfcoe.h:362: warning: Function parameter or struct member 'data_src_addr' not described in 'fcoe_port' libfcoe.h:362: warning: Function parameter or struct member 'get_netdev' not described in 'fcoe_port' libfcoe.h:362: warning: Excess struct member 'data_srt_addr' description in 'fcoe_port' libfcoe.h:369: warning: No description found for return value of 'fcoe_get_netdev' libfcoe.h:386: warning: missing initial short description on line: * struct netdev_list libfcoe.h:393: warning: expecting prototype for struct netdev_list. Prototype was for struct fcoe_netdev_mapping instead Signed-off-by:
-
Randy Dunlap authored
Correct kernel-doc comments for struct iser_ctrl to prevent warnings: iser.h:76: warning: Function parameter or struct member 'read_stag' not described in 'iser_ctrl' iser.h:76: warning: Excess struct member 'reaf_stag' description in 'iser_ctrl' Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by:
-
Randy Dunlap authored
Add entries for missing documentation to prevent kernel-doc warnings: scsi_cmnd.h:365: warning: Function parameter or struct member 'cmd' not described in 'scsi_msg_to_host_byte' scsi_cmnd.h:365: warning: Function parameter or struct member 'msg' not described in 'scsi_msg_to_host_byte' Signed-off-by:
-
Randy Dunlap authored
- Change http to https where the latter works - Drop references to I2O (Intelligent I/O) - Use lore.kernel.org instead of marc.info for email links - Update the location of the scsi_debug documentation Signed-off-by:
-
Randy Dunlap authored
- Update the format (txt to rst) and location of this document (archive.org to docs.kernel.org) - Change url to URL - Spell out "lk" (Linux Kernel) Signed-off-by:
-
Li Zhijian authored
Per filesystems/sysfs.rst, show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. coccinelle complains that there are still a couple of functions that use snprintf(). Convert them to sysfs_emit(). sprintf() and scnprintf() will be converted as well if they have. Generally, this patch is generated by make coccicheck M=<path/to/file> MODE=patch \ COCCI=scripts/coccinelle/api/device_attr_show.cocci No functional change intended CC: Karan Tilak Kumar <kartilak@cisco.com> CC: Sesidhar Baddela <sebaddel@cisco.com> CC: James E.J. Bottomley <jejb@linux.ibm.com> CC: Martin K. Petersen <martin.petersen@oracle.com> CC: linux-scsi@vger.kernel.org Signed-off-by:
Li Zhijian <lizhijian@fujitsu.com> Link: https://lore.kernel.org/r/20240319063132.1588443-12-lizhijian@fujitsu.comReviewed-by:
Karan Tilak Kumar <kartilak@cisco.com> Signed-off-by:
-
Colin Ian King authored
Pointer currTar_Info is being assigned a value that is never read, it is being re-assigned a few lines later in the start of a following do-while loop. The assignment is redundant and can be removed. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20240406155029.2593439-1-colin.i.king@gmail.comSigned-off-by:
-
Prasad Pandit authored
Fix indentation of config option's help text by adding leading spaces. Generally help text is indented by two more spaces beyond the leading tab <\t> character. It helps Kconfig parsers to read file without error. Signed-off-by:
Prasad Pandit <pjp@fedoraproject.org> Link: https://lore.kernel.org/r/20240408050110.3679890-1-ppandit@redhat.comSigned-off-by:
-
Prasad Pandit authored
Fix indentation of config option's help text by adding leading spaces. Generally help text is indented by couple of spaces more beyond the leading tab <\t> character. It helps Kconfig parsers to read file without error. Signed-off-by:
-
Prasad Pandit authored
Fix indentation of megaraid options help text by adding leading spaces. Generally help text is indented by couple of spaces more beyond the leading tab <\t> character. Signed-off-by:
-
- 08 Apr, 2024 2 commits
-
-
Arnd Bergmann authored
Calling a function through an incompatible pointer type causes breaks kcfi, so clang warns about the assignments: drivers/scsi/cxlflash/main.c:3498:3: error: cast from 'int (*)(struct cxlflash_cfg *, struct ht_cxlflash_lun_provision *)' to 'hioctl' (aka 'int (*)(struct cxlflash_cfg *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 3498 | (hioctl)cxlflash_lun_provision }, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/cxlflash/main.c:3500:3: error: cast from 'int (*)(struct cxlflash_cfg *, struct ht_cxlflash_afu_debug *)' to 'hioctl' (aka 'int (*)(struct cxlflash_cfg *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 3500 | (hioctl)cxlflash_afu_debug }, | ^~~~~~~~~~~~~~~~~~~~~~~~~~ Address these by changing the functions to have the correct type and replace the function pointer cast with a cast of its argument. Link: https://lore.kernel.org/lkml/20240326145140.3257163-6-arnd@kernel.org/Signed-off-by:Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240404161524.3473857-1-arnd@kernel.orgSigned-off-by:
-
Manivannan Sadhasivam authored
Let's add the checks to warn the user if the ICC scaling is not supported for the gear/lane values and also fallback to the max value if that's the case. Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20240403-ufs-icc-fix-v2-2-958412a5eb45@linaro.orgReviewed-by:
Andrew Halaney <ahalaney@redhat.com> Signed-off-by:
-
- 06 Apr, 2024 20 commits
-
-
Martin K. Petersen authored
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> says: Hello, this series fixes the same issue in four drivers. The warning is a false positive and to suppress it the driver structs are marked with __refdata and a comment is added to describe the (non-trivial) situation. Best regards Uwe Link: https://lore.kernel.org/r/cover.1711746359.git.u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent the following section mismatch warning WARNING: modpost: drivers/scsi/mac_scsi: section mismatch in reference: mac_scsi_driver+0x8 (section: .data) -> mac_scsi_remove (section: .exit.text) that triggers on an allmodconfig W=1 build. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/e41d10906948a980e985f6065485445d9bbbd2f7.1711746359.git.u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent the following section mismatch warning WARNING: modpost: drivers/scsi/atari_scsi: section mismatch in reference: atari_scsi_driver+0x8 (section: .data) -> atari_scsi_remove (section: .exit.text) that triggers on an allmodconfig W=1 build. Signed-off-by:
-
Uwe Kleine-König authored
As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent the following section mismatch warning WARNING: modpost: drivers/scsi/a4000t: section mismatch in reference: amiga_a4000t_scsi_driver+0x8 (section: .data) -> amiga_a4000t_scsi_remove (section: .exit.text) that triggers on an allmodconfig W=1 build. Signed-off-by:
-
Uwe Kleine-König authored
As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent the following section mismatch warning WARNING: modpost: drivers/scsi/a3000: section mismatch in reference: amiga_a3000_scsi_driver+0x8 (section: .data) -> amiga_a3000_scsi_remove (section: .exit.text) that triggers on an allmodconfig W=1 build. Signed-off-by:
-
Martin K. Petersen authored
Andrew Halaney <ahalaney@redhat.com> says: Please review with care as I'm not all that confident in this subject. UFS has a lot of mb() variants used, most with comments saying "ensure this takes effect before continuing". mb()'s aren't really the way to guarantee that, a read back is the best method. Some of these though I think could go a step further and remove the mb() variant without a read back. As far as I can tell there's no real reason to ensure it takes effect in most cases (there's no delay() or anything afterwards, and eventually another readl()/writel() happens which is by definition ordered). Some of the patches in this series do that if I was confident it was safe (or a reviewer pointed out prior that they thought it was safe to do so). Thanks in advance for the help, Andrew Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-0-181252004586@redhat.comSigned-off-by:
-
Andrew Halaney authored
Currently a wmb() is used to ensure that writes to the UTP_TASK_REQ_LIST_BASE* regs are completed prior to following writes to the run/stop registers. wmb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring the bits have taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 But, none of that is necessary here. All of the writel()/readl()'s here are to the same endpoint, so they will be ordered. There's no subsequent delay() etc that requires it to have taken effect already, so no readback is necessary here. For that reason just drop the wmb() altogether. Fixes: 897efe62 ("scsi: ufs: add missing memory barriers") Signed-off-by: -
Andrew Halaney authored
Currently, the doorbell is written to and a wmb() is used to commit it immediately. wmb() ensures that the write completes before following writes occur, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 But, completion and taking effect aren't necessary to guarantee here. There's already other examples of the doorbell being rung that don't do this. The writel() of the doorbell guarantees prior writes by this thread (to the request being setup for example) complete prior to the ringing of the doorbell, and the following wait_for_completion_io_timeout() doesn't require any special memory barriers either. With that in mind, just remove the wmb() altogether here. Fixes: ad1a1b9c ("scsi: ufs: commit descriptors before setting the doorbell") Signed-off-by: -
Andrew Halaney authored
Currently, the UIC_COMMAND_COMPL interrupt is disabled and a wmb() is used to complete the register write before any following writes. wmb() ensures the writes complete in that order, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. Because the wmb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: d75f7fe4 ("scsi: ufs: reduce the interrupts for power mode change requests") Reviewed-by:Can Guo <quic_cang@quicinc.com> Reviewed-by:
-
Andrew Halaney authored
Currently, interrupts are cleared and disabled prior to registering the interrupt. An mb() is used to complete the clear/disable writes before the interrupt is registered. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring these bits have taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure these bits hit the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: 199ef13c ("scsi: ufs: avoid spurious UFS host controller interrupts") Reviewed-by: -
Andrew Halaney authored
Currently, the UTP_TASK_REQ_LIST_BASE_L/UTP_TASK_REQ_LIST_BASE_H regs are written to and then completed with an mb(). mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring these bits have taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bits hit the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: 88441a8d ("scsi: ufs: core: Add hibernation callbacks") Reviewed-by: -
Andrew Halaney authored
Currently, HCLKDIV is written to and then completed with an mb(). mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: d90996da ("scsi: ufs: Add UFS platform driver for Cadence UFS") Reviewed-by: -
Andrew Halaney authored
Currently, the CGC enable bit is written and then an mb() is used to ensure that completes before continuing. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Reviewed-by: -
Andrew Halaney authored
Currently, the QUNIPRO_SEL bit is written to and then an mb() is used to ensure that completes before continuing. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 But, there's really no reason to even ensure completion before continuing. The only requirement here is that this write is ordered to this endpoint (which readl()/writel() guarantees already). For that reason the mb() can be dropped altogether without anything forcing completion. Fixes: f06fcc71 ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations") Signed-off-by: -
Andrew Halaney authored
Currently, the testbus configuration is written and completed with an mb(). mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 But, there's really no reason to even ensure completion before continuing. The only requirement here is that this write is ordered to this endpoint (which readl()/writel() guarantees already). For that reason the mb() can be dropped altogether without anything forcing completion. Fixes: 9c46b867 ("scsi: ufs-qcom: dump additional testbus registers") Signed-off-by: -
Andrew Halaney authored
Currently after writing to REG_UFS_SYS1CLK_1US a mb() is used to ensure that write has gone through to the device. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: f06fcc71 ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations") Reviewed-by: -
Andrew Halaney authored
Currently, the reset bit for the UFS provided reset controller (used by its phy) is written to, and then a mb() happens to try and ensure that hit the device. Immediately afterwards a usleep_range() occurs. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. By doing so and guaranteeing the ordering against the immediately following usleep_range(), the mb() can safely be removed. Fixes: 81c0fc51 ("ufs-qcom: add support for Qualcomm Technologies Inc platforms") Reviewed-by: -
Krzysztof Kozlowski authored
Core in scsi_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240328-b4-module-owner-scsi-v1-6-c86cb4f6e91c@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
Core in scsi_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
-
Krzysztof Kozlowski authored
Core in scsi_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
-
