1. 07 Jun, 2014 1 commit
  2. 13 May, 2014 1 commit
    • Dan Williams's avatar
      libata/ahci: accommodate tag ordered controllers · cfd192c9
      Dan Williams authored
      commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream.
      The AHCI spec allows implementations to issue commands in tag order
      rather than FIFO order:
      	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: Dave Jiang <dave.jiang@intel.com>
      Cc: Ed Ciechanowski <ed.ciechanowski@intel.com>
      Reviewed-by: 's avatarMatthew Wilcox <matthew.r.wilcox@intel.com>
      Signed-off-by: 's avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 24 Mar, 2014 1 commit
  4. 07 Mar, 2014 3 commits
  5. 06 Feb, 2014 3 commits
    • Tejun Heo's avatar
      libata: disable LPM for some WD SATA-I devices · f07b772d
      Tejun Heo authored
      commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream.
      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: 's avatarTejun Heo <tj@kernel.org>
      Reported-and-tested-by: 's avatarNikos Barkas <levelwol@gmail.com>
      Reported-and-tested-by: 's avatarIoannis Barkas <risc4all@yahoo.com>
      References: https://bugzilla.kernel.org/show_bug.cgi?id=57211Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lior Amsalem's avatar
      ata: sata_mv: fix disk hotplug for Armada 370/XP SoCs · 6314611a
      Lior Amsalem authored
      commit 9013d64e661fc2a37a1742670202171c27fef4b5 upstream.
      On Armada 370/XP SoCs, once a disk is removed from a SATA port, then the
      re-plug events are not detected by the sata_mv driver. This patch fixes
      the issue by updating the PHY speed in the LP_PHY_CTL register (0x58)
      according to the SControl speed.
      Note that this fix is only applied if the compatible string
      "marvell,armada-370-sata" is found in the SATA DT node.
      Fixes: 9ae6f740 ("arm: mach-mvebu: add support for Armada 370 and Armada XP with DT")
      Signed-off-by: 's avatarLior Amsalem <alior@marvell.com>
      Signed-off-by: 's avatarNadav Haklai <nadavh@marvell.com>
      Signed-off-by: 's avatarSimon Guinot <simon.guinot@sequanux.org>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Acked-by: 's avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Simon Guinot's avatar
      ata: sata_mv: introduce compatible string "marvell, armada-370-sata" · 509e5695
      Simon Guinot authored
      commit b1f5c73bd5a4752efb7d7af019034044b08aafe9 upstream.
      The sata_mv driver supports the SATA IP found in several Marvell SoCs.
      As some new SATA registers have been introduced with the Armada 370/XP
      SoCs, a way to identify them is needed.
      This patch introduces a new compatible string for the SATA IP found in
      Armada 370/XP SoCs.
      Signed-off-by: 's avatarSimon Guinot <simon.guinot@sequanux.org>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Lior Amsalem <alior@marvell.com>
      Acked-by: 's avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 15 Jan, 2014 1 commit
  7. 09 Jan, 2014 4 commits
  8. 12 Dec, 2013 1 commit
  9. 04 Dec, 2013 5 commits
    • Samir Benmendil's avatar
      ahci: add Marvell 9230 to the AHCI PCI device list · 61688ba3
      Samir Benmendil authored
      commit 6d5278a68a75891db1df5ae1ecf83d288fc58c65 upstream.
      Tested with a DAWICONTROL DC-624e on 3.10.10
      Signed-off-by: 's avatarSamir Benmendil <samir.benmendil@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Reviewed-by: 's avatarLevente Kurusa <levex@linux.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • xiangliang yu's avatar
      ahci: disabled FBS prior to issuing software reset · 420df0f5
      xiangliang yu authored
      commit 89dafa20f3daab5b3e0c13d0068a28e8e64e2102 upstream.
      Tested with Marvell 88se9125, attached with one port mulitplier(5 ports)
      and one disk, we will get following boot log messages if using current
        ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
        ata8.15: Port Multiplier 1.2, 0x1b4b:0x9715 r160, 5 ports, feat 0x1/0x1f
        ahci 0000:03:00.0: FBS is enabled
        ata8.00: hard resetting link
        ata8.00: SATA link down (SStatus 0 SControl 330)
        ata8.01: hard resetting link
        ata8.01: SATA link down (SStatus 0 SControl 330)
        ata8.02: hard resetting link
        ata8.02: SATA link down (SStatus 0 SControl 330)
        ata8.03: hard resetting link
        ata8.03: SATA link up 6.0 Gbps (SStatus 133 SControl 133)
        ata8.04: hard resetting link
        ata8.04: failed to resume link (SControl 133)
        ata8.04: failed to read SCR 0 (Emask=0x40)
        ata8.04: failed to read SCR 0 (Emask=0x40)
        ata8.04: failed to read SCR 1 (Emask=0x40)
        ata8.04: failed to read SCR 0 (Emask=0x40)
        ata8.03: native sectors (2) is smaller than sectors (976773168)
        ata8.03: ATA-8: ST3500413AS, JC4B, max UDMA/133
        ata8.03: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
        ata8.03: configured for UDMA/133
        ata8.04: failed to IDENTIFY (I/O error, err_mask=0x100)
        ata8.15: hard resetting link
        ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
        ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
        ata8.15: PMP revalidation failed (errno=-19)
        ata8.15: hard resetting link
        ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
        ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
        ata8.15: PMP revalidation failed (errno=-19)
        ata8.15: limiting SATA link speed to 3.0 Gbps
        ata8.15: hard resetting link
        ata8.15: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
        ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
        ata8.15: PMP revalidation failed (errno=-19)
        ata8.15: failed to recover PMP after 5 tries, giving up
        ata8.15: Port Multiplier detaching
        ata8.03: disabled
        ata8.00: disabled
        ata8: EH complete
      The reason is that current detection code doesn't follow AHCI spec:
      First,the port multiplier detection process look like this:
      	ahci_hardreset(link, class, deadline)
      	if (class == ATA_DEV_PMP) {
      		sata_pmp_attach(dev)	/* will enable FBS */
      		sata_pmp_init_links(ap, nr_ports);
      		ata_for_each_link(link, ap, EDGE) {
      			sata_std_hardreset(link, class, deadline);
      			if (link_is_online)	/* do soft reset */
      				ahci_softreset(link, class, deadline);
      But, according to chapter 9.3.9 in AHCI spec: Prior to issuing software
      reset, software shall clear PxCMD.ST to '0' and then clear PxFBS.EN to
      The patch test ok with kernel 3.11.1.
      tj: Patch white space contaminated, applied manually with trivial
      Signed-off-by: 's avatarXiangliang Yu <yuxiangl@marvell.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • James Ralston's avatar
      ahci: Add Device IDs for Intel Wildcat Point-LP · 296cfdec
      James Ralston authored
      commit 9f961a5f6efc87a79571d7166257b36af28ffcfe upstream.
      This patch adds the AHCI-mode SATA Device IDs for the Intel Wildcat Point-LP PCH.
      Signed-off-by: 's avatarJames Ralston <james.d.ralston@intel.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Shan Hai's avatar
      drivers/libata: Set max sector to 65535 for Slimtype DVD A DS8A9SH drive · 922b22ff
      Shan Hai authored
      commit 0523f037f65dba10191b0fa9c51266f90ba64630 upstream.
      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"
      Signed-off-by: 's avatarShan Hai <shan.hai@windriver.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Gwendal Grignou's avatar
      libata: Fix display of sata speed · 929742b8
      Gwendal Grignou authored
      commit 3e85c3ecbc520751324a191d23bb94873ed01b10 upstream.
      6.0 Gbps link speed was not decoded properly:
      speed was reported at 3.0 Gbps only.
      Tested: On a machine where libata reports 6.0 Gbps in
          ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
          	cat /sys/class/ata_link/link1/sata_spd
          	3.0 Gbps
          	cat /sys/class/ata_link/link1/sata_spd
          	6.0 Gbps
      Signed-off-by: 's avatarGwendal Grignou <gwendal@google.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. 13 Nov, 2013 1 commit
  11. 29 Aug, 2013 2 commits
    • Terry Suereth's avatar
      libata: apply behavioral quirks to sil3826 PMP · 323d5a7b
      Terry Suereth authored
      commit 8ffff94d20b7eb446e848e0046107d51b17a20a8 upstream.
      Fixing support for the Silicon Image 3826 port multiplier, by applying
      to it the same quirks applied to the Silicon Image 3726.  Specifically
      fixes the repeated timeout/reset process which previously afflicted
      the 3726, as described from line 290.  Slightly based on notes from:
      https://bugzilla.redhat.com/show_bug.cgi?id=890237Signed-off-by: 's avatarTerry Suereth <terry.suereth@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Anthony Foiani's avatar
      sata_fsl: save irqs while coalescing · 2650a684
      Anthony Foiani authored
      commit 99bbdfa6bdcb4bdf5be914a48e9b46941bf30819 upstream.
      Before this patch, I was seeing the following lockdep splat on my
      MPC8315 (PPC32) target:
        [    9.086051] =================================
        [    9.090393] [ INFO: inconsistent lock state ]
        [    9.094744] 3.9.7-ajf-gc39503d #1 Not tainted
        [    9.099087] ---------------------------------
        [    9.103432] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
        [    9.109431] scsi_eh_1/39 [HC1[1]:SC0[0]:HE0:SE1] takes:
        [    9.114642]  (&(&host->lock)->rlock){?.+...}, at: [<c02f4168>] sata_fsl_interrupt+0x50/0x250
        [    9.123137] {HARDIRQ-ON-W} state was registered at:
        [    9.128004]   [<c006cdb8>] lock_acquire+0x90/0xf4
        [    9.132737]   [<c043ef04>] _raw_spin_lock+0x34/0x4c
        [    9.137645]   [<c02f3560>] fsl_sata_set_irq_coalescing+0x68/0x100
        [    9.143750]   [<c02f36a0>] sata_fsl_init_controller+0xa8/0xc0
        [    9.149505]   [<c02f3f10>] sata_fsl_probe+0x17c/0x2e8
        [    9.154568]   [<c02acc90>] driver_probe_device+0x90/0x248
        [    9.159987]   [<c02acf0c>] __driver_attach+0xc4/0xc8
        [    9.164964]   [<c02aae74>] bus_for_each_dev+0x5c/0xa8
        [    9.170028]   [<c02ac218>] bus_add_driver+0x100/0x26c
        [    9.175091]   [<c02ad638>] driver_register+0x88/0x198
        [    9.180155]   [<c0003a24>] do_one_initcall+0x58/0x1b4
        [    9.185226]   [<c05aeeac>] kernel_init_freeable+0x118/0x1c0
        [    9.190823]   [<c0004110>] kernel_init+0x18/0x108
        [    9.195542]   [<c000f6b8>] ret_from_kernel_thread+0x64/0x6c
        [    9.201142] irq event stamp: 160
        [    9.204366] hardirqs last  enabled at (159): [<c043f778>] _raw_spin_unlock_irq+0x30/0x50
        [    9.212469] hardirqs last disabled at (160): [<c000f414>] reenable_mmu+0x30/0x88
        [    9.219867] softirqs last  enabled at (144): [<c002ae5c>] __do_softirq+0x168/0x218
        [    9.227435] softirqs last disabled at (137): [<c002b0d4>] irq_exit+0xa8/0xb4
        [    9.234481]
        [    9.234481] other info that might help us debug this:
        [    9.240995]  Possible unsafe locking scenario:
        [    9.240995]
        [    9.246898]        CPU0
        [    9.249337]        ----
        [    9.251776]   lock(&(&host->lock)->rlock);
        [    9.255878]   <Interrupt>
        [    9.258492]     lock(&(&host->lock)->rlock);
        [    9.262765]
        [    9.262765]  *** DEADLOCK ***
        [    9.262765]
        [    9.268684] no locks held by scsi_eh_1/39.
        [    9.272767]
        [    9.272767] stack backtrace:
        [    9.277117] Call Trace:
        [    9.279589] [cfff9da0] [c0008504] show_stack+0x48/0x150 (unreliable)
        [    9.285972] [cfff9de0] [c0447d5c] print_usage_bug.part.35+0x268/0x27c
        [    9.292425] [cfff9e10] [c006ace4] mark_lock+0x2ac/0x658
        [    9.297660] [cfff9e40] [c006b7e4] __lock_acquire+0x754/0x1840
        [    9.303414] [cfff9ee0] [c006cdb8] lock_acquire+0x90/0xf4
        [    9.308745] [cfff9f20] [c043ef04] _raw_spin_lock+0x34/0x4c
        [    9.314250] [cfff9f30] [c02f4168] sata_fsl_interrupt+0x50/0x250
        [    9.320187] [cfff9f70] [c0079ff0] handle_irq_event_percpu+0x90/0x254
        [    9.326547] [cfff9fc0] [c007a1fc] handle_irq_event+0x48/0x78
        [    9.332220] [cfff9fe0] [c007c95c] handle_level_irq+0x9c/0x104
        [    9.337981] [cfff9ff0] [c000d978] call_handle_irq+0x18/0x28
        [    9.343568] [cc7139f0] [c000608c] do_IRQ+0xf0/0x1a8
        [    9.348464] [cc713a20] [c000fc8c] ret_from_except+0x0/0x14
        [    9.353983] --- Exception: 501 at _raw_spin_unlock_irq+0x40/0x50
        [    9.353983]     LR = _raw_spin_unlock_irq+0x30/0x50
        [    9.364839] [cc713af0] [c043db10] wait_for_common+0xac/0x188
        [    9.370513] [cc713b30] [c02ddee4] ata_exec_internal_sg+0x2b0/0x4f0
        [    9.376699] [cc713be0] [c02de18c] ata_exec_internal+0x68/0xa8
        [    9.382454] [cc713c20] [c02de4b8] ata_dev_read_id+0x158/0x594
        [    9.388205] [cc713ca0] [c02ec244] ata_eh_recover+0xd88/0x13d0
        [    9.393962] [cc713d20] [c02f2520] sata_pmp_error_handler+0xc0/0x8ac
        [    9.400234] [cc713dd0] [c02ecdc8] ata_scsi_port_error_handler+0x464/0x5e8
        [    9.407023] [cc713e10] [c02ecfd0] ata_scsi_error+0x84/0xb8
        [    9.412528] [cc713e40] [c02c4974] scsi_error_handler+0xd8/0x47c
        [    9.418457] [cc713eb0] [c004737c] kthread+0xa8/0xac
        [    9.423355] [cc713f40] [c000f6b8] ret_from_kernel_thread+0x64/0x6c
      This fix was suggested by Bhushan Bharat <R65777@freescale.com>, and
      was discussed in email at:
      Same patch successfully tested with 3.9.7.  linux-next compiled but
      not tested on hardware.
      This patch is based off linux-next tag next-20130819
      (which is commit 66a01bae29d11916c09f9f5a937cafe7d402e4a5 )
      Signed-off-by: 's avatarAnthony Foiani <anthony.foiani@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. 04 Aug, 2013 2 commits
  13. 25 Jul, 2013 4 commits
  14. 22 Jul, 2013 3 commits
  15. 24 Jun, 2013 1 commit
    • Aaron Lu's avatar
      libata-acpi: add back ACPI based hotplug functionality · 44521527
      Aaron Lu authored
      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: 's avatarDirk Griesbach <spamthis@freenet.de>
      Signed-off-by: 's avatarAaron Lu <aaron.lu@intel.com>
      Acked-by: 's avatarTejun Heo <tj@kernel.org>
      Cc: 3.6+ <stable@vger.kernel.org>
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  16. 02 Jun, 2013 1 commit
    • Sergei Shtylyov's avatar
      sata_rcar: fix interrupt handling · 52a2a108
      Sergei Shtylyov authored
      The driver's interrupt handling code is too picky in deciding whether it should
      handle an interrupt or not which causes completely unneeded spurious interrupts.
      Thus make sata_rcar_{ata|serr}_interrupt() *void*; add ATA status register read
      to sata_rcar_ata_interrupt() to clear an unexpected ATA interrupt -- it doesn't
      get cleared by writing to the SATAINTSTAT register in the interrupt mode we use.
      Also, in sata_rcar_ata_interrupt() we should check SATAINTSTAT register only for
      enabled interrupts and we should clear  only those interrupts  that we have read
      as active first time around, because else we have  a  race and risk clearing  an
      interrupt that  can  occur between read  and write of the  SATAINTSTAT  register
      and never registering it...
      Signed-off-by: 's avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
  17. 29 May, 2013 1 commit
  18. 21 May, 2013 2 commits
    • Sergei Shtylyov's avatar
      sata_rcar: clear STOP bit in bmdma_start() method · df7e131f
      Sergei Shtylyov authored
      Iff bmdma_setup() has to stop a DMA transfer before starting a new
      one, then the STOP bit in the ATAPI_CONTROL1 register will remain set
      (it's only cleared when setting the START bit to 1) and then
      bmdma_start() method will set both START and STOP bits simultaneously
      which should abort the transfer being just started.  Avoid that by
      explicitly clearing the STOP bit in bmdma_start() method (in this case
      it will be ignored on write).
      Signed-off-by: 's avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
    • Vincent Pelletier's avatar
      libata: make ata_exec_internal_sg honor DMADIR · e771451c
      Vincent Pelletier authored
      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
        [ 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:
      tj: minor formatting changes.
      Signed-off-by: 's avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
  19. 16 May, 2013 1 commit
  20. 14 May, 2013 1 commit
  21. 12 May, 2013 1 commit