linux-toradex.git/drivers/ata, branch v3.10.3 Linux kernel for Apalis and Colibri modules sata_highbank: increase retry count but shorten duration for Calxeda controller 2013-07-25T21:07:28+00:00 Mark Langsdorf mark.langsdorf@calxeda.com 2013-06-03T13:22:54+00:00 31c1a76deb262a074b209ad14a35bef7f5b9ab81 commit ddfef5de3d716f77bad32dbbba6b280158dfd721 upstream. Increase the retry count for the hard reset function to 100 but shorten the time out period to 500 ms. See the comment for ahci_highbank_hardreset for the reasons why those vaulues were chosen. Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ddfef5de3d716f77bad32dbbba6b280158dfd721 upstream.

Increase the retry count for the hard reset function to 100 but
shorten the time out period to 500 ms. See the comment for
ahci_highbank_hardreset for the reasons why those vaulues were
chosen.

Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ata_piix: IDE-mode SATA patch for Intel Coleto Creek DeviceIDs 2013-07-25T21:07:27+00:00 Seth Heasley seth.heasley@intel.com 2013-06-19T23:25:37+00:00 b568411d97ec8c91eef5e512b5b2ec5df050c9c1 commit c7e8695bfa0611b39493a9dfe8bab9f63f9809bd upstream. This patch adds the IDE-mode SATA DeviceIDs for the Intel Coleto Creek PCH. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit c7e8695bfa0611b39493a9dfe8bab9f63f9809bd upstream.

This patch adds the IDE-mode SATA DeviceIDs for the Intel Coleto Creek PCH.

Signed-off-by: Seth Heasley <seth.heasley@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
libata: skip SRST for all SIMG [34]7x port-multipliers 2013-07-25T21:07:27+00:00 Tejun Heo tj@kernel.org 2013-06-11T07:11:36+00:00 64a03b5c4206bb104ea69efed3c8189427fcedfe commit 7a87718d92760fc688628ad6a430643dafa16f1f upstream. For some reason, a lot of port-multipliers have issues with softreset. SIMG [34]7x series port-multipliers have been quite erratic in this regard. I recall that it was better with some firmware revisions and the current list of quirks worked fine for a while. I think it got worse with later firmwares or maybe my test coverage wasn't good enough. Anyways, HPA is reporting that his 3726 setup suffers SRST failures and then the PMP gets confused and fails to probe the last port. The hope was that we try to stick to the standard as much as possible and soonish the PMPs and their firmwares will improve in quality, so the quirk list was kept to minimum. Well, it seems like that's never gonna happen. Let's set NO_SRST for all [34]7x PMPs so that whatever remaining userbase of the device suffer the least. Maybe we should do the same for 57xx's but unfortunately I don't have any device left to test and I'm not even sure 57xx's have ever been made widely available, so let's leave those alone for now. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7a87718d92760fc688628ad6a430643dafa16f1f upstream.

For some reason, a lot of port-multipliers have issues with softreset.
SIMG [34]7x series port-multipliers have been quite erratic in this
regard.  I recall that it was better with some firmware revisions and
the current list of quirks worked fine for a while.  I think it got
worse with later firmwares or maybe my test coverage wasn't good
enough.  Anyways, HPA is reporting that his 3726 setup suffers SRST
failures and then the PMP gets confused and fails to probe the last
port.

The hope was that we try to stick to the standard as much as possible
and soonish the PMPs and their firmwares will improve in quality, so
the quirk list was kept to minimum.  Well, it seems like that's never
gonna happen.

