- 12 Aug, 2021 20 commits
-
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-17-bvanassche@acm.orgReviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-16-bvanassche@acm.orgReviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-15-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-14-bvanassche@acm.orgReviewed-by:
-
Bart Van Assche authored
This patch prepares for the removal of the request pointer from struct scsi_cmnd and does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-13-bvanassche@acm.org Cc: Michael Schmitz <schmitzmic@gmail.com> Suggested-by:
Finn Thain <fthain@linux-m68k.org> Acked-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-12-bvanassche@acm.orgReviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-11-bvanassche@acm.orgAcked-by:
Benjamin Block <bblock@linux.ibm.com> Reviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-10-bvanassche@acm.orgReviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-9-bvanassche@acm.orgReviewed-by:
Max Gurtovoy <mgurtovoy@nvidia.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-8-bvanassche@acm.org Cc: Jens Axboe <axboe@kernel.dk> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-7-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-6-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-5-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-4-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Bart Van Assche authored
Prepare for removal of the request pointer by using scsi_cmd_to_rq() instead. Cast away constness where necessary when passing a SCSI command pointer to scsi_cmd_to_rq(). This patch does not change any functionality. Link: https://lore.kernel.org/r/20210809230355.8186-3-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Bart Van Assche authored
The 'request' member of struct scsi_cmnd is superfluous. The struct request and struct scsi_cmnd data structures are adjacent and hence the request pointer can be derived easily from a scsi_cmnd pointer. Introduce a helper function that performs that conversion in a type-safe way. This patch is the first step towards removing the request member from struct scsi_cmnd. Making that change has the following advantages: - This is a performance optimization since adding an offset to a pointer takes less time than dereferencing a pointer. - struct scsi_cmnd becomes smaller. Link: https://lore.kernel.org/r/20210809230355.8186-2-bvanassche@acm.org Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Avri Altman authored
In host control mode, eviction is perceived as an extreme measure. There are several conditions that both the entering and exiting regions should meet, so that eviction will take place. The common case however, is that those conditions are rarely met, so it is normal that the act of eviction fails. Therefore, do not report an error in host control mode if eviction fails. Link: https://lore.kernel.org/r/20210808090024.21721-5-avri.altman@wdc.com Fixes: 6c59cb50 (scsi: ufs: ufshpb: Make eviction depend on region's reads) Signed-off-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
-
Avri Altman authored
'num_inflight_map_req' should not be negative. It is incremented and decremented without any protection, allowing it theoretically to be negative, should some weird unbalanced count occur. Verify that the those calls are properly serialized. Link: https://lore.kernel.org/r/20210808090024.21721-4-avri.altman@wdc.com Fixes: 33845a2d (scsi: ufs: ufshpb: Limit the number of in-flight map requests) Signed-off-by:
-
Avri Altman authored
In HPB2.0, if pre_req_min_tr_len < transfer_len < pre_req_max_tr_len, the driver is expected to send a HPB-WRITE-BUFFER companion to HPB-READ. The upper bound should fit into a single byte, regardless of bMAX_ DATA_SIZE_FOR_HPB_SINGLE_CMD which being an attribute (u32) can be significantly larger. To further illustrate the issue, consider the following scenario: - SCSI_DEFAULT_MAX_SECTORS is 1024 limiting the I/O chunks to 512KB - The OEM changes scsi_host_template .max_sectors to be 2048 which allows for 1MB requests: transfer_len = 256 - pre_req_max_tr_len = HPB_MULTI_CHUNK_HIGH = 256 - ufshpb_is_supported_chunk() returns true (256 <= 256) - WARN_ON_ONCE(256 > 256) doesn't warn - ufshpb_set_hpb_read_to_upiu() casts transfer_len to u8: transfer_len = 0 - The command is failing with ILLEGAL REQUEST Link: https://lore.kernel.org/r/20210808090024.21721-3-avri.altman@wdc.com Fixes: 41d8a933 (scsi: ufs: ufshpb: Add HPB 2.0 support) Signed-off-by:
-
Avri Altman authored
The purpose of the "cold"-timer is not to hang-on to active regions with no reads. Therefore the read timeout should be rewound on every read, and not just when the region is activated. Link: https://lore.kernel.org/r/20210808090024.21721-2-avri.altman@wdc.com Fixes: 13c044e9 (scsi: ufs: ufshpb: Add "cold" regions timer) Signed-off-by:
-
- 10 Aug, 2021 12 commits
-
-
Colin Ian King authored
The variable 'rv' is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Link: https://lore.kernel.org/r/20210804143319.115340-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
The variable 'lba' is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Link: https://lore.kernel.org/r/20210804133241.113509-1-colin.king@canonical.comSigned-off-by:
-
Colin Ian King authored
The variable 'ret' is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Link: https://lore.kernel.org/r/20210804132451.113086-1-colin.king@canonical.comSigned-off-by:
-
Wei Li authored
If request_region() fails the return value is not set. Return -EBUSY on error. Link: https://lore.kernel.org/r/20210715032625.1395495-1-liwei391@huawei.com Fixes: 8674a8aa ("scsi: fdomain: Add PCMCIA support") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Li <liwei391@huawei.com> Signed-off-by:
-
Colin Ian King authored
The variable ret is being initialized with a value that is never read, the assignment is redundant and can be removed. Link: https://lore.kernel.org/r/20210806112313.12434-1-colin.king@canonical.comSigned-off-by:
-
Adrian Hunter authored
Managed device links are deleted by device_del(). However it is possible to add a device link to a consumer before device_add(), and then discovering an error prevents the device from being used. In that case normally references to the device would be dropped and the device would be deleted. However the device link holds a reference to the device, so the device link and device remain indefinitely (unless the supplier is deleted). For UFSHCD, if a LUN fails to probe (e.g. absent BOOT WLUN), the device will not have been registered but can still have a device link holding a reference to the device. The unwanted device link will prevent runtime suspend indefinitely. Amend device link removal to accept removal of a link with an unregistered consumer device (suggested by Rafael), and fix UFSHCD by explicitly deleting the device link when SCSI destroys the SCSI device. Link: https://lore.kernel.org/r/a1c9bac8-b560-b662-f0aa-58c7e000cbbd@intel.com Fixes: b294ff3e ("scsi: ufs: core: Enable power management for wlun") Reviewed-by:
Rafael J. Wysocki <rafael@kernel.org> Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Colin Ian King authored
Variable 'tag' is currently an unsigned int and is being compared to less than zero, this check is always false. Fix this by making 'tag' an int. Link: https://lore.kernel.org/r/20210806144301.19864-1-colin.king@canonical.com Fixes: 4728ab4a ("scsi: ufs: Remove ufshcd_valid_tag()") Reviewed-by:
-
Damien Le Moal authored
Similarly to AHCI, introduce the device sysfs attribute sas_ncq_prio_supported to advertise if a SATA device supports the NCQ priority feature. Without this new attribute, the user can only discover if a SATA device supports NCQ priority by trying to enable the feature use with the sas_ncq_prio_enable sysfs device attribute, which fails when the device does not support high prioity commands. Link: https://lore.kernel.org/r/20210807041859.579409-11-damien.lemoal@wdc.comReviewed-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
-
Suganath Prabu S authored
Update driver version to 39.100.00.00. Link: https://lore.kernel.org/r/20210809072639.21228-3-suganath-prabu.subramani@broadcom.comSigned-off-by:
Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Suganath Prabu S authored
Currently, the mpt3sas driver sets the default queue depth based on the physical interface of the attached device: - SAS : 254 - SATA: 32 - NVMe: 128 The IOC firmware provides a recommended queue depth for each device through SAS IO Unit Page1 for SAS/SATA and PCIe IO Unit Page 1 for NVMe devices. If the host sets the queue depth greater than the firmware recommended value, then the IOC places the I/Os above the recommended queue depth in an internal pending queue. This consumes outstanding host-credit/resources, thereby leading to potential starvation of other devices. To avoid this, use the device depth recommended by the IOC firmware. Link: https://lore.kernel.org/r/20210809072639.21228-2-suganath-prabu.subramani@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Bump driver version to 38.100.00.00. Link: https://lore.kernel.org/r/20210803065134.19090-1-sreekanth.reddy@broadcom.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
Enable the driver to work in non-IRQ mode, i.e. there will not be any MSI-X vectors associated with queues dedicated to polling. The IOC hardware is single submission queue and multiple reply queue. However, using the shared host tagset support it is possible to simulate multiple hardware queues. When poll_queues are enabled through the module parameter, the driver will allocate extra reply queues without an MSI-X association. All I/O completion on these queues will be done through the iopoll interface. Link: https://lore.kernel.org/r/20210727081212.2742-1-sreekanth.reddy@broadcom.comSigned-off-by:
-
- 06 Aug, 2021 5 commits
-
-
Bean Huo authored
We need to check whether HPB is enabled on a given LU from the userspace tool. Add lu_enable sysfs node. Link: https://lore.kernel.org/r/20210804182128.458356-3-huobean@gmail.comTested-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
Bean Huo authored
For Micron UFS devices the L2P entry need to be byteswapped before sending an HPB READ command to the UFS device. Add the quirk UFS_DEVICE_QUIRK_SWAP_L2P_ENTRY_FOR_HPB_READ to address this. Link: https://lore.kernel.org/r/20210804182128.458356-2-huobean@gmail.comReviewed-by:
-
Bean Huo authored
ufshcd_add_cmd_upiu_trace() will be called later anyway. Simplify code by moving if-statement. Link: https://lore.kernel.org/r/20210802180803.100033-1-huobean@gmail.comReviewed-by:
-
Colin Ian King authored
The variable num_cnt is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Link: https://lore.kernel.org/r/20210804131344.112635-1-colin.king@canonical.comReviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
-
Dan Carpenter authored
The sp->free(sp); call frees "sp" and then the debug code dereferences it on the next line. Swap the order. Link: https://lore.kernel.org/r/20210803155625.GA22735@kili Fixes: 84318a9f ("scsi: qla2xxx: edif: Add send, receive, and accept for auth_els") Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 03 Aug, 2021 3 commits
-
-
David Disseldorp authored
These members are only used for ALUA sense detail propagation, which can just as easily be done via sense_reason_t. Link: https://lore.kernel.org/r/20210728115353.2396-4-ddiss@suse.deReviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
David Disseldorp <ddiss@suse.de> Signed-off-by:
-
David Disseldorp authored
The se_cmd scsi_asc and scsi_ascq members are only used for tracking ALUA SCSI sense detail between target_core_alua and translate_sense_reason(), so they're effectively always zero here. Link: https://lore.kernel.org/r/20210728115353.2396-3-ddiss@suse.de Cc: Chris Boot <bootc@bootc.net> Reviewed-by:
-
David Disseldorp authored
core_alua_state_lba_dependent() currently uses lun->lun_tg_pt_gp without holding the lun_tg_pt_gp_lock. The lock is taken in the caller, so obtain the needed tg_pt_gp_id there instead. Link: https://lore.kernel.org/r/20210728115353.2396-2-ddiss@suse.de Cc: Hannes Reinecke <hare@suse.de> Reviewed-by:
-
