- 15 Mar, 2019 1 commit
-
-
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:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> [jejb: fix commit oneliner] Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com>
-
- 14 Mar, 2019 2 commits
-
-
Sagar Biradar authored
Fix performance issue where the queue depth for SmartIOC logical volumes is set to 1, and allow the usual logical volume code to be executed Fixes: a052865f (aacraid: Set correct Queue Depth for HBA1000 RAW disks) Cc: stable@vger.kernel.org Signed-off-by:
Sagar Biradar <Sagar.Biradar@microchip.com> Reviewed-by:
Dave Carroll <david.carroll@microsemi.com> Signed-off-by:
-
Dan Carpenter authored
It used to be that "error" was set to -ENODEV at the start of the function but we shifted some code around an now "error" is set to zero for most error paths. There is a mix of direct returns and "goto out" but I changed everything to direct returns for consistency. Fixes: 56de8357 ("scsi: lpfc: fix calls to dma_set_mask_and_coherent()") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
- 08 Mar, 2019 1 commit
-
-
Lee Duncan authored
If there is an error queueing an iscsi command in iscsi_queuecommand(), for example if the transport fails to take the command in sessuin->tt->xmit_task(), then the error path can call iscsi_complete_task() without first aquiring the back_lock as required. This can lead to things like ITT pool can get corrupt, resulting in duplicate ITTs being sent out. The solution is to hold the back_lock around iscsi_complete_task() calls, and to add a little commenting to help others understand when back_lock must be held. Signed-off-by:
Lee Duncan <lduncan@suse.com> Acked-by:
Chris Leech <cleech@redhat.com> Signed-off-by:
-
- 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:
-
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:
-
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:
-
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:
-
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 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:
-
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: -
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:
-
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:
-
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:
-
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:
-
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:Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
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:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
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:
-
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:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
-
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:
-
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:
-
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:
-
- 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:
-
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:
-
- 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:
-
Varun Prakash authored
Instead of using viid to get pf number, directly get pf number from lldi->pf. Signed-off-by:
-
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:
-
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:
-
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:
-
Hannes Reinecke authored
No users left, kill it. Signed-off-by:
-
Hannes Reinecke authored
Use request tag instead of the serial number when printing out logging messages. Signed-off-by:
-
Hannes Reinecke authored
Use the request tag for logging instead of the scsi command serial number. Signed-off-by:
-
Hannes Reinecke authored
Drop references to scsi_cmnd->serial_number. Signed-off-by:
-
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:
-
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:
Evan Green <evgreen@chromium.org> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
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 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:
-
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:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by:
-
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:
-
- 26 Feb, 2019 1 commit
-
-
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:
-