Let's set NO_SRST for all [34]7x PMPs so that whatever remaining
userbase of the device suffer the least.  Maybe we should do the same
for 57xx's but unfortunately I don't have any device left to test and
I'm not even sure 57xx's have ever been made widely available, so
let's leave those alone for now.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
libata-zpodd: must use ata_tf_init() 2013-07-25T21:07:27+00:00 Sergei Shtylyov sergei.shtylyov@cogentembedded.com 2013-06-23T19:25:04+00:00 fe1ebd057ddfb37a23cc37090d427fb0a68d3000 commit d0887c43f51c308b01605346e55d906ba858a6f9 upstream. There are some SATA controllers which have both devices 0 and 1 but this module just zeroes out taskfile and sets then ATA_TFLAG_DEVICE (not sure that's needed) which could lead to a wrong device being selected just before issuing command. Thus we should call ata_tf_init() which sets up the device register value properly, like all other users of ata_exec_internal() do... Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d0887c43f51c308b01605346e55d906ba858a6f9 upstream.

There are  some SATA controllers which have both devices 0 and 1 but this module
just zeroes out taskfile and sets then ATA_TFLAG_DEVICE (not sure that's needed)
which could  lead to a wrong device being selected just before issuing command.
Thus we should  call ata_tf_init()  which sets  up the device register value
properly, like  all other users of ata_exec_internal() do...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ahci: remove pmp link online check in FBS EH 2013-07-22T01:21:31+00:00 Shane Huang shane.huang@amd.com 2013-06-08T08:00:16+00:00 f4f391e86e14bcbc0ddcbca8a52b81cac7bf0c7c commit 912b9ac683b112615d5605686f1dc086402ce9f7 upstream. ata_link_online() check in ahci_error_intr() is unnecessary, it should be removed otherwise may lead to lockup with FBS enabled PMP. http://marc.info/?l=linux-ide&m=137050421603272&w=2 Reported-by: Yu Liu <liuyu.ac@gmail.com> Signed-off-by: Shane Huang <shane.huang@amd.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 912b9ac683b112615d5605686f1dc086402ce9f7 upstream.

ata_link_online() check in ahci_error_intr() is unnecessary, it should
be removed otherwise may lead to lockup with FBS enabled PMP.
http://marc.info/?l=linux-ide&m=137050421603272&w=2

Reported-by: Yu Liu <liuyu.ac@gmail.com>
Signed-off-by: Shane Huang <shane.huang@amd.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ahci: AHCI-mode SATA patch for Intel Coleto Creek DeviceIDs 2013-07-22T01:21:31+00:00 Seth Heasley seth.heasley@intel.com 2013-06-19T23:36:45+00:00 21e8e04d6f137aeab872fd9e0ef356dd1126deb4 commit 1cfc7df3de10c40ed459e13cce6de616023bf41c upstream. This patch adds the AHCI-mode SATA DeviceIDs for the Intel Coleto Creek PCH. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1cfc7df3de10c40ed459e13cce6de616023bf41c upstream.

This patch adds the AHCI-mode SATA DeviceIDs for the Intel Coleto Creek PCH.

Signed-off-by: Seth Heasley <seth.heasley@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ahci: Add AMD CZ SATA device ID 2013-07-22T01:21:30+00:00 Shane Huang shane.huang@amd.com 2013-06-03T10:24:10+00:00 7d31ea0d281c8443c8637c78822f56388f4cf82d commit fafe5c3d82a470d73de53e6b08eb4e28d974d895 upstream. To add AMD CZ SATA controller device ID of IDE mode. [bhelgaas: drop pci_ids.h update] Signed-off-by: Shane Huang <shane.huang@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fafe5c3d82a470d73de53e6b08eb4e28d974d895 upstream.

To add AMD CZ SATA controller device ID of IDE mode.

[bhelgaas: drop pci_ids.h update]
Signed-off-by: Shane Huang <shane.huang@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
libata-acpi: add back ACPI based hotplug functionality 2013-06-24T22:51:33+00:00 Aaron Lu aaron.lu@intel.com 2013-06-20T01:38:34+00:00 44521527be36172864e6e7a6fba4b66e9aa48e40 Commit 30dcf76acc69 "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=59871 Reported-bisected-and-tested-by: Dirk Griesbach <spamthis@freenet.de> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Tejun Heo <tj@kernel.org> Cc: 3.6+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Commit 30dcf76acc69 "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=59871
Reported-bisected-and-tested-by: Dirk Griesbach <spamthis@freenet.de>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: 3.6+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'for-3.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata 2013-06-03T08:55:09+00:00 Linus Torvalds torvalds@linux-foundation.org 2013-06-03T08:55:09+00:00 338e33acd820fa89b8a2d5b6574233784702f618 Pull libata changes from Tejun Heo: "Nothing too interesting. PCI ID additions, some sata_rcar fixes and a fringe bug fix for DMADIR handling which shouldn't affect any device remotely modern." * 'for-3.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: sata_rcar: fix interrupt handling ahci: add an observed PCI ID for Marvell 88se9172 SATA controller sata_rcar: clear STOP bit in bmdma_start() method libata: make ata_exec_internal_sg honor DMADIR ata_piix: add PCI IDs for Intel BayTail libata: update "Maintained by:" tags 
Pull libata changes from Tejun Heo:
 "Nothing too interesting.  PCI ID additions, some sata_rcar fixes and a
  fringe bug fix for DMADIR handling which shouldn't affect any device
  remotely modern."

* 'for-3.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  sata_rcar: fix interrupt handling
  ahci: add an observed PCI ID for Marvell 88se9172 SATA controller
  sata_rcar: clear STOP bit in bmdma_start() method
  libata: make ata_exec_internal_sg honor DMADIR
  ata_piix: add PCI IDs for Intel BayTail
  libata: update "Maintained by:" tags
sata_rcar: fix interrupt handling 2013-06-02T07:54:45+00:00 Sergei Shtylyov sergei.shtylyov@cogentembedded.com 2013-05-31T22:38:35+00:00 52a2a1087b5924de00484f35ef5e2a73f61dbd22 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: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org 
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: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org