The IOC firmware assumes that the host driver is still alive after shutdown
and continues to post events to host memory (due to faulty expander phy
links, etc). This leads to 0x2666 (a bus fault occurred during a host-IOC
memory access).

Perform an IOC soft reset as part of shutdown to disable event posting.

Link: https://lore.kernel.org/r/20210705145951.32258-1-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

If a firmware fault occurs while scanning the devices during IOC
initialization then the driver issues the hard reset operation to recover
the IOC. However, the driver is not issuing a Port enable request
message as part of hard reset operation during IOC initialization.  Due to
this, the driver will not receive get any device discovery-related events
and hence devices will not be accessible.

Teach the driver to gracefully handle firmware faults while scanning for
target devices during IOC initialization. Make the driver issue a port
enable request message as part of hard reset operation. This permits
receiving device discovery-related events from the firmware after the hard
reset operation completes.

Link: https://lore.kernel.org/r/20210518051625.1596742-4-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

During first half of IOC initialization (i.e.  before going for device
scanning), if any firmware fault occurs then driver is aborting the IOC
initialization operation.

Modify the driver to issue a diag reset operation to recover IOC from fault
state and reinitialize the IOC.

Link: https://lore.kernel.org/r/20210518051625.1596742-3-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Update driver version to 37.101.00.00.

Link: https://lore.kernel.org/r/20210305102904.7560-8-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

According to the MPI specification, PCIe SGL buffers can not cross a 4 GB
boundary.

While allocating, if any buffer crosses the 4 GB boundary, then:

 - Release the already allocated memory pools; and

 - Reallocate them by changing the DMA coherent mask to 32-bit

Link: https://lore.kernel.org/r/20210305102904.7560-2-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Update driver version to 37.100.00.00.

Link: https://lore.kernel.org/r/20210204033724.1345-3-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

When a host trace buffer is released, applications never know for what
reason the buffer is released. Add a new IOCTL MPT3ADDNLDIAGQUERY to
provide the trigger information due to which the diag buffer is released.

Link: https://lore.kernel.org/r/20210204033724.1345-2-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

MPT Fusion adapters can steer completions to individual queues and we now
have support for shared host-wide tags in the I/O stack. The addition of
the host-wide tags allows us to enable multiqueue support for MPT Fusion
adapters. Once host-wise tags are enabled, the CPU hotplug feature is also
supported.

Allow use of host-wide tags to be disabled through the "host_tagset_enable"
module parameter. Once we do not have any major performance regressions
using host-wide tags, we will drop the hand-crafted interrupt affinity
settings.

Performance is meeting expectations. About 3.1M IOPS using 24 Drive SSD on
Aero controllers.

Link: https://lore.kernel.org/r/20210202095832.23072-1-sreekanth.reddy@broadcom.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Update driver version to 36.100.00.00

Link: https://lore.kernel.org/r/20201126094311.8686-9-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

This page is used to store information about MPI (IOC Status & LogInfo)
triggers.

 Driver Persistent Trigger Page-4 format:
 -------------------------------------------------------
 | 31       24 23           16 15         8 7          0|  Byte
 -------------------------------------------------------
 | PageType   | PageNumber    | Reserved  | PageVersion |  0x00
 --------------------------------------------------------
 | Reserved   | ExtPageType   |      ExtPageLength      |  0x04
 --------------------------------------------------------
 |          Reserved          | NumMpiTriggerEntries    |  0x08
 --------------------------------------------------------
 |             MPITriggerEntry[0]                       |  0x0C
 --------------------------------------------------------
 |               …                                      |
 --------------------------------------------------------
 |            MPITriggerEntry[19]                       |  0xA4
 --------------------------------------------------------

NumMpiTriggerEntries:

This field indicates number of MPI (IOC Status & LogInfo) trigger entries
stored in this page. Currently driver is supporting a maximum of 20-MPI
trigger entries.

MPITriggerEntry:

 -----------------------------------------------------
 | 31                    16 15                     0 |
 -----------------------------------------------------
 |        Reserved         |      IOCStatus          |
 -----------------------------------------------------
 |                   IOCLogInfo                      |
 -----------------------------------------------------

