Samsung's pci-e SSDs with device ID 0x1600 which are found on some
macbooks time out on NCQ commands.  Blacklist NCQ on the device so
that the affected machines can at least boot.
Original-patch-by: NLevente Kurusa <levex@linux.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60731
Cc: stable@vger.kernel.org

When an error occurs in the port initialization loop, currently the
driver tries to cleanup all the ports. This results in a NULL pointer
dereference if the ports were only partially initialized.

Fix this by updating only the number of initialized ports (either
with failure or successfully), before jumping to the error path
and looping over that number in the cleanup loop.

Cc: Andrew Lunn <andrew@lunn.ch>
Reported-by: NMikael Pettersson <mikpelinux@gmail.com>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

Make use of devm_phy_optional_get() in order to fix probe failures on
Armada 370, XP and others, when there is no phy driver available.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NTejun Heo <tj@kernel.org>
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

It's a bit odd to see a newer device showing mod15write; however, the
reported behavior is highly consistent and other factors which could
contribute seem to have been verified well enough.  Also, both
sata_sil itself and the drive are fairly outdated at this point making
the risk of this change fairly low.  It is possible, probably likely,
that other drive models in the same family have the same problem;
however, for now, let's just add the specific model which was tested.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: Nmatson <lists-matsonpa@luxsci.me>
References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com
Cc: stable@vger.kernel.org

Without the patch the kernel generates the following error.

 ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'
 ata11.15: PMP revalidation failed (errno=-19)
 ata11.15: failed to recover PMP after 5 tries, giving up

This patch helps to bypass this error and the device becomes
functional.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: <linux-ide@vger.kernel.org>
Cc: stable@vger.kernel.org

SATA_MV depends on GENERIC_PHY. So if SATA_MV is built in, GENERIC_PHY
cannot be modular. Fixes build error found by kbuild test robot.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NTejun Heo <tj@kernel.org>

clk_prepare_enable() may fail, so let's check its return value and propagate it
in the case of error.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Some Marvell SoCs have a SATA PHY which can be powered off, in order
to save power. Make use of the generic phy framework to control these
phys.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NTejun Heo <tj@kernel.org>

The sata-highbank driver is a complete standalone sata driver, which does
not use ahci_platform.c / ahci_platform_data in any way.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

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

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: NLior Amsalem <alior@marvell.com>
Signed-off-by: NNadav Haklai <nadavh@marvell.com>
Signed-off-by: NSimon 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: stable@vger.kernel.org # v3.6+
Acked-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NTejun Heo <tj@kernel.org>

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: NSimon 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>
Cc: stable@vger.kernel.org # v3.6+
Acked-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NTejun Heo <tj@kernel.org>

These macros are not used in the file. Remove them.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

The new pci_msi_vec_count() interface makes pci_enable_msi_block_auto()
superfluous.

Drivers can use pci_msi_vec_count() to learn the maximum number of MSIs
supported by the device, and then call pci_enable_msi_block().

pci_enable_msi_block_auto() was introduced recently, and its only user is
the AHCI driver, which is also updated by this change.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NTejun Heo <tj@kernel.org>

Use devm_ioremap_resource() in order to make the code simpler,
and remove redundant return value check of platform_get_resource()
because the value is checked by devm_ioremap_resource().
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Since pata_samsung_cf.h is referenced only by pata_samsung_cf.c, merge
it into the .c file.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

sata_sis has no suspend/resume methods. The default ones will do fine and
are needed on some systems.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch adds support for the PCI ID provided by the Marvell 88SE9170
SATA controller.
Signed-off-by: NSimon Guinot <sguinot@lacie.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

plat/regs-ata.h is used only by Samsung PATA driver.
Move this file to the drivers folder to remove platform
dependency required for multiplatform support.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

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.

