1. 12 5月, 2018 4 次提交
  2. 11 5月, 2018 1 次提交
  3. 27 3月, 2018 1 次提交
  4. 19 3月, 2018 3 次提交
    • H
      libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version · d418ff56
      Hans de Goede 提交于
      When commit 9c7be59f ("libata: Apply NOLPM quirk to Crucial MX100
      512GB SSDs") was added it inherited the ATA_HORKAGE_NO_NCQ_TRIM quirk
      from the existing "Crucial_CT*MX100*" entry, but that entry sets model_rev
      to "MU01", where as the entry adding the NOLPM quirk sets it to NULL.
      
      This means that after this commit we no apply the NO_NCQ_TRIM quirk to
      all "Crucial_CT512MX100*" SSDs even if they have the fixed "MU02"
      firmware. This commit splits the "Crucial_CT512MX100*" quirk into 2
      quirks, one for the "MU01" firmware and one for all other firmware
      versions, so that we once again only apply the NO_NCQ_TRIM quirk to the
      "MU01" firmware version.
      
      Fixes: 9c7be59f ("libata: Apply NOLPM quirk to ... MX100 512GB SSDs")
      Cc: stable@vger.kernel.org
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      d418ff56
    • H
      libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions · 3bf7b5d6
      Hans de Goede 提交于
      Commit b17e5729 ("libata: disable LPM for Crucial BX100 SSD 500GB
      drive"), introduced a ATA_HORKAGE_NOLPM quirk for Crucial BX100 500GB SSDs
      but limited this to the MU02 firmware version, according to:
      http://www.crucial.com/usa/en/support-ssd-firmware
      
      MU02 is the last version, so there are no newer possibly fixed versions
      and if the MU02 version has broken LPM then the MU01 almost certainly
      also has broken LPM, so this commit changes the quirk to apply to all
      firmware versions.
      
      Fixes: b17e5729 ("libata: disable LPM for Crucial BX100 SSD 500GB...")
      Cc: stable@vger.kernel.org
      Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      3bf7b5d6
    • H
      libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs · 62ac3f73
      Hans de Goede 提交于
      There have been reports of the Crucial M500 480GB model not working
      with LPM set to min_power / med_power_with_dipm level.
      
      It has not been tested with medium_power, but that typically has no
      measurable power-savings.
      
      Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03
      and there is a MU05 update available, but that update does not mention any
      LPM fixes in its changelog, so the quirk matches all firmware versions.
      
      In my experience the LPM problems with (older) Crucial SSDs seem to be
      limited to higher capacity versions of the SSDs (different firmware?),
      so this commit adds a NOLPM quirk for the 480 and 960GB versions of the
      M500, to avoid LPM causing issues with these SSDs.
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: NMartin Steigerwald <martin@lichtvoll.de>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      62ac3f73
  5. 14 3月, 2018 2 次提交
  6. 12 3月, 2018 1 次提交
  7. 21 2月, 2018 1 次提交
  8. 18 2月, 2018 1 次提交
  9. 13 2月, 2018 1 次提交
    • E
      libata: remove WARN() for DMA or PIO command without data · 9173e5e8
      Eric Biggers 提交于
      syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0.  This
      happened because it issued a READ_6 command with no data buffer.
      
      Just remove the WARN(), as it doesn't appear indicate a kernel bug.  The
      expected behavior is to fail the command, which the code does.
      
      Here's a reproducer that works in QEMU when /dev/sg0 refers to a disk of
      the default type ("82371SB PIIX3 IDE"):
      
          #include <fcntl.h>
          #include <unistd.h>
      
          int main()
          {
                  char buf[42] = { [36] = 0x8 /* READ_6 */ };
      
                  write(open("/dev/sg0", O_RDWR), buf, sizeof(buf));
          }
      
      Fixes: f92a2636 ("libata: change ATA_QCFLAG_DMAMAP semantics")
      Reported-by: syzbot+f7b556d1766502a69d85071d2ff08bd87be53d0f@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org> # v2.6.25+
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      9173e5e8
  10. 19 12月, 2017 1 次提交
  11. 05 12月, 2017 1 次提交
    • D
      libata: sata_down_spd_limit should return if driver has not recorded sstatus speed · 2dc0b46b
      David Milburn 提交于
      During hotplug, it is possible for 6Gbps link speed to be limited all
      the way down to 1.5 Gbps which may lead to a slower link speed when
      drive is re-connected.
      
      This behavior has been seen on a Intel Lewisburg SATA controller
      (8086:a1d2) with HGST HUH728080ALE600 drive where SATA link speed was
      limited to 1.5 Gbps and when re-connected the link came up 3.0 Gbps.
      
      This patch was retested on above configuration and showed the
      hotplugged link to come back online at max speed (6Gbps). I did not
      see the downgrade when testing on Intel C600/X79, but retested patched
      linux-4.14-rc5 kernel and didn't see any side effects from this
      change. Also, successfully retested hotplug on port multiplier 3Gbps
      link.
      
      tj: Minor comment updates.
      Signed-off-by: NDavid Milburn <dmilburn@redhat.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      2dc0b46b
  12. 30 10月, 2017 1 次提交
  13. 23 10月, 2017 1 次提交
  14. 17 10月, 2017 1 次提交
  15. 03 10月, 2017 1 次提交
  16. 19 9月, 2017 1 次提交
    • H
      libata: Add new med_power_with_dipm link_power_management_policy setting · f4ac6476
      Hans de Goede 提交于
      As described by Matthew Garret quite a while back:
      https://mjg59.dreamwidth.org/34868.html
      
      Intel CPUs starting with the Haswell generation need SATA links to power
      down for the "package" part of the CPU to reach low power-states like
      PC7 / P8 which bring a significant power-saving with them.
      
      The default max_performance lpm policy does not allow for these high
      PC states, both the medium_power and min_power policies do allow this.
      
      The min_power policy saves significantly more power, but there are some
      reports of some disks / SSDs not liking min_power leading to system
      crashes and in some cases even data corruption has been reported.
      
      Matthew has found a document documenting the default settings of
      Intel's IRST Windows driver with which most laptops ship:
      https://www-ssl.intel.com/content/dam/doc/reference-guide/sata-devices-implementation-recommendations.pdf
      
      Matthew wrote a patch changing med_power to match those defaults, but
      that never got anywhere as some people where reporting issues with the
      patch-set that patch was a part of.
      
      This commit is another attempt to make the default IRST driver settings
      available under Linux, but instead of changing medium_power and
      potentially introducing regressions, this commit adds a new
      med_power_with_dipm setting which is identical to the existing
      medium_power accept that it enables dipm on top, which makes it match
      the Windows IRST driver settings, which should hopefully be safe to
      use on most devices.
      
      The med_power_with_dipm setting is close to min_power, except that:
      a) It does not use host-initiated slumber mode (ASP not set),
         but it does allow device-initiated slumber
      b) It does not enable DevSlp mode
      
      On my T440s test laptop I get the following power savings when idle:
      medium_power		0.9W
      med_power_with_dipm	1.2W
      min_power		1.2W
      Suggested-by: NMatthew Garrett <mjg59@srcf.ucam.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      f4ac6476
  17. 08 9月, 2017 1 次提交
  18. 29 8月, 2017 3 次提交
  19. 11 7月, 2017 1 次提交
    • D
      libata: Cleanup ata_read_log_page() · 7cfdfdc8
      Damien Le Moal 提交于
      The warning message "READ LOG DMA EXT failed, trying unqueued" in
      ata_read_log_page() as well as the macro name ATA_HORKAGE_NO_NCQ_LOG
      are confusing: the command READ LOG DMA EXT is not an queued NCQ command
      unless it is encapsulated in a RECEIVE FPDMA QUEUED command.
      From ACS-4 READ LOG DMA EXT description:
      
      "The device processes the READ LOG DMA EXT command in the NCQ feature
      set environment (see 4.13.6) if the READ LOG DMA EXT command is
      encapsulated in a RECEIVE FPDMA QUEUED command (see 7.30) with the
      inputs encapsulated as shown in 7.23.6."
      
      To avoid confusion, fix the warning messsage to mention switching to PIO and
      not "unqueued" and rename the macro ATA_HORKAGE_NO_NCQ_LOG to
      ATA_HORKAGE_NO_DMA_LOG.
      Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      7cfdfdc8
  20. 27 6月, 2017 1 次提交
  21. 06 6月, 2017 5 次提交
  22. 01 6月, 2017 1 次提交
  23. 16 5月, 2017 2 次提交
  24. 14 3月, 2017 2 次提交
  25. 07 1月, 2017 2 次提交
    • D
      libata: Fix ATA request sense · 2dae9955
      Damien Le Moal 提交于
      For an ATA device supporting the sense data reporting feature set, a
      failed command will trigger the execution of ata_eh_request_sense if
      the result task file of the failed command has the ATA_SENSE bit set
      (sense data available bit). ata_eh_request_sense executes the REQUEST
      SENSE DATA EXT command to retrieve the sense data of the failed
      command. On success of REQUEST SENSE DATA EXT, the ATA_SENSE bit will
      NOT be set (the command succeeded) but ata_eh_request_sense
      nevertheless tests the availability of sense data by testing that bit
      presence in the result tf of the REQUEST SENSE DATA EXT command.  This
      leads us to falsely assume that request sense data failed and to the
      warning message:
      
      atax.xx: request sense failed stat 50 emask 0
      
      Upon success of REQUEST SENSE DATA EXT, set the ATA_SENSE bit in the
      result task file command so that sense data can be returned by
      ata_eh_request_sense.
      Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
      2dae9955
    • T
      libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices · e0edc8c5
      Tejun Heo 提交于
      Marko reports that CX1-JB512-HP shows the same timeout issues as
      CX1-JB256-HP.  Let's apply MAX_SEC_128 to all devices in the series.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NMarko Koski-Vähälä <marko@koski-vahala.com>
      Cc: stable@vger.kernel.org # v3.19+
      e0edc8c5