IOCStatus  => Status value from the IOC
IOCLogInfo => Specific value that supplements the IOCStatus.

Link: https://lore.kernel.org/r/20201126094311.8686-7-suganath-prabu.subramani@broadcom.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Trigger Page3 is used to store information about SCSI Sense triggers:

 Persistent Trigger Page-3
 ------------------------------------------------------------------
 | 31         24 23            16 15              8 7            0|    Byte
 ------------------------------------------------------------------
 | PageType      | PageNumber     | Reserved       | PageVersion  |    0x00
 ------------------------------------------------------------------
 | Reserved      | ExtPageType    |          ExtPageLen           |    0x04
 ------------------------------------------------------------------
 | Reserved      | NumScsiSense   |         TriggerEntries        |    0x08
 ------------------------------------------------------------------
 |               ScsiSenseTriggerEntry[0]                         |    0x0C
 ------------------------------------------------------------------
 |                    …        …                                  |
 ------------------------------------------------------------------
 |               ScsiSenseTriggerEntry[19]                        |    0x58
 ------------------------------------------------------------------

NumScsiSenseTriggerEntries:

This field indicates number of SCSI Sense trigger entries stored in this
page. Currently driver is supporting a maximum of 20-SCSI Sense trigger
entries.

ScsiSenseTriggerEntry:

 -----------------------------------------------
 | 31      24 23       16 15       8 7       0 |
 -----------------------------------------------
 | Reserved   | SenseKey  |    ASC   |   ASCQ  |
 -----------------------------------------------

 ASCQ     => Additional Sense Code Qualifier
 ASC      => Additional Sense Code
 SenseKey => Sense Key values

 ASCQ     => Additional Sense Code Qualifier
 ASC      => Additional Sense Code
 SenseKey => Sense Key values

Link: https://lore.kernel.org/r/20201126094311.8686-6-suganath-prabu.subramani@broadcom.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Trigger Page2 is used to store information about Event triggers:

  31     24 23        16 15      8 7         0   Byte
 -----------------------------------------------
 |PageType  |PageNumber  |Reserved |PageVersion| 0x00
 -----------------------------------------------
 |Reserved  |ExtPageType |   ExtPageLength     | 0x04
 -----------------------------------------------
 |     Reserved          | NumMPIEventTriggers | 0x08
 -----------------------------------------------
 |                 MPIEventTriggerEntries      | 0x0C
 |                                             | 0xFC
 -----------------------------------------------

Number of MPI Event Trigger Entries currently stored in this page.  If this
is set to zero, there are no valid MPI-Event-Trigger entries available in
this page.

MPIEventTriggerEntry:

 - MPIEventCode [15:00]
   MPI Event code specified in MPI-Spec

 - MPIEventCodeSpecific [16:31]
   For Event Code “MPI2_EVENT_LOG_ENTRY_ADDED (0x0021)”,
   this field specifies the Log-Entry-Qualifier.
   For all other Event Codes, this field is reserved and not used

Maximum of 20-event trigger entries can be stored in this page.

Link: https://lore.kernel.org/r/20201126094311.8686-5-suganath-prabu.subramani@broadcom.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Trigger Page 1 is used to store information about Master triggers.  Below
are the Master trigger conditions:

  Bit[3]  Trigger condition for Device Removal event
  Bit[2]  Trigger condition for TM command issued by driver
  Bit[1]  Trigger condition for Adapter reset issued by driver
  Bit[0]  Trigger condition for IOC Fault state

During driver load, if Master trigger type bit is enabled in the Persistent
Trigger Page0, then read the Persistent Trigger Page1 and update the IOC
instance's diag_trigger_master.MasterData with Persistent Trigger Page1's
MasterTriggerFlags.

Link: https://lore.kernel.org/r/20201126094311.8686-4-suganath-prabu.subramani@broadcom.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The user can set trigger values in order to collect the IOC's host trace
buffer automatically upon detecting certain conditions. However, the
trigger values that the user sets are not persistent across system reboot
or reload of the driver.

