1. 15 Apr, 2019 5 commits
    • John Garry's avatar
      scsi: libsas: Do discovery on empty PHY to update PHY info · d8649fc1
      John Garry authored
      When we discover the PHY is empty in sas_rediscover_dev(), the PHY
      information (like negotiated linkrate) is not updated.
      
      As such, for a user examining sysfs for that PHY, they would see
      incorrect values:
      
      root@(none)$ cd /sys/class/sas_phy/phy-0:0:20
      root@(none)$ more negotiated_linkrate
      3.0 Gbit
      root@(none)$ echo 0 > enable
      root@(none)$ more negotiated_linkrate
      3.0 Gbit
      
      So fix this, simply discover the PHY again, even though we know it's empty;
      in the above example, this gives us:
      
      root@(none)$ more negotiated_linkrate
      Phy disabled
      
      We must do this after unregistering the device associated with the PHY
      (in sas_unregister_devs_sas_addr()).
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      d8649fc1
    • John Garry's avatar
      scsi: libsas: Inject revalidate event for root port event · 085f104a
      John Garry authored
      According to the SAS spec, an expander device shall transmit BROADCAST
      (CHANGE) from at least one phy in each expander port other than the
      expander port that is the cause for transmitting BROADCAST (CHANGE).
      
      As such, for when the link is lost for a root PHY attached to an expander
      PHY, we get no broadcast event.
      
      This causes an issue for libsas, in that we will not revalidate the domain
      for these events.
      
      As a solution, for when a root PHY is formed or deformed from a root port,
      insert a broadcast event to trigger a domain revalidation.
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      085f104a
    • John Garry's avatar
      scsi: libsas: Improve vague log in SAS rediscovery · a5b38d31
      John Garry authored
      When an expander PHY which was part of a wideport disconnects, we would see
      a log like this from sas_rediscover():
      
      [   39.695554] sas: phy20 part of wide port with phy16
      
      Here, phy20 is the PHY that disconnected, and phy16 is the lowest indexed
      member PHY of the wideport.
      
      The log implies the phy20 is still part of the wideport with phy16, so is
      misleading or, at least, vague.
      
      Improve the logs in SAS rediscovery by removing this log and adding a log
      in sas_rediscover_dev() to tell what's really going on.
      
      While we're at it, also make the logs in sas_find_bcast_dev() more
      informative (and more consistent with the reset of the expander logs).
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      a5b38d31
    • John Garry's avatar
      scsi: libsas: Try to retain programmed min linkrate for SATA min pathway unmatch fixing · f7ddb43e
      John Garry authored
      Currently for fixing the linkrate matching during discovery such that the
      linkrate of a SATA PHY does not exceed min pathway to initiator, we set the
      SATA PHY programmed min linkrate to the same value as the programmed max
      linkrate.
      
      This is unnecessary, and we should be able to keep the same programmed min
      linkrate if it is already lower than this new max programmed linkrate.
      
      This patch makes that change.
      
      In effect, this will not make much difference since we generally will
      negotiate a linkrate at the programmed max linkrate, and the programmed min
      linkrate will have no impact.
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      f7ddb43e
    • John Garry's avatar
      scsi: libsas: Stop hardcoding SAS address length · 7b27c5fe
      John Garry authored
      Many times we use 8 for SAS address length, while we already have a macro
      for this - SAS_ADDR_SIZE.
      
      Replace instances of this with the macro. However, don't touch the SAS
      address array sizes sas.h, as these are defined according to the SAS spec.
      
      Some missing whitespaces are also added, and whitespace indentation
      in sas_hash_addr() is also fixed (see sas_hash_addr()).
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      7b27c5fe
  2. 13 Apr, 2019 22 commits
  3. 10 Apr, 2019 1 commit
  4. 09 Apr, 2019 12 commits