1. 07 Mar, 2014 3 commits
  2. 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>
      f07b772d
    • 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>
      6314611a
    • 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>
      509e5695
  3. 15 Jan, 2014 1 commit
  4. 09 Jan, 2014 4 commits
  5. 12 Dec, 2013 1 commit
  6. 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>
      61688ba3
    • 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
      code:
      
        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
      '0'.
      
      The patch test ok with kernel 3.11.1.
      
      tj: Patch white space contaminated, applied manually with trivial
          updates.
      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>
      420df0f5
    • 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>
      296cfdec
    • 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>
      922b22ff
    • 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
              /var/log/messages:
          ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
      
          Before:
          	cat /sys/class/ata_link/link1/sata_spd
          	3.0 Gbps
          After:
          	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>
      929742b8
  7. 13 Nov, 2013 1 commit
  8. 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>
      323d5a7b
    • 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:
      
        http://linuxppc.10917.n7.nabble.com/MPC8315-reboot-failure-lockdep-splat-possibly-related-tp75162.html
      
      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>
      2650a684
  9. 04 Aug, 2013 2 commits
  10. 25 Jul, 2013 4 commits
  11. 22 Jul, 2013 3 commits
  12. 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>
      44521527
  13. 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
      52a2a108
  14. 29 May, 2013 1 commit
  15. 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
      df7e131f
    • 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
      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: 's avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
      e771451c
  16. 16 May, 2013 1 commit
  17. 14 May, 2013 1 commit
  18. 12 May, 2013 1 commit
  19. 30 Apr, 2013 3 commits
    • Robert Richter's avatar
      sata_highbank: Rename proc_name to the module name · 2cc1144a
      Robert Richter authored
      mkinitrd looks at /sys/class/scsi_host/host$hostnum/proc_name to find
      the module name of a disk driver. Current name is "highbank-ahci" but
      the module is "sata_highbank". Rename it to match the module name.
      
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Alexander Graf <agraf@suse.de>
      Cc: <stable@vger.kernel.org> v3.7..
      Signed-off-by: 's avatarRobert Richter <robert.richter@calxeda.com>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
      2cc1144a
    • Lv Zheng's avatar
      ACPI/libata: Restore libata.noacpi support · 19ccee76
      Lv Zheng authored
      This patch restores libata.noacpi support to libata-acpi.c.
      There are broken optional control methods for ATA controller devices in the
      real world.  The libata.noacpi has been used for a long time as a
      workaround to deal with issues caused by the broken ASL codes.
      1. The "noacpi" option is introduced by the following commit:
         commit 11ef697b
         Date: Thu, 28 Sep 2006 11:29:01 -0700
         Subject: libata: ACPI and _GTF support
      2. The "noacpi" option is renamed to "libata_noacpi" by the following
         commit:
         commit d7d0dad6
         Date: Wed, 28 Mar 2007 01:57:37 -0400
         Subject: [libata] Disable ACPI by default; fix namespace problems
      3. Some of its logics are changed over time - becomes relying on the
         "acpi_handle" bound to the ATA devices since this commit:
         commit fafbae87
         Date: Tue, 15 May 2007 03:28:16 +0900
         Subject: libata-acpi: implement ata_acpi_associate()
      4. The option is deleted by the following commit:
         commit 30dcf76a
         Date: Mon, 25 Jun 2012 16:13:04 +0800
         Subject: libata: migrate ACPI code over to new bindings
      But the libata.noacpi setup is still left in the kernel without codes to
      implement it.  So the deletion introduces a regression to the Linux.
      This patch disables ATA_ACPI support at runtime by stopping acpi binding
      on the ATA devices to fix this regression.
      This patch is tested by booting a SATA x86-64 kernel or a PATA x86 kernel
      with or without "libata.noacpi=1" kernel command line argument.
      Signed-off-by: 's avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: 's avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
      19ccee76
    • Aaron Lu's avatar
      [libata] acpi: make ata_ap_acpi_handle not block · d66af4df
      Aaron Lu authored
      Since commit 30dcf76a, ata_ap_acpi_handle will always do a namespace
      walk, which requires acquiring an acpi namespace mutex. This made it
      impossible to be used when calling path has held a spinlock.
      
      For example, it can occur in the following code path for pata_acpi:
      ata_scsi_queuecmd (ap->lock is acquired)
        __ata_scsi_queuecmd
          ata_scsi_translate
            ata_qc_issue
              pacpi_qc_issue
                ata_acpi_stm
                  ata_ap_acpi_handle
                    acpi_get_child
                      acpi_walk_namespace
                        acpi_ut_acquire_mutex (acquire mutex while holding lock)
      This caused scheduling while atomic bug, as reported in bug #56781.
      
      Actually, ata_ap_acpi_handle doesn't have to walk the namespace every
      time it is called, it can simply return the bound acpi handle on the
      corresponding SCSI host. The reason previously it is not done this way
      is, ata_ap_acpi_handle is used in the binding function
      ata_acpi_bind_host by ata_acpi_gtm when the handle is not bound to the
      SCSI host yet. Since we already have the ATA port's handle in its
      binding function, we can simply use it instead of calling
      ata_ap_acpi_handle there. So introduce a new function __ata_acpi_gtm,
      where it will receive an acpi handle param in addition to the ATA port
      which is solely used for debug statement. With this change, we can make
      ata_ap_acpi_handle simply return the bound handle for SCSI host instead
      of walking the acpi namespace now.
      
      Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=56781
      Reported-and-tested-by: <kenzopl@o2.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
      d66af4df