scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery
+----------+ +----------+
| | | |
| |--- 3.0 G ---| |--- 6.0 G --- SAS disk
| | | |
| |--- 3.0 G ---| |--- 6.0 G --- SAS disk
|initiator | | |
| device |--- 3.0 G ---| Expander |--- 6.0 G --- SAS disk
| | | |
| |--- 3.0 G ---| |--- 6.0 G --- SATA disk -->failed to connect
| | | |
| | | |--- 6.0 G --- SATA disk -->failed to connect
| | | |
+----------+ +----------+
According to Serial Attached SCSI - 1.1 (SAS-1.1):
If an expander PHY attached to a SATA PHY is using a physical link rate
greater than the maximum connection rate supported by the pathway from an
STP initiator port, a management application client should use the SMP PHY
CONTROL function (see 10.4.3.10) to set the PROGRAMMED MAXIMUM PHYSICAL
LINK RATE field of the expander PHY to the maximum connection rate
supported by the pathway from that STP initiator port.
Currently libsas does not support checking if this condition occurs, nor
rectifying when it does.
Such a condition is not at all common, however it has been seen on some
pre-silicon environments where the initiator PHY only supports a 1.5 Gbit
maximum linkrate, mated with 12G expander PHYs and 3/6G SATA phy.
This patch adds support for checking and rectifying this condition during
initial device discovery only.
We do support checking min pathway connection rate during revalidation phase,
when new devices can be detected in the topology. However we do not
support in the case of the the user reprogramming PHY linkrates, such that
min pathway condition is not met/maintained.
A note on root port PHY rates:
The libsas root port PHY rates calculation is broken. Libsas sets the
rates (min, max, and current linkrate) of a root port to the same linkrate
of the first PHY member of that same port. In doing so, it assumes that
all other PHYs which subsequently join the port to have the same
negotiated linkrate, when they could actually be different.
In practice this doesn't happen, as initiator and expander PHYs are
normally initialised with consistent min/max linkrates.
This has not caused an issue so far, so leave alone for now.
Tested-by: Jian Luo <email address hidden>
Signed-off-by: John Garry <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit cec9771d2e954650095aa37a6a97722c8194e7d2 linux-next)
Signed-off-by: dann frazier <email address hidden>
scsi: libsas: Check SMP PHY control function result
Currently the SMP PHY control execution result is checked, however the
function result for the command is not.
As such, we may be missing all potential errors, like SMP FUNCTION FAILED,
INVALID REQUEST FRAME LENGTH, etc., meaning the PHY control request has
failed.
In some scenarios we need to ensure the function result is accepted, so add
a check for this.
Tested-by: Jian Luo <email address hidden>
Signed-off-by: John Garry <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 01929a65dfa13e18d89264ab1378854a91857e59 linux-next)
Signed-off-by: dann frazier <email address hidden>
scsi: hisi_sas: No need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the return
value. The function can work or not, but the code logic should never do
something different based on this.
Signed-off-by: John Garry <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit c2c7e740577154e755ec373712e32e5864e88315 linux-next)
Signed-off-by: dann frazier <email address hidden>
scsi: hisi_sas: Fix type casting and missing static qualifier in debugfs code
Sparse can detect some type casting issues in the debugfs code, so fix it
up.
Also a missing static qualifier is added to hisi_sas_debugfs_to_reg_name().
Signed-off-by: John Garry <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 5b0eeac4bed4b1a261acf3cd893f929e68814a0d linux-next)
Signed-off-by: dann frazier <email address hidden>
scsi: hisi_sas: send primitive NOTIFY to SSP situation only
Send primitive NOTIFY to SSP situation only, or it causes underflow issue
when sending IO. Also rename hisi_sas_hw.sl_notify() to hisi_sas_hw.
sl_notify_ssp().
Signed-off-by: Xiang Chen <email address hidden>
Signed-off-by: John Garry <email address hidden>
Signed-off-by: Martin K. Petersen <<email address hidden> >
(cherry picked from commit 569eddcf3a0f4efff4ef96a7012010e0f7daa8b4 linux-next)
Signed-off-by: dann frazier <email address hidden>
scsi: hisi_sas: shutdown axi bus to avoid exception CQ returned
When injecting 2 bit ECC error, it will cause fatal AXI interrupts. Before
the recovery of SAS controller reset, the internal of SAS controller is in
error. If CQ interrupts return at the time, actually it is exception CQ
interrupt, and it may cause resource release in disorder.
To avoid the exception situation, shutdown AXI bus after fatal AXI
interrupt. In SAS controller reset, it will restart AXI bus. For later
version of v3 hw, hardware will shutdown AXI bus for this situation, so
just fix current ver of v3 hw.
Signed-off-by: Xiang Chen <email address hidden>
Signed-off-by: John Garry <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 5c31b0c677531c2b8b4e29b3cfb923df663f39b7 linux-next)
Signed-off-by: dann frazier <email address hidden>
scsi: hisi_sas: remove the check of sas_dev status in hisi_sas_I_T_nexus_reset()
When issing a hardreset to a SATA device when running IO, it is possible
that abnormal CQs of the device are returned. Then enter error handler, it
doesn't enter function hisi_sas_abort_task() as there is no timeout IO, and
it doesn't set device as HISI_SAS_DEV_EH. So when hardreset by libata
later, it actually doesn't issue hardreset as there is a check to judge
whether device is in error.
For this situation, actually need to hardreset the device to recover.
So remove the check of sas_dev status in hisi_sas_I_T_nexus_reset().
Before we add the check to avoid the endless loop of reset for
directly-attached SATA device at probe time, actually we flutter it for
it, so it is not necessary to add the check now.
Signed-off-by: Xiang Chen <email address hidden>
Signed-off-by: John Garry <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit ffb1c820b8b6a0466a51c467dcd8c0add77d00a7 linux-next)
Signed-off-by: dann frazier <email address hidden>
