- 21 Dec, 2018 4 commits
-
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1475400 ("Missing break in switch") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/fcoe/fcoe.c: In function 'fcoe_recv_frame': drivers/scsi/fcoe/fcoe.c:1672:20: warning: variable 'port' set but not used [-Wunused-but-set-variable] drivers/scsi/fcoe/fcoe.c: In function 'fcoe_device_notification': drivers/scsi/fcoe/fcoe.c:1861:20: warning: variable 'port' set but not used [-Wunused-but-set-variable] Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Johannes Thumshirn <jth@kernel.org> Signed-off-by:
-
Yanjiang Jin authored
We must free all irqs during shutdown, else kexec's 2nd kernel would hang in pqi_wait_for_completion_io() as below: Call trace: pqi_wait_for_completion_io pqi_submit_raid_request_synchronous.constprop.78+0x23c/0x310 [smartpqi] pqi_configure_events+0xec/0x1f8 [smartpqi] pqi_ctrl_init+0x814/0xca0 [smartpqi] pqi_pci_probe+0x400/0x46c [smartpqi] local_pci_probe+0x48/0xb0 pci_device_probe+0x14c/0x1b0 really_probe+0x218/0x3fc driver_probe_device+0x70/0x140 __driver_attach+0x11c/0x134 bus_for_each_dev+0x70/0xc8 driver_attach+0x30/0x38 bus_add_driver+0x1f0/0x294 driver_register+0x74/0x12c __pci_register_driver+0x64/0x70 pqi_init+0xd0/0x10000 [smartpqi] do_one_initcall+0x60/0x1d8 do_init_module+0x64/0x1f8 load_module+0x10ec/0x1350 __se_sys_finit_module+0xd4/0x100 __arm64_sys_finit_module+0x28/0x34 el0_svc_handler+0x104/0x160 el0_svc+0x8/0xc This happens only in the following combinations: 1. smartpqi is built as module, not built-in; 2. We have a disk connected to smartpqi card; 3. Both kexec's 1st and 2nd kernels use this disk as Rootfs' mount point. Signed-off-by:
Yanjiang Jin <yanjiang.jin@hxt-semitech.com> Acked-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
Don Brace authored
Fix kbuild warning and fallout from linux-next -Wimplicit-fallthrough. [mkp: added fall through statements] Signed-off-by:
-
- 20 Dec, 2018 36 commits
-
-
Don Brace authored
- need to bump up the driver version because of the OFA patch and the fw status register read timeout patch. Reviewed-by:
Gerry Morong <gerry.morong@microsemi.com> Signed-off-by:
-
Mahesh Rajashekhara authored
- when OFA event occurs, driver will stop traffic to RAID/HBA path. Driver waits for all the outstanding requests to complete. - Driver sends OFA event acknowledgment to firmware. - Driver will wait until the new firmware is up and running. - Driver will free up the resources. - Driver calls SIS/PQI initialization and rescans the device list. - Driver will resume the traffic to RAID/HBA path. Reviewed-by:
Murthy Bhat <murthy.bhat@microsemi.com> Signed-off-by:
Mahesh Rajashekhara <mahesh.rajashekhara@microsemi.com> Signed-off-by:
-
Mahesh Rajashekhara authored
Problem: - during the driver initialization, driver will poll fw for KERNEL_UP in a 30 seconds timeout. - if the firmware is not ready after 30 seconds, driver will not be loaded. Fix: - change timeout from 30 seconds to 3 minutes. Reported-by:
Feng Li <lifeng1519@gmail.com> Reviewed-by:
Ajish Koshy <ajish.koshy@microsemi.com> Reviewed-by:
Dave Carroll <david.carroll@microsemi.com> Reviewed-by:
Kevin Barnett <kevin.barnett@microsemi.com> Signed-off-by:
-
Don Brace authored
Reviewed-by:
-
Don Brace authored
Reviewed-by:
Scott Benesh <scott.benesh@microsemi.com> Reviewed-by:
Scott Teel <scott.teel@microsemi.com> Reviewed-by:
-
Kevin Barnett authored
Problem: The Linux kernel takes a logical volume offline after a LUN reset. This is generally accompanied by this message in the dmesg output: Device offlined - not ready after error recovery Root Cause: The root cause is a "quirk" in the timeout handling in the Linux SCSI layer. The Linux kernel places a 30-second timeout on most media access commands (reads and writes) that it send to device drivers. When a media access command times out, the Linux kernel goes into error recovery mode for the LUN that was the target of the command that timed out. Every command that timed out is kept on a list inside of the Linux kernel to be retried later. The kernel attempts to recover the command(s) that timed out by issuing a LUN reset followed by a TEST UNIT READY. If the LUN reset and TEST UNIT READY commands are successful, the kernel retries the command(s) that timed out. Each SCSI command issued by the kernel has a result field associated with it. This field indicates the final result of the command (success or error). When a command times out, the kernel places a value in this result field indicating that the command timed out. The "quirk" is that after the LUN reset and TEST UNIT READY commands are completed, the kernel checks each command on the timed-out command list before retrying it. If the result field is still "timed out", the kernel treats that command as not having been successfully recovered for a retry. If the number of commands that are in this state are greater than two, the kernel takes the LUN offline. Fix: When our RAIDStack receives a LUN reset, it simply waits until all outstanding commands complete. Generally, all of these outstanding commands complete successfully. Therefore, the fix in the smartpqi driver is to always set the command result field to indicate success when a request completes successfully. This normally isn’t necessary because the result field is always initialized to success when the command is submitted to the driver. So when the command completes successfully, the result field is left untouched. But in this case, the kernel changes the result field behind the driver’s back and then expects the field to be changed by the driver as the commands that timed-out complete. Reviewed-by:
-
Dave Carroll authored
- fix race condition when a unit is deleted after an RLL, and before we have gotten the LV_STATUS page of the unit. - In this case we will get a standard inquiry, rather than the desired page. This will result in a unit presented which no longer exists. - If we ask for LV_STATUS, insure we get LV_STATUS Reviewed-by: -
Dave Carroll authored
Reviewed-by:
-
Ajish Koshy authored
Reviewed-by:
-
Mahesh Rajashekhara authored
- wait on all outstanding I/O to complete before the device is removed. - check for null device pointers in IO entry/completion functions. Reviewed-by:
-
Ajish Koshy authored
Reviewed-by:
-
Sagar Biradar authored
- set pci_dev->dev to 0 only if the node is NO_NUMA_NODE. If not, do not reset the value but retain it. Reviewed-by:
Sagar Biradar <sagar.biradar@microsemi.com> Signed-off-by:
-
Dave Carroll authored
- set allow_restart option during scsi_device init. This allows the kernel to send a START/STOP Unit command to the drive if it encounters a 4/2 check condition in sense data. Reviewed-by:
-
Murthy Bhat authored
- fix a formatting issue. Reviewed-by:
-
Murthy Bhat authored
Reviewed-by:
-
Dave Carroll authored
- add sysfs device attributes, unique_id, lunid and path_info. Reviewed-by:
-
Dave Carroll authored
Clean up the common code which creates a raid path request for the controller LUNID and sends it synchronously, into a common routine; Reviewed-by:
-
Dave Carroll authored
- allow update the luns for PTRAID devices. Reviewed-by:
Justin Lindley <justin.lindley@microsemi.com> Reviewed-by:
-
Mahesh Rajashekhara authored
Reviewed-by:
-
Dave Carroll authored
During slave_alloc, for logical volumes include no_write_same into the scsi_device structure. This will insure that WRITE_SAME will not be used for LD's. Reviewed-by:
-
Mahesh Rajashekhara authored
Reviewed-by:
-
Kevin Barnett authored
Add support for new IUs and parsing of the Firmware Features section of the PQI Config Table to implement the "handshake" between the driver and firmware to communicate firmware features supported and enabled by the driver. Reviewed-by:
-
James Smart authored
Update lpfc version to 12.0.0.10 Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
James Smart authored
This patch adds a "pci_bus_reset" option to the board_mode sysfs attribute. This option uses the pci_reset_bus() api to reset the PCIe link the adapter is on, which will reset the chip/adapter. Prior to issuing this option, all functions on the same chip must be placed in the offline state by the admin. After the reset, all of the instances may be brought online again. The primary purpose of this functionality is to support cases where firmware update required a chip reset but the admin did not want to reboot the machine in order to instantiate the firmware update. Sanity checks take place prior to the reset to ensure the adapter is the sole entity on the PCIe bus and that all functions are in the offline state. Signed-off-by:
-
James Smart authored
Current messages report generic actions (like send GID_FT), but misses reporting for what protocol type the action is taken. Revise the messages to reflect the FC4 protocol type being worked on. [mkp: typo] Signed-off-by:
-
James Smart authored
When a target's link dropped, an RSCN was received to communicate the change. The driver detected the loss of the target and issued and UNREG_RPI mailbox command. While that was being processed, another RSCN was received to communicate the port coming back. The driver deferred the PLOGI to the port until the mailbox command finishes. When the mailbox command completed it saw the pending port and called the routines to issue the PLOGI. However, it forgot to clear the UNREG_INP state flag, so the PLOGI xmt routine nooped the PLOGI request assuming it needed to wait for the mailbox command. At this point, login would never be re-attempted. Clear UNREG_INP before issuing the deferred PLOGI. Signed-off-by:
-
James Smart authored
Currently, when a trunk link goes down due to some fault, the driver snapshots the fault code. If the link then comes back up, meaning there is no fault, the driver is not clearing the fault code so the sysfs link_state entry reports old/stale data. Revise the logic so that on successful link up the fault code is cleared. Signed-off-by:
-
James Smart authored
The existing MDS loopback diagnostics support processing received frames in the slowpath work thread. It caps the number of frames it will process at 64, before waiting for another event to indicate additional frame reception. The net-net is this results in very slow frame processing during loopback tests and sometimes orphans an io, causing the loopback test to report failure by the switch. Move MDS loopback frame processing out of the slow path worker thread and into the normal RQ processing routines. Signed-off-by:
-
James Smart authored
If the adapter is taken offline, the trunk link port attributes continue to report trunk links as up even though all links are down as the adapter is offline. Clear the trunk links state as part of taking the adapter offline. Signed-off-by:
-
Colin Ian King authored
There is a break statement with an extra space that needs removed and a call to bfa_trc that is indented one level too much. Fix these. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
There is a tab missing on a return statement, add the missing tab. Signed-off-by:
-
Varun Prakash authored
In case of ->vport_create() call scsi_add_host_with_dma() instead of scsi_add_host() to pass correct dma device. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Christoph Hellwig authored
The old DAC960 driver was fine with merging over segment boundaries, so this new driver should be too. [mkp: typos] Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
The old DAC960 driver was fine with merging over segment boundaries, so this new driver should be too. [mkp: typos] Signed-off-by:
-
Shivasharan S authored
Signed-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by:
-
Shivasharan S authored
Although MegaRAID controllers support 64-bit DMA addressing, as per hardware design, DMA address with all 64-bits set (0xFFFFFFFF-FFFFFFFF) results in a firmware fault. Driver will set 63-bit DMA mask to ensure the above address will not be used. Cc: stable@vger.kernel.org Signed-off-by:
-
