1. 22 Jun, 2015 1 commit
  2. 06 Jun, 2015 2 commits
  3. 30 Jan, 2015 2 commits
    • Andy Shevchenko's avatar
      sata_dwc_460ex: fix resource leak on error path · e8eb477e
      Andy Shevchenko authored
      commit 4aaa71873ddb9faf4b0c4826579e2f6d18ff9ab4 upstream.
      
      DMA mapped IO should be unmapped on the error path in probe() and
      unconditionally on remove().
      
      Fixes: 62936009 ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex)
      Signed-off-by: 's avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e8eb477e
    • David Jeffery's avatar
      libata: prevent HSM state change race between ISR and PIO · 1dd95dfd
      David Jeffery authored
      commit ce7514526742c0898b837d4395f515b79dfb5a12 upstream.
      
      It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to
      HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE
      and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().
      
      This problem is hard to reproduce making this patch hard to verify, but this
      fix will prevent the race.
      
      I have not been able to reproduce the problem, but here is a crash dump from
      a 2.6.32 kernel.
      
      On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE:
      
      crash> struct ata_port.hsm_task_state ffff881c1121c000
        hsm_task_state = 0
      
      Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(),
      which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value.
      
      PID: 11053  TASK: ffff8816e846cae0  CPU: 0   COMMAND: "sshd"
       #0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b
       #1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92
       #2 [ffff88008ba03a90] oops_end at ffffffff8152b510
       #3 [ffff88008ba03ac0] die at ffffffff81010e0b
       #4 [ffff88008ba03af0] do_trap at ffffffff8152ad74
       #5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95
       #6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b
          [exception RIP: ata_sff_hsm_move+317]
          RIP: ffffffff813a77ad  RSP: ffff88008ba03ca0  RFLAGS: 00010097
          RAX: 0000000000000000  RBX: ffff881c1121dc60  RCX: 0000000000000000
          RDX: ffff881c1121dd10  RSI: ffff881c1121dc60  RDI: ffff881c1121c000
          RBP: ffff88008ba03d00   R8: 0000000000000000   R9: 000000000000002e
          R10: 000000000001003f  R11: 000000000000009b  R12: ffff881c1121c000
          R13: 0000000000000000  R14: 0000000000000050  R15: ffff881c1121dd78
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd
       #8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e
       #9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0
      1dd95dfd
  4. 16 Dec, 2014 3 commits
  5. 21 Nov, 2014 2 commits
  6. 14 Nov, 2014 2 commits
    • Ondrej Zary's avatar
      libata-sff: Fix controllers with no ctl port · fa6709b9
      Ondrej Zary authored
      commit 6d8ca28fa688a9354bc9fbc935bdaeb3651b6677 upstream.
      
      Currently, ata_sff_softreset is skipped for controllers with no ctl port.
      But that also skips ata_sff_dev_classify required for device detection.
      This means that libata is currently broken on controllers with no ctl port.
      
      No device connected:
      [    1.872480] pata_isapnp 01:01.02: activated
      [    1.889823] scsi2 : pata_isapnp
      [    1.890109] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
      [    6.888110] ata3.01: qc timeout (cmd 0xec)
      [    6.888179] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   16.888085] ata3.01: qc timeout (cmd 0xec)
      [   16.888147] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   46.888086] ata3.01: qc timeout (cmd 0xec)
      [   46.888148] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   51.888100] ata3.00: qc timeout (cmd 0xec)
      [   51.888160] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   61.888079] ata3.00: qc timeout (cmd 0xec)
      [   61.888141] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   91.888089] ata3.00: qc timeout (cmd 0xec)
      [   91.888152] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
      
      ATAPI device connected:
      [    1.882061] pata_isapnp 01:01.02: activated
      [    1.893430] scsi2 : pata_isapnp
      [    1.893719] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
      [    6.892107] ata3.01: qc timeout (cmd 0xec)
      [    6.892171] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   16.892079] ata3.01: qc timeout (cmd 0xec)
      [   16.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   46.892079] ata3.01: qc timeout (cmd 0xec)
      [   46.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   46.908586] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr
      [   46.924570] ata3.00: configured for PIO0 (device error ignored)
      [   46.926295] scsi 2:0:0:0: CD-ROM            ACER     CD-767E/O        1.5X PQ: 0 ANSI: 5
      [   46.984519] sr0: scsi3-mmc drive: 6x/6x xa/form2 tray
      [   46.984592] cdrom: Uniform CD-ROM driver Revision: 3.20
      
      So don't skip ata_sff_softreset, just skip the reset part of ata_bus_softreset
      if the ctl port is not available.
      
      This makes IDE port on ES968 behave correctly:
      
      No device connected:
      [    4.670888] pata_isapnp 01:01.02: activated
      [    4.673207] scsi host2: pata_isapnp
      [    4.673675] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
      [    7.081840] Adding 2541652k swap on /dev/sda2.  Priority:-1 extents:1 across:2541652k
      
      ATAPI device connected:
      [    4.704362] pata_isapnp 01:01.02: activated
      [    4.706620] scsi host2: pata_isapnp
      [    4.706877] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
      [    4.872782] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr
      [    4.888673] ata3.00: configured for PIO0 (device error ignored)
      [    4.893984] scsi 2:0:0:0: CD-ROM            ACER     CD-767E/O        1.5X PQ: 0 ANSI: 5
      [    7.015578] Adding 2541652k swap on /dev/sda2.  Priority:-1 extents:1 across:2541652k
      Signed-off-by: 's avatarOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa6709b9
    • Scott Carter's avatar
      pata_serverworks: disable 64-KB DMA transfers on Broadcom OSB4 IDE Controller · dd1e981a
      Scott Carter authored
      commit 37017ac6849e772e67dd187ba2fbd056c4afa533 upstream.
      
      The Broadcom OSB4 IDE Controller (vendor and device IDs: 1166:0211)
      does not support 64-KB DMA transfers.
      Whenever a 64-KB DMA transfer is attempted,
      the transfer fails and messages similar to the following
      are written to the console log:
      
         [ 2431.851125] sr 0:0:0:0: [sr0] Unhandled sense code
         [ 2431.851139] sr 0:0:0:0: [sr0]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
         [ 2431.851152] sr 0:0:0:0: [sr0]  Sense Key : Hardware Error [current]
         [ 2431.851166] sr 0:0:0:0: [sr0]  Add. Sense: Logical unit communication time-out
         [ 2431.851182] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 76 f4 00 00 40 00
         [ 2431.851210] end_request: I/O error, dev sr0, sector 121808
      
      When the libata and pata_serverworks modules
      are recompiled with ATA_DEBUG and ATA_VERBOSE_DEBUG defined in libata.h,
      the 64-KB transfer size in the scatter-gather list can be seen
      in the console log:
      
         [ 2664.897267] sr 9:0:0:0: [sr0] Send:
         [ 2664.897274] 0xf63d85e0
         [ 2664.897283] sr 9:0:0:0: [sr0] CDB:
         [ 2664.897288] Read(10): 28 00 00 00 7f b4 00 00 40 00
         [ 2664.897319] buffer = 0xf6d6fbc0, bufflen = 131072, queuecommand 0xf81b7700
         [ 2664.897331] ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 00 00 7f b4 00 00 40
         [ 2664.897338] ata_scsi_translate: ENTER
         [ 2664.897345] ata_sg_setup: ENTER, ata1
         [ 2664.897356] ata_sg_setup: 3 sg elements mapped
         [ 2664.897364] ata_bmdma_fill_sg: PRD[0] = (0x66FD2000, 0xE000)
         [ 2664.897371] ata_bmdma_fill_sg: PRD[1] = (0x65000000, 0x10000)
         ------------------------------------------------------> =======
         [ 2664.897378] ata_bmdma_fill_sg: PRD[2] = (0x66A10000, 0x2000)
         [ 2664.897386] ata1: ata_dev_select: ENTER, device 0, wait 1
         [ 2664.897422] ata_sff_tf_load: feat 0x1 nsect 0x0 lba 0x0 0x0 0xFC
         [ 2664.897428] ata_sff_tf_load: device 0xA0
         [ 2664.897448] ata_sff_exec_command: ata1: cmd 0xA0
         [ 2664.897457] ata_scsi_translate: EXIT
         [ 2664.897462] leaving scsi_dispatch_cmnd()
         [ 2664.897497] Doing sr request, dev = sr0, block = 0
         [ 2664.897507] sr0 : reading 64/256 512 byte blocks.
         [ 2664.897553] ata_sff_hsm_move: ata1: protocol 7 task_state 1 (dev_stat 0x58)
         [ 2664.897560] atapi_send_cdb: send cdb
         [ 2666.910058] ata_bmdma_port_intr: ata1: host_stat 0x64
         [ 2666.910079] __ata_sff_port_intr: ata1: protocol 7 task_state 3
         [ 2666.910093] ata_sff_hsm_move: ata1: protocol 7 task_state 3 (dev_stat 0x51)
         [ 2666.910101] ata_sff_hsm_move: ata1: protocol 7 task_state 4 (dev_stat 0x51)
         [ 2666.910129] sr 9:0:0:0: [sr0] Done:
         [ 2666.910136] 0xf63d85e0 TIMEOUT
      
      lspci shows that the driver used for the Broadcom OSB4 IDE Controller is
      pata_serverworks:
      
         00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8e [Master SecP SecO PriP])
                 Flags: bus master, medium devsel, latency 64
                 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
                 [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
                 I/O ports at 0170 [size=8]
                 I/O ports at 0374 [size=4]
                 I/O ports at 1440 [size=16]
                 Kernel driver in use: pata_serverworks
      
      The pata_serverworks driver supports five distinct device IDs,
      one being the OSB4 and the other four belonging to the CSB series.
      The CSB series appears to support 64-KB DMA transfers,
      as tests on a machine with an SAI2 motherboard
      containing a Broadcom CSB5 IDE Controller (vendor and device IDs: 1166:0212)
      showed no problems with 64-KB DMA transfers.
      
      This problem was first discovered when attempting to install openSUSE
      from a DVD on a machine with an STL2 motherboard.
      Using the pata_serverworks module,
      older releases of openSUSE will not install at all due to the timeouts.
      Releases of openSUSE prior to 11.3 can be installed by disabling
      the pata_serverworks module using the brokenmodules boot parameter,
      which causes the serverworks module to be used instead.
      Recent releases of openSUSE (12.2 and later) include better error recovery and
      will install, though very slowly.
      On all openSUSE releases, the problem can be recreated
      on a machine containing a Broadcom OSB4 IDE Controller
      by mounting an install DVD and running a command similar to the following:
      
         find /mnt -type f -print | xargs cat > /dev/null
      
      The patch below corrects the problem.
      Similar to the other ATA drivers that do not support 64-KB DMA transfers,
      the patch changes the ata_port_operations qc_prep vector to point to a routine
      that breaks any 64-KB segment into two 32-KB segments and
      changes the scsi_host_template sg_tablesize element to reduce by half
      the number of scatter/gather elements allowed.
      These two changes affect only the OSB4.
      Signed-off-by: 's avatarScott Carter <ccscott@funsoft.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd1e981a
  7. 05 Oct, 2014 4 commits
  8. 31 Jul, 2014 3 commits
    • Romain Degez's avatar
      ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode) · d35acb6e
      Romain Degez authored
      commit b32bfc06aefab61acc872dec3222624e6cd867ed upstream.
      
      Add support of the Promise FastTrak TX8660 SATA HBA in ahci mode by
      registering the board in the ahci_pci_tbl[].
      
      Note: this HBA also provide a hardware RAID mode when activated in
      BIOS but specific drivers from the manufacturer are required in this
      case.
      Signed-off-by: 's avatarRomain Degez <romain.degez@gmail.com>
      Tested-by: 's avatarRomain Degez <romain.degez@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d35acb6e
    • Tejun Heo's avatar
      libata: introduce ata_host->n_tags to avoid oops on SAS controllers · 03cccb9c
      Tejun Heo authored
      commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6 upstream.
      
      1871ee134b73 ("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: 's avatarTejun Heo <tj@kernel.org>
      Reported-by: 's avatarMike Qiu <qiudayu@linux.vnet.ibm.com>
      Reported-by: 's avatarJesse Brandeburg <jesse.brandeburg@gmail.com>
      Reported-by: 's avatarPeter Hurley <peter@hurleysoftware.com>
      Reported-by: 's avatarPeter Zijlstra <peterz@infradead.org>
      Tested-by: 's avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Fixes: 1871ee134b73 ("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>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03cccb9c
    • Kevin Hao's avatar
      libata: support the ata host which implements a queue depth less than 32 · 97a23070
      Kevin Hao authored
      commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream.
      
      The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6
      ("libata/ahci: accommodate tag ordered controllers"). The reason is
      that the ata controller on this SoC only implement a queue depth of
      16. When issuing the commands in tag order, all the commands in tag
      16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
      malfunction. It makes no senses to use a 32 queue in software while
      the hardware has less queue depth. So consider the queue depth
      implemented by the hardware when requesting a command tag.
      
      Fixes: 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers")
      Signed-off-by: 's avatarKevin Hao <haokexin@gmail.com>
      Acked-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>
      97a23070
  9. 16 Jun, 2014 2 commits
  10. 07 Jun, 2014 2 commits
  11. 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:
      
      	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: 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>
      cfd192c9
  12. 24 Mar, 2014 1 commit
  13. 07 Mar, 2014 3 commits
  14. 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
  15. 15 Jan, 2014 1 commit
  16. 09 Jan, 2014 4 commits
  17. 12 Dec, 2013 1 commit
  18. 04 Dec, 2013 3 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