talos-op-linux/drivers/scsi/mpt3sas, branch master

Merge tag 'block-ioctl-cleanup-5.6' into 5.6/scsi-queue

2020-01-10T05:14:46+00:00

Pull compat_ioctl cleanup from Arnd. Here's his description: This series concludes the work I did for linux-5.5 on the compat_ioctl() cleanup, killing off fs/compat_ioctl.c and block/compat_ioctl.c by moving everything into drivers. Overall this would be a reduction both in complexity and line count, but as I'm also adding documentation the overall number of lines increases in the end. My plan was originally to keep the SCSI and block parts separate. This did not work easily because of interdependencies: I cannot do the final SCSI cleanup in a good way without first addressing the CDROM ioctls, so this is one series that I hope could be merged through either the block or the scsi git trees, or possibly both if you can pull in the same branch. The series comes in these steps: 1. clean up the sg v3 interface as suggested by Linus. I have talked about this with Doug Gilbert as well, and he would rebase his sg v4 patches on top of "compat: scsi: sg: fix v3 compat read/write interface" 2. Actually moving handlers out of block/compat_ioctl.c and block/scsi_ioctl.c into drivers, mixed in with cleanup patches 3. Document how to do this right. I keep getting asked about this, and it helps to point to some documentation file. The branch is based on another one that fixes a couple of bugs found during the creation of this series. Changes since v3: https://lore.kernel.org/lkml/20200102145552.1853992-1-arnd@arndb.de/ - Move sr_compat_ioctl fixup to correct patch (Ben Hutchings) - Add Reviewed-by tags Changes since v2: https://lore.kernel.org/lkml/20191217221708.3730997-1-arnd@arndb.de/ - Rebase to v5.5-rc4, which contains the earlier bugfixes - Fix sr_block_compat_ioctl() error handling bug found by Ben Hutchings - Fix idecd_locked_compat_ioctl() compat_ptr() bug - Don't try to handle HDIO_DRIVE_TASKFILE in drivers/ide - More documentation improvements Changes since v1: https://lore.kernel.org/lkml/20191211204306.1207817-1-arnd@arndb.de/ - move out the bugfixes into a branch for itself - clean up scsi sg driver further as suggested by Christoph Hellwig - avoid some ifdefs by moving compat_ptr() out of asm/compat.h - split out the blkdev_compat_ptr_ioctl function; bug spotted by Ben Hutchings - Improve formatting of documentation Signed-off-by: Martin K. Petersen

scsi: mpt3sas: Update drive version to 33.100.00.00

2020-01-03T03:23:17+00:00

Update mpt3sas driver version from 32.100.00.00 to 33.100.00.00 Link: https://lore.kernel.org/r/20191226111333.26131-11-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen

scsi: mpt3sas: Remove usage of device_busy counter

2020-01-03T03:23:17+00:00

Remove usage of device_busy counter from driver. Instead of device_busy counter now driver uses 'nr_active' counter of request_queue to get the number of inflight request for a LUN. Link: https://lore.kernel.org/r/20191226111333.26131-10-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen

scsi: mpt3sas: Print function name in which cmd timed out

2020-01-03T03:23:17+00:00

Print the function name in which MPT command got timed out. This will facilitate debugging in which path corresponding MPT command got timeout in first failure instance of log itself. Link: https://lore.kernel.org/r/20191226111333.26131-9-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen

scsi: mpt3sas: Optimize mpt3sas driver logging

2020-01-03T03:23:17+00:00

This improves mpt3sas driver default debug information collection and allows for a higher percentage of issues being able to be resolved with a first-time data capture. However, this improvement to balance the amount of debug data captured with the performance of driver. Enabled below print messages with out affecting the IO performance, 1. When task abort TM is received then print IO commands's timeout value and how much time this command has been outstanding. 2. Whenever hard reset occurs then print from where this hard reset has been issued. 3. Failure message should be displayed for failure scenarios without any logging level. 4. Added a print after driver successfully register or unregistered a target drive with the SML. This print will be useful for debugging the issue where the drive addition or deletion is hanging at SML. 5. During driver load time print request, reply, sense and config page pool's information such as its address, length and size. Also printed sg_tablesize information. Link: https://lore.kernel.org/r/20191226111333.26131-8-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen

scsi: mpt3sas: print in which path firmware fault occurred

2020-01-03T03:23:17+00:00

When Firmware fault occurs then print in which path firmware fault has occurred. This will be useful while debugging the firmware fault issues. Link: https://lore.kernel.org/r/20191226111333.26131-7-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen

scsi: mpt3sas: Handle CoreDump state from watchdog thread

2020-01-03T03:23:16+00:00

