Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 11月, 2020 10 次提交
    • S
      scsi: mpt3sas: Handle vSES vphy object during HBA reset · ffa381d6
      由 Sreekanth Reddy 提交于 
      During HBA reset the Port ID of vSES device may change. As a result, it is
necessary to refresh virtual_phy objects after reset.

Each Port's vphy_list table needs to be updated after updating the
HBA port table. The algorithm is as follows:

 - Loop over each port entry from HBA port table
   * Loop over each virtual phy entry from port's vphys_list table
     - Mark virtual phy entry as dirty by setting dirty bit in virtual phy
       entry's flags field
 - Read SASIOUnitPage0 page
 - Loop over each HBA Phy's Phy data from SASIOUnitPage0
    * If phy's remote attached device is not SES device then continue with
      processing next HBA Phy's Phy data;
    * Read SASPhyPage0 data for this Phy number and determine whether
      current phy is a virtual phy or not. If it is not a virtual phy then
      continue with next Phy data;
    * Get the current phy's remote attached vSES device's SAS Address;
    * Loop over each port entry from HBA port table
      - If Port's vphys_mask field is zero then continue with
        next Port entry,
      - Loop over each virtual phy entry from Port's vphy_list table
      - If the current phy's remote SAS Address is different from
        virtual phy entry's SAS Address then continue with next
        virtual phy entry,
      - Set bit corresponding to current phy number in virtual phy
        entry's phy_mask field,
      - Get the HBA port table's Port entry corresponding to
        Phy data's 'Port' value,
        * If there is no Port entry corresponding to Phy data's
	 'Port' value in HBA port table then create a new port entry
	 and add it to HBA port table.
      - If this retrieved Port entry is the same as the current Port
        entry then don't do anything, just clear the dirty bit from
        virtual phy entry's flag field and continue with processing
        next HBA Phy's Phy data.
      - If this retrieved Port entry is different from the current Port
        entry then move the current virtual phy entry from current Port's
        vphys_list to retrieved Port entry's vphys_list.
        * Clear current phy bit in current Port entry's vphys_mask and
          set the current phy bit in the retrieved Port entry's
          vphys_mask field.
        * Clear the dirty bit from virtual phy entry's flag field and
          continue with next HBA Phy's Phy data.
 - Delete the 'virtual phy' entries and HBA's 'Port table' entries which
   are still marked as 'dirty'.

Link: https://lore.kernel.org/r/20201027130847.9962-13-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      ffa381d6
    • S
      scsi: mpt3sas: Add bypass_dirty_port_flag parameter · 34b0a785
      由 Sreekanth Reddy 提交于 
      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>
      34b0a785
    • S
      scsi: mpt3sas: Handling HBA vSES device · ccc59923
      由 Sreekanth Reddy 提交于 
      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>
      ccc59923
    • S
      scsi: mpt3sas: Set valid PhysicalPort in SMPPassThrough · 9d0348a9
      由 Sreekanth Reddy 提交于 
      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>
      9d0348a9
    • S
      scsi: mpt3sas: Update hba_port objects after host reset · a5e99fda
      由 Sreekanth Reddy 提交于 
      During host reset there is a chance that the Port number allocated by the
firmware for the attached devices may change. Also, it may be possible that
some HBA phy's can go down/come up after reset. As a result, the driver
can't just trust the HBA Port table that it has populated before host reset
as valid. Instead it has to update the HBA Port table in such a way that it
shouldn't disturb the drives which are still accessible even after host
reset.

Use the following algorithm to update the HBA Port table during host reset:

I. After host reset operation and before marking the devices as
   responding/non-responding, create a temporary Port table called "New
   Port table" by parsing each of the HBA phy's Phy data info read from SAS
   IOUnit Page0:

   a. Check whether Phy's negotiated link rate is greater than 1.5Gbps, if
      not go to next Phy;

   b. Get the SAS Address of the attached device;

   c. Create a new entry in the "New Port table" with SAS Address field
      filled with attached device's SAS Address, port number with Phy's
      Port number (read from SAS IOUnit Page0) and enable bit in the 'Phy
      mask' field corresponding to current Phy number.  New entry is
      created only if the driver can't find an entry in the "New Port
      table" which matches with attached device 'SAS Address' & 'Port
      Number'. If it finds an entry with matches with attached device 'SAS
      Address' & 'Port Number' then the driver takes that matched entry and
      will enable current Phy number bit in the 'Phy mask' field;

   d. After parsing all the HBA phy's info, the driver will have complete
      Port table info in "New Port table".