In order to make the user trigger settings persistent, these trigger values
need to be saved in the IOC's NVRAM pages:

 - Driver Persistent Trigger Page 0:
     This page is used to store list of trigger types that are enabled

 - Driver Persistent Trigger Page 1:
     This page stores the list of Master triggers that are enabled

 - Driver Persistent Trigger Page 2:
     This page stores the list of MPI Event Triggers that are enabled

 - Driver Persistent Trigger Page 3:
     This page stores the list of SCSI Sense Triggers that are enabled

 - Driver Persistent Trigger Page 4:
     This page stores the list of IOCStatus-LogInfo Triggers that are
     enabled.

Whenever user configures triggers, the driver persists the values in the
corresponding trigger pages. When the driver is subsequently reloaded, the
driver reads the values from the trigger pages and configures the triggers
accordingly.

During firmware upload operation, if the newer firmware supports the
trigger page feature, then driver persists the configured diag trigger
values to NVRAM.

Link: https://lore.kernel.org/r/20201126094311.8686-3-suganath-prabu.subramani@broadcom.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The controller time currently gets updated with host time during driver
load or when a controller reset is issued. I.e. when host issues the
IOCInit request message to the HBA firmware. This IOCInit message has a
field named 'TimeStamp' with which the host updates the controller time.

Sometimes controller time drifts with respect to the host and it is
difficult to correlate host logs with controller logs. Issuing a controller
reset to sync the time would impact in-flight I/O and is not a viable
option.

Instead the driver now sends an IO_UNIT_CONTROL Request to sync the time
periodically. This is done from the watchdog thread which gets invoked
every second.

The time synchronization interval is specified in the 'TimeSyncInterval'
field in Manufacturing Page11 by the controller:

    TimeSyncInterval - 8 bits
	bits  0-6: Time stamp Synchronization interval value
	bit	7: Time stamp Synchronization interval unit,
		   (if this bit is one then Timestamp Synchronization
		   interval value is specified in terms of hours else
		   Timestamp Synchronization interval value is
		   specified in terms of minutes).

The driver keeps track of the timer using IOC's timestamp_update_count
field. This field value gets incremented whenever the watchdog thread gets
invoked. And whenever this field value is greater than or equal to the Time
Stamp Synchronization interval value, the driver sends the IO_UNIT_CONTROL
Request message to controller to update the time and then it resets the
timestamp_update_count field to zero.

Link: https://lore.kernel.org/r/20201126094311.8686-2-suganath-prabu.subramani@broadcom.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Bump mpt3sas driver version to 35.101.00.00

Link: https://lore.kernel.org/r/20201027130847.9962-15-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Add module parameter multipath_on_hba to enable/disable multi-port path
topology support.  By default this feature is enabled on SAS3.5 HBA device
and disabled on SAS3 &SAS2.5 HBA devices.

When this feature is disabled then driver uses a default
PhysicalPort(PortID) number i.e. 255 instead of the PhysicalPort number
provided by HBA firmware.

Link: https://lore.kernel.org/r/20201027130847.9962-14-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Added a new parameter bypass_dirty_port_flag in function
mpt3sas_get_port_by_id(). When this parameter is set to one then search for
matching hba port entry from port_table_list even when this hba_port entry
is marked as dirty.

Link: https://lore.kernel.org/r/20201027130847.9962-12-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Each direct attached device will have a unique Port ID, but with an
exception. HBA vSES may use the same Port ID of another direct attached
device Port's ID. As a result, special handling is needed for vSES.

Create a virtual_phy object when a new HBA vSES device is detected and add
this virtual_phy object to vphys_list of port ID's hba_port object.  When
the HBA vSES device is removed then remove the corresponding virtual_phy
object from its parent's hba_port's vphy_list and free this virtual_vphy
object.

In hba_port object add vphy_mask field to hold the list of HBA phy bits
which are assigned to vSES devices. Also add vphy_list list to hold list of
virtual_phy objects which holds the same portID of current hba_port's
portID.

