- 07 Mar, 2019 18 commits
-
-
Xiang Chen authored
With default value of register SERDES_CFG, the link is not stable for some special disks when running IO. According to HW guys' suggestion, need to make the bit10~19 value of register SERDES_CFG the max value to increase the reliability of the HiLink. Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by:
Yupeng Zhou <zhouyupeng1@huawei.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Xiang Chen authored
If we exchange SAS expander from one SAS controller to other SAS controller without powering it down, the STP target port will maintain previous affiliation and reject all subsequent connection requests from other STP initiator ports with OPEN_REJECT (STP RESOURCES BUSY). To solve this issue, send HARD RESET to clear the previous affiliation of STP target port according to SPL (chapter 6.19.4). We (re-)introduce dev status flag to know if to sleep in NEXUS reset code or not for remote PHYs. The idea is that if the device is being initialised, we don't require the delay, and caller would wait for link to be established, cf. sas_ata_hard_reset(). Co-developed-by:
Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
John Garry authored
When the PHY comes down, we currently do not set the negotiated linkrate: root@(none)$ pwd /sys/class/sas_phy/phy-0:0 root@(none)$ more enable 1 root@(none)$ more negotiated_linkrate 12.0 Gbit root@(none)$ echo 0 > enable root@(none)$ more negotiated_linkrate 12.0 Gbit root@(none)$ This patch fixes the driver code to set it properly when the PHY comes down. If the PHY had been enabled, then set unknown; otherwise, flag as disabled. The logical place to set the negotiated linkrate for this scenario is PHY down routine, which is called from the PHY down ISR. However, it is not possible to know if the PHY comes down due to PHY disable or loss of link, as sas_phy.enabled member is not set until after the transport disable routine is complete, which races with the PHY down ISR. As an imperfect solution, use sas_phy_data.enable as the flag to know if the PHY is down due to disable. It's imperfect, as sas_phy_data is internal to libsas. I can't see another way without adding a new field to hisi_sas_phy and managing it, or changing SCSI SAS transport. Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Xiaofei Tan authored
The later revision of v3 hw has added an function of interrupt coalesce according to time for PHY RX errors. We set the coalesce time to 1s. Then we print PHY RX errors count when PHY RX errors happen, and don't need to worry that there may be too much log prints. Besides, we use hisi_sas_phy.lock to protect error count value. Because we update them by calling phy_get_events_v3_hw(), which is also used by core driver (for get PHY events function). We relocate phy_get_events_v3_hw() to avoid a further declaration. Signed-off-by:
Xiaofei Tan <tanxiaofei@huawei.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Xiang Chen authored
For internal IO and SMP IO, there is a time-out timer for them. In the timer handler, it checks whether IO is done according to the flag task->task_state_lock. There is an issue which may cause system suspended: internal IO or SMP IO is sent, but at that time because of hardware exception (such as inject 2Bit ECC error), so IO is not completed and also not timeout. But, at that time, the SAS controller reset occurs to recover system. It will release the resource and set the status of IO to be SAS_TASK_STATE_DONE, so when IO timeout, it will never complete the completion of IO and wait for ever. [ 729.123632] Call trace: [ 729.126791] [<ffff00000808655c>] __switch_to+0x94/0xa8 [ 729.133106] [<ffff000008d96e98>] __schedule+0x1e8/0x7fc [ 729.138975] [<ffff000008d974e0>] schedule+0x34/0x8c [ 729.144401] [<ffff000008d9b000>] schedule_timeout+0x1d8/0x3cc [ 729.150690] [<ffff000008d98218>] wait_for_common+0xdc/0x1a0 [ 729.157101] [<ffff000008d98304>] wait_for_completion+0x28/0x34 [ 729.165973] [<ffff000000dcefb4>] hisi_sas_internal_task_abort+0x2a0/0x424 [hisi_sas_test_main] [ 729.176447] [<ffff000000dd18f4>] hisi_sas_abort_task+0x244/0x2d8 [hisi_sas_test_main] [ 729.185258] [<ffff000008971714>] sas_eh_handle_sas_errors+0x1c8/0x7b8 [ 729.192391] [<ffff000008972774>] sas_scsi_recover_host+0x130/0x398 [ 729.199237] [<ffff00000894d8a8>] scsi_error_handler+0x148/0x5c0 [ 729.206009] [<ffff0000080f4118>] kthread+0x10c/0x138 [ 729.211563] [<ffff0000080855dc>] ret_from_fork+0x10/0x18 To solve the issue, callback function task_done of those IOs need to be called when on SAS controller reset. Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Xiang Chen authored
According to the tool fortify, phy_up_v3_hw() returns signed value, while it should return an unsigned value. So change variable "res" from int to irq_return_t. Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Dan Carpenter authored
The error handling was unintentionally left out so it introduces a Smatch static checker warning: drivers/scsi/qla2xxx/qla_attr.c:1655 qla2x00_port_speed_store() error: uninitialized symbol 'type'. Fixes: a7b9ca7fc87a ("scsi: qla2xxx: Add support for setting port speed") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Arnd Bergmann authored
On 32-bit architectures, we see a warning when %ld is used to print a size_t: In file included from drivers/scsi/lpfc/lpfc_init.c:62: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_new_io_buf': drivers/scsi/lpfc/lpfc_logmsg.h:62:45: error: format '%ld' expects argument of type 'long int', but argument 5 has type 'unsigned int' [-Werror=format=] This is harmless, but portable code should just use %zd to avoid the warning. Fixes: 0794d601 ("scsi: lpfc: Implement common IO buffers between NVME and SCSI") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Arnd Bergmann authored
The newly introduced 'cpu' variable is only used inside of an optional block, so we get a warning without CONFIG_SCSI_LPFC_DEBUG_FS: drivers/scsi/lpfc/lpfc_nvme.c: In function 'lpfc_nvme_io_cmd_wqe_cmpl': drivers/scsi/lpfc/lpfc_nvme.c:968:30: error: unused variable 'cpu' [-Werror=unused-variable] uint32_t code, status, idx, cpu; Move the declaration into the same block to avoid the warning. Fixes: 63df6d63 ("scsi: lpfc: Adapt cpucheck debugfs logic to Hardware Queues") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Andy Shevchenko authored
Switch to bitmap_zalloc() to show clearly what we are allocating. Besides that it returns pointer of bitmap type instead of opaque void *. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Acked-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Vasily Averin authored
In "XFS over network block device" scenario XFS can create IO requests with slab-based XFS metadata. During processing such requests tcp_sendpage() can merge skb fragments with neighbour slab objects. If receiving side is located on the same host tcp_recvmsg() can trigger BUG_ON in hardening check and crash the host with following message: usercopy: kernel memory exposure attempt detected from XXXXXXXX (kmalloc-512) (1024 bytes) This patch redirect such requests from sednpage to sendmsg path. The problem is similar to one described in recent commit 7e241f64 ("libceph: fall back to sendmsg for slab pages") Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Acked-by:
Chris Leech <cleech@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Arnd Bergmann authored
Depending on the target architecture and configuration, both phys_addr_t and dma_addr_t may be smaller than 'long long', so we get a warning when printing either of them using the %llx format string: drivers/scsi/qla2xxx/qla_iocb.c: In function 'qla24xx_walk_and_build_prot_sglist': drivers/scsi/qla2xxx/qla_iocb.c:1140:46: error: format '%llx' expects argument of type 'long long unsigned int', but argument 6 has type 'dma_addr_t' {aka 'unsigned int'} [-Werror=format=] "%s: page boundary crossing (phys=%llx len=%x)\n", ~~~^ %x __func__, sle_phys, sg->length); ~~~~~~~~ drivers/scsi/qla2xxx/qla_iocb.c:1180:29: error: format '%llx' expects argument of type 'long long unsigned int', but argument 7 has type 'dma_addr_t' {aka 'unsigned int'} [-Werror=format=] "%s: sg[%x] (phys=%llx sglen=%x) ldma_sg_len: %x dif_bundl_len: %x ldma_needed: %x\n", ~~~^ There are special %pad and %pap format strings in Linux that we could use here, but since the driver already does 64-bit arithmetic on the values, using a plain 'u64' seems more consistent here. Note: A possible related issue may be that the driver possibly checks the wrong kind of overflow: when an IOMMU is in use, buffers that cross a 32-bit boundary in physical addresses would still be mapped into dma addresses within the low 4GB space, so I suspect that we actually want to check sg_dma_address() instead of sg_phys() here. Fixes: 50b81275 ("scsi: qla2xxx: Fix DMA error when the DIF sg buffer crosses 4GB boundary") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
James Smart authored
The patch that replaced io channels for hdw_queues now reports the following static checker warning: drivers/scsi/lpfc/lpfc_init.c:11136 lpfc_sli4_hba_unset() error: we previously assumed 'phba->pport' could be null (see line 11074) Resolve by adding a pport NULL check. [mkp: tag tweak] Fixes: cdb42bec ("scsi: lpfc: Replace io_channels for nvme and fcp with general hdw_queues per cpu"_ Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
James Smart authored
The outer routine lpfc_sli_issue_iocb(), which decomposes into the SLI3 (s3) or SLI4 (s4) subroutines takes out the locks. For s3, it takes out the hbalock. For s4, it takes out the ring_lock. The lockdep check in the s3 and s4 subroutines both check hbalock, which is incorrect for s4. Revise the s4 subroutine to lockdep check the ring_lock. Reported-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Arnd Bergmann authored
Without CONFIG_OF, the of_match_node() helper does not evaluate its argument, and the compiler warns about the unused variable: drivers/scsi/ufs/ufs-hisi.c: In function 'ufs_hisi_probe': drivers/scsi/ufs/ufs-hisi.c:673:17: error: unused variable 'dev' [-Werror=unused-variable] Rework this code to pass the data directly, and while we're at it, correctly handle the const pointers. Fixes: 653fcb07 ("scsi: ufs: Add HI3670 SoC UFS driver support") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Bill Kuzeja authored
When trying to display tgt_counters in the debugfs, a panic can result. There is no null check for qpair after it is assigned in the for-loop. Unless vha->hw->queue_pair_map array is completely filled with entries, the system will panic dereferencing a null pointer. Signed-off-by:
Bill Kuzeja <william.kuzeja@stratus.com> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Steve Sistare authored
megaraid_sas takes 1+ seconds to load while waiting for firmware: [2.822603] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state [3.871003] megaraid_sas 0000:03:00.0: FW now in Ready state This is due to the following loop in megasas_transition_to_ready(), which waits a minimum of 1 second, even though the FW becomes ready in tens of millisecs: /* * The cur_state should not last for more than max_wait secs */ for (i = 0; i < max_wait; i++) { ... msleep(1000); ... dev_info(&instance->pdev->dev, "FW now in Ready state\n"); This is a regression, caused by a change of the msleep granularity from 1 to 1000 due to concern about waiting too long on systems with coarse jiffies. To fix, increase iterations and use msleep(20), which results in: [2.670627] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state [2.739386] megaraid_sas 0000:03:00.0: FW now in Ready state Fixes: fb2f3e96d80f ("scsi: megaraid_sas: Fix msleep granularity") Signed-off-by:
Steve Sistare <steven.sistare@oracle.com> Acked-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Cathy Avery authored
genlmsg_multicast_allns now returns the correct statuses when a message is sent to a listener. However in the case of adding a device we want to wait for the listener otherwise we may miss the the device during startup. Signed-off-by:
Cathy Avery <cavery@redhat.com> Acked-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 06 Mar, 2019 2 commits
-
-
Felipe Franciosi authored
The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of device-readable records and a single device-writable response entry: struct virtio_scsi_ctrl_tmf { // Device-readable part le32 type; le32 subtype; u8 lun[8]; le64 id; // Device-writable part u8 response; } The above should be organised as two descriptor entries (or potentially more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64 id" or after "u8 response". The Linux driver doesn't respect that, with virtscsi_abort() and virtscsi_device_reset() setting cmd->sc before calling virtscsi_tmf(). It results in the original scsi command payload (or writable buffers) added to the tmf. This fixes the problem by leaving cmd->sc zeroed out, which makes virtscsi_kick_cmd() add the tmf to the control vq without any payload. Cc: stable@vger.kernel.org Signed-off-by:
Felipe Franciosi <felipe@nutanix.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Erwan Velu authored
When the HARDWARE_ERROR/0x3e/0x1 case is triggered, the logical volume is offlined. When reading the kernel log, the reason why the device got offlined isn't reported to the user. This situation makes it difficult for admins to root cause. Log a message when this condition occurs. [mkp: tweaked commit message] Signed-off-by:
Erwan Velu <e.velu@criteo.com> Acked-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 27 Feb, 2019 15 commits
-
-
Varun Prakash authored
T6 adapters generates DDP completion message on receiving all iSCSI pdus in a sequence. Because of this, driver can not keep track of tcp sequence number for T6 adapters. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Varun Prakash authored
Instead of using viid to get pf number, directly get pf number from lldi->pf. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Benjamin Block authored
We had a test-report where, under memory pressure, adding LUNs to the systems would fail (the tests add LUNs strictly in sequence): [ 5525.853432] scsi 0:0:1:1088045124: Direct-Access IBM 2107900 .148 PQ: 0 ANSI: 5 [ 5525.853826] scsi 0:0:1:1088045124: alua: supports implicit TPGS [ 5525.853830] scsi 0:0:1:1088045124: alua: device naa.6005076303ffd32700000000000044da port group 0 rel port 43 [ 5525.853931] sd 0:0:1:1088045124: Attached scsi generic sg10 type 0 [ 5525.854075] sd 0:0:1:1088045124: [sdk] Disabling DIF Type 1 protection [ 5525.855495] sd 0:0:1:1088045124: [sdk] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB) [ 5525.855606] sd 0:0:1:1088045124: [sdk] Write Protect is off [ 5525.855609] sd 0:0:1:1088045124: [sdk] Mode Sense: ed 00 00 08 [ 5525.855795] sd 0:0:1:1088045124: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5525.857838] sdk: sdk1 [ 5525.859468] sd 0:0:1:1088045124: [sdk] Attached SCSI disk [ 5525.865073] sd 0:0:1:1088045124: alua: transition timeout set to 60 seconds [ 5525.865078] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA [ 5526.015070] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA [ 5526.015213] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA [ 5526.587439] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured [ 5526.588562] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured Looking at the code of scsi_alloc_sdev(), and all the calling contexts, there seems to be no reason to use GFP_ATMOIC here. All the different call-contexts use a mutex at some point, and nothing in between that requires no sleeping, as far as I could see. Additionally, the code that later allocates the block queue for the device (scsi_mq_alloc_queue()) already uses GFP_KERNEL. There are similar allocations in two other functions: scsi_probe_and_add_lun(), and scsi_add_lun(),; that can also be done with GFP_KERNEL. Here is the contexts for the three functions so far: scsi_alloc_sdev() scsi_probe_and_add_lun() scsi_sequential_lun_scan() __scsi_scan_target() scsi_scan_target() mutex_lock() scsi_scan_channel() scsi_scan_host_selected() mutex_lock() scsi_report_lun_scan() __scsi_scan_target() ... __scsi_add_device() mutex_lock() __scsi_scan_target() ... scsi_report_lun_scan() ... scsi_get_host_dev() mutex_lock() scsi_probe_and_add_lun() ... scsi_add_lun() scsi_probe_and_add_lun() ... So replace all these, and give them a bit of a better chance to succeed, with more chances of reclaim. Signed-off-by:
Benjamin Block <bblock@linux.ibm.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Gustavo A. R. Silva authored
Fix the following warnings by adding the proper missing breaks: drivers/scsi/mpt3sas/mpt3sas_base.c: In function _base_display_OEMs_branding : drivers/scsi/mpt3sas/mpt3sas_base.c:3548:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (ioc->pdev->subsystem_device) { ^~~~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3566:3: note: here case MPI2_MFGPAGE_DEVID_SAS2308_2: ^~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3567:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (ioc->pdev->subsystem_device) { ^~~~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3601:3: note: here case MPI25_MFGPAGE_DEVID_SAS3008: ^~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3735:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (ioc->pdev->subsystem_device) { ^~~~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3745:3: note: here case MPI2_MFGPAGE_DEVID_SAS2308_2: ^~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3746:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (ioc->pdev->subsystem_device) { ^~~~~~ drivers/scsi/mpt3sas/mpt3sas_base.c:3768:3: note: here default: ^~~~~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Gustavo A. R. Silva authored
Add missing break statement and fix identation issue. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 9cb62fa2 ("aacraid: Log firmware AIF messages") Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
No users left, kill it. Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
Use request tag instead of the serial number when printing out logging messages. Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
Use the request tag for logging instead of the scsi command serial number. Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
Drop references to scsi_cmnd->serial_number. Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Iustin Pop authored
Negative constant left-shift is undefined behaviour in the C standard, and as such newer versions of clang (at least) warn against it. GCC supports it for a long time, but it would be better to remove it and rely on defined behaviour. My understanding is "~(-1 << N)" in 2's complement is intended to generate a bit pattern of zeroes ending with N '1' bits. The same can be achieved by "(1 << N) - 1" in a well-defined way, so switch to it to remove the warning. Tested: building a kernel with generic SCSI tape, and checking basic operations (mt status, mt eject) on a real LTO unit. Cannot test the osst driver. Signed-off-by:
Iustin Pop <iustin@k1024.org> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Avri Altman authored
Add this functionality, placing the descriptor being read in the actual data buffer in the bio. That is, for both read and write descriptors query upiu, we are using the job's request_payload. This in turn, is mapped back in user land to the applicable sg_io_v4 xferp: dout_xferp for write descriptor, and din_xferp for read descriptor. Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Avri Altman authored
Allow to read descriptors via raw upiu. This in fact was forbidden just as a precaution, as ufs-bsg actually enforces which functionality is supported. Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Avri Altman authored
When we had a write descriptor query upiu, we appended the descriptor right after the bsg request. This was fine as the bsg driver allows to allocate whatever buffer we needed in its job request. Still, the proper way to deliver payload, however small (we only write config descriptors of 144 bytes), is by using the job request payload data buffer. So change this ABI now, while ufs-bsg is still new, and nobody is actually using it. Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Marc Gonzalez authored
The UFSHC driver defines a few quirks that are not used anywhere: UFS_DEVICE_QUIRK_BROKEN_LCC UFS_DEVICE_NO_VCCQ UFS_DEVICE_QUIRK_NO_LINK_OFF UFS_DEVICE_NO_FASTAUTO Let's remove them. Acked-by:
Avri Altman <avri.altman@wdc.com> Acked-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Signed-off-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Marc Gonzalez authored
This reverts commit 60f01870. There was one conflict in drivers/scsi/ufs/ufshcd.c <<<<<<< HEAD /* Init check for device descriptor sizes */ ufshcd_init_desc_sizes(hba); ret = ufs_get_device_desc(hba, &card); if (ret) { dev_err(hba->dev, "%s: Failed getting device info. err = %d\n", __func__, ret); goto out; } ufs_fixup_device_setup(hba, &card); ufshcd_tune_unipro_params(hba); ret = ufshcd_set_vccq_rail_unused(hba, (hba->dev_quirks & UFS_DEVICE_NO_VCCQ) ? true : false); if (ret) goto out; ======= ufs_advertise_fixup_device(hba); >>>>>>> parent of 60f01870... scsi: ufs: disable vccq if it's not needed by UFS device Resolution: keep HEAD, and delete the ufshcd_set_vccq_rail_unused() call and corresponding error-handling code. Clean up loose ends in a follow-up patch. 60f01870 introduced a small power optimization: ignore the vccq load specified in the UFSHC DT node when said host controller is connected to specific Flash chips (currently, Samsung and Hynix). Unfortunately, this optimization breaks UFS on systems where vccq powers not only the Flash chip, but the host controller as well, such as APQ8098 MEDIABOX or MTP8998: [ 3.929877] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 for idn 13 failed, index 0, err = -11 [ 5.433815] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 for idn 13 failed, index 0, err = -11 [ 6.937771] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 for idn 13 failed, index 0, err = -11 [ 6.937866] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr_retry: query attribute, idn 13, failed with error -11 after 3 retires [ 6.946412] ufshcd-qcom 1da4000.ufshc: ufshcd_disable_auto_bkops: failed to enable exception event -11 [ 6.957972] ufshcd-qcom 1da4000.ufshc: dme-peer-get: attr-id 0x1587 failed 3 retries [ 6.967181] ufshcd-qcom 1da4000.ufshc: dme-peer-get: attr-id 0x1586 failed 3 retries [ 6.975025] ufshcd-qcom 1da4000.ufshc: ufshcd_get_max_pwr_mode: invalid max pwm tx gear read = 0 [ 6.982755] ufshcd-qcom 1da4000.ufshc: ufshcd_probe_hba: Failed getting max supported power mode [ 8.505770] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [ 10.009807] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [ 11.513766] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [ 11.513861] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag_retry: query attribute, opcode 5, idn 3, failed with error -11 after 3 retires [ 13.049807] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode 0x01 for idn 8 failed, index 0, err = -11 [ 14.553768] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode 0x01 for idn 8 failed, index 0, err = -11 [ 16.057767] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode 0x01 for idn 8 failed, index 0, err = -11 [ 16.057872] ufshcd-qcom 1da4000.ufshc: ufshcd_read_desc_param: Failed reading descriptor. desc_id 8, desc_index 0, param_offset 0, ret -11 [ 16.067109] ufshcd-qcom 1da4000.ufshc: ufshcd_init_icc_levels: Failed reading power descriptor.len = 98 ret = -11 [ 37.073787] ufshcd-qcom 1da4000.ufshc: link startup failed 1 In my opinion, the rationale for the original patch is questionable. If neither the UFSHC, nor the Flash chip, require any load from vccq, then that power rail should simply not be specified at all in the DT. Working around that fact in the driver is detrimental, as evidenced by the failure to initialize the host controller on MSM8998. Acked-by:
Avri Altman <avri.altman@wdc.com> Acked-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 26 Feb, 2019 4 commits
-
-
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:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Avri Altman authored
Those are no longer in use since commit 242f9dcb ("block: unify request timeout handling"). Signed-off-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
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:
Christoph Anton Mitterer <calestyo@scientia.net> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
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:
Martin K. Petersen <martin.petersen@oracle.com>
-
- 19 Feb, 2019 1 commit
-
-
Sedat Dilek authored
commit 1917d42d ("fcoe: use enum for fip_mode") introduces a separate enum for the fip_mode that shall be used during initialisation handling until it is passed to fcoe_ctrl_link_up to set the initial fip_state. That change was incomplete and gcc quietly converted in various places between the fip_mode and the fip_state enum values with implicit enum conversions, which fortunately cannot cause any issues in the actual code's execution. clang however warns about these implicit enum conversions in the scsi drivers. This commit consolidates the use of the two enums, guided by clang's enum-conversion warnings. This commit now completes the use of the fip_mode: It expects and uses fip_mode in {bnx2fc,fcoe}_interface_create and fcoe_ctlr_init, and it calls fcoe_ctrl_set_set() with the correct values in fcoe_ctlr_link_up(). It also breaks the association between FIP_MODE_AUTO and FIP_ST_AUTO to indicate these two enums are distinct. Link: https://github.com/ClangBuiltLinux/linux/issues/151 Fixes: 1917d42d ("fcoe: use enum for fip_mode") Reported-by:
Dmitry Golovin <dima@golovin.in> Original-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> CC: Lukas Bulwahn <lukas.bulwahn@gmail.com> CC: Nick Desaulniers <ndesaulniers@google.com> CC: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Tested-by:
Nathan Chancellor <natechancellor@gmail.com> Suggested-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-