II. Mark all the existing sas_device & sas_expander device structures as
    'dirty'.

III. Mark each entry of the HBA Port lists as 'dirty'.

IV. Take each entry from 'New Port table' one by one and check whether the
    entry has any corresponding matched entry (which is marked as 'dirty')
    in the HBA Port table or not.  While looking for a corresponding
    matched entry, look for matched entry in the sequence from top row to
    bottom row listed in the following table. If you find any matched entry
    (according to any of the rules tabulated below) then perform the action
    mentioned in the 'Action' column in that matched rule.

    ===========================================================================
    |Search  |SAS     | Phy Mask | Port    | Possibilities| Action            |
    |every   |Address |    or    | Number  |              | required          |
    |entry   |matched?| subset of| matched?|              |                   |
    |in below|        | phy mask |         |              |                   |
    |sequence|        | matched? |         |              |                   |
    ===========================================================================
    |  1     |matched | matched  | matched | nothing      |* unmark HBA port  |
    |        |        |          |         | changed      |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------
    |  2     |matched | matched  | not     | port number  |* Update port      |
    |        |        |          | matched | is changed   |number in the      |
    |        |        |          |         |              |matched port table |
    |        |        |          |         |              |entry              |
    |        |        |          |         |              |* unmask HBA port  |
    |        |        |          |         |              |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------
    |  3.a   |matched | subset of| matched |some phys     |* Add these new    |
    |        |        | phy mask | (or)    |might have    |phys to current    |
    |        |        | matched  | not     |enabled which |port in STL        |
    |        |        |          | matched |are previously|* Update phy mask  |
    |        |        |          | (but    |disabled      |field in HBA's port|
    |        |        |          | first   |              |table's matched    |
    |        |        |          | look for|              |entry,             |
    |        |        |          | matched |              |* Update port      |
    |        |        |          | one)    |              |number in the      |
    |	     |	      |		 | 	   |		  |matched port       |
    |        |        |          |         |              |table entry (if    |
    |        |        |          |         |              |port number is     |
    |        |        |          |         |              |changed),          |
    |        |        |          |         |              |* Unmask HBA port  |
    |        |        |          |         |              |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------
    |  3.b   |matched | subset of| matched |some phys     |*Remove these phys |
    |        |        | phy mask | (or)    |might have    |from current port  |
    |        |        | matched  | not     |disabled which|in STL             |
    |        |        |          | matched |are previously|* Update phy mask  |
    |        |        |          | (but    |enabled       |field in HBA's port|
    |        |        |          | first   |              |tables's matched   |
    |        |        |          | look for|              |entry,             |
    |        |        |          | matched |              |*Update port number|
    |        |        |          | one)    |              |in the matched port|
    |        |        |          |         |              |table entry (if    |
    |        |        |          |         |              |port number is     |
    |        |        |          |         |              |changed),          |
    |        |        |          |         |              |* Unmask HBA port  |
    |        |        |          |         |              |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------
    |  4     |matched | not      | matched |A cable       |*Remove old phys & |
    |        |        | matched  | (or)    |attached to an|new phys to current|
    |        |        |          | not     |expander is   |port in STL        |
    |        |        |          | matched |changed to    |* Update phy mask  |
    |        |        |          |         |another HBA   |field in HBA's port|
    |        |        |          |         |port during   |tables's matched   |
    |        |        |          |         |reset         |entry,             |
    |        |        |          |         |              |*Update port number|
    |        |        |          |         |              |in the matched port|
    |        |        |          |         |              |table entry (if    |
    |        |        |          |         |              |port number is     |
    |        |        |          |         |              |changed),          |
    |        |        |          |         |              |* Unmask HBA port  |
    |        |        |          |         |              |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------

V. Delete the hba_port objects which are still marked as dirty.

Link: https://lore.kernel.org/r/20201027130847.9962-9-sreekanth.reddy@broadcom.comReported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      a5e99fda
    • S
      scsi: mpt3sas: Get sas_device objects using device's rphy · 6df6be91
      由 Sreekanth Reddy 提交于 
      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>
      6df6be91
    • S
      scsi: mpt3sas: Get device objects using sas_address & portID · 7d310f24
      由 Sreekanth Reddy 提交于 
      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>
      7d310f24
    • S
      scsi: mpt3sas: Update hba_port's sas_address & phy_mask · e2f0cdf7
      由 Sreekanth Reddy 提交于 
      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>
      e2f0cdf7
    • S
      scsi: mpt3sas: Rearrange _scsih_mark_responding_sas_device() · 78ca7003
      由 Sreekanth Reddy 提交于 
      Rearrange _scsih_mark_responding_sas_device function. No functional change.