839a8e86 ("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: NTejun Heo <tj@kernel.org>
Reported-by: NTomaž Šolc <tomaz.solc@tablix.org>
Reviewed-by: N"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>

Certain drives cannot handle queued TRIM commands properly, even
though support is indicated in the IDENTIFY DEVICE buffer.  This patch
allows for disabling the commands for the affected drives and apply it
to the Micron/Crucial M500 SSDs which exhibit incorrect protocol
behavior when issued queued TRIM commands, which could lead to silent
data corruption.

tj: Merged two unnecessarily split patches and made minor edits
    including shortening horkage name.
Signed-off-by: NMarc Carino <marc.ceeeee@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Link: http://lkml.kernel.org/g/1387246554-7311-1-git-send-email-marc.ceeeee@gmail.com
Cc: stable@vger.kernel.org # 3.12+

A user on StackExchange had a failing SSD that's soldered directly
onto the motherboard of his system. The BIOS does not give any option
to disable it at all, so he can't just hide it from the OS via the
BIOS.

The old IDE layer had hdX=noprobe override for situations like this,
but that was never ported to the libata layer.

This patch implements a disable flag for libata.force.

Example use:

 libata.force=2.0:disable

[v2 of the patch, removed the nodisable flag per Tejun Heo]
Signed-off-by: NRobin H. Johnson <robbat2@gentoo.org>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Link: http://unix.stackexchange.com/questions/102648/how-to-tell-linux-kernel-3-0-to-completely-ignore-a-failing-disk
Link: http://askubuntu.com/questions/352836/how-can-i-tell-linux-kernel-to-completely-ignore-a-disk-as-if-it-was-not-even-co
Link: http://superuser.com/questions/599333/how-to-disable-kernel-probing-for-drive

The check for "combined mode" (which disables ahci support) on ICH6 is
done after the first use of AHCI BAR. But if ahci is not enabled AHCI
BAR is initialized to 0x00000000. (At least it is on the ICH6-M I tested
this on. If I understand the datasheet correctly it should also be on
ICH6R.) This apparently makes the call of
pcim_iomap_regions_request_all() return -EINVAL. And we end up with
    ahci: probe of 0000:00:1f.2 failed with error -22

(at warning level) in the logs.

So check for "combined mode" before calling
pcim_iomap_regions_request_all().
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch marks the function ahci_port_intr() and
ahci_hw_port_interrupt() as static in libahci.c because they are not
used outside this file.

Thus, it also eliminates the following warnings in libahci.c:
drivers/ata/libahci.c:1767:6: warning: no previous prototype for ‘ahci_port_intr’ [-Wmissing-prototypes]
drivers/ata/libahci.c:1800:6: warning: no previous prototype for ‘ahci_hw_port_interrupt’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>

This patch marks the function ahci_init_interrupts() as static in ahci.c
because it is not used outside this file.

Thus, it also eliminates the following warning in ahci.c:
drivers/ata/ahci.c:1099:5: warning: no previous prototype for ‘ahci_init_interrupts’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>

Release alloced resources instead of direct return from
imx_ahci_probe() in the error handling case.

Fixes: 4a23d179 ('ahci: imx: Add i.MX53 support')
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NMarek Vasut <marex@denx.de>

Modify acpi_preset_companion() to take a struct acpi_device pointer
instead of an ACPI handle as its second argument and redefine it as
a static inline wrapper around ACPI_COMPANION_SET() passing the
return value of acpi_find_child_device() directly as the second
argument to it.  Update its users to pass struct acpi_device
pointers instead of ACPI handles to it.

This allows some unnecessary acpi_bus_get_device() calls to be
avoided.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com> # for ATA binding

Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
<acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
inclusions and remove some inclusions of those files that aren't
necessary.

First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
<linux/acpi.h> includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.

Second, there are ordering dependencies between those files that always
have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
latter depends on are always there.  And <acpi/acpi.h> which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
<linux/acpi.h> as appropriate.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Add minor adjustments to support i.MX53 SATA port as well as i.MX6Q one.
The difference here is mostly the clock which need to be enabled and also
the lack of need of programming IOMUXC registers on i.MX53. All of which
is well handles in the clock enable/disable functions. Note that this patch
also cleans up the names of the common functions, so they don't read imx6q_*
but imx_* instead.
Signed-off-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Cc: Richard Zhu <r65037@freescale.com>
Cc: Linux-IDE <linux-ide@vger.kernel.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

The same code for enabling and disabling SATA clock was found in multiple
places in the driver. Implement functions that enable/disable the SATA clock
and use them in such places instead of duplicating the code.
Signed-off-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Cc: Richard Zhu <r65037@freescale.com>
Cc: Linux-IDE <linux-ide@vger.kernel.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

We must clear this IMX6Q_GPR13_SATA_MPLL_CLK_EN bit on i.MX6Q, otherwise
Linux will fail to find the attached drive on some boards.

This entire fix was:
Reported-by: NEric Nelson <eric.nelson@boundarydevices.com>
Signed-off-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Cc: Richard Zhu <r65037@freescale.com>
Cc: Linux-IDE <linux-ide@vger.kernel.org>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

We've received multiple reports in Fedora via (BZ 907193)
that the Seagate Momentus SpinPoint M8 errors out when enabling AA:
[    2.555905] ata2.00: failed to enable AA (error_mask=0x1)
[    2.568482] ata2.00: failed to enable AA (error_mask=0x1)

Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk.
Reported-by: NNicholas <arealityfarbetween@googlemail.com>
Signed-off-by: NMichele Baldessari <michele@acksyn.org>
Tested-by: NNicholas <arealityfarbetween@googlemail.com>
Acked-by: NAlan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

R-Car Gen2 SoCs have a different PHY which is not compatible
with the older R-Car H1 (R8A7779) version.
This adds OF/platform device id tables and PHY initialization
callbacks for the following Gen2 SoCs:
  * R-Car H2: R8A7790;
  * R-Car M2: R8A7791.

PHY initialization method is chosen based on the device id.
Default PHY settings are applied for Gen2 SoCs, which should
suit the Gen2 boards available.

While at it, this also adds "sata-r8a7779" compatibility string
for R8A7779 SATA, while keeping the old one for compatibility.
Signed-off-by: NValentine Barshak <valentine.barshak@cogentembedded.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

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: NMartin K. Petersen <martin.petersen@oracle.com>
Cc: stable@kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

After commit bcdde7e2 (sysfs: make __sysfs_remove_dir() recursive)
Mika Westerberg sees traces analogous to the one below in Thunderbolt
hot-remove testing:

 WARNING: CPU: 0 PID: 4 at fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()
 sysfs group ffffffff81c6f1e0 not found for kobject 'host7'
 Modules linked in:
 CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.12.0+ #13
 Hardware name:                  /D33217CK, BIOS GKPPT10H.86A.0042.2013.0422.1439 04/22/2013
 Workqueue: kacpi_hotplug acpi_hotplug_work_fn
  0000000000000009 ffff8801002459b0 ffffffff817daab1 ffff8801002459f8
  ffff8801002459e8 ffffffff810436b8 0000000000000000 ffffffff81c6f1e0
  ffff88006d440358 ffff88006d440188 ffff88006e8b4c28 ffff880100245a48
 Call Trace:
  [<ffffffff817daab1>] dump_stack+0x45/0x56
  [<ffffffff810436b8>] warn_slowpath_common+0x78/0xa0
  [<ffffffff81043727>] warn_slowpath_fmt+0x47/0x50
  [<ffffffff811ad319>] ? sysfs_get_dirent_ns+0x49/0x70
  [<ffffffff811ae526>] sysfs_remove_group+0xc6/0xd0
  [<ffffffff81432f7e>] dpm_sysfs_remove+0x3e/0x50
  [<ffffffff8142a0d0>] device_del+0x40/0x1b0
  [<ffffffff8142a24d>] device_unregister+0xd/0x20
  [<ffffffff8144131a>] scsi_remove_host+0xba/0x110
  [<ffffffff8145f526>] ata_host_detach+0xc6/0x100
  [<ffffffff8145f578>] ata_pci_remove_one+0x18/0x20
  [<ffffffff812e8f48>] pci_device_remove+0x28/0x60
  [<ffffffff8142d854>] __device_release_driver+0x64/0xd0
  [<ffffffff8142d8de>] device_release_driver+0x1e/0x30
  [<ffffffff8142d257>] bus_remove_device+0xf7/0x140
  [<ffffffff8142a1b1>] device_del+0x121/0x1b0
  [<ffffffff812e43d4>] pci_stop_bus_device+0x94/0xa0
  [<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
  [<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
  [<ffffffff812e44dd>] pci_stop_and_remove_bus_device+0xd/0x20
  [<ffffffff812fc743>] trim_stale_devices+0x73/0xe0
  [<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
  [<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
  [<ffffffff812fcb6e>] acpiphp_check_bridge+0x7e/0xd0
  [<ffffffff812fd90d>] hotplug_event+0xcd/0x160
  [<ffffffff812fd9c5>] hotplug_event_work+0x25/0x60
  [<ffffffff81316749>] acpi_hotplug_work_fn+0x17/0x22
  [<ffffffff8105cf3a>] process_one_work+0x17a/0x430
  [<ffffffff8105db29>] worker_thread+0x119/0x390
  [<ffffffff8105da10>] ? manage_workers.isra.25+0x2a0/0x2a0
  [<ffffffff81063a5d>] kthread+0xcd/0xf0
  [<ffffffff81063990>] ? kthread_create_on_node+0x180/0x180
  [<ffffffff817eb33c>] ret_from_fork+0x7c/0xb0
  [<ffffffff81063990>] ? kthread_create_on_node+0x180/0x180

The source of this problem is that SCSI hosts are removed from
ATA ports after calling ata_tport_delete() which removes the
port's sysfs directory, among other things.  Now, after commit
bcdde7e2, the sysfs directory is removed along with all of
its subdirectories that include the SCSI host's sysfs directory
and its subdirectories at this point.  Consequently, when
device_del() is finally called for any child device of the SCSI
host and tries to remove its "power" group (which is already
gone then), it triggers the above warning.

To make the warnings go away, change the removal ordering in
ata_port_detach() so that the SCSI host is removed from the
port before ata_tport_delete() is called.

References: https://bugzilla.kernel.org/show_bug.cgi?id=65281Reported-and-tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Tested with a DAWICONTROL DC-624e on 3.10.10
Signed-off-by: NSamir Benmendil <samir.benmendil@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Reviewed-by: NLevente Kurusa <levex@linux.com>
Cc: stable@vger.kernel.org

Since acpi_bus_get_device() returns plain int and not acpi_status,
ACPI_FAILURE() should not be used for checking its return value.  Fix
that.

tj: Dropped unused local variable @status from odd_can_poweroff().
    Reported by kbuild test bot.
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NAaron Lu <aaron.lu@intel.com>
Cc: linux-ide@vger.kernel.org
Cc: kbuild test robot <fengguang.wu@intel.com>

Apple's BIOS emulation forcibly disables MCP89 AHCI, eg. on Macbook7,1.
We can re-enable it, replacing the previous workaround of using
ata_generic.

tj: whitespace adjustments, dropped inline from is_mcp89_apple()
Signed-off-by: NJames Laird <jhl@mafipulation.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

Add the missing clk_disable_unprepare() before return from cf_init()
in the error handling case.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>