linux-stable.git/drivers/ata, branch v4.0.7

ata: ahci_mvebu: Fix wrongly set base address for the MBus window setting

2015-06-23T00:03:34+00:00

commit e96998fc200867f005dd14c7d1dd35e1107d4914 upstream.

According to the Armada 38x datasheet, the window base address
registers value is set in bits [31:4] of the register and corresponds
to the transaction address bits [47:20].

Therefore, the 32bit base address value should be shifted right by
20bits and left by 4bits, resulting in 16 bit shift right.

The bug as not been noticed yet because if the memory available on
the platform is less than 2GB, then the base address is zero.

[gregory.clement@free-electrons.com: add extra-explanation]

Fixes: a3464ed2f14 (ata: ahci_mvebu: new driver for Marvell Armada 380
AHCI interfaces)
Signed-off-by: Nadav Haklai 
Reviewed-by: Omri Itach 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

pata_octeon_cf: fix broken build

2015-06-23T00:03:31+00:00

commit 4710f2facb5c68d629015747bd09b37203e0d137 upstream.

MODULE_DEVICE_TABLE is referring to wrong driver's table and breaks the
build. Fix that.

Signed-off-by: Aaro Koskinen 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

libata: Blacklist queued TRIM on all Samsung 800-series

2015-06-06T15:21:02+00:00

commit 9a9324d3969678d44b330e1230ad2c8ae67acf81 upstream.

The queued TRIM problems appear to be generic to Samsung's firmware and
not tied to a particular model. A recent update to the 840 EVO firmware
introduced the same issue as we saw on 850 Pro.

Blacklist queued TRIM on all 800-series drives while we work this issue
with Samsung.

Reported-by: Günter Waller 
Reported-by: Sven Köhler 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

libata: Ignore spurious PHY event on LPM policy change

2015-06-06T15:21:02+00:00

commit 09c5b4803a80a5451d950d6a539d2eb311dc0fb1 upstream.

When the LPM policy is set to ATA_LPM_MAX_POWER, the device might
generate a spurious PHY event that cuases errors on the link.
Ignore this event if it occured within 10s after the policy change.

The timeout was chosen observing that on a Dell XPS13 9333 these
spurious events can occur up to roughly 6s after the policy change.

Link: http://lkml.kernel.org/g/3352987.ugV1Ipy7Z5@xps13
Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

libata: Add helper to determine when PHY events should be ignored

2015-06-06T15:21:02+00:00

commit 8393b811f38acdf7fd8da2028708edad3e68ce1f upstream.

This is a preparation commit that will allow to add other criteria
according to which PHY events should be dropped.

Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

ahci: avoton port-disable reset-quirk

2015-06-06T15:21:01+00:00

commit dbfe8ef5599a5370abc441fcdbb382b656563eb4 upstream.

Avoton AHCI occasionally sees drive probe timeouts at driver load time.
When this happens SCR_STATUS indicates device detected, but no D2H FIS
reception.  Reset the internal link state machines by bouncing
port-enable in the PCS register when this occurs.

Signed-off-by: Dan Williams 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

libata: Blacklist queued TRIM on Samsung SSD 850 Pro

2015-03-27T19:22:46+00:00

Blacklist queued TRIM on this drive for now.

Reported-by: Stefan Keller 
Signed-off-by: Martin K. Petersen 
CC: stable@vger.kernel.org
Signed-off-by: Tejun Heo

libata: Update Crucial/Micron blacklist

2015-03-27T19:22:40+00:00

Micron has released an updated firmware (MU02) for M510/M550/MX100
drives to fix the issues with queued TRIM. Queued TRIM remains broken on
M500 but is working fine on later drives such as M600 and MX200.

Tweak our blacklist to reflect the above.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=71371
Signed-off-by: Martin K. Petersen 
Cc: stable@vger.kernel.org
Signed-off-by: Tejun Heo

ata: Add a new flag to destinguish sas controller

2015-03-19T18:14:43+00:00