Link: https://lore.kernel.org/r/20201027130847.9962-4-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      78ca7003
    • S
      scsi: mpt3sas: Allocate memory for hba_port objects · e238e71b
      由 Sreekanth Reddy 提交于 
      Allocate hba_port object whenever a new HBA's wide/narrow port is
identified while processing the SASIOUnitPage0's phy data and add this
object to port_table_list.  Deallocate these objects during driver unload.

Link: https://lore.kernel.org/r/20201027130847.9962-3-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      e238e71b
  3. 16 9月, 2020 1 次提交
  5. 24 8月, 2020 1 次提交
  7. 21 8月, 2020 3 次提交
  9. 08 5月, 2020 2 次提交
  11. 01 4月, 2020 1 次提交
    • S
      scsi: mpt3sas: Fix kernel panic observed on soft HBA unplug · cc41f11a
      由 Sreekanth Reddy 提交于 
      Generic protection fault type kernel panic is observed when user performs
soft (ordered) HBA unplug operation while IOs are running on drives
connected to HBA.

When user performs ordered HBA removal operation, the kernel calls PCI
device's .remove() call back function where driver is flushing out all the
outstanding SCSI IO commands with DID_NO_CONNECT host byte and also unmaps
sg buffers allocated for these IO commands.

However, in the ordered HBA removal case (unlike of real HBA hot removal),
HBA device is still alive and hence HBA hardware is performing the DMA
operations to those buffers on the system memory which are already unmapped
while flushing out the outstanding SCSI IO commands and this leads to
kernel panic.

Don't flush out the outstanding IOs from .remove() path in case of ordered
removal since HBA will be still alive in this case and it can complete the
outstanding IOs. Flush out the outstanding IOs only in case of 'physical
HBA hot unplug' where there won't be any communication with the HBA.

During shutdown also it is possible that HBA hardware can perform DMA
operations on those outstanding IO buffers which are completed with
DID_NO_CONNECT by the driver from .shutdown(). So same above fix is applied
in shutdown path as well.

It is safe to drop the outstanding commands when HBA is inaccessible such
as when permanent PCI failure happens, when HBA is in non-operational
state, or when someone does a real HBA hot unplug operation. Since driver
knows that HBA is inaccessible during these cases, it is safe to drop the
outstanding commands instead of waiting for SCSI error recovery to kick in
and clear these outstanding commands.

Link: https://lore.kernel.org/r/1585302763-23007-1-git-send-email-sreekanth.reddy@broadcom.com
Fixes: c666d3be ("scsi: mpt3sas: wait for and flush running commands on shutdown/unload")
Cc: stable@vger.kernel.org #v4.14.174+
Signed-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      cc41f11a
  13. 12 3月, 2020 1 次提交
  15. 03 1月, 2020 6 次提交
  17. 25 10月, 2019 1 次提交
  19. 01 10月, 2019 1 次提交
    • S
      scsi: mpt3sas: Register trace buffer based on NVDATA settings · d04a6edf
      由 Sreekanth Reddy 提交于 
      Currently if user wishes to enable the host trace buffer during driver load
time, then user has to load the driver with module parameter
'diag_buffer_enable' set to one.

Alternatively now the user can enable host trace buffer by enabling the
following fields in manufacturing page11 in NVDATA (nvdata xml is used
while building HBA firmware image):

 * HostTraceBufferMaxSizeKB - Maximum trace buffer size in KB that host can
                              allocate,

 * HostTraceBufferMinSizeKB - Minimum trace buffer size in KB atleast host
                              should allocate,

 * HostTraceBufferDecrementSizeKB - size by which host can reduce from
                              buffer size and retry the buffer allocation
                              when buffer allocation failed with previous
                              calculated buffer size.

The driver will register the trace buffer automatically without any module
parameter during boot time when above fields are enabled in manufacturing
page11 in HBA firmware.

Driver follows the following algorithm for enabling the host trace buffer
during driver load time:

* If user has loaded the driver with module parameter 'diag_buffer_enable'
  set to one, then driver allocates 2MB buffer and registers this buffer
  with HBA firmware for capturing the firmware trace logs.

