- 12 Apr, 2024 8 commits
-
-
Christoph Hellwig authored
Use the SCSI host's dma_alignment field and set it in ->init and remove the now unused config_scsi_dev method. Signed-off-by:
Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20240409143748.980206-9-hch@lst.deReviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Damien Le Moal <dlemoal@kernel.org> Reviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Christoph Hellwig authored
Get drivers out of the business of having to call the block layer DMA alignment limits helpers themselves. Signed-off-by:
John Garry <john.g.garry@oracle.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Christoph Hellwig authored
While we really should be killing the block layer bounce buffering ASAP, I even more urgently need to stop the drivers to fiddle with the limits from ->slave_configure. Add a no_highmem flag to the Scsi_Host to centralize this setting and switch the remaining four drivers that use block layer bounce buffering to it. Signed-off-by:
-
Christoph Hellwig authored
ibmvfc only supports a single segment for BSG FC passthrough. Instead of having it set a queue limits after creating the BSG queues, add a field so that the FC transport can set it before allocating the queue. Signed-off-by:
-
Christoph Hellwig authored
Turn __scsi_init_queue() into scsi_init_limits() which initializes queue_limits structure that can be passed to blk_mq_alloc_queue(). Signed-off-by:
-
Christoph Hellwig authored
Pass the limits to bsg_setup_queue() instead of setting them up on the live queue. Signed-off-by:
-
Christoph Hellwig authored
This allows bsg_setup_queue() to pass them to blk_mq_alloc_queue() and thus set up the limits at queue allocation time. Signed-off-by:
-
Christoph Hellwig authored
Drivers might have to perform complex actions to determine queue limits, and those might fail. Add a helper to cancel a queue limit update that can be called in those cases. Signed-off-by:
Kanchan Joshi <joshi.k@samsung.com> Reviewed-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 25 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:
-
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:
-
Krzysztof Kozlowski authored
Modules registering driver with scsi_driver_register() might forget to set .owner field. The field is used by some of other kernel parts for reference counting (try_module_get()), so it is expected that drivers will set it. Solve the problem by moving this task away from the drivers to the core scsi code, just like we did for platform_driver in commit 9447057e ("platform_device: use a macro instead of platform_driver_register"). Signed-off-by:
-
Krzysztof Kozlowski authored
PCI core in pci_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
-
Krzysztof Kozlowski authored
PCI core in pci_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
-
- 28 Mar, 2024 1 commit
-
-
Damien Le Moal authored
Commit b4d3ddd2 ("scsi: libsas: Define NCQ Priority sysfs attributes for SATA devices") introduced support for ATA NCQ priority control for ATA devices managed by libsas. This commit introduces the ncq_prio_supported and ncq_prio_enable sysfs device attributes to discover and control the use of this features, similarly to libata. However, libata publicly declares these device attributes and export them for use in ATA low level drivers. This leads to a compilation error when libsas and libata are built-in due to the double definition: ld: drivers/ata/libata-sata.o:/home/Linux/scsi/drivers/ata/libata-sata.c:900: multiple definition of `dev_attr_ncq_prio_supported'; drivers/scsi/libsas/sas_ata.o:/home/Linux/scsi/drivers/scsi/libsas/sas_ata.c:984: first defined here ld: drivers/ata/libata-sata.o:/home/Linux/scsi/drivers/ata/libata-sata.c:1026: multiple definition of `dev_attr_ncq_prio_enable'; drivers/scsi/libsas/sas_ata.o:/home/Linux/scsi/drivers/scsi/libsas/sas_ata.c:1022: first defined here Resolve this problem by directly declaring the libsas attributes instead of using the DEVICE_ATTR() macro. And for good measure, the device attribute variables are also renamed. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Fixes: b4d3ddd2 ("scsi: libsas: Define NCQ Priority sysfs attributes for SATA devices") Signed-off-by:
-
- 26 Mar, 2024 4 commits
-
-
Martin K. Petersen authored
Peter Wang <peter.wang@mediatek.com> says: This series fixes some defects and provide features in MediaTek UFS drivers. Link: https://lore.kernel.org/r/20240315083448.7185-1-peter.wang@mediatek.comSigned-off-by:
-
Alice Chao authored
Add mtcmos control function and config. Signed-off-by:
Alice Chao <alice.chao@mediatek.com> Reviewed-by:
Peter Wang <peter.wang@mediatek.com> Acked-by:
Chun-Hung Wu <Chun-Hung.Wu@mediatek.com> Signed-off-by:
-
Peter Wang authored
Reset mphy when resetting host. Backup mphy setting after mphy reset control get. Restore mphy setting after mphy reset. Acked-by:
-
Po-Wen Kao authored
Mediatek host power includes two parts: 1. ufshci power, which is the main power of ufs host controller. 2. ufshci crypto sram power, which is the power of ufs crypto engine. The host power control is actually controlling crypto sram power. Rename it. Signed-off-by:
Po-Wen Kao <powen.kao@mediatek.com> Acked-by:
Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20240315083448.7185-6-peter.wang@mediatek.comSigned-off-by:
-