SAS controller has its own tag allocation, which doesn't directly match to ATA
tag, so SAS and SATA have different code path for ata tags. Originally we use
port->scsi_host (98bd4be1) to destinguish SAS controller, but libsas set
->scsi_host too, so we can't use it for the destinguish, we add a new flag for
this purpose.

Without this patch, the following oops can happen because scsi-mq uses
a host-wide tag map shared among all devices with some integer tag
values >= ATA_MAX_QUEUE.  These unexpectedly high tag values cause
__ata_qc_from_tag() to return NULL, which is then dereferenced in
ata_qc_new_init().

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
  IP: [] ata_qc_new_init+0x3e/0x120
  PGD 32adf0067 PUD 32adf1067 PMD 0
  Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
  Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi igb
  i2c_algo_bit ptp pps_core pm80xx libsas scsi_transport_sas sg coretemp
  eeprom w83795 i2c_i801
  CPU: 4 PID: 1450 Comm: cydiskbench Not tainted 4.0.0-rc3 #1
  Hardware name: Supermicro X8DTH-i/6/iF/6F/X8DTH, BIOS 2.1b       05/04/12
  task: ffff8800ba86d500 ti: ffff88032a064000 task.ti: ffff88032a064000
  RIP: 0010:[]  [] ata_qc_new_init+0x3e/0x120
  RSP: 0018:ffff88032a067858  EFLAGS: 00010046
  RAX: 0000000000000000 RBX: ffff8800ba0d2230 RCX: 000000000000002a
  RDX: ffffffff80505ae0 RSI: 0000000000000020 RDI: ffff8800ba0d2230
  RBP: ffff88032a067868 R08: 0000000000000201 R09: 0000000000000001
  R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800ba0d0000
  R13: ffff8800ba0d2230 R14: ffffffff80505ae0 R15: ffff8800ba0d0000
  FS:  0000000041223950(0063) GS:ffff88033e480000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000058 CR3: 000000032a0a3000 CR4: 00000000000006e0
  Stack:
   ffff880329eee758 ffff880329eee758 ffff88032a0678a8 ffffffff80502dad
   ffff8800ba167978 ffff880329eee758 ffff88032bf9c520 ffff8800ba167978
   ffff88032bf9c520 ffff88032bf9a290 ffff88032a0678b8 ffffffff80506909
  Call Trace:
   [] ata_scsi_translate+0x3d/0x1b0
   [] ata_sas_queuecmd+0x149/0x2a0
   [] sas_queuecommand+0xa0/0x1f0 [libsas]
   [] scsi_dispatch_cmd+0xd4/0x1a0
   [] scsi_queue_rq+0x66f/0x7f0
   [] __blk_mq_run_hw_queue+0x208/0x3f0
   [] blk_mq_run_hw_queue+0x88/0xc0
   [] blk_mq_insert_request+0xc4/0x130
   [] blk_execute_rq_nowait+0x73/0x160
   [] sg_common_write+0x3da/0x720 [sg]
   [] sg_new_write+0x250/0x360 [sg]
   [] sg_write+0x13b/0x450 [sg]
   [] vfs_write+0xd1/0x1b0
   [] SyS_write+0x54/0xc0
   [] system_call_fastpath+0x12/0x17

tj: updated description.

Fixes: 12cb5ce101ab ("libata: use blk taging")
Reported-and-tested-by: Tony Battersby 
Signed-off-by: Shaohua Li 
Signed-off-by: Tejun Heo

sata-fsl: Apply link speed limits

2015-03-02T17:08:43+00:00

The driver was ignoring limits requested by libata.force.  The output
would look like:

fsl-sata ffe18000.sata: Sata FSL Platform/CSB Driver init
ata1: FORCE: PHY spd limit set to 1.5Gbps
ata1: SATA max UDMA/133 irq 74
ata1: Signature Update detected @ 0 msecs
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 310)

Signed-off-by: Martin Hicks 
Signed-off-by: Tejun Heo