(Correction in this resend: fixed function name acer_sa5_271_workaround; fixed
 the always-true condition in the function; fixed description.)

On the Acer Switch Alpha 12 (model number: SA5-271), the internal SSD may not
get detected because the port_map and CAP.nr_ports combination causes the driver
to skip the port that is actually connected to the SSD. More specifically,
either all SATA ports are identified as DUMMY, or all ports get ``link down''
and never get up again.

This problem occurs occasionally. When this problem occurs, CAP may hold a
value of 0xC734FF00 or 0xC734FF01 and port_map may hold a value of 0x00 or 0x01.
When this problem does not occur, CAP holds a value of 0xC734FF02 and port_map
may hold a value of 0x07. Overriding the CAP value to 0xC734FF02 and port_map to
0x7 significantly reduces the occurrence of this problem.

Link: https://bugzilla.kernel.org/attachment.cgi?id=253091Signed-off-by: NSui Chen <suichen6@gmail.com>
Tested-by: NDamian Ivanov <damianatorrpm@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTejun Heo <tj@kernel.org>

Some Intel ahci implementations have a completely broken remapping mode
where they hide one or more NVMe devices behind the bar of an AHCI device.

Intel refuses to let the OS reprogram the BIOS to switch out of this
mode at runtime, and so far we're not come up with another good way
to undo the mess that the Chipset people created.  So for now the only
thing we can do is to alert users about this situation and switch to the
faster and much saner so called "AHCI" mode insted of the RAID mode in
the BIOS so that the BIOS does not hide the NVMe devices from us.

The sitation is even worse as at least one vendor (thanks a lot Lenovo..)
has started hardcoding their BIOS into the "RAID" mode even for laptops
that don't use AHCI _at all_ and just have a single NVMe device.  For now
there is an unspported Linux-only BIOS that undoes this braindamage,
but we'll have to see if things are getting better or worse from here.

Based on an earlier patch from Dan Williams <dan.j.williams@intel.com>.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NTejun Heo <tj@kernel.org>

Don't try to guess what the errors from pci_irq_alloc_vectors mean, as
that's too fragile.  Instead always try allocating a single vector
when multi-MSI mode fails.  This makes various intel Desktop and
Laptop CPUs use MSI again.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reported-by: NMichael Marley <michael@michaelmarley.com>
Tested-by: NMichael Marley <michael@michaelmarley.com>
Fixes: 0b9e2988 ("ahci: use pci_alloc_irq_vectors")
Signed-off-by: NTejun Heo <tj@kernel.org>

We need to make sure hpriv->irq is set properly if we don't use per-port
vectors, so switch from blindly assigning pdev->irq to using
pci_irq_vector, which handles all interrupt types correctly.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reported-by: NRobert Richter <robert.richter@cavium.com>
Tested-by: NRobert Richter <robert.richter@cavium.com>
Tested-by: NDavid Daney <ddaney.cavm@gmail.com>
Fixes: 0b9e2988 ("ahci: use pci_alloc_irq_vectors")
Signed-off-by: NTejun Heo <tj@kernel.org>

