1. 29 8月, 2017 2 次提交
  2. 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
  3. 06 6月, 2017 1 次提交
  4. 16 5月, 2017 2 次提交
  5. 07 2月, 2017 1 次提交
  6. 11 1月, 2017 1 次提交
  7. 20 10月, 2016 2 次提交
  8. 22 9月, 2016 1 次提交
  9. 19 7月, 2016 3 次提交
  10. 15 7月, 2016 1 次提交
  11. 14 7月, 2016 1 次提交
  12. 10 5月, 2016 5 次提交
  13. 05 4月, 2016 1 次提交
  14. 26 2月, 2016 1 次提交
    • H
      libata: Align ata_device's id on a cacheline · 4ee34ea3
      Harvey Hunt 提交于
      The id buffer in ata_device is a DMA target, but it isn't explicitly
      cacheline aligned. Due to this, adjacent fields can be overwritten with
      stale data from memory on non coherent architectures. As a result, the
      kernel is sometimes unable to communicate with an ATA device.
      
      Fix this by ensuring that the id buffer is cacheline aligned.
      
      This issue is similar to that fixed by Commit 84bda12a
      ("libata: align ap->sector_buf").
      Signed-off-by: NHarvey Hunt <harvey.hunt@imgtec.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 2.6.18
      Signed-off-by: NTejun Heo <tj@kernel.org>
      4ee34ea3
  15. 26 1月, 2016 1 次提交
    • D
      drivers: ata: wake port before DMA stop for ALPM · fb329633
      Danesh Petigara 提交于
      The AHCI driver code stops and starts port DMA engines at will
      without considering the power state of the particular port. The
      AHCI specification isn't very clear on how to handle this scenario,
      leaving implementation open to interpretation.
      
      Broadcom's STB SATA host controller is unable to handle port DMA
      controller restarts when the port in question is in low power mode.
      When a port enters partial or slumber mode, its PHY is powered down.
      When a controller restart is requested, the controller's internal
      state machine expects the PHY to be brought back up by software which
      never happens in this case, resulting in failures.
      
      To avoid this situation, logic is added to manually wake up the port
      just before its DMA engine is stopped, if the port happens to be in
      a low power state. HBA initiated power management ensures that the port
      eventually returns to its configured low power state, when the link is
      idle (as per the conditions listed in the spec). A new host flag is also
      added to ensure this logic is only exercised for hosts with the above
      limitation.
      
      tj: Formatting changes.
      Signed-off-by: NDanesh Petigara <dpetigara@broadcom.com>
      Reviewed-by: NMarkus Mayer <mmayer@broadcom.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      fb329633
  16. 09 1月, 2016 1 次提交
  17. 07 12月, 2015 1 次提交
  18. 01 10月, 2015 1 次提交
    • M
      ata: ahci: find eSATA ports and flag them as removable · 8a3e33cf
      Manuel Lauss 提交于
      If the AHCI ports' HPCP or ESP bits are set, the port
      should be considered external (e.g. eSATA) and is marked
      as removable.  Userspace tools like udisks then treat it
      like an usb drive.
      
      With this patch applied, when I plug a drive into the esata port,
      KDE pops up a window asking what to do with the drives(s), just
      like it does for any random USB stick.
      
      Removability is indicated to the upper layers by way of the
      SCSI RMB bit, as I haven't found another way to signal
      userspace to treat a sata disk like any usb stick.
      Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      8a3e33cf
  19. 15 7月, 2015 2 次提交
  20. 01 6月, 2015 1 次提交
  21. 05 5月, 2015 1 次提交
  22. 26 4月, 2015 2 次提交
  23. 25 3月, 2015 1 次提交
    • T
      libata: remove ATA_FLAG_LOWTAG · 3a028243
      Tejun Heo 提交于
      sata_sil24 for some reason pukes when tags are allocated round-robin
      which helps tag ordered controllers.  To work around the issue,
      72dd299d ("libata: allow sata_sil24 to opt-out of tag ordered
      submission") introduced ATA_FLAG_LOWTAG which tells libata tag
      allocation to do lowest-first.
      
      However, with the recent switch to blk-mq tag allocation, the liata
      tag allocation code path is no longer used and the workaround is now
      implemented in the block layer and selected by setting
      scsi_host_template->tag_alloc_policy to BLK_TAG_ALLOC_FIFO.  See
      9269e234 ("libata: make sata_sil24 use fifo tag allocator").
      
      This leaves ATA_FLAG_LOWTAG withoout any actual user.  Remove it.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Shaohua Li <shli@fb.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      3a028243
  24. 20 3月, 2015 1 次提交
    • S
      ata: Add a new flag to destinguish sas controller · 5067c046
      Shaohua Li 提交于
      SAS controller has its own tag allocation, which doesn't directly match to ATA
      tag, so SAS and SATA have different code path for ata tags. Originally we use
      port->scsi_host (98bd4be1) to destinguish SAS controller, but libsas set
      ->scsi_host too, so we can't use it for the destinguish, we add a new flag for
      this purpose.
      
      Without this patch, the following oops can happen because scsi-mq uses
      a host-wide tag map shared among all devices with some integer tag
      values >= ATA_MAX_QUEUE.  These unexpectedly high tag values cause
      __ata_qc_from_tag() to return NULL, which is then dereferenced in
      ata_qc_new_init().
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
        IP: [<ffffffff804fd46e>] ata_qc_new_init+0x3e/0x120
        PGD 32adf0067 PUD 32adf1067 PMD 0
        Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
        Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi igb
        i2c_algo_bit ptp pps_core pm80xx libsas scsi_transport_sas sg coretemp
        eeprom w83795 i2c_i801
        CPU: 4 PID: 1450 Comm: cydiskbench Not tainted 4.0.0-rc3 #1
        Hardware name: Supermicro X8DTH-i/6/iF/6F/X8DTH, BIOS 2.1b       05/04/12
        task: ffff8800ba86d500 ti: ffff88032a064000 task.ti: ffff88032a064000
        RIP: 0010:[<ffffffff804fd46e>]  [<ffffffff804fd46e>] ata_qc_new_init+0x3e/0x120
        RSP: 0018:ffff88032a067858  EFLAGS: 00010046
        RAX: 0000000000000000 RBX: ffff8800ba0d2230 RCX: 000000000000002a
        RDX: ffffffff80505ae0 RSI: 0000000000000020 RDI: ffff8800ba0d2230
        RBP: ffff88032a067868 R08: 0000000000000201 R09: 0000000000000001
        R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800ba0d0000
        R13: ffff8800ba0d2230 R14: ffffffff80505ae0 R15: ffff8800ba0d0000
        FS:  0000000041223950(0063) GS:ffff88033e480000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 0000000000000058 CR3: 000000032a0a3000 CR4: 00000000000006e0
        Stack:
         ffff880329eee758 ffff880329eee758 ffff88032a0678a8 ffffffff80502dad
         ffff8800ba167978 ffff880329eee758 ffff88032bf9c520 ffff8800ba167978
         ffff88032bf9c520 ffff88032bf9a290 ffff88032a0678b8 ffffffff80506909
        Call Trace:
         [<ffffffff80502dad>] ata_scsi_translate+0x3d/0x1b0
         [<ffffffff80506909>] ata_sas_queuecmd+0x149/0x2a0
         [<ffffffffa0046650>] sas_queuecommand+0xa0/0x1f0 [libsas]
         [<ffffffff804ea544>] scsi_dispatch_cmd+0xd4/0x1a0
         [<ffffffff804eb50f>] scsi_queue_rq+0x66f/0x7f0
         [<ffffffff803e5098>] __blk_mq_run_hw_queue+0x208/0x3f0
         [<ffffffff803e54b8>] blk_mq_run_hw_queue+0x88/0xc0
         [<ffffffff803e5c74>] blk_mq_insert_request+0xc4/0x130
         [<ffffffff803e0b63>] blk_execute_rq_nowait+0x73/0x160
         [<ffffffffa0023fca>] sg_common_write+0x3da/0x720 [sg]
         [<ffffffffa0025100>] sg_new_write+0x250/0x360 [sg]
         [<ffffffffa0025feb>] sg_write+0x13b/0x450 [sg]
         [<ffffffff8032ec91>] vfs_write+0xd1/0x1b0
         [<ffffffff8032ee54>] SyS_write+0x54/0xc0
         [<ffffffff80689932>] system_call_fastpath+0x12/0x17
      
      tj: updated description.
      
      Fixes: 12cb5ce1 ("libata: use blk taging")
      Reported-and-tested-by: NTony Battersby <tonyb@cybernetics.com>
      Signed-off-by: NShaohua Li <shli@fb.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      5067c046
  25. 29 1月, 2015 1 次提交
    • A
      ata: ahci_platform: fix owner module reference mismatch for scsi host · 018d5ef2
      Akinobu Mita 提交于
      The owner module reference of the ahci platform's scsi_host is
      initialized to libahci_platform's one, because these drivers use a
      scsi_host_template defined in libahci_platform.  So these drivers can
      be unloaded even if the scsi device is being accessed.
      
      This fixes it by pushing the scsi_host_template from libahci_platform
      to all leaf drivers.  The scsi_host_template is passed through a new
      argument of ahci_platform_init_host().
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: linux-ide@vger.kernel.org
      Cc: linux-scsi@vger.kernel.org
      018d5ef2
  26. 24 1月, 2015 1 次提交
    • S
      libata: use blk taging · 12cb5ce1
      Shaohua Li 提交于
      libata uses its own tag management which is duplication and the
      implementation is poor. And if we switch to blk-mq, tag is build-in.
      It's time to switch to generic taging.
      
      The SAS driver has its own tag management, and looks we can't directly
      map the host controler tag to SATA tag. So I just bypassed the SAS case.
      
      I changed the code/variable name for the tag management of libata to
      make it self contained. Only sas will use it. Later if libsas implements
      its tag management, the tag management code in libata can be deleted
      easily.
      
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: NShaohua Li <shli@fb.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      12cb5ce1
  27. 19 1月, 2015 1 次提交
  28. 08 1月, 2015 1 次提交
    • M
      libata: Whitelist SSDs that are known to properly return zeroes after TRIM · e61f7d1c
      Martin K. Petersen 提交于
      As defined, the DRAT (Deterministic Read After Trim) and RZAT (Return
      Zero After Trim) flags in the ATA Command Set are unreliable in the
      sense that they only define what happens if the device successfully
      executed the DSM TRIM command. TRIM is only advisory, however, and the
      device is free to silently ignore all or parts of the request.
      
      In practice this renders the DRAT and RZAT flags completely useless and
      because the results are unpredictable we decided to disable discard in
      MD for 3.18 to avoid the risk of data corruption.
      
      Hardware vendors in the real world obviously need better guarantees than
      what the standards bodies provide. Unfortuntely those guarantees are
      encoded in product requirements documents rather than somewhere we can
      key off of them programatically. So we are compelled to disabling
      discard_zeroes_data for all devices unless we explicitly have data to
      support whitelisting them.
      
      This patch whitelists SSDs from a few of the main vendors. None of the
      whitelists are based on written guarantees. They are purely based on
      empirical evidence collected from internal and external users that have
      tested or qualified these drives in RAID deployments.
      
      The whitelist is only meant as a starting point and is by no means
      comprehensive:
      
         - All intel SSD models except for 510
         - Micron M5?0/M600
         - Samsung SSDs
         - Seagate SSDs
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      e61f7d1c
  29. 24 11月, 2014 1 次提交