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://<email address hidden>
Cc: <email address hidden>
Reviewed-by: Hannes Reinecke <email address hidden>
Reviewed-by: Tomas Henzl <email address hidden>
Reviewed-by: Himanshu Madhani <email address hidden>
Signed-off-by: Kashyap Desai <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 28cbe2f420d338cc4cb8f0cc367b22ea3c41b3b5)
Signed-off-by: Jeff Lane <email address hidden>
6a7b457...
by
Kashyap Desai <email address hidden>
scsi: mpi3mr: Add support for PM suspend and resume
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://<email address hidden>
Cc: <email address hidden>
Reviewed-by: Hannes Reinecke <email address hidden>
Reviewed-by: Tomas Henzl <email address hidden>
Reviewed-by: Himanshu Madhani <email address hidden>
Signed-off-by: Kashyap Desai <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit f061178e076210a549a546f3879ed51a61fcf938)
Signed-off-by: Jeff Lane <email address hidden>
c7503e2...
by
Kashyap Desai <email address hidden>
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://<email address hidden>
Cc: <email address hidden>
Reviewed-by: Hannes Reinecke <email address hidden>
Reviewed-by: Tomas Henzl <email address hidden>
Reviewed-by: Himanshu Madhani <email address hidden>
Signed-off-by: Kashyap Desai <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 463429f8dd5c94aae4b0948c56e67eb21cb6964e)
Signed-off-by: Jeff Lane <email address hidden>
030b703...
by
Kashyap Desai <email address hidden>
scsi: mpi3mr: Hardware workaround for UNMAP commands to NVMe drives
The controller hardware can not handle certain UNMAP commands for NVMe
drives. Add support in the driver for checking those commands and handle
them appropriately.
Link: https://<email address hidden>
Cc: <email address hidden>
Reviewed-by: Hannes Reinecke <email address hidden>
Reviewed-by: Tomas Henzl <email address hidden>
Reviewed-by: Himanshu Madhani <email address hidden>
Signed-off-by: Kashyap Desai <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 392bbeb85b2a6f80e3036dfccdf55a1d076bba2c)
Signed-off-by: Jeff Lane <email address hidden>
1bde6df...
by
Kashyap Desai <email address hidden>
scsi: mpi3mr: Allow certain commands during pci-remove hook
Instead of driver returning DID_NO_CONNECT during driver unload allow SSU
and Sync Cache commands to be sent to the controller to flush any cached
data from the drive.
Link: https://<email address hidden>
Cc: <email address hidden>
Reviewed-by: Hannes Reinecke <email address hidden>
Reviewed-by: Tomas Henzl <email address hidden>
Reviewed-by: Himanshu Madhani <email address hidden>
Signed-off-by: Kashyap Desai <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 82141ddba90a88df8ebde782c5b24c7cc5a9926e)
Signed-off-by: Jeff Lane <email address hidden>