Watchdog thread polls for IOC state every 1 second. If it detects that IOC state is in CoreDump state then it immediately stops the IOs and also clears the outstanding commands issued to the HBA firmware and then it will poll for IOC state to be out of CoreDump state and once it detects that IOC state is changed from CoreDump state to Fault state (or) CoreDumpTOSec number of seconds are elapsed then it will issue host reset operation and moves the IOC state to Operational state and resumes the IOs. Whenever any TM is received from SML then if driver detects the IOC state is in CoreDump state then it will wait for CoreDump state to be cleared and will host reset operation. Link: https://lore.kernel.org/r/20191226111333.26131-6-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen

scsi: mpt3sas: Add support IOCs new state named COREDUMP

2020-01-03T03:23:16+00:00

New feature is added in HBA firmware where it copies the collected firmware logs in flash region named 'CoreDump' whenever HBA firmware faults occur. For copying the logs to CoreDump flash region firmware needs some time and hence it has introduced a new IOC state named "CoreDump" State. Whenever driver detects the CoreDump state then it means that some firmware fault has occurred and firmware is copying the logs to the coredump flash region. During this time driver should not perform any operation with the HBA, driver should wait for HBA firmware to move the IOC state from 'CoreDump' state to 'Fault' state once it's done with copying the logs to coredump region. Once driver detects the Fault state then it will issue the diag reset/host reset operation to move the IOC state from Fault to Operational state. Here the valid IOC state transactions w.r.t to this CoreDump state feature, Operational -> Fault: The IOC transitions to the Fault state when an operational error occurs AND CoreDump is not supported (or disabled) by the firmware(FW). Operational -> CoreDump: The IOC transitions to the CoreDump state when an operational error occurs AND CoreDump is supported & enabled by the FW. CoreDump -> Fault: A transition from CoreDump state to Fault state happens when the FW completes the CoreDump collection. CoreDump -> Reset: A transition out of the CoreDump state happens when the host sets the Reset Adapter bit in the System Diagnostic Register (Hard Reset). This reset action indicates that CoreDump took longer than the host time out. Firmware informs the driver about the maximum time that driver has to wait for firmware to transition the IOC state from 'CoreDump' to 'FAULT' state through 'CoreDumpTOSec' field of ManufacturingPage11 page. if this 'CoreDumpTOSec' field value is zero then driver will wait for max 15 seconds. Driver informs the HBA firmware that it supports this new IOC state named 'CoreDump' state by enabling COREDUMP_ENABLE flag in ConfigurationFlags field of ioc init request message. Current patch handles the CoreDump state only during HBA initialization and release scenarios where watchdog thread (which polls the IOC state in every one second) is disabled. Next subsequent patch handle the CoreDump state when watchdog thread is enabled. During HBA initialization or release execution time if driver detects the CoreDump state then driver will wait for maximum CoreDumpTOSec value seconds for FW to copy the logs. After that it will issue the diag reset operation to move the IOC state to Operational state. Link: https://lore.kernel.org/r/20191226111333.26131-5-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen

scsi: mpt3sas: renamed _base_after_reset_handler function

2020-01-03T03:23:16+00:00

Renamed _base_after_reset_handler function to _base_clear_outstanding_commands so that it can be used in multiple scenarios with suitable name which matches with the operation it does. Also renamed its child functions. No functional changes. Link: https://lore.kernel.org/r/20191226111333.26131-4-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen

scsi: mpt3sas: Add support for NVMe shutdown

2020-01-03T03:23:16+00:00

Introduce function _scsih_nvme_shutdown() to issue IO Unit Control message to IOC firmware with operation code 'shutdown'. This causes IOC firmware to issue NVMe shutdown commands to all NVMe drives attached to it. NVMe Shutdown: NVMe devices need to have a specific shutdown sequence performed before power is removed. For this, the IOC firmware needs to be notified when the system is being shutdown. So during the system shutdown time, driver issues an IO Unit Control request with operation code MPI26_CTRL_OP_SHUTDOWN to inform firmware that a shutdown is initiated. This shutdown command is issued only if NVMe devices are attached to the controller. During each NVMe device addition, driver reads pcie device page2 to get shutdown latency (e.g. drive's RTD3 Entry Latency) and updates the max latency value among the added NVMe drives in ioc->max_shutdown_latency. This is used as the timeout value for IO Unit Control command at the time of shutdown. When a NVMe drive is removed and its shutdown latency matches which ioc->max_shutdown_latency then ioc->max_shutdown_latency is updated to next max value (by iterating over the list of available devices). If the shutdown latency is 0, then default timeout is set to six seconds. Link: https://lore.kernel.org/r/20191226111333.26131-3-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen