Skip to content

L
linux
Switch branch/tag
  1. 26 Feb, 2019 4 commits
    • YueHaibing's avatar
      scsi: megaraid_sas: Remove a bunch of set but not used variables · 379c003f
      YueHaibing authored 
      Fixes gcc '-Wunused-but-set-variable' warning:

drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'wait_and_poll':
drivers/scsi/megaraid/megaraid_sas_fusion.c:936:25: warning:
 variable 'fusion' set but not used [-Wunused-but-set-variable]

drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_sync_map_info':
drivers/scsi/megaraid/megaraid_sas_fusion.c:1329:6: warning:
 variable 'size_sync_info' set but not used [-Wunused-but-set-variable]

drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_init_adapter_fusion':
drivers/scsi/megaraid/megaraid_sas_fusion.c:1639:39: warning:
 variable 'reg_set' set but not used [-Wunused-but-set-variable]

drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_is_prp_possible':
drivers/scsi/megaraid/megaraid_sas_fusion.c:1925:25: warning:
 variable 'fusion' set but not used [-Wunused-but-set-variable]

drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_make_prp_nvme':
drivers/scsi/megaraid/megaraid_sas_fusion.c:2047:25: warning:
 variable 'fusion' set but not used [-Wunused-but-set-variable]

drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_build_ldio_fusion':
drivers/scsi/megaraid/megaraid_sas_fusion.c:2620:42: warning:
 variable 'req_desc' set but not used [-Wunused-but-set-variable]

drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_build_and_issue_cmd_fusion':
drivers/scsi/megaraid/megaraid_sas_fusion.c:3245:25: warning:
 variable 'fusion' set but not used [-Wunused-but-set-variable]

drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_task_abort_fusion':
drivers/scsi/megaraid/megaraid_sas_fusion.c:4398:25: warning:
 variable 'fusion' set but not used [-Wunused-but-set-variable]

drivers/scsi/megaraid/megaraid_sas_fusion.c: In function 'megasas_reset_target_fusion':
drivers/scsi/megaraid/megaraid_sas_fusion.c:4484:25: warning:
 variable 'fusion' set but not used [-Wunused-but-set-variable]

They're not used anymore and can be removed.
Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
Acked-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      379c003f
    • Avri Altman's avatar
      scsi: clean obsolete return values of eh_timed_out · 82c10ac7
      Avri Altman authored 
      Those are no longer in use since commit 242f9dcb
("block: unify request timeout handling").
Signed-off-by: default avatarAvri Altman <avri.altman@wdc.com>
Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      82c10ac7
    • Martin K. Petersen's avatar
      scsi: sd: Optimal I/O size should be a multiple of physical block size · a83da8a4
      Martin K. Petersen authored 
      It was reported that some devices report an OPTIMAL TRANSFER LENGTH of
0xFFFF blocks. That looks bogus, especially for a device with a
4096-byte physical block size.

Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's
reported physical block size.

To make the sanity checking conditionals more readable--and to
facilitate printing warnings--relocate the checking to a helper
function. No functional change aside from the printks.

Cc: <stable@vger.kernel.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759Reported-by: default avatarChristoph Anton Mitterer <calestyo@scientia.net>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      a83da8a4
    • Martin K. Petersen's avatar
      scsi: MAINTAINERS: SCSI initiator and target tweaks · d1420f2c
      Martin K. Petersen authored 
      Nic has been absent for a while and target changes now go through the SCSI
tree. To avoid confusion wrt. the NVMe target, clarify that this entry
refers to the SCSI target subsystem.

Also add patchwork links for both SCSI initiator and target.
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      d1420f2c
  3. 19 Feb, 2019 19 commits
  5. 14 Feb, 2019 2 commits
  7. 13 Feb, 2019 5 commits
  9. 12 Feb, 2019 7 commits
  11. 08 Feb, 2019 3 commits
    • John Garry's avatar
      scsi: hisi_sas: Do some more tidy-up · 4a8bec88
      John Garry authored 
      Do some very minor tidy-up, for things like needlessly initing variable and
not leaving whitespace before quote endings.

Originally-from: Xiang Chen <chenxiang66@hisilicon.com>
Originally-from: Luo Jiaxing <luojiaxing@huawei.com>
Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      4a8bec88
    • Xiang Chen's avatar
      scsi: hisi_sas: Use pci_irq_get_affinity() for v3 hw as experimental · 4fefe5bb
      Xiang Chen authored 
      For auto-control irq affinity mode, choose the dq to deliver IO according
to the current CPU.

Then it decreases the performance regression that fio and CQ interrupts are
processed on different node.

For user control irq affinity mode, keep it as before.

To realize it, also need to distinguish the usage of dq lock and sas_dev
lock.

We mark as experimental due to ongoing discussion on managed MSI IRQ
during hotplug:
https://marc.info/?l=linux-scsi&m=154876335707751&w=2

We're almost at the point where we can expose multiple queues to the upper
layer for SCSI MQ, but we need to sort out the per-HBA tags performance
issue.
Signed-off-by: default avatarXiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      4fefe5bb
    • John Garry's avatar
      scsi: hisi_sas: Issue internal abort on all relevant queues · 795f25a3
      John Garry authored 
      To support queue mapped to a CPU, it needs to be ensured that issuing an
internal abort is safe, in that it is guaranteed that an internal abort is
processed for a single IO or a device after all the relevant command(s)
which it is attempting to abort have been processed by the controller.

Currently we only deliver commands for any device on a single queue to
solve this problem, as we know that commands issued on the same queue will
be processed in order, and we will not have a scenario where the internal
abort is racing against a command(s) which it is trying to abort.

To enqueue commands on queue mapped to a CPU, choosing a queue for an
command is based on the associated queue for the current CPU, so this is
not safe for internal abort since it would definitely not be guaranteed
that commands for the command devices are issued on the same queue.

To solve this issue, we take a bludgeoning approach, and issue a separate
internal abort on any queue(s) relevant to the command or device, in that
we will be guaranteed that at least one of these internal aborts will be
received last in the controller.

So, for aborting a single command, we can just force the internal abort to
be issued on the same queue as the command which we are trying to abort.

For aborting all commands associated with a device, we issue a separate
internal abort on all relevant queues. Issuing multiple internal aborts in
this fashion would have not side affect.
Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
Signed-off-by: default avatarXiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      795f25a3
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7