| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Detect asynchronous reset that occurred in the firmware by polling for
reset history bit of IOC status register is set and if that bit is set,
then the driver waits for the controller to become ready and then
re-initializes the controller.
Also reduce the time driver is waiting for the controller to acknowledge
the reset action after issuing a specific reset action to the
controller. The wait time is reduced from 510 seconds to 30 seconds. If the
controller didn't acknowledge a specific reset action within the time
interval then the driver marks the controller as unrecoverable instead of
retrying two more times prior to giving up.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the driver marks the controller as unrecoverable if there is an
asynchronous reset or fault during the initialization, reinitialization
post reset, and OS resume.
Enhance driver to retry the initialization, re-initialization, and resume
sequences for a maximum of 3 times if the controller became faulty or
asynchronously reset due to a firmware activation during the initialization
sequence.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Save snapdump and fault the controller with the given reason code if it is
already not in the fault or not in asynchronous reset. This ensures that
soft reset is issued from the watchdog thread. This will also be used to
handle initialization time faults/resets/timeout as in those cases
immediate soft reset invocation is not required.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
- Increase internal command timeout to 60 seconds.
- Enable 16 device removal handshake processing in parallel in the device
removal handshake infrastructure.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SAS4 Controller firmware exposes the SES devices in Managed PCIe Switch
as a PCIe Device Type SCSI Device
(MPI3_DEVICE0_PCIE_DEVICE_INFO_TYPE_SCSI_DEVICE).
Driver is enhanced to handle this device type by:
- Exposing the device to the upper layers and
- Not updating any hardware sectors & virtual boundary settings as these
settings are needed only for NVMe devices.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
| |
Continued updating MPI3 headers.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Driver is not setting up IRQs in the resume path. As a result, hibernation
path is broken and controller will not be operational after system is
resumed.
Set up IRQs to handle the hibernation case.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Cc: [email protected]
Reported-by: Marco Patalano <[email protected]>
Tested-by: Marco Patalano <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the following warnings:
drivers/scsi/mpi3mr/mpi3mr_os.c:24:5: warning: symbol 'prot_mask' was not declared. Should it be static?
drivers/scsi/mpi3mr/mpi3mr_os.c:28:5: warning: symbol 'prot_guard_mask' was not declared. Should it be static?
drivers/scsi/mpi3mr/mpi3mr_os.c:31:5: warning: symbol 'logging_level' was not declared. Should it be static?
Link: https://lore.kernel.org/r/[email protected]
Reported-by: Hulk Robot <[email protected]>
Acked-by: Kashyap Desai <[email protected]>
Signed-off-by: Yang Yingliang <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Read PCI_EXT_CAP_ID_DSN to query security status.
The driver will throw a warning message when a non-secure type controller
is detected. The purpose of this interface is to avoid interacting with any
firmware which is not secured/signed by Broadcom. Any tampering on
firmware component will be detected by hardware and it will be communicated
to the driver to avoid any further interaction with that component.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Wait for host I/O completion (default 180 seconds) if I/O timeout is
detected on VDs.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlock the host diagnostic register, write the specific reset type to that
and wait for reset acknowledgment from the controller. If the reset is not
successful retry for the predefined number of times
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Register driver for threaded interrupts.
By default the driver will attempt I/O completion from interrupt context
(primary handler). Since the driver tracks per reply queue outstanding
I/Os, it will schedule threaded ISR if there are any outstanding I/Os
expected on that particular reply queue.
Threaded ISR (secondary handler) will loop for I/O completion as long as
there are outstanding I/Os (speculative method using same per reply queue
outstanding counter) or it has completed some X amount of commands
(something like budget).
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This operation requests that the IOC update the TimeStamp.
When the I/O Unit is powered on it sets the TimeStamp field value to
0x0000_0000_0000_0000 and increments the current value every millisecond.
A host driver sets the TimeStamp field to the current time by using an
IOCInit request. The TimeStamp field is periodically updated by the host
driver.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Detection of firmware fault or any kind of unresponsiveness in the
controller (any admin command which times out) results in resetting the
controller. The primary reset mechanisms used are either soft reset or diag
fault reset. A reset is performed if the host sets the ResetAction field in
the HostDiagnostic register to either 001b (soft reset) or 007b (diag fault
reset). After successfully resetting the controller the driver
reinitializes the controller by going through start of the day
initialization procedure. Pending I/Os during the reset are returned back
to the SCSI midlayer for retry.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Firmware can report various MPI Events. Enable support for processing the
following events related to device addition/removal to the driver:
- MPI3_EVENT_DEVICE_ADDED
- MPI3_EVENT_DEVICE_INFO_CHANGED
- MPI3_EVENT_DEVICE_STATUS_CHANGE
- MPI3_EVENT_ENCL_DEVICE_STATUS_CHANGE
- MPI3_EVENT_SAS_TOPOLOGY_CHANGE_LIST
- MPI3_EVENT_SAS_DISCOVERY
- MPI3_EVENT_SAS_DEVICE_DISCOVERY_ERROR
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reported-by: kernel test robot <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The watchdog thread is the driver's internal thread which does a few things
such as detecting firmware faults, resetting the controller, performing
timestamp sync, etc.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Send Port Enable Request to FW for Device Discovery. As part of port
enable completion driver calls scan_start and scan_finished hooks. SCSI
layer references like sdev, starget, etc. are added but actual device
discovery will be supported once driver adds complete event process
handling.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create operational request and reply queue pair.
The MPI3 transport interface consists of an Administrative Request Queue,
an Administrative Reply Queue, and Operational Messaging Queues. The
Operational Messaging Queues are the primary communication mechanism
between the host and the I/O Controller (IOC). Request messages, allocated
in host memory, identify I/O operations to be performed by the IOC. These
operations are queued on an Operational Request Queue by the host driver.
Reply descriptors track I/O operations as they complete. The IOC queues
these completions in an Operational Reply Queue.
To fulfil large contiguous memory requirement, driver creates multiple
segments and provide the list of segments. Each segment size should be 4K
which is a hardware requirement. An element array is contiguous or
segmented. A contiguous element array is located in contiguous physical
memory. A contiguous element array must be aligned on an element size
boundary. An element's physical address within the array may be directly
calculated from the base address, the Producer/Consumer index, and the
element size.
Expected phased identifier bit is used to find out valid entry on reply
queue. Driver sets <ephase> bit and IOC inverts the value of this bit on
each pass.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
|
Implement basic pci device driver requirements: Device probing, memory
allocation, mapping system registers, allocate irq lines, etc.
Source is managed in mainly three different files:
- mpi3mr_fw.c: Common code which interacts with underlying fw/hw.
- mpi3mr_os.c: Common code which interacts with SCSI midlayer.
- mpi3mr_app.c: Common code which interacts with application/ioctl.
This is currently work in progress.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
