- 27 Sep, 2016 3 commits
-
-
Christoph Hellwig authored
The driver has not seen any maintainer activity or other work that wasn't tree wide conversion or clenaups in the entire history of the git tree. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Hannes Reinicke <hare@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
tang.junhui authored
buff should be freed before returning with SCSI_DH_RETRY in alua_rtpg(). Signed-off-by:
tang.junhui <tang.junhui@zte.com.cn> Signed-off-by:
-
Baoyou Xie authored
We get a few warnings when building kernel with W=1: drivers/scsi/lpfc/lpfc_sli.c:5693:1: warning: no previous prototype for 'lpfc_set_features' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_sli.c:8972:1: warning: no previous prototype for 'lpfc_sli_calc_ring' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_els.c:4621:1: warning: no previous prototype for 'lpfc_rdp_res_link_service' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_els.c:4633:1: warning: no previous prototype for 'lpfc_rdp_res_sfp_desc' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_els.c:4698:1: warning: no previous prototype for 'lpfc_rdp_res_link_error' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_els.c:4727:1: warning: no previous prototype for 'lpfc_rdp_res_bbc_desc' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_els.c:4752:1: warning: no previous prototype for 'lpfc_rdp_res_oed_temp_desc' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_els.c:4780:1: warning: no previous prototype for 'lpfc_rdp_res_oed_voltage_desc' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_els.c:4809:1: warning: no previous prototype for 'lpfc_rdp_res_oed_txbias_desc' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_els.c:4838:1: warning: no previous prototype for 'lpfc_rdp_res_oed_txpower_desc' [-Wmissing-prototypes] .... In fact, these functions are only used in the file in which they are declared and don't need a declaration, but can be made static. So this patch marks these functions with 'static'. Signed-off-by:
Baoyou Xie <baoyou.xie@linaro.org> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
-
- 21 Sep, 2016 2 commits
-
-
Don Brace authored
calling fill_cmd() using a MACRO definition not handled in switch statement causes BUG() to be called. Signed-off-by:
Don Brace <don.brace@microsemi.com> Reviewed-by:
Scott Teel <scott.teel@microsemi.com> Reviewed-by:
Kevin Barnett <kevin.barnett@microsemi.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
Kiwoong Kim authored
When any UFS host controller receives a TM(Task Management) response from a UFS device, UFS driver has been recognize like receiving a message of "Task Management Function Complete"(00h) in all cases, so far. That means there is no pending task for a tag of the TM request sent before in the UFS device. That's because the byte offset 6 in TM response which has been used to get a TM service response so far represents just whether or not a TM transmission passes. Regarding UFS spec, the correct byte offset to get TM service response is 15, not 6. I tested that UFS driver responds properly for the TM response from a UFS device with an reference board with exynos8890, as follow: No pending task -> Task Management Function Complete (00h) Pending task -> Task Management Function Succeeded (08h) [mkp: applied by hand] Signed-off-by:
Kiwoong Kim <kwmad.kim@samsung.com> Signed-off-by:
HeonGwang Chu <hg.chu@samsung.com> Tested-by:
-
- 19 Sep, 2016 7 commits
-
-
Brian King authored
If a VFC port gets unmapped in the VIOS, it may not respond with a CRQ init complete following H_REG_CRQ. If this occurs, we can end up having called scsi_block_requests and not a resulting unblock until the init complete happens, which may never occur, and we end up hanging I/O requests. This patch ensures the host action stay set to IBMVFC_HOST_ACTION_TGT_DEL so we move all rports into devloss state and unblock unless we receive an init complete. Cc: <stable@vger.kernel.org> Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Acked-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
-
Baoyou Xie authored
We get a few warnings when building kernel with W=1: drivers/scsi/megaraid/megaraid_sas_fusion.c:281:1: warning: no previous prototype for 'megasas_free_cmds_fusion' [-Wmissing-prototypes] drivers/scsi/megaraid/megaraid_sas_fusion.c:714:1: warning: no previous prototype for 'megasas_ioc_init_fusion' [-Wmissing-prototypes] .... In fact, these functions are declared in drivers/scsi/megaraid/megaraid_sas_base.c, but should be declared in a header file, thus can be recognized in other file. So this patch adds the declarations into drivers/scsi/megaraid/megaraid_sas_fusion.h. Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Brian King authored
Whenever multiple HRRQs are enabled, which is the default setting now, we end up seeing the following message logged prior to initialization of each HRRQ: Starting IOA initialization sequence This results in 16 of these messages on most adapters, which serves little purpose. Change to just log this once. Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
-
Brian King authored
A 9084 error gets logged by the ipr adapter when adapter raw mode gets enabled. A bunch of unformatted hex data also gets logged for this error, which is of little use, so let's avoid logging it by default in order to avoid the log getting polluted with useless data. Signed-off-by:
-
kevin Barnett authored
In the ioaccel path, the calculation of the starting LBA for READ(6)/WRITE(6) SCSI commands does not take into account the most significant 5 bits of the LBA: it only uses the least significant 16 bits of the starting LBA. Reported-by:
Mahesh Rajashekhara <mahesh.rajashekhara@microsemi.com> Signed-off-by:
-
Mahesh Rajashekhara authored
Missing 5 bits of byte 1 in the LBA issued by SML. Reported-by:
-
Bryant G. Ly authored
[mkp: applied by hand] Signed-off-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Reviewed-by:
-
- 15 Sep, 2016 5 commits
-
-
Dan Carpenter authored
We need to put an upper bound on "user_len" so the memcpy() doesn't overflow. Cc: <stable@vger.kernel.org> Reported-by:
Marco Grassi <marco.gra@gmail.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Wei Yongjun authored
Fix to return error code -ENOMEM from the dma mapping error handling case instead of 0, as done elsewhere in this function. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Christoph Hellwig authored
These should go together with the rest of the T10 protection information defintions. [mkp: s/T10_DIF/T10_PI/] Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Christoph Hellwig authored
Instead of defining a local version of it. Signed-off-by:
-
Christoph Hellwig authored
And remove the declaration of the latter in sd.h as scsi_debug was the only user. Signed-off-by:
-
- 14 Sep, 2016 23 commits
-
-
Wei Yongjun authored
Fix to return error code -ENOMEM from the workqueue alloc error handling case instead of 0, as done elsewhere in this function. Signed-off-by:
-
Don Brace authored
Reviewed-by:
Scott Benesh <scott.benest@microsemi.com> Reviewed-by:
-
Scott Teel authored
Reviewed-by:
-
Scott Teel authored
Before using vendor-specific VPD pages for getting raid_level and device_id, check for page support. If page isn't supported, don't try to use it. Also, pay attention to return status on hpsa_get_device_id. [mkp: fix boolean return warnings reported by kbuild test robot] Reviewed-by:
-
Don Brace authored
A device can be deleted causing NULL pointer issues. Reviewed-by:
Scott Benesh <scott.benesh@microsemi.com> Reviewed-by:
-
Don Brace authored
Currently we are checking for external status before we are determining if a device is an external device. Reviewed-by:
-
Finn Thain authored
Large PIO transfers are broken up into chunks to try to avoid disabling local IRQs for long periods. But IRQs are still disabled for too long and this causes SCC FIFO overruns during serial port transfers. This patch reduces the PIO chunk size to reduce interrupt latency to something on the order of milliseconds, at the expense of additional CPU overhead from extra iterations of the NCR5380_main() loop. That CPU overhead is a problem for slow machines (e.g. mac_scsi on 25 MHz 68030) but these machines generally use PDMA not PIO. This patch doesn't make the overhead any worse on my Mac LC III (because it only gets about 510 accesses per ms). This patch decreases disk performance by a fraction of one percent for dmx3191d on my 333 MHz PowerPC 750. Other affected hardware (such as g_NCR5380 on x86) was not tested but 5380 ISA cards generally use PDMA and not PIO. [mkp: fix whitespace] Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Reviewed-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
-
Daniel Wagner authored
There is only one waiter for the completion, therefore there is no need to use complete_all(). Let's make that clear by using complete() instead of complete_all(). The usage pattern of the completion is: waiter context waker context virtscsi_tmf() DECLARE_COMPLETION_ONSTACK() virtscsi_kick_cmd() wait_for_completion() virtscsi_complete_free() complete() Signed-off-by:Daniel Wagner <daniel.wagner@bmw-carit.de> Reviewed-by:
-
Daniel Wagner authored
There is only one waiter for the completion, therefore there is no need to use complete_all(). Let's make that clear by using complete() instead of complete_all(). The usage pattern of the completion is: waiter context waker context sym_eh_handler() struct completion eh_done init_completion(eh_done) pci_channel_offline() wait_for_completion_timeout(eh_done) sym2_io_resume() complete(eh_done) Signed-off-by: -
Daniel Wagner authored
The (re)initializing of the completion object should be done before we trigger the transfer. Doing this after triggering the hardware opens up a race window. Without the timeout we would problaly even deadlock. Use also reinit_completion because we initalize the whole data structure in csio_scscim_init(). There is only one waiter for the completion, therefore there is no need to use complete_all(). Let's make that clear by using complete() instead of complete_all(). The usage pattern of the completion is: waiter context waker context csio_eh_abort_handler() reinit_completion() wait_for_completion_timeout() csio_scsi_err_handler() complete() [mkp: fix typo] Signed-off-by: -
Colin Ian King authored
A dev_printk message spans two lines and the literal string is missing a white space between words. Add the white space. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
John Garry authored
When the v2 hw is attached with many disks through an expander, there may be OOB reset resulting in a PHY going down after the speed is negotiated (very low probability). This issue is resolved by modifying the link control registers to send three identify frames before the PHY is ready (according to 6.10.3.3.2 in SAS 3.0 spec) and close ready when the PHY is down. Signed-off-by:
NengLong Zhao <zhaonenglong@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Reviewed-by:
-
John Garry authored
In setup_itct_v2_hw(), SATA device type SAS_SATA_PENDING is missing, so add it. Note: The HiSi SAS controller does not support SATA PM, so do not handle SAS_SATA_PM_PORT or SAS_SATA_PM. Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by:
-
John Garry authored
Function config_id_frame_v1_hw() is called twice for each PHY during initialisation, which is unneeded. So remove init_id_frame_v1_hw(), which only calls config_id_frame_v1_hw(). We will keep the call to config_id_frame_v1_hw() in start_phy_v1_hw() since it will be used for PHY reset functions. Signed-off-by:
-
John Garry authored
Function config_id_frame_v2_hw() is called twice for each PHY during initialisation, which is unneeded. So remove init_id_frame_v2_hw(), which only calls config_id_frame_v2_hw(). We will keep the call to config_id_frame_v2_hw() in start_phy_v2_hw() since it will be used for PHY reset functions. Signed-off-by:
-
John Garry authored
The endianness for the SAS address in the TX_ID_DWORD registers is set incorrectly. We see errors like this in the boot log for v2 hw (which would have the same issue as v1 hw): [ 7.583284] sas: target proto 0x0 at 50000d1108e7923f:0x1f not handled This is due to the host SAS addr not matching the PHY SAS addr in the expander host-attached phy discovery responses. To fix, we byte swap the SAS addr from BE to LE (which is the endianness of the SAS controller). Signed-off-by:
-
John Garry authored
The endianness for the SAS address in the TX_ID_DWORD registers is set incorrectly. We see errors like this in the boot log: [ 7.583284] sas: target proto 0x0 at 50000d1108e7923f:0x1f not handled This is due to the host SAS addr not matching the PHY SAS addr in the expander host-attached phy discovery responses. To fix, we byte swap the SAS addr from BE to LE (which is the endianness of the SAS controller). Signed-off-by:
-
John Garry authored
The device DMA mask was being set after the bulk of the DMA allocations in the driver init, so potentially DMA allocates fail. To resolve, relocate before allocating the DMA memory when initialising the driver. Signed-off-by:
-
John Garry authored
If hisi_sas_task_prep() fails for a SATA device due to PHY down, we return a failure to libata and also call task_done(), which will cause ata_qc_complete() to be called twice: - first call from hisi_sas_task_prep(), which will clear flag ATA_QCFLAG_ACTIVE - ata_qc_complete() called from libata The warning call trace is as follows: [ 117.070206] [<ffff0000084f59b0>] __ata_qc_complete+0xf4/0x11c [ 117.070208] [<ffff0000084f5b58>] ata_qc_complete+0x180/0x200 [ 117.070210] [<ffff0000084f5dd0>] ata_qc_issue+0x110/0x354 [ 117.070212] [<ffff0000084f6254>] ata_exec_internal_sg+0x240/0x4d0 [ 117.070214] [<ffff0000084f6544>] ata_exec_internal+0x60/0xa0 [ 117.070217] [<ffff000008501580>] ata_read_log_page+0x188/0x1b4 [ 117.070218] [<ffff0000085017dc>] ata_eh_analyze_ncq_error+0xa8/0x274 [ 117.070220] [<ffff000008501a3c>] ata_eh_link_autopsy+0x94/0x8c8 [ 117.070222] [<ffff0000085022a4>] ata_eh_autopsy+0x34/0xe8 [ 117.070223] [<ffff00000850540c>] ata_do_eh+0x28/0xc0 [ 117.070225] [<ffff0000085054e0>] ata_std_error_handler+0x3c/0x84 [ 117.070227] [<ffff000008505140>] ata_scsi_port_error_handler+0x480/0x674 [ 117.070230] [<ffff0000084e3020>] async_sas_ata_eh+0x44/0x78 [ 117.070231] [<ffff0000080d6b8c>] async_run_entry_fn+0x40/0x104 [ 117.070234] [<ffff0000080ce518>] process_one_work+0x128/0x2f0 [ 117.070235] [<ffff0000080ce738>] worker_thread+0x58/0x434 [ 117.070237] [<ffff0000080d416c>] kthread+0xd4/0xe8 [ 117.070240] [<ffff000008084e10>] ret_from_fork+0x10/0x40 The issue is resolved by simply returning a failure status code to the upper layer. Signed-off-by:
-
John Garry authored
In function phy_up_v2_hw(), we needlessly recalculate the phy linkrate for all phys, and the calculation is incorrect for phy8, so remove this code. Signed-off-by:
-
John Garry authored
The Delivery queue enable register should only be written to once at reset for v2 hw. Signed-off-by:
-
John Garry authored
The memory calculation for the tags bitmap should use BITS_PER_BYTE macro instead of coincidental same value of sizeof(unsigned long). Signed-off-by:
-
John Garry authored
Currently the slot memory is zeroed when it is freed and also when it is reused, like in hisi_sas_task_prep(). Optimise by avoiding the redundant zeroing in the free. Signed-off-by:
-
