The function mpi3mr_qcmd() of the mpi3mr driver is able to indicate to
the HBA if a read or write command directed at an ATA device should be
translated to an NCQ read/write command with the high prioiryt bit set
when the request uses the RT priority class and the user has enabled NCQ
priority through sysfs.
However, unlike the mpt3sas driver, the mpi3mr driver does not define
the sas_ncq_prio_supported and sas_ncq_prio_enable sysfs attributes, so
the ncq_prio_enable field of struct mpi3mr_sdev_priv_data is never
actually set and NCQ Priority cannot ever be used.
Fix this by defining these missing atributes to allow a user to check if
an ATA device supports NCQ priority and to enable/disable the use of NCQ
priority. To do this, lift the function scsih_ncq_prio_supp() out of the
mpt3sas driver and make it the generic SCSI SAS transport function
sas_ata_ncq_prio_supported(). Nothing in that function is hardware
specific, so this function can be used in both the mpt3sas driver and
the mpi3mr driver.
Reported-by: Scott McCoy <scott.mccoy@wdc.com>
Fixes: 023ab2a9b4 ("scsi: mpi3mr: Add support for queue command processing")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20240611083435.92961-1-dlemoal@kernel.org
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The mpt3sas_ctl_exit() should be called after communication with the
controller stops but currently it may cause false warnings about not
released memory. Fix this by letting mpt3sas_ctl_exit() handle misc driver
release per driver and release DMA in mpt3sas_ctl_release() per ioc.
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Link: https://lore.kernel.org/r/20231019153706.7967-1-thenzl@redhat.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The per-adapter struct (struct MPT3SAS_ADAPTER) contains a
MPI2_CONFIG_PAGE_IO_UNIT_8 (Mpi2IOUnitPage8_t) iounit_pg8 member that is
populated by mpt3sas_base.c:_base_static_config_pages().
As the name of that function indicates, the iounit_pg8 member represents a
static configuration page data structure that rarely changes, and is among
several such static config pages that are currently being fetched once per
adapter per init (or reset) and copied to the per-adapter struct for later
use.
However, unlike the other static config pages, the iounit_pg8 member is
never actually used outside of _base_static_config_pages(). Also,
Mpi2IOUnitPage8_t has a flexible array member, making its presence in the
_middle_ of the per-adapter struct rather strange.
Remove this member from the per-adapter struct and fix up the portion of
_base_static_config_pages() that uses it.
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20230806170604.16143-9-james@equiv.tech
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The driver retries certain register reads 3 times if the returned value is
0. This was done because the controller could return 0 for certain
registers if other registers were being accessed concurrently by the BMC.
In certain systems with increased BMC interactions, the register values
returned can be 0 for longer than 3 retries. Change the retry count from 3
to 30 for the affected registers to prevent problems with out-of-band
management.
Fixes: b899202901 ("scsi: mpt3sas: Add separate function for aero doorbell reads")
Cc: stable@vger.kernel.org
Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
Link: https://lore.kernel.org/r/20230829090020.5417-2-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add ATTO's PCI IDs and modify the driver to handle the unique NVRAM
structure used by ATTO's devices.
Link: https://lore.kernel.org/r/20220805174609.14830-1-bgrove@attotech.com
Co-developed-by: Rob Crispo <rcrispo@attotech.com>
Signed-off-by: Rob Crispo <rcrispo@attotech.com>
Signed-off-by: Bradley Grove <bgrove@attotech.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The replyPostRegisterIndex array of struct MPT3SAS_ADAPTER stores iomem
resource addresses. Fix its declaration to annotate it with __iomem to
avoid sparse warnings for writel() calls using the stored addresses.
Link: https://lore.kernel.org/r/20220307234854.148145-6-damien.lemoal@opensource.wdc.com
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Store sysfs-provided trigger values into the corresponding persistent
trigger pages. Otherwise trigger entries are not persistent across system
reboots.
Link: https://lore.kernel.org/r/20211227053055.289537-1-suganath-prabu.subramani@broadcom.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
While determining the SAS address of a drive, the driver checks whether the
handle number is less than the HBA phy count or not. If the handle number
is less than the HBA phy count then driver assumes that this handle belongs
to HBA and hence it assigns the HBA SAS address.
During IOC firmware downgrade operation, if the number of HBA phys is
reduced and the OS drive's device handle drops below the phy count while
determining the drive's SAS address, the driver ends up using the HBA's SAS
address. This leads to a mismatch of drive's SAS address and hence the
driver unregisters the OS drive and the system goes into read-only mode.
Update the IOC's num_phys to the HBA phy count provided by actual loaded
firmware.
Link: https://lore.kernel.org/r/20211117105058.3505-1-sreekanth.reddy@broadcom.com
Fixes: a5e99fda01 ("scsi: mpt3sas: Update hba_port objects after host reset")
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Link: https://lore.kernel.org/r/20211012233558.4066756-30-bvanassche@acm.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently, the mpt3sas driver sets the default queue depth based on the
physical interface of the attached device:
- SAS : 254
- SATA: 32
- NVMe: 128
The IOC firmware provides a recommended queue depth for each device through
SAS IO Unit Page1 for SAS/SATA and PCIe IO Unit Page 1 for NVMe devices.
If the host sets the queue depth greater than the firmware recommended
value, then the IOC places the I/Os above the recommended queue depth in an
internal pending queue. This consumes outstanding host-credit/resources,
thereby leading to potential starvation of other devices.
To avoid this, use the device depth recommended by the IOC firmware.
Link: https://lore.kernel.org/r/20210809072639.21228-2-suganath-prabu.subramani@broadcom.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Enable the driver to work in non-IRQ mode, i.e. there will not be any MSI-X
vectors associated with queues dedicated to polling. The IOC hardware is
single submission queue and multiple reply queue. However, using the shared
host tagset support it is possible to simulate multiple hardware queues.
When poll_queues are enabled through the module parameter, the driver will
allocate extra reply queues without an MSI-X association. All I/O
completion on these queues will be done through the iopoll interface.
Link: https://lore.kernel.org/r/20210727081212.2742-1-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin 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.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