Also, add a hba_vphy field in _sas_phy object to determine whether this
_sas_phy object belongs to vSES device or not.

 - Allocate a virtual_phy object whenever a virtual phy is detected while
   processing the SASIOUnitPage0's phy data. And this allocated virtual_phy
   object to corresponding PortID's hba_port's vphy_list.

 - When a vSES device is added to the SML then initialize the corresponding
   virtual_phy objects's sas_address field with vSES device's SAS Address.

 - Free this virtual_phy object during driver unload time and when this
   vSES device is removed.

Link: https://lore.kernel.org/r/20201027130847.9962-11-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The driver currently sets PhysicalPort field to 0xFF for SMPPassthrough
Request message. In zoning topologies this SMPPassthrough command always
operates on devices in one zone (default zone) even when user issues SMP
command for other zone drives.

Define _transport_get_port_id_by_rphy() and
_transport_get_port_id_by_sas_phy() helper functions to get Physical Port
number from sas_rphy & sas_phy respectively for SMPPassthrough request
message so that SMP Passthrough request message is sent to intended zone
device.

Link: https://lore.kernel.org/r/20201027130847.9962-10-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

In the following scsi_host_template and sas_function_template callback
functions the driver does not have PhysicalPort number information to
retrieve the sas_device object using SAS Address & PhysicalPort number. In
these callback functions the device's rphy object is used to retrieve
sas_device object for the device.

.target_alloc,
.get_enclosure_identifier
.get_bay_identifier

When a rphy (of type sas_rphy) object is allocated then its address is
saved in corresponding sas_device object's rphy field. In
__mpt3sas_get_sdev_by_rphy(), the driver loops over all the sas_device
objects from sas_device_list list to retrieve the sas_device objects whose
rphy matches the provided rphy.

Link: https://lore.kernel.org/r/20201027130847.9962-8-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Renamed _transport_add_phy_to_an_existing_port() to
mpt3sas_transport_add_phy_to_an_existing_port() and
_transport_del_phy_from_an_existing_port() to
mpt3sas_transport_del_phy_from_an_existing_port() as the driver needs to
call these functions from outside mpt3sas_transport.c file.

Added extra function argument 'port' of type struct hba_port to above
functions and check for portID before adding/removing the phy from the
_sas_port object.  I.e. add/remove the phy from _sas_port object only if
_sas_port's port object and phy's port object are the same.

Link: https://lore.kernel.org/r/20201027130847.9962-7-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Currently driver retrieves the sas_device/sas_expander objects from
corresponding object's lists using just device's SAS Address.

Make driver retrieve the objects from the corresponding objects list using
device's SAS Address and PhysicalPort (or PortID) number. PhysicalPort
number is the port number of the HBA through which this device is accessed.

Link: https://lore.kernel.org/r/20201027130847.9962-6-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Update hba_port's sas_address & phy_mask fields whenever a direct expander
or sas/sata target devices are added or removed.

When any direct attached device is discovered then driver:

 - Gets the hba_port object corresponding to device's PhysicalPort
   number;

 - Updates the hba_port's sas_address field with device's SAS
   Address;

 - Updates the hba_port's phy_mask filed with device's narrow/wide
   port Phy number bits;

 - If a sas/sata end device (not only direct-attached devices) is added
   then corresponding sas_device object's port variable is assigned with
   hba_port object's address whose port_id matches the device's
   PhysicalPort number.

 - If an expander device is added then corresponding sas_expander object's
   port variable is assigned with hba_port object's address whose port_id
   matches the expander device's PhysicalPort number.

When any direct attached device is detached then driver will delete the
hba_port object corresponding to device's PhysicalPort number.

Whenever any HBA phy's link (of direct attached device's port) comes up
then update the phy_mask field of corresponding hba_port object.

Link: https://lore.kernel.org/r/20201027130847.9962-5-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Define a new hba_port structure which holds the following variables:

 - port_id: Port ID of the narrow/wide port of the HBA

 - sas_address: SAS Address of the remote device that is attached to the
   current HBA port

 - phy_mask: HBA's phy bits to which above SAS addressed device is attached

 - flags: This field is used to refresh port details during HBA reset

Link: https://lore.kernel.org/r/20201027130847.9962-2-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Updated driver version to 35.100.00.00

Link: https://lore.kernel.org/r/1596096229-3341-8-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

