Pull libata updates from Tejun Heo:
 "Support for some new embedded controllers.

  A couple late (<= a week) fixes have stable cc'd and one patch ("SATA:
  MV: Add support for the optional PHYs") got committed yesterday
  because otherwise the resulting kernel would fail boot on an embedded
  board due to interdependent changes in its platform tree.

  Other than that, nothing too noteworthy"

* 'for-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  SATA: MV: Add support for the optional PHYs
  sata-highbank: Remove unnecessary ahci_platform.h include
  libata: disable LPM for some WD SATA-I devices
  ARM: mvebu: update the SATA compatible string for Armada 370/XP
  ata: sata_mv: fix disk hotplug for Armada 370/XP SoCs
  ata: sata_mv: introduce compatible string "marvell, armada-370-sata"
  ata: pata_samsung_cf: Remove unused macros
  ata: pata_samsung_cf: Use devm_ioremap_resource()
  ata: pata_samsung_cf: Merge pata_samsung_cf.h into pata_samsung_cf.c
  ata: pata_samsung_cf: Move plat/regs-ata.h to drivers/ata
  drivers: ata: Mark the function as static in libahci.c
  drivers: ata: Mark the function ahci_init_interrupts() as static in ahci.c
  ahci: imx: fix the error handling in imx_ahci_probe()
  ahci: imx: ahci_imx_softreset() can be static
  ahci: imx: Add i.MX53 support
  ahci: imx: Pull out the clock enable/disable calls
  libata, dt: Document sata_rcar bindings
  sata_rcar: Add R-Car Gen2 SATA PHY support
  ahci: mcp89: enter AHCI mode under Apple BIOS emulation
  ata: libata-eh: Remove unnecessary snprintf arithmetic

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: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Nikos Barkas <levelwol@gmail.com>
Reported-and-tested-by: Ioannis Barkas <risc4all@yahoo.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
Cc: stable@vger.kernel.org

Pull libata fixes from Tejun Heo:
 "There's one interseting commit - "libata, freezer: avoid block device
  removal while system is frozen".  It's an ugly hack working around a
  deadlock condition between driver core resume and block layer device
  removal paths through freezer which was made more reproducible by
  writeback being converted to workqueue some releases ago.  The bug has
  nothing to do with libata but it's just an workaround which is easy to
  backport.  After discussion, Rafael and I seem to agree that we don't
  really need kernel freezables - both kthread and workqueue.  There are
  few specific workqueues which constitute PM operations and require
  freezing, which will be converted to use workqueue_set_max_active()
  instead.  All other kernel freezer uses are planned to be removed,
  followed by the removal of kthread and workqueue freezer support,
  hopefully.

  Others are device-specific fixes.  The most notable is the addition of
  NO_NCQ_TRIM which is used to disable queued TRIM commands to Micro
  M500 SSDs which otherwise suffers data corruption"

* 'for-3.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  libata, freezer: avoid block device removal while system is frozen
  libata: implement ATA_HORKAGE_NO_NCQ_TRIM and apply it to Micro M500 SSDs
  libata: disable a disk via libata.force params
  ahci: bail out on ICH6 before using AHCI BAR
  ahci: imx: Explicitly clear IMX6Q_GPR13_SATA_MPLL_CLK_EN
  libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8

Freezable kthreads and workqueues are fundamentally problematic in
that they effectively introduce a big kernel lock widely used in the
kernel and have already been the culprit of several deadlock
scenarios.  This is the latest occurrence.

During resume, libata rescans all the ports and revalidates all
pre-existing devices.  If it determines that a device has gone
missing, the device is removed from the system which involves
invalidating block device and flushing bdi while holding driver core
layer locks.  Unfortunately, this can race with the rest of device
resume.  Because freezable kthreads and workqueues are thawed after
device resume is complete and block device removal depends on
freezable workqueues and kthreads (e.g. bdi_wq, jbd2) to make
progress, this can lead to deadlock - block device removal can't
proceed because kthreads are frozen and kthreads can't be thawed
because device resume is blocked behind block device removal.

