1. 27 3月, 2015 2 次提交
  2. 25 1月, 2015 1 次提交
  3. 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
  4. 19 1月, 2015 1 次提交
  5. 12 1月, 2015 1 次提交
  6. 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
  7. 06 11月, 2014 1 次提交
  8. 08 10月, 2014 1 次提交
  9. 23 9月, 2014 1 次提交
  10. 19 8月, 2014 2 次提交
  11. 07 8月, 2014 1 次提交
  12. 23 7月, 2014 1 次提交
    • T
      libata: introduce ata_host->n_tags to avoid oops on SAS controllers · 1a112d10
      Tejun Heo 提交于
      1871ee13 ("libata: support the ata host which implements a queue
      depth less than 32") directly used ata_port->scsi_host->can_queue from
      ata_qc_new() to determine the number of tags supported by the host;
      unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
      leading to the following oops.
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
       IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
       PGD 0
       Oops: 0002 [#1] SMP
       Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
       CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
       Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
       task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
       RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
       RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
       RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
       RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
       RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
       R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
       R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
       FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
       Stack:
        ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
        ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
        ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
       Call Trace:
        [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
        [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
        [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300
        [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
        [<ffffffff81317613>] __blk_run_queue+0x33/0x40
        [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
        [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
        [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
        [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
        [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
        [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
        [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
        [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
        [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
        [<ffffffff811e3734>] vfs_read+0x94/0x170
        [<ffffffff811e43c6>] SyS_read+0x46/0xb0
        [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
        [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
       Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00
      
      Fix it by introducing ata_host->n_tags which is initialized to
      ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
      scsi_host_template->can_queue in ata_host_register() for !SAS ones.
      As SAS hosts are never registered, this will give them the same
      ATA_MAX_QUEUE - 1 as before.  Note that we can't use
      scsi_host->can_queue directly for SAS hosts anyway as they can go
      higher than the libata maximum.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NMike Qiu <qiudayu@linux.vnet.ibm.com>
      Reported-by: NJesse Brandeburg <jesse.brandeburg@gmail.com>
      Reported-by: NPeter Hurley <peter@hurleysoftware.com>
      Reported-by: NPeter Zijlstra <peterz@infradead.org>
      Tested-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Fixes: 1871ee13 ("libata: support the ata host which implements a queue depth less than 32")
      Cc: Kevin Hao <haokexin@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: stable@vger.kernel.org
      1a112d10
  13. 15 7月, 2014 1 次提交
  14. 03 6月, 2014 1 次提交
  15. 07 5月, 2014 1 次提交
  16. 19 4月, 2014 1 次提交
    • D
      libata/ahci: accommodate tag ordered controllers · 8a4aeec8
      Dan Williams 提交于
      The AHCI spec allows implementations to issue commands in tag order
      rather than FIFO order:
      
      	5.3.2.12 P:SelectCmd
      	HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
      	or HBA selects the command to issue that has had the
      	PxCI bit set to '1' longer than any other command
      	pending to be issued.
      
      The result is that commands posted sequentially (time-wise) may play out
      of sequence when issued by hardware.
      
      This behavior has likely been hidden by drives that arrange for commands
      to complete in issue order.  However, it appears recent drives (two from
      different vendors that we have found so far) inflict out-of-order
      completions as a matter of course.  So, we need to take care to maintain
      ordered submission, otherwise we risk triggering a drive to fall out of
      sequential-io automation and back to random-io processing, which incurs
      large latency and degrades throughput.
      
      This issue was found in simple benchmarks where QD=2 seq-write
      performance was 30-50% *greater* than QD=32 seq-write performance.
      
      Tagging for -stable and making the change globally since it has a low
      risk-to-reward ratio.  Also, word is that recent versions of an unnamed
      OS also does it this way now.  So, drives in the field are already
      experienced with this tag ordering scheme.
      
      Cc: <stable@vger.kernel.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Ed Ciechanowski <ed.ciechanowski@intel.com>
      Reviewed-by: NMatthew Wilcox <matthew.r.wilcox@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      8a4aeec8
  17. 03 4月, 2014 1 次提交
  18. 19 3月, 2014 2 次提交
    • T
      libata: async resume · 200421a8
      Todd Brandt 提交于
      Improve overall system resume time by making libata link recovery
      actions asynchronous relative to other resume events.
      
      Link resume operations are performed using the scsi_eh thread, so
      commands, particularly the sd resume start/stop command, will be held
      off until the device exits error handling.  Libata already flushes eh
      with ata_port_wait_eh() in the port teardown paths, so there are no
      concerns with async operation colliding with the end-of-life of the
      ata_port object.  Also, libata-core is already careful to flush
      in-flight pm operations before another round of pm starts on the given
      ata_port.
      
      Reference: https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Phillip Susi <psusi@ubuntu.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NTodd Brandt <todd.e.brandt@linux.intel.com>
      [djbw: rebase on cleanup patch, changelog wordsmithing]
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      200421a8
    • D
      libata, libsas: kill pm_result and related cleanup · bc6e7c4b
      Dan Williams 提交于
      Tejun says:
        "At least for libata, worrying about suspend/resume failures don't make
         whole lot of sense.  If suspend failed, just proceed with suspend.  If
         the device can't be woken up afterwards, that's that.  There isn't
         anything we could have done differently anyway.  The same for resume, if
         spinup fails, the device is dud and the following commands will invoke
         EH actions and will eventually fail.  Again, there really isn't any
         *choice* to make.  Just making sure the errors are handled gracefully
         (ie. don't crash) and the following commands are handled correctly
         should be enough."
      
      The only libata user that actually cares about the result from a suspend
      operation is libsas.  However, it only cares about whether queuing a new
      operation collides with an in-flight one.  All libsas does with the
      error is retry, but we can just let libata wait for the previous
      operation before continuing.
      
      Other cleanups include:
      1/ Unifying all ata port pm operations on an ata_port_pm_ prefix
      2/ Marking all ata port pm helper routines as returning void, only
         ata_port_pm_ entry points need to fake a 0 return value.
      3/ Killing ata_port_{suspend|resume}_common() in favor of calling
         ata_port_request_pm() directly
      4/ Killing the wrappers that just do a to_ata_port() conversion
      5/ Clearly marking the entry points that do async operations with an
        _async suffix.
      
      Reference: http://marc.info/?l=linux-scsi&m=138995409532286&w=2
      
      Cc: Phillip Susi <psusi@ubuntu.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Suggested-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NTodd Brandt <todd.e.brandt@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      bc6e7c4b
  19. 10 3月, 2014 1 次提交
  20. 08 3月, 2014 1 次提交
  21. 04 3月, 2014 1 次提交
  22. 19 2月, 2014 1 次提交
  23. 16 1月, 2014 1 次提交
    • T
      libata: disable LPM for some WD SATA-I devices · ecd75ad5
      Tejun Heo 提交于
      For some reason, some early WD drives spin up and down drives
      erratically when the link is put into slumber mode which can reduce
      the life expectancy of the device significantly.  Unfortunately, we
      don't have full list of devices and given the nature of the issue it'd
      be better to err on the side of false positives than the other way
      around.  Let's disable LPM on all WD devices which match one of the
      known problematic model prefixes and are SATA-I.
      
      As horkage list doesn't support matching SATA capabilities, this is
      implemented as two horkages - WD_BROKEN_LPM and NOLPM.  The former is
      set for the known prefixes and sets the latter if the matched device
      is SATA-I.
      
      Note that this isn't optimal as this disables all LPM operations and
      partial link power state reportedly works fine on these; however, the
      way LPM is implemented in libata makes it difficult to precisely map
      libata LPM setting to specific link power state.  Well, these devices
      are already fairly outdated.  Let's just disable whole LPM for now.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-and-tested-by: NNikos Barkas <levelwol@gmail.com>
      Reported-and-tested-by: NIoannis Barkas <risc4all@yahoo.com>
      References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
      Cc: stable@vger.kernel.org
      ecd75ad5
  24. 17 12月, 2013 2 次提交
  25. 30 11月, 2013 1 次提交
  26. 28 11月, 2013 1 次提交
    • R
      ATA: Fix port removal ordering · c5700766
      Rafael J. Wysocki 提交于
      After commit bcdde7e2 (sysfs: make __sysfs_remove_dir() recursive)
      Mika Westerberg sees traces analogous to the one below in Thunderbolt
      hot-remove testing:
      
       WARNING: CPU: 0 PID: 4 at fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()
       sysfs group ffffffff81c6f1e0 not found for kobject 'host7'
       Modules linked in:
       CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.12.0+ #13
       Hardware name:                  /D33217CK, BIOS GKPPT10H.86A.0042.2013.0422.1439 04/22/2013
       Workqueue: kacpi_hotplug acpi_hotplug_work_fn
        0000000000000009 ffff8801002459b0 ffffffff817daab1 ffff8801002459f8
        ffff8801002459e8 ffffffff810436b8 0000000000000000 ffffffff81c6f1e0
        ffff88006d440358 ffff88006d440188 ffff88006e8b4c28 ffff880100245a48
       Call Trace:
        [<ffffffff817daab1>] dump_stack+0x45/0x56
        [<ffffffff810436b8>] warn_slowpath_common+0x78/0xa0
        [<ffffffff81043727>] warn_slowpath_fmt+0x47/0x50
        [<ffffffff811ad319>] ? sysfs_get_dirent_ns+0x49/0x70
        [<ffffffff811ae526>] sysfs_remove_group+0xc6/0xd0
        [<ffffffff81432f7e>] dpm_sysfs_remove+0x3e/0x50
        [<ffffffff8142a0d0>] device_del+0x40/0x1b0
        [<ffffffff8142a24d>] device_unregister+0xd/0x20
        [<ffffffff8144131a>] scsi_remove_host+0xba/0x110
        [<ffffffff8145f526>] ata_host_detach+0xc6/0x100
        [<ffffffff8145f578>] ata_pci_remove_one+0x18/0x20
        [<ffffffff812e8f48>] pci_device_remove+0x28/0x60
        [<ffffffff8142d854>] __device_release_driver+0x64/0xd0
        [<ffffffff8142d8de>] device_release_driver+0x1e/0x30
        [<ffffffff8142d257>] bus_remove_device+0xf7/0x140
        [<ffffffff8142a1b1>] device_del+0x121/0x1b0
        [<ffffffff812e43d4>] pci_stop_bus_device+0x94/0xa0
        [<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
        [<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
        [<ffffffff812e44dd>] pci_stop_and_remove_bus_device+0xd/0x20
        [<ffffffff812fc743>] trim_stale_devices+0x73/0xe0
        [<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
        [<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
        [<ffffffff812fcb6e>] acpiphp_check_bridge+0x7e/0xd0
        [<ffffffff812fd90d>] hotplug_event+0xcd/0x160
        [<ffffffff812fd9c5>] hotplug_event_work+0x25/0x60
        [<ffffffff81316749>] acpi_hotplug_work_fn+0x17/0x22
        [<ffffffff8105cf3a>] process_one_work+0x17a/0x430
        [<ffffffff8105db29>] worker_thread+0x119/0x390
        [<ffffffff8105da10>] ? manage_workers.isra.25+0x2a0/0x2a0
        [<ffffffff81063a5d>] kthread+0xcd/0xf0
        [<ffffffff81063990>] ? kthread_create_on_node+0x180/0x180
        [<ffffffff817eb33c>] ret_from_fork+0x7c/0xb0
        [<ffffffff81063990>] ? kthread_create_on_node+0x180/0x180
      
      The source of this problem is that SCSI hosts are removed from
      ATA ports after calling ata_tport_delete() which removes the
      port's sysfs directory, among other things.  Now, after commit
      bcdde7e2, the sysfs directory is removed along with all of
      its subdirectories that include the SCSI host's sysfs directory
      and its subdirectories at this point.  Consequently, when
      device_del() is finally called for any child device of the SCSI
      host and tries to remove its "power" group (which is already
      gone then), it triggers the above warning.
      
      To make the warnings go away, change the removal ordering in
      ata_port_detach() so that the SCSI host is removed from the
      port before ata_tport_delete() is called.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=65281Reported-and-tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      c5700766
  27. 28 10月, 2013 1 次提交
    • S
      drivers/libata: Set max sector to 65535 for Slimtype DVD A DS8A9SH drive · 0523f037
      Shan Hai 提交于
      The "Slimtype DVD A  DS8A9SH" drive locks up with following backtrace when
      the max sector is smaller than 65535 bytes, fix it by adding a quirk to set
      the max sector to 65535 bytes.
      
      INFO: task flush-11:0:663 blocked for more than 120 seconds.
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      flush-11:0    D 00000000ffff5ceb     0   663      2 0x00000000
       ffff88026d3b1710 0000000000000046 0000000000000001 0000000000000000
       ffff88026f2530c0 ffff88026d365860 ffff88026d3b16e0 ffffffff812ffd52
       ffff88026d4fd3d0 0000000100000001 ffff88026d3b16f0 ffff88026d3b1fd8
      Call Trace:
       [<ffffffff812ffd52>] ? cfq_may_queue+0x52/0xf0
       [<ffffffff81604338>] schedule+0x18/0x30
       [<ffffffff81604392>] io_schedule+0x42/0x60
       [<ffffffff812f22bb>] get_request_wait+0xeb/0x1f0
       [<ffffffff81065660>] ? autoremove_wake_function+0x0/0x40
       [<ffffffff812eb382>] ? elv_merge+0x42/0x210
       [<ffffffff812f26ae>] __make_request+0x8e/0x4e0
       [<ffffffff812f068e>] generic_make_request+0x21e/0x5e0
       [<ffffffff812f0aad>] submit_bio+0x5d/0xd0
       [<ffffffff81141422>] submit_bh+0xf2/0x130
       [<ffffffff8114474c>] __block_write_full_page+0x1dc/0x3a0
       [<ffffffff81143f60>] ? end_buffer_async_write+0x0/0x120
       [<ffffffff811474e0>] ? blkdev_get_block+0x0/0x70
       [<ffffffff811474e0>] ? blkdev_get_block+0x0/0x70
       [<ffffffff81143f60>] ? end_buffer_async_write+0x0/0x120
       [<ffffffff811449ee>] block_write_full_page_endio+0xde/0x100
       [<ffffffff81144a20>] block_write_full_page+0x10/0x20
       [<ffffffff81148703>] blkdev_writepage+0x13/0x20
       [<ffffffff810d7525>] __writepage+0x15/0x40
       [<ffffffff810d7c0f>] write_cache_pages+0x1cf/0x3e0
       [<ffffffff810d7510>] ? __writepage+0x0/0x40
       [<ffffffff810d7e42>] generic_writepages+0x22/0x30
       [<ffffffff810d7e6f>] do_writepages+0x1f/0x40
       [<ffffffff8113ae67>] writeback_single_inode+0xe7/0x3b0
       [<ffffffff8113b574>] writeback_sb_inodes+0x184/0x280
       [<ffffffff8113bedb>] writeback_inodes_wb+0x6b/0x1a0
       [<ffffffff8113c24b>] wb_writeback+0x23b/0x2a0
       [<ffffffff8113c42d>] wb_do_writeback+0x17d/0x190
       [<ffffffff8113c48b>] bdi_writeback_task+0x4b/0xe0
       [<ffffffff810e82a0>] ? bdi_start_fn+0x0/0x100
       [<ffffffff810e8321>] bdi_start_fn+0x81/0x100
       [<ffffffff810e82a0>] ? bdi_start_fn+0x0/0x100
       [<ffffffff8106522e>] kthread+0x8e/0xa0
       [<ffffffff81039274>] ? finish_task_switch+0x54/0xc0
       [<ffffffff81003334>] kernel_thread_helper+0x4/0x10
       [<ffffffff810651a0>] ? kthread+0x0/0xa0
       [<ffffffff81003330>] ? kernel_thread_helper+0x0/0x10
      
       The above trace was triggered by
         "dd if=/dev/zero of=/dev/sr0 bs=2048 count=32768"
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NShan Hai <shan.hai@windriver.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      0523f037
  28. 03 9月, 2013 1 次提交
  29. 25 8月, 2013 2 次提交
  30. 24 8月, 2013 1 次提交
    • A
      ata: acpi: rework the ata acpi bind support · f1bc1e4c
      Aaron Lu 提交于
      Binding ACPI handle to SCSI device has several drawbacks, namely:
      1 During ATA device initialization time, ACPI handle will be needed
        while SCSI devices are not created yet. So each time ACPI handle is
        needed, instead of retrieving the handle by ACPI_HANDLE macro,
        a namespace scan is performed to find the handle for the corresponding
        ATA device. This is inefficient, and also expose a restriction on
        calling path not holding any lock.
      2 The binding to SCSI device tree makes code complex, while at the same
        time doesn't bring us any benefit. All ACPI handlings are still done
        in ATA module, not in SCSI.
      
      Rework the ATA ACPI binding code to bind ACPI handle to ATA transport
      devices(ATA port and ATA device). The binding needs to be done only once,
      since the ATA transport devices do not go away with hotplug. And due to
      this, the flush_work call in hotplug handler for ATA bay is no longer
      needed.
      
      Tested on an Intel test platform for binding and runtime power off for
      ODD(ZPODD) and hard disk; on an ASUS S400C for binding and normal boot
      and S3, where its SATA port node has _SDD and _GTF control methods when
      configured as an AHCI controller and its PATA device node has _GTF
      control method when configured as an IDE controller. SATA PMP binding
      and ATA hotplug is not tested.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Tested-by: NDirk Griesbach <spamthis@freenet.de>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      f1bc1e4c
  31. 25 6月, 2013 1 次提交
    • A
      libata-acpi: add back ACPI based hotplug functionality · 44521527
      Aaron Lu 提交于
      Commit 30dcf76a "libata: migrate ACPI code over to new bindings"
      mistakenly dropped the code to register hotplug notificaion handler
      for ATA port/devices, causing regression for people using ATA bay,
      as kernel bug #59871 shows.
      
      Fix this by adding back the hotplug notification handler registration
      code.  Since this code has to be run once and notification needs to
      be installed on every ATA port/devices handle no matter if there is
      actual device attached, we can't do this in binding time for ATA
      device ACPI handle, as the binding only occurs when a SCSI device is
      created, i.e. there is device attached.  So introduce the
      ata_acpi_hotplug_init() function to loop scan all ATA ACPI handles
      and if it is available, install the notificaion handler for it during
      ATA init time.
      
      With the ATA ACPI handle binding to SCSI device tree, it is possible
      now that when the SCSI hotplug work removes the SCSI device, the ACPI
      unbind function will find that the corresponding ACPI device has
      already been deleted by dock driver, causing a scaring message like:
      [  128.263966] scsi 4:0:0:0: Oops, 'acpi_handle' corrupt
      Fix this by waiting for SCSI hotplug task finish in our notificaion
      handler, so that the removal of ACPI device done in ACPI unbind
      function triggered by the removal of SCSI device is run earlier when
      ACPI device is still available.
      
      [rjw: Rebased]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=59871Reported-bisected-and-tested-by: NDirk Griesbach <spamthis@freenet.de>
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: 3.6+ <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      44521527
  32. 04 6月, 2013 1 次提交
  33. 22 5月, 2013 2 次提交
    • V
      libata: Add atapi_dmadir force flag · 966fbe19
      Vincent Pelletier 提交于
      Some device require DMADIR to be enabled, but are not detected as such
      by atapi_id_dmadir.  One such example is "Asus Serillel 2"
      SATA-host-to-PATA-device bridge: the bridge itself requires DMADIR,
      even if the bridged device does not.
      
      As atapi_dmadir module parameter can cause problems with some devices
      (as per Tejun Heo's memory), enabling it globally may not be possible
      depending on the hardware.
      
      This patch adds atapi_dmadir in the form of a "force" horkage value,
      allowing global, per-bus and per-device control.
      Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      966fbe19
    • V
      libata: make ata_exec_internal_sg honor DMADIR · e771451c
      Vincent Pelletier 提交于
      libata honors DMADIR for regular commands, but not for internal commands
      used (among other) during device initialisation.
      
      This makes SATA-host-to-PATA-device bridges based on Silicon Image SiL3611
      (such as "Abit Serillel 2") end up disabled when used with an ATAPI device
      after a few tries.
      
      Log output of the bridge being hot-plugged with an ATAPI drive:
      
        [ 9631.212901] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
        [ 9631.212913] ata1: irq_stat 0x00000040, connection status changed
        [ 9631.212923] ata1: SError: { CommWake 10B8B DevExch }
        [ 9631.212939] ata1: hard resetting link
        [ 9632.104962] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        [ 9632.106393] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33
        [ 9632.106407] ata1.00: applying bridge limits
        [ 9632.108151] ata1.00: configured for UDMA/33
        [ 9637.105303] ata1.00: qc timeout (cmd 0xa0)
        [ 9637.105324] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
        [ 9637.105335] ata1: hard resetting link
        [ 9638.044599] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        [ 9638.047878] ata1.00: configured for UDMA/33
        [ 9643.044933] ata1.00: qc timeout (cmd 0xa0)
        [ 9643.044953] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
        [ 9643.044963] ata1: limiting SATA link speed to 1.5 Gbps
        [ 9643.044971] ata1.00: limiting speed to UDMA/33:PIO3
        [ 9643.044979] ata1: hard resetting link
        [ 9643.984225] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
        [ 9643.987471] ata1.00: configured for UDMA/33
        [ 9648.984591] ata1.00: qc timeout (cmd 0xa0)
        [ 9648.984612] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
        [ 9648.984619] ata1.00: disabled
        [ 9649.000593] ata1: hard resetting link
        [ 9649.939902] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
        [ 9649.955864] ata1: EH complete
      
      With this patch, the drive enumerates correctly when libata is loaded with
      atapi_dmadir=1:
      
        [ 9891.810863] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
        [ 9891.810874] ata1: irq_stat 0x00000040, connection status changed
        [ 9891.810884] ata1: SError: { CommWake 10B8B DevExch }
        [ 9891.810900] ata1: hard resetting link
        [ 9892.762105] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        [ 9892.763544] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33, DMADIR
        [ 9892.763558] ata1.00: applying bridge limits
        [ 9892.765393] ata1.00: configured for UDMA/33
        [ 9892.786063] ata1: EH complete
        [ 9892.792062] scsi 0:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-115  1.06 PQ: 0 ANSI: 5
        [ 9892.798455] sr2: scsi3-mmc drive: 12x/12x writer dvd-ram cd/rw xa/form2 cdda tray
        [ 9892.798837] sr 0:0:0:0: Attached scsi CD-ROM sr2
        [ 9892.799109] sr 0:0:0:0: Attached scsi generic sg6 type 5
      
      Based on a patch by Csaba Halász <csaba.halasz@gmail.com> on linux-ide:
      http://marc.info/?l=linux-ide&m=136121147832295&w=2
      
      tj: minor formatting changes.
      Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
      e771451c
  34. 15 5月, 2013 1 次提交
    • D
      libata: export ata_port port_no attribute via /sys · e628dc99
      David Milburn 提交于
      While registering host controller track port number based upon number
      of ports available on the controller, export port_no attribute through
      /sys. This patch is needed by udev for composing persistent links in
      /dev/disk/by-path.
      
      /sys/devices/pci0000:00/0000:00:1f.2/ata8/ata_port/ata8
      total 0
      lrwxrwxrwx. 1 root root    0 Mar  6 12:43 device -> ../../../ata8
      -r--r--r--. 1 root root 4096 Mar  6 12:43 idle_irq
      -r--r--r--. 1 root root 4096 Mar  6 12:43 nr_pmp_links
      -r--r--r--. 1 root root 4096 Mar  6 12:43 port_no
      drwxr-xr-x. 2 root root    0 Mar  6 12:42 power
      lrwxrwxrwx. 1 root root    0 Mar  6 12:41 subsystem -> ../../../../../../class/ata_port
      -rw-r--r--. 1 root root 4096 Mar  6 12:40 uevent
      1
      Signed-off-by: NDavid Milburn <dmilburn@redhat.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      e628dc99