commit 17a51f12 ("ahci: only try to use multi-MSI mode if there is more
than 1 port") lead to a case where nvec isn't initialized before it's
used.  Fix this by moving the check into the n_ports conditional.

Reported-and-reviewed-by Colin Ian King <colin.king@canonical.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NTejun Heo <tj@kernel.org>

We should only try to allocate multiple MSI or MSI-X vectors if the device
actually has multiple ports.  Otherwise pci_alloc_irq_vectors will return
a single vector due to n_ports = 1, in which case we shouldn't set the
AHCI_HFLAG_MULTI_MSI flag.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Fixes: 0b9e2988 ("ahci: use pci_alloc_irq_vectors")
Reported-by: NEmmanuel Benisty <benisty.e@gmail.com>
Tested-by: NEmmanuel Benisty <benisty.e@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Use the new pci_alloc_irq_vectors API to allocate MSI-X and MSI vectors.
The big advantage over the old code is that we can use the same API for
MSI and MSI-X, and that we don't need to store the MSI-X vector mapping
in driver-private data structures.

This first conversion keeps the probe order as-is: MSI-X multi vector,
MSI multi vector, MSI single vector, MSI-X single vector and last a
single least legacy interrupt line.  There is one small change of
behavior: we now check the "MSI Revert to Single Message" flag for
MSI-X in addition to MSI.

Because the API to find the Linux IRQ number for a MSI/MSI-X vector
is PCI specific, but libahaci is bus-agnostic I had to a
get_irq_vector function pointer to struct ahci_host_priv.  The
alternative would be to move the multi-vector case of ahci_host_activate
to ahci.c and just call ata_host_activate directly from the others
users of ahci_host_activate.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NTejun Heo <tj@kernel.org>

The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
built-in or as a module, use that macro instead of open coding the same.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

These PCI device IDs have been removed from the Intel Lewisburg design
specification. They are no longer needed.
Signed-off-by: NScott Lawson <scott.lawson@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Due to Errata in ThunderX, HOST_IRQ_STAT should be
cleared before leaving the interrupt handler.
The patch attempts to satisfy the need.

Changes from V2:
	- removed newfile
	- code is now under CONFIG_ARM64

Changes from V1:
	- Rebased on top of libata/for-4.6
        - Moved ThunderX intr handler to new file

tj: Minor adjustments to comments.
Signed-off-by: NTirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch adds runtime PM support for the AHCI host controller driver so
that the host controller is powered down when all SATA ports are runtime
suspended. Powering down the AHCI host controller can reduce power
consumption and possibly allow the CPU to enter lower power idle states
(S0ix) during runtime.

Runtime PM is blocked by default and needs to be unblocked from userspace
as needed (via power/* sysfs nodes).
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

In order to add support for runtime PM to the ahci driver we first need to
convert the driver to use modern non-legacy system suspend hooks. There
should be no functional changes.

tj: Updated .driver.pm init for older compilers as suggested by Andy
    and Chrsitoph.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch complements the list of device IDs previously
added for lewisburg sata.
Signed-off-by: NAlexandra Yates <alexandra.yates@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

Adding Intel codename DNV platform device IDs for SATA.
Signed-off-by: NAlexandra Yates <alexandra.yates@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

Some AHCI controllers support per-port MSI-X vectors.  At the same time
the Linux AHCI driver needs to support one-off architectures that
implement a single MSI-X vector for all ports.  The heuristic for
enabling AHCI ports becomes, in order of preference:

1/ per-port multi-MSI-X

2/ per-port multi-MSI

3/ single MSI

4/ single MSI-X

5/ legacy INTX

This all depends on AHCI implementations with potentially broken MSI-X
requesting less vectors than the number of ports.  If this assumption is
violated we will need to start explicitly white-listing AHCI-MSIX
implementations.
Reported-by: NRicardo Neri <ricardo.neri@intel.com>
[ricardo: fix struct msix_entry handling]
Reported-by: Nkernel test robot <ying.huang@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This change was to preserve the ascending order of device IDs.
There was an exception with the first two Lewisburg device IDs to
keep all device IDs of the same kind grouped by code name.
Signed-off-by: NAlexandra Yates <alexandra.yates@linux.intel.com>
signed-off-by: NTejun Heo <tj@kernel.org>

This patch adds missing AHCI RAID SATA Device IDs for the Intel Sunrise
Point PCH.
Signed-off-by: NNanda Kishore Chinna <nanda_kishore_chinna@dell.com>
Signed-off-by: NCharles Rose <charles_rose@dell.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Adding Intel codename Lewisburg platform device IDs for SATA.
Signed-off-by: NAlexandra Yates <alexandra.yates@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Add device id for Marvell 88se91a2
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NTejun Heo <tj@kernel.org>

On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
function 1 doesn't work if it is powered on before the SATA controller at
function 0.  The result is that PATA doesn't work after resume, and we
print messages like this:

  pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
  irq 17: nobody cared (try booting with the "irqpoll" option)

Async resume was introduced in v3.15 by 76569faa ("PM / sleep:
Asynchronous threads for resume_noirq").  Prior to that, we powered on
the functions in order, so this problem shouldn't happen.

e6b7e41c ("ata: Disabling the async PM for JMicron chip 363/361")
solved the problem for JMicron 361 and 363 devices.  With async suspend
disabled, we always power on function 0 before function 1.

Barto then reported the same problem with a JMicron 368 (see comment #57 in
the bugzilla).

Rather than extending the blacklist piecemeal, disable async suspend for
all JMicron multi-function SATA/PATA/AHCI devices.

This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
the problem will occur even if pata_jmicron isn't loaded until after the
suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
power-on order even if the drivers aren't loaded.

[bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551Reported-and-tested-by: NBarto <mister.freeman@laposte.net>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.15+

It turned out the irq vector of the msix can be obtained from struct
msix_entry. This makes the lookup function for msi_desc obsolete.

This fixes a build error if PCI_MSI is unset:

 drivers/ata/ahci.c: In function ‘msix_get_desc’:
 drivers/ata/ahci.c:1210:2: error: ‘struct pci_dev’ has no member named ‘msi_list’

Catched by Fengguang's build bot.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NRobert Richter <rrichter@cavium.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch adds support for Cavium's ThunderX host controller. The
controller resides on the SoC and is a AHCI compatible SATA controller
with one port, compliant with Serial ATA 3.1 and AHCI Revision 1.31.
There can exists multiple SATA controllers on the SoC.

The controller depends on MSI-X support since the PCI ECAM controller
on the SoC does not implement MSI nor lagacy intx interrupt support.
Thus, during device initialization, if MSI fails MSI-X will be used to
enable the device's interrupts.

The controller uses non-standard BAR0 for its register range. The
already existing device lookup (vendor and device id) that is already
implemented for other host controllers is used to change the PCI BAR.
Signed-off-by: NRobert Richter <rrichter@cavium.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch adds generic MSI-X support for single interrupts to the
SATA PCI driver. MSI-X support is needed for host controller that only
have MSI-X support implemented, but no MSI or intx. This patch only
adds support for single interrupts, multiple per-port MSI-X interrupts
are not yet implemented.

The new implementation still initializes MSIs first. Only if that
fails, the code tries to enable MSI-X. If that fails too, setup is
continued with intx interrupts.

To not break other chips by this generic code change, there are the
following precautions:

 * Interrupt ranges are not enabled at all.

 * Only single interrupt mode is enabled for msix cap devices. Thus,
   only one interrupt will be setup.

 * During the discussion with Tejun we agreed to change the init
   sequence from msix-msi-intx to msi-msix-intx. Thus, if a device
   offers msi and init does not fail, the msix init code will not be
   executed. This is equivalent to current code.

With this, the code only setups single mode msix as a last resort if
msi fails. No interrupt range is enabled at all. Only one interrupt
will be enabled.

tj: comment edits.

Changes of the patch series:

v5:
 * updated patch subject that the patch only implements single IRQ
 * moved Cavium specific code to a separate patch
 * detect Cavium ThunderX device with PCI_CLASS_STORAGE_SATA_AHCI
   instead of vendor/dev id
 * added more comments to the code
 * enable single msix support for all kind of devices (removing strict
   check)
 * rebased onto update libata/for-4.2 with patch 1, 2 applied

v4:
 * removed implementation of ahci_init_intx()
 * improved patch descriptions
 * rebased onto libata/for-4.2

v3:
 * store irq number in struct ahci_host_priv
 * change initialization order from msix-msi-intx to msi-msix-intx
 * improve comments in ahci_init_msix()
 * improve error message in ahci_init_msix()
 * do not enable MSI-X if MSI is actively disabled for the device

v2:
 * determine irq vector from pci_dev->msi_list

Based on a patch from Sunil Goutham <sgoutham@cavium.com>.
Signed-off-by: NRobert Richter <rrichter@cavium.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Currently, ahci supports only msi and intx. To also support msix the
handling of the irq number need to be changed. The irq number for msix
devices is taken from msi_list instead of pci_dev. Thus, the irq
number of a device needs to be stored in struct ahci_host_priv now.
This allows the host controller to be activated in a generic way.

This change is only intended for ahci drivers. For that reason the irq
number is stored in struct ahci_host_priv used only by ahci drivers.
Thus, the ABI changes only for ahci_host_activate(), but existing ata
drivers (about 50) are unaffected and keep unchanged. All users of
ahci_host_activate() have been updated.

While touching drivers/ata/libahci.c, doing a small code cleanup in
ahci_port_start().
Signed-off-by: NRobert Richter <rrichter@cavium.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch refactors ahci_init_interrupts() and moves msi code to a
separate function. Need the split since we add msix initialization in
a later patch. The initialization for msix will be done after msi but
before intx.
Signed-off-by: NRobert Richter <rrichter@cavium.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

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.

Cc: <stable@vger.kernel.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Replace occurences of the pci api by appropriate call to the dma api.

A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr)

@deprecated@
idexpression id;
position p;
@@

(
  pci_dma_supported@p ( id, ...)
|
  pci_alloc_consistent@p ( id, ...)
)

@bad1@
idexpression id;
position deprecated.p;
@@
...when != &id->dev
   when != pci_get_drvdata ( id )
   when != pci_enable_device ( id )
(
  pci_dma_supported@p ( id, ...)
|
  pci_alloc_consistent@p ( id, ...)
)

@depends on !bad1@
idexpression id;
expression direction;
position deprecated.p;
@@

(
- pci_dma_supported@p ( id,
+ dma_supported ( &id->dev,
...
+ , GFP_ATOMIC
  )
|
- pci_alloc_consistent@p ( id,
+ dma_alloc_coherent ( &id->dev,
...
+ , GFP_ATOMIC
  )
)
Signed-off-by: NQuentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch removes a duplicate AHCI-mode SATA Device ID for the Intel Sunrise Point PCH.
Signed-off-by: NJames Ralston <james.d.ralston@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Just like 0x1600 which got blacklisted by 66a7cbc3 ("ahci: disable
MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes
on NCQ commands if MSI is enabled.  Disable MSI.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NDominik Mierzejewski <dominik@greysector.net>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171
Cc: stable@vger.kernel.org

This patch adds DeviceIDs for Sunrise Point-LP.
Signed-off-by: NDevin Ryles <devin.ryles@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

Changes into the AHCI subsystem have introduced a bug by not taking into
account the force_port_map and mask_port_map parameters when using the
ahci_pci_save_initial_config function. This commit fixes it by setting
the internal parameters of the ahci_port_priv structure.

Fixes: 725c7b57Reported-and-tested-by: NZlatko Calusic <zcalusic@bitsync.net>
Signed-off-by: NAntoine Tenart <antoine.tenart@free-electrons.com>

This patch adds the AHCI-mode SATA Device IDs for the Intel Sunrise Point PCH.
Signed-off-by: NJames Ralston <james.d.ralston@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

Samsung pci-e SSDs on macbooks failed miserably on NCQ commands, so
67809f85 ("ahci: disable NCQ on Samsung pci-e SSDs on macbooks")
disabled NCQ on them.  It turns out that NCQ is fine as long as MSI is
not used, so let's turn off MSI and leave NCQ on.
Signed-off-by: NTejun Heo <tj@kernel.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=60731
Tested-by: <dorin@i51.org>
Tested-by: NImre Kaloz <kaloz@openwrt.org>
Cc: stable@vger.kernel.org
Fixes: 67809f85 ("ahci: disable NCQ on Samsung pci-e SSDs on macbooks")

Currently host activation done by calling either function
ahci_host_activate() or ata_host_activate(). Consolidate
the code by only calling ahci_host_activate() for all AHCI
devices.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org

This update is a prerequisite for consolidation of
AHCI host activation code within ahci_host_activate()
function.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org

This update is a prerequisite for consolidation of
AHCI host activation code within ahci_host_activate()
function.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org

Sharing Last Message (SLM) mode is currently checked in two
functions: ahci_host_activate() and ahci_init_interrupts().
This update consolidates SLM mode check with activation of
multiple MSIs mode.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org

Keystone K2E EVM uses Marvel 0x9182 controller. This requires support
for the ID in the ahci driver.
Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: stable@vger.kernel.org

After enabled the PM feature that supporting async noirq(76569faa
(PM / sleep: Asynchronous threads for resume_noirq)),
Jay hit the system resuming issue, that one of the JMicron controller
can not be powered up.

His device tree is like below:
             +-1c.4-[02]--+-00.0  JMicron Technology Corp. JMB363 SATA/IDE Controller
             |            \-00.1  JMicron Technology Corp. JMB363 SATA/IDE Controller

After investigation, we found the the Micron chip 363 included
one SATA controller(0000:02:00.0) and one PATA controller(0000:02:00.1),
these two controllers do not have parent-children relationship,
but the PATA controller only can be powered on after the SATA controller
has finished the powering on.

If we enabled the async noirq(), then the below error is hit during noirq
phase:
pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3

Here for JMicron chip 363/361, we need forcedly to disable the async method.

Bug detail: https://bugzilla.kernel.org/show_bug.cgi?id=81551Reported-by: NJay <MyMailClone@t-online.de>
Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The DMI table does not need to be written to, make it r/o.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>