* Else driver reads manufacture page11 data and checks whether
  HostTraceBufferMaxSizeKB filed is zero or not?

  - If HostTraceBufferMaxSizeKB is non-zero then driver tries to allocate
    HostTraceBufferMaxSizeKB size of memory. If the buffer allocation is
    successful, then it will register this buffer with HBA firmware, else
    in a loop the driver will try again by reducing the current buffer size
    with HostTraceBufferDecrementSizeKB size until memory allocation is
    successful or buffer size falls below HostTraceBufferMinSizeKB. If the
    memory allocation is successful, then the buffer will be registered
    with the firmware. Else, if the buffer size falls below the
    HostTraceBufferMinSizeKB, then driver won't register trace buffer with
    HBA firmware.

  - If HostTraceBufferMaxSizeKB is zero, then driver won't register trace
    buffer with HBA firmware.

Link: https://lore.kernel.org/r/1568379890-18347-2-git-send-email-sreekanth.reddy@broadcom.comSigned-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      d04a6edf
  21. 30 8月, 2019 1 次提交
  23. 28 8月, 2019 1 次提交
  25. 08 8月, 2019 5 次提交
    • S
      scsi: mpt3sas: Run SAS DEVICE STATUS CHANGE EVENT from ISR · 54d74e6b
      由 Suganath Prabu 提交于 
      In some cases, like while performing extensive expander reset or phy reset,
user may observe that drives are not visible in OS. Driver's
firmware-worker thread is blocked for more than 120 seconds resulting in a
call trace.

1. Received target add event for Device A and hence driver has registered
this device to SML by calling sas_rphy_add(). SML has half added this
device and returned the control to the driver by quitting from
sas_rphy_add() API, and started some background scanning on this device A.

2. While background scanning is going on device A, driver has received SAS
DEVICE STATUS CHANGE EVENT with RC code "Internal device reset" event and
hence driver has set tm_busy flag for this Device A from FW worker thread
context. When tm_busy flag is set then driver return scsi commands with
device busy status asking the kernel to retry the command after some time.
So background scanning for device A will be waiting for this tm_busy to be
cleared.

3. Meanwhile driver has received a target add event for Device B and hence
driver called sas_rphy_add() API to register this device with SML. But
since background scanning for Device A is still pending and SML is not
quitting from sas_rphy_add(), the driver’s firmware worker thread got
blocked.

4. Now driver has received SAS DEVICE STATUS CHANGE EVENT with RC code
"Internal device reset complete" event. But as driver’s firmware worker
thread got blocked in Step3, it can’t process this event and it was not
clearing the tm_busy flag and deadlock occurred (where SML was waiting for
tm_busy flag to be cleared and our FW worker thread is waiting for SML to
quit from sas_device_rphy_add() API).

Same deadlock will be observed even if device B is getting removed in
step3. So to limit these types of deadlocks driver will process the SAS
DEVICE STATUS CHANGE EVENT events from ISR context instead of processing
this event from worker thread context.  This improvement avoids above
deadlock.
Signed-off-by: NSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      54d74e6b
    • S
      scsi: mpt3sas: Reduce the performance drop · 1edc6770
      由 Suganath Prabu 提交于 
      This patch is to reduce the performance drop depth observed on SATA HDD
when ATA PT command is outstanding.

Driver returns IO commands with status "SAM_STAT_BUSY" whenever ATA PT
command is outstanding. With this, IO commands will be retried until this
outstanding ATA PT to complete and hence we will observe drop in
performance.

As the driver is completing the subsequent IOs commands with SAM_STAT_BUSY
status, these IOs has to go though the block layer.  Hence it adds latency
to the IOs and large performance drop is observed.