If driver has not received the interrupt for the aborted SCSI command
before processing the TM reply, driver polls all the reply descriptor pools
looking for the reply for the aborted SCSI command before marking TM as
FAILED. If it finds the reply, then it marks the TM as SUCCESS otherwise it
marks it FAILED.

scsih_tm_cmd_map_status() checks whether TM has aborted the timed out SCSI
command or not. If TM has aborted the IO, then it returns SUCCESS else it
returns FAILED.

Link: https://lore.kernel.org/r/1596096229-3341-7-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Add helper functions to check whether any SCSI command is outstanding on
particular Target, LUN device.

Also add function parameters 'channel', 'id' to function
mpt3sas_scsih_issue_tm().

Link: https://lore.kernel.org/r/1596096229-3341-6-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Rename Function _base_unmask_interrupts() to
mpt3sas_base_unmask_interrupts() and _base_mask_interrupts() to
mpt3sas_base_mask_interrupts(). Also add function declarion to
mpt3sas_base.h

Link: https://lore.kernel.org/r/1596096229-3341-5-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

It is not recommended to issue back-to-back host reset without any delay.
However, if someone issues back-to-back host reset then we observe that
target devices get unregistered and re-register with SML.  And if OS drive
is behind the HBA when it gets unregistered, then file-system goes into
read-only mode.

Normally during host reset, driver marks accessible target devices as
responding and triggers the event MPT3SAS_REMOVE_UNRESPONDING_DEVICES to
remove any non-responding devices through FW worker thread. While
processing this event, driver unregisters the non-responding devices and
clears the responding flag for all the devices.

Currently, during host reset, driver is cancelling only those Firmware
event works which are pending in Firmware event workqueue. It is not
cancelling work which is currently running. Change the driver to cancel all
events.

Link: https://lore.kernel.org/r/1596096229-3341-4-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Fix typo: "tigger" --> "trigger"

Link: https://lore.kernel.org/r/20200609161313.32098-1-f.suligoi@asem.itSigned-off-by: NFlavio Suligoi <f.suligoi@asem.it>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Information needed to debug driver problems and firmware faults is stored
in the IOC’s MPT3SAS_ADAPTER data structure. Parameters such as IOCFacts,
IOC flags (related to sge, MSI-X, error recovery etc.), performance mode
type, TMs, internal commands reply status, etc. are present.

For debugging purposes, it is therefore helpful to be able to capture this
information so that the fault can be analyzed. Export the MPT3SAS_ADAPTER
data structure in debugfs. The data is available in:

	 /sys/kernel/debug/mpt3sas/scsi_hostX/ioc_dump

Link: https://lore.kernel.org/r/1588056322-29227-1-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Update mpt3sas driver version from 33.100.00.00 to 33.101.00.00.

Link: https://lore.kernel.org/r/1587626596-1044-6-git-send-email-suganath-prabu.subramani@broadcom.comSigned-off-by: NSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

For INVADER_SERIES, each set of 8 reply queues (0 - 7, 8 - 15,..), and for
VENTURA_SERIES, each set of 16 reply queues (0 - 15, 16 - 31,..) need to be
within the same 4 GB boundary. Driver uses limitation of VENTURA_SERIES to
manage INVADER_SERIES as well. The driver is allocating the DMA able
memory for RDPQs accordingly.

1) At driver load, set DMA mask to 64 and allocate memory for RDPQs

2) Check if allocated resources for RDPQ are in the same 4GB range

3) If #2 is true, continue with 64 bit DMA and go to #6

4) If #2 is false, then free all the resources from #1

5) Set DMA mask to 32 and allocate RDPQs

6) Proceed with driver loading and other allocations

Link: https://lore.kernel.org/r/1587626596-1044-5-git-send-email-suganath-prabu.subramani@broadcom.comReviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The DMA layer does not allow changing the DMA coherent mask after there are
outstanding allocations.

Link: https://lore.kernel.org/r/1587626596-1044-2-git-send-email-suganath-prabu.subramani@broadcom.comReported-by: NAbdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

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.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

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.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

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.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

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.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

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.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>