839a8e8660b6 ("writeback: replace custom worker pool implementation
with unbound workqueue") made this particular deadlock scenario more
visible but the underlying problem has always been there - the
original forker task and jbd2 are freezable too.  In fact, this is
highly likely just one of many possible deadlock scenarios given that
freezer behaves as a big kernel lock and we don't have any debug
mechanism around it.

I believe the right thing to do is getting rid of freezable kthreads
and workqueues.  This is something fundamentally broken.  For now,
implement a funny workaround in libata - just avoid doing block device
hot[un]plug while the system is frozen.  Kernel engineering at its
finest.  :(

v2: Add EXPORT_SYMBOL_GPL(pm_freezing) for cases where libata is built
    as a module.

v3: Comment updated and polling interval changed to 10ms as suggested
    by Rafael.

v4: Add #ifdef CONFIG_FREEZER around the hack as pm_freezing is not
    defined when FREEZER is not configured thus breaking build.
    Reported by kbuild test robot.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Tomaž Šolc <tomaz.solc@tablix.org>
Reviewed-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=62801
Link: http://lkml.kernel.org/r/20131213174932.GA27070@htj.dyndns.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: stable@vger.kernel.org
Cc: kbuild test robot <fengguang.wu@intel.com>

Some host adapters do not pass commands through to the target disk
directly. Instead they provide an emulated target which may or may not
accurately report its capabilities. In some cases the physical device
characteristics are reported even when the host adapter is processing
commands on the device's behalf. This can lead to adapter firmware hangs
or excessive I/O errors.

This patch disables WRITE SAME for devices connected to host adapters
that provide an emulated target. Driver writers can disable WRITE SAME
by setting the no_write_same flag in the host adapter template.

[jejb: fix up rejections due to eh_deadline patch]
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: stable@kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

Previously, we wanted SCSI devices corrsponding to ATA devices to
be runtime resumed when the power resource for those ATA device was
turned on by some other device, so we added the SCSI device to the
dependent device list of the ATA device's ACPI node.  However, this
code has no effect after commit 41863fc (ACPI / power: Drop automaitc
resume of power resource dependent devices) and the mechanism it was
supposed to implement is regarded as a bad idea now, so drop it.

[rjw: Changelog]
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull libata changes from Tejun Heo:
 "Two interesting changes.

   - libata acpi handling has been restructured so that the association
     between ata devices and ACPI handles are less convoluted.  This
     change shouldn't change visible behavior.

   - Queued TRIM support, which enables sending TRIM to the device
     without draining in-flight RW commands, is added.  Currently only
     enabled for ahci (and likely to stay that way for the foreseeable
     future).

  Other changes are driver-specific updates / fixes"

* 'for-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  libata: bugfix: Remove __le32 in ata_tf_to_fis()
  libata: acpi: Remove ata_dev_acpi_handle stub in libata.h
  libata: Add support for queued DSM TRIM
  libata: Add support for SEND/RECEIVE FPDMA QUEUED
  libata: Add H2D FIS "auxiliary" port flag
  libata: Populate host-to-device FIS "auxiliary" field
  ata: acpi: rework the ata acpi bind support
  sata, highbank: send extra clock cycles in SGPIO patterns
  sata, highbank: set tx_atten override bits
  devicetree: create a separate binding description for sata_highbank
  drivers/ata/sata_rcar.c: simplify use of devm_ioremap_resource
  sata highbank: enable 64-bit DMA mask when using LPAE
  ata: pata_samsung_cf: add missing __iomem annotation
  ata: pata_arasan: Staticize local symbols
  sata_mv: Remove unneeded CONFIG_HAVE_CLK ifdefs
  ata: use dev_get_platdata()
  sata_mv: Remove unneeded forward declaration
  libata: acpi: remove dead code for ata_acpi_(un)bind
  libata: move 'struct ata_taskfile' and friends from ata.h to libata.h

Some new SSDs support the queued version of the DSM TRIM command.
Let the driver use the new command if supported.

Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>

Binding ACPI handle to SCSI device has several drawbacks, namely:
1 During ATA device initialization time, ACPI handle will be needed
  while SCSI devices are not created yet. So each time ACPI handle is
  needed, instead of retrieving the handle by ACPI_HANDLE macro,
  a namespace scan is performed to find the handle for the corresponding
  ATA device. This is inefficient, and also expose a restriction on
  calling path not holding any lock.
2 The binding to SCSI device tree makes code complex, while at the same
  time doesn't bring us any benefit. All ACPI handlings are still done
  in ATA module, not in SCSI.

Rework the ATA ACPI binding code to bind ACPI handle to ATA transport
devices(ATA port and ATA device). The binding needs to be done only once,
since the ATA transport devices do not go away with hotplug. And due to
this, the flush_work call in hotplug handler for ATA bay is no longer
needed.

Tested on an Intel test platform for binding and runtime power off for
ODD(ZPODD) and hard disk; on an ASUS S400C for binding and normal boot
and S3, where its SATA port node has _SDD and _GTF control methods when
configured as an AHCI controller and its PATA device node has _GTF
control method when configured as an IDE controller. SATA PMP binding
and ATA hotplug is not tested.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Tested-by: Dirk Griesbach <spamthis@freenet.de>
Signed-off-by: Tejun Heo <tj@kernel.org>

The usage of strict_strtol() is not preferred, because
strict_strtol() is obsolete. Thus, kstrtol() should be
used.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Tejun Heo <tj@kernel.org>