So to reduce this performance dropp, added improvement in driver to return
the subsequent IOs with SCSI_MLQUEUE_DEVICE_BUSY status instead of
completing the IOs with SAM_STAT_BUSY status when ATA PT command is
outstanding. Sending command back with SCSI_MLQUEUE_DEVICE_BUSY does not go
through complete block layer stack (as scsi_done won't be called) SML will
immediately retry the command and this method will avoid latency of block
layer stack and the performance impact will be reduced.

On Local setup, ran 512k sequential read IO operation on HGST SATA drive
with existing driver & with this improvement drivers and here is the
result,

1. With existing driver: IOs are running at bandwidth of ~230 rMB/s and
whenever any ATA PT command is outstanding (e.g issued from systemd-udevd
daemon) then this bandwidth drops to ~150 rMB/s.

2. With this improvement driver: IOs are running at bandwidth of ~230 rMB/s
and whenever any ATA PT command is outstanding then this bandwidth drops to
just ~190 rMB/s.
Signed-off-by: NSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      1edc6770
    • S
      scsi: mpt3sas: Add sysfs to know supported features · 3ac8e47b
      由 Suganath Prabu 提交于 
      Currently with sysfs parameter "drv_support_bitmap" driver exposes whether
driver supports toolbox memory move command or not.

And application should issue the toolbox memory move command only if driver
tell that memory move tool box command is supported through this sysfs
parameter.

In future we can utilize this sysfs parameter if any new feature is added
and need to notify the same to applications.
Signed-off-by: NSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      3ac8e47b
    • S
      scsi: mpt3sas: Allow ioctls to blocked access status NVMe · 3c090ce3
      由 Suganath Prabu 提交于 
      If driver sees the NVMe drive with "DEVICE_BLOCKED" AccessStatus in its
PCIe Device Page0, then driver removes the drive from its internal list and
does not allow any IOCTL commands to be sent to the drive and will return
the IOCTLs with "-ENODEV" status.

The driver will now allow NVMe Encapsulated IOCTL issued to the NVMe device
with an access status of DEVICE_BLOCKED. This change allows the user to
flash new drive firmware online and revive the drive.

Add NVMe device only the driver's internal list even though the device is
in the blocked state so that the device will be visible to Apps. This way
Apps can send NVMe Encapsulated IOCTLs to this drive and bring the drive
online. This NVMe drive with DEVICE_BLOCKED access status won't added to
the SML, it will be added only in the driver's internal list.

[mkp: clarified desc]
Signed-off-by: NSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      3c090ce3
    • S
      scsi: mpt3sas: Enumerate SES of a managed PCIe switch · 5bb309db
      由 Suganath Prabu 提交于 
      SES device of managed PCIe switch will be enumerated same as NVMe drives.

The device info type for this SES device is

        MPI26_PCIE_DEVINFO_SCSI (0x4),

whereas the device info type for NVMe drives is

        MPI26_PCIE_DEVINFO_NVME (0x3).

Based on this device info type driver determines whether the device is NVMe
drive or a SES device of a managed PCIe switch.

This SES device doesn't have the PCIe device page 2 information like NVMe
drives, so driver won't read PCIe device page 2 information for SES device.

This SES device uses only IEEE SGL's, So driver build's IEEE SGL's whenever
it receives any SCSI commands for this SES device.
Signed-off-by: NSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      5bb309db
  27. 17 7月, 2019 1 次提交
  29. 21 6月, 2019 1 次提交
  31. 19 6月, 2019 3 次提交
  33. 26 3月, 2019 1 次提交
    • S
      scsi: mpt3sas: Fix kernel panic during expander reset · c2fe742f
      由 Sreekanth Reddy 提交于 
      During expander reset handling, the driver invokes kernel function
scsi_host_find_tag() to obtain outstanding requests associated with the
scsi host managed by the driver. Driver loops from tag value zero to hba
queue depth to obtain the outstanding scmds. But when blk-mq is enabled,
the block layer may return stale entry for one or more requests. This may
lead to kernel panic if the returned value is inaccessible or the memory
pointed by the returned value is reused.

Reference of upstream discussion:

	https://patchwork.kernel.org/patch/10734933/

Instead of calling scsi_host_find_tag() API for each and every smid (smid
is tag +1) from one to shost->can_queue, now driver will call this API (to
obtain the outstanding scmd) only for those smid's which are outstanding at
the driver level.

Driver will determine whether this smid is outstanding at driver level by
looking into it's corresponding MPI request frame, if its MPI request frame
is empty, then it means that this smid is free and does not need to call
scsi_host_find_tag() for it.  By doing this, driver will invoke
scsi_host_find_tag() for only those tags which are outstanding at the
driver level.

Driver will check whether particular MPI request frame is empty or not by
looking into the "DevHandle" field. If this field is zero then it means
that this MPI request is empty. For active MPI request DevHandle must be
non-zero.

Also driver will memset the MPI request frame once the corresponding scmd
is processed (i.e. just before calling
scmd->done function).
Signed-off-by: NSreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      c2fe742f