2019-05-19 21:51:48 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* ahci.c - AHCI SATA support
|
|
|
|
|
*
|
2013-05-15 02:09:50 +08:00
|
|
|
* Maintained by: Tejun Heo <tj@kernel.org>
|
2005-08-29 08:18:39 +08:00
|
|
|
* Please ALWAYS copy linux-ide@vger.kernel.org
|
|
|
|
|
* on emails.
|
|
|
|
|
*
|
|
|
|
|
* Copyright 2004-2005 Red Hat, Inc.
|
|
|
|
|
*
|
|
|
|
|
* libata documentation is available via 'make {ps|pdf}docs',
|
2017-05-14 22:52:56 +08:00
|
|
|
* as Documentation/driver-api/libata.rst
|
2005-08-29 08:18:39 +08:00
|
|
|
*
|
|
|
|
|
* AHCI hardware documentation:
|
2005-04-17 06:20:36 +08:00
|
|
|
* http://www.intel.com/technology/serialata/pdf/rev1_0.pdf
|
2005-08-29 08:18:39 +08:00
|
|
|
* http://www.intel.com/technology/serialata/pdf/rev1_1.pdf
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/pci.h>
|
|
|
|
|
#include <linux/blkdev.h>
|
|
|
|
|
#include <linux/delay.h>
|
|
|
|
|
#include <linux/interrupt.h>
|
2005-04-08 15:53:06 +08:00
|
|
|
#include <linux/dma-mapping.h>
|
2005-10-31 03:39:11 +08:00
|
|
|
#include <linux/device.h>
|
2007-10-25 13:59:16 +08:00
|
|
|
#include <linux/dmi.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/gfp.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <scsi/scsi_host.h>
|
2005-11-07 13:59:37 +08:00
|
|
|
#include <scsi/scsi_cmnd.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/libata.h>
|
2016-12-03 02:31:03 +08:00
|
|
|
#include <linux/ahci-remap.h>
|
|
|
|
|
#include <linux/io-64-nonatomic-lo-hi.h>
|
2010-03-28 12:22:14 +08:00
|
|
|
#include "ahci.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
#define DRV_NAME "ahci"
|
2007-09-23 12:19:54 +08:00
|
|
|
#define DRV_VERSION "3.0"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
enum {
|
2012-01-06 20:33:39 +08:00
|
|
|
AHCI_PCI_BAR_STA2X11 = 0,
|
2015-06-06 01:49:26 +08:00
|
|
|
AHCI_PCI_BAR_CAVIUM = 0,
|
2020-03-10 20:50:08 +08:00
|
|
|
AHCI_PCI_BAR_LOONGSON = 0,
|
2013-01-05 06:39:09 +08:00
|
|
|
AHCI_PCI_BAR_ENMOTUS = 2,
|
2017-10-11 13:37:51 +08:00
|
|
|
AHCI_PCI_BAR_CAVIUM_GEN5 = 4,
|
2012-01-06 20:33:39 +08:00
|
|
|
AHCI_PCI_BAR_STANDARD = 5,
|
2010-03-29 09:32:39 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum board_ids {
|
|
|
|
|
/* board IDs by feature in alphabetical order */
|
|
|
|
|
board_ahci,
|
ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
observed that was immediately preceded by the following kernel
messages:
ahci 0000:28:00.0: Using 64-bit DMA addresses
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
The first message is produced by code in drivers/iommu/dma-iommu.c
which is accompanied by the following comment that seems to apply:
/*
* Try to use all the 32-bit PCI addresses first. The original SAC vs.
* DAC reasoning loses relevance with PCIe, but enough hardware and
* firmware bugs are still lurking out there that it's safest not to
* venture into the 64-bit space until necessary.
*
* If your device goes wrong after seeing the notice then likely either
* its driver is not setting DMA masks accurately, the hardware has
* some inherent bug in handling >32-bit addresses, or not all the
* expected address bits are wired up between the device and the IOMMU.
*/
Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
address 0xffffffff00000000 produces the following I/O page faults:
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
Note that the upper 21 bits of the logged DMA address are zero. (When
asking a different PCIe device in the same PCIe slot to DMA to the
same I/O virtual address, we do see all the upper 32 bits of the DMA
address as 1, so this is not an issue with the chipset or IOMMU
configuration on the test system.)
Also, hacking libahci to always set the upper 21 bits of all DMA
addresses to 1 produces no discernible effect on the behavior of the
ASM1061, and mkfs/mount/scrub/etc work as without this hack.
This all strongly suggests that the ASM1061 has a 43 bit DMA address
limit, and this commit therefore adds a quirk to deal with this limit.
This issue probably applies to (some of) the other supported ASMedia
parts as well, but we limit it to the PCI IDs known to refer to
ASM1061 parts, as that's the only part we know for sure to be affected
by this issue at this point.
Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
[cassel: drop date from error messages in commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-01-25 23:04:01 +08:00
|
|
|
board_ahci_43bit_dma,
|
2010-03-29 09:32:39 +08:00
|
|
|
board_ahci_ign_iferr,
|
2022-01-05 23:36:18 +08:00
|
|
|
board_ahci_no_debounce_delay,
|
2024-02-14 21:00:12 +08:00
|
|
|
board_ahci_no_msi,
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
/*
|
|
|
|
|
* board_ahci_pcs_quirk is for legacy Intel platforms.
|
|
|
|
|
* Modern Intel platforms should use board_ahci instead.
|
|
|
|
|
* (Some modern Intel platforms might have been added with
|
|
|
|
|
* board_ahci_pcs_quirk, however, we cannot change them to board_ahci
|
|
|
|
|
* without testing that the platform actually works without the quirk.)
|
|
|
|
|
*/
|
|
|
|
|
board_ahci_pcs_quirk,
|
2024-02-14 21:00:10 +08:00
|
|
|
board_ahci_pcs_quirk_no_devslp,
|
2024-02-14 21:00:09 +08:00
|
|
|
board_ahci_pcs_quirk_no_sntf,
|
2010-07-24 22:53:48 +08:00
|
|
|
board_ahci_yes_fbs,
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-03-29 09:32:39 +08:00
|
|
|
/* board IDs for specific chipsets in alphabetical order */
|
2019-10-17 22:46:53 +08:00
|
|
|
board_ahci_al,
|
2015-05-09 03:23:55 +08:00
|
|
|
board_ahci_avn,
|
2010-03-29 09:32:39 +08:00
|
|
|
board_ahci_mcp65,
|
2010-03-30 09:28:32 +08:00
|
|
|
board_ahci_mcp77,
|
|
|
|
|
board_ahci_mcp89,
|
2010-03-29 09:32:39 +08:00
|
|
|
board_ahci_mv,
|
|
|
|
|
board_ahci_sb600,
|
|
|
|
|
board_ahci_sb700, /* for SB700 and SB800 */
|
|
|
|
|
board_ahci_vt8251,
|
|
|
|
|
|
|
|
|
|
/* aliases */
|
|
|
|
|
board_ahci_mcp_linux = board_ahci_mcp65,
|
|
|
|
|
board_ahci_mcp67 = board_ahci_mcp65,
|
|
|
|
|
board_ahci_mcp73 = board_ahci_mcp65,
|
2010-03-30 09:28:32 +08:00
|
|
|
board_ahci_mcp79 = board_ahci_mcp77,
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
2007-10-19 18:42:56 +08:00
|
|
|
static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
|
2016-02-18 16:54:17 +08:00
|
|
|
static void ahci_remove_one(struct pci_dev *dev);
|
2020-01-25 11:37:29 +08:00
|
|
|
static void ahci_shutdown_one(struct pci_dev *dev);
|
2022-12-09 17:26:34 +08:00
|
|
|
static void ahci_intel_pcs_quirk(struct pci_dev *pdev, struct ahci_host_priv *hpriv);
|
libata: make reset related methods proper port operations
Currently reset methods are not specified directly in the
ata_port_operations table. If a LLD wants to use custom reset
methods, it should construct and use a error_handler which uses those
reset methods. It's done this way for two reasons.
First, the ops table already contained too many methods and adding
four more of them would noticeably increase the amount of necessary
boilerplate code all over low level drivers.
Second, as ->error_handler uses those reset methods, it can get
confusing. ie. By overriding ->error_handler, those reset ops can be
made useless making layering a bit hazy.
Now that ops table uses inheritance, the first problem doesn't exist
anymore. The second isn't completely solved but is relieved by
providing default values - most drivers can just override what it has
implemented and don't have to concern itself about higher level
callbacks. In fact, there currently is no driver which actually
modifies error handling behavior. Drivers which override
->error_handler just wraps the standard error handler only to prepare
the controller for EH. I don't think making ops layering strict has
any noticeable benefit.
This patch makes ->prereset, ->softreset, ->hardreset, ->postreset and
their PMP counterparts propoer ops. Default ops are provided in the
base ops tables and drivers are converted to override individual reset
methods instead of creating custom error_handler.
* ata_std_error_handler() doesn't use sata_std_hardreset() if SCRs
aren't accessible. sata_promise doesn't need to use separate
error_handlers for PATA and SATA anymore.
* softreset is broken for sata_inic162x and sata_sx4. As libata now
always prefers hardreset, this doesn't really matter but the ops are
forced to NULL using ATA_OP_NULL for documentation purpose.
* pata_hpt374 needs to use different prereset for the first and second
PCI functions. This used to be done by branching from
hpt374_error_handler(). The proper way to do this is to use
separate ops and port_info tables for each function. Converted.
Signed-off-by: Tejun Heo <htejun@gmail.com>
2008-03-25 11:22:50 +08:00
|
|
|
static int ahci_vt8251_hardreset(struct ata_link *link, unsigned int *class,
|
|
|
|
|
unsigned long deadline);
|
2015-05-09 03:23:55 +08:00
|
|
|
static int ahci_avn_hardreset(struct ata_link *link, unsigned int *class,
|
|
|
|
|
unsigned long deadline);
|
2013-11-19 08:06:38 +08:00
|
|
|
static void ahci_mcp89_apple_enable(struct pci_dev *pdev);
|
|
|
|
|
static bool is_mcp89_apple(struct pci_dev *pdev);
|
libata: make reset related methods proper port operations
Currently reset methods are not specified directly in the
ata_port_operations table. If a LLD wants to use custom reset
methods, it should construct and use a error_handler which uses those
reset methods. It's done this way for two reasons.
First, the ops table already contained too many methods and adding
four more of them would noticeably increase the amount of necessary
boilerplate code all over low level drivers.
Second, as ->error_handler uses those reset methods, it can get
confusing. ie. By overriding ->error_handler, those reset ops can be
made useless making layering a bit hazy.
Now that ops table uses inheritance, the first problem doesn't exist
anymore. The second isn't completely solved but is relieved by
providing default values - most drivers can just override what it has
implemented and don't have to concern itself about higher level
callbacks. In fact, there currently is no driver which actually
modifies error handling behavior. Drivers which override
->error_handler just wraps the standard error handler only to prepare
the controller for EH. I don't think making ops layering strict has
any noticeable benefit.
This patch makes ->prereset, ->softreset, ->hardreset, ->postreset and
their PMP counterparts propoer ops. Default ops are provided in the
base ops tables and drivers are converted to override individual reset
methods instead of creating custom error_handler.
* ata_std_error_handler() doesn't use sata_std_hardreset() if SCRs
aren't accessible. sata_promise doesn't need to use separate
error_handlers for PATA and SATA anymore.
* softreset is broken for sata_inic162x and sata_sx4. As libata now
always prefers hardreset, this doesn't really matter but the ops are
forced to NULL using ATA_OP_NULL for documentation purpose.
* pata_hpt374 needs to use different prereset for the first and second
PCI functions. This used to be done by branching from
hpt374_error_handler(). The proper way to do this is to use
separate ops and port_info tables for each function. Converted.
Signed-off-by: Tejun Heo <htejun@gmail.com>
2008-03-25 11:22:50 +08:00
|
|
|
static int ahci_p5wdh_hardreset(struct ata_link *link, unsigned int *class,
|
|
|
|
|
unsigned long deadline);
|
2016-02-18 16:54:17 +08:00
|
|
|
#ifdef CONFIG_PM
|
|
|
|
|
static int ahci_pci_device_runtime_suspend(struct device *dev);
|
|
|
|
|
static int ahci_pci_device_runtime_resume(struct device *dev);
|
2016-02-18 16:54:15 +08:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
|
static int ahci_pci_device_suspend(struct device *dev);
|
|
|
|
|
static int ahci_pci_device_resume(struct device *dev);
|
2007-03-02 16:31:26 +08:00
|
|
|
#endif
|
2016-02-18 16:54:17 +08:00
|
|
|
#endif /* CONFIG_PM */
|
2006-11-01 17:00:24 +08:00
|
|
|
|
2023-03-23 03:53:59 +08:00
|
|
|
static const struct scsi_host_template ahci_sht = {
|
2010-09-21 15:25:48 +08:00
|
|
|
AHCI_SHT("ahci"),
|
|
|
|
|
};
|
|
|
|
|
|
libata: implement and use ops inheritance
libata lets low level drivers build ata_port_operations table and
register it with libata core layer. This allows low level drivers
high level of flexibility but also burdens them with lots of
boilerplate entries.
This becomes worse for drivers which support related similar
controllers which differ slightly. They share most of the operations
except for a few. However, the driver still needs to list all
operations for each variant. This results in large number of
duplicate entries, which is not only inefficient but also error-prone
as it becomes very difficult to tell what the actual differences are.
This duplicate boilerplates all over the low level drivers also make
updating the core layer exteremely difficult and error-prone. When
compounded with multi-branched development model, it ends up
accumulating inconsistencies over time. Some of those inconsistencies
cause immediate problems and fixed. Others just remain there dormant
making maintenance increasingly difficult.
To rectify the problem, this patch implements ata_port_operations
inheritance. To allow LLDs to easily re-use their own ops tables
overriding only specific methods, this patch implements poor man's
class inheritance. An ops table has ->inherits field which can be set
to any ops table as long as it doesn't create a loop. When the host
is started, the inheritance chain is followed and any operation which
isn't specified is taken from the nearest ancestor which has it
specified. This operation is called finalization and done only once
per an ops table and the LLD doesn't have to do anything special about
it other than making the ops table non-const such that libata can
update it.
libata provides four base ops tables lower drivers can inherit from -
base, sata, pmp, sff and bmdma. To avoid overriding these ops
accidentaly, these ops are declared const and LLDs should always
inherit these instead of using them directly.
After finalization, all the ops table are identical before and after
the patch except for setting .irq_handler to ata_interrupt in drivers
which didn't use to. The .irq_handler doesn't have any actual effect
and the field will soon be removed by later patch.
* sata_sx4 is still using old style EH and currently doesn't take
advantage of ops inheritance.
Signed-off-by: Tejun Heo <htejun@gmail.com>
2008-03-25 11:22:49 +08:00
|
|
|
static struct ata_port_operations ahci_vt8251_ops = {
|
|
|
|
|
.inherits = &ahci_ops,
|
libata: make reset related methods proper port operations
Currently reset methods are not specified directly in the
ata_port_operations table. If a LLD wants to use custom reset
methods, it should construct and use a error_handler which uses those
reset methods. It's done this way for two reasons.
First, the ops table already contained too many methods and adding
four more of them would noticeably increase the amount of necessary
boilerplate code all over low level drivers.
Second, as ->error_handler uses those reset methods, it can get
confusing. ie. By overriding ->error_handler, those reset ops can be
made useless making layering a bit hazy.
Now that ops table uses inheritance, the first problem doesn't exist
anymore. The second isn't completely solved but is relieved by
providing default values - most drivers can just override what it has
implemented and don't have to concern itself about higher level
callbacks. In fact, there currently is no driver which actually
modifies error handling behavior. Drivers which override
->error_handler just wraps the standard error handler only to prepare
the controller for EH. I don't think making ops layering strict has
any noticeable benefit.
This patch makes ->prereset, ->softreset, ->hardreset, ->postreset and
their PMP counterparts propoer ops. Default ops are provided in the
base ops tables and drivers are converted to override individual reset
methods instead of creating custom error_handler.
* ata_std_error_handler() doesn't use sata_std_hardreset() if SCRs
aren't accessible. sata_promise doesn't need to use separate
error_handlers for PATA and SATA anymore.
* softreset is broken for sata_inic162x and sata_sx4. As libata now
always prefers hardreset, this doesn't really matter but the ops are
forced to NULL using ATA_OP_NULL for documentation purpose.
* pata_hpt374 needs to use different prereset for the first and second
PCI functions. This used to be done by branching from
hpt374_error_handler(). The proper way to do this is to use
separate ops and port_info tables for each function. Converted.
Signed-off-by: Tejun Heo <htejun@gmail.com>
2008-03-25 11:22:50 +08:00
|
|
|
.hardreset = ahci_vt8251_hardreset,
|
libata: implement and use ops inheritance
libata lets low level drivers build ata_port_operations table and
register it with libata core layer. This allows low level drivers
high level of flexibility but also burdens them with lots of
boilerplate entries.
This becomes worse for drivers which support related similar
controllers which differ slightly. They share most of the operations
except for a few. However, the driver still needs to list all
operations for each variant. This results in large number of
duplicate entries, which is not only inefficient but also error-prone
as it becomes very difficult to tell what the actual differences are.
This duplicate boilerplates all over the low level drivers also make
updating the core layer exteremely difficult and error-prone. When
compounded with multi-branched development model, it ends up
accumulating inconsistencies over time. Some of those inconsistencies
cause immediate problems and fixed. Others just remain there dormant
making maintenance increasingly difficult.
To rectify the problem, this patch implements ata_port_operations
inheritance. To allow LLDs to easily re-use their own ops tables
overriding only specific methods, this patch implements poor man's
class inheritance. An ops table has ->inherits field which can be set
to any ops table as long as it doesn't create a loop. When the host
is started, the inheritance chain is followed and any operation which
isn't specified is taken from the nearest ancestor which has it
specified. This operation is called finalization and done only once
per an ops table and the LLD doesn't have to do anything special about
it other than making the ops table non-const such that libata can
update it.
libata provides four base ops tables lower drivers can inherit from -
base, sata, pmp, sff and bmdma. To avoid overriding these ops
accidentaly, these ops are declared const and LLDs should always
inherit these instead of using them directly.
After finalization, all the ops table are identical before and after
the patch except for setting .irq_handler to ata_interrupt in drivers
which didn't use to. The .irq_handler doesn't have any actual effect
and the field will soon be removed by later patch.
* sata_sx4 is still using old style EH and currently doesn't take
advantage of ops inheritance.
Signed-off-by: Tejun Heo <htejun@gmail.com>
2008-03-25 11:22:49 +08:00
|
|
|
};
|
2007-10-25 13:59:16 +08:00
|
|
|
|
libata: implement and use ops inheritance
libata lets low level drivers build ata_port_operations table and
register it with libata core layer. This allows low level drivers
high level of flexibility but also burdens them with lots of
boilerplate entries.
This becomes worse for drivers which support related similar
controllers which differ slightly. They share most of the operations
except for a few. However, the driver still needs to list all
operations for each variant. This results in large number of
duplicate entries, which is not only inefficient but also error-prone
as it becomes very difficult to tell what the actual differences are.
This duplicate boilerplates all over the low level drivers also make
updating the core layer exteremely difficult and error-prone. When
compounded with multi-branched development model, it ends up
accumulating inconsistencies over time. Some of those inconsistencies
cause immediate problems and fixed. Others just remain there dormant
making maintenance increasingly difficult.
To rectify the problem, this patch implements ata_port_operations
inheritance. To allow LLDs to easily re-use their own ops tables
overriding only specific methods, this patch implements poor man's
class inheritance. An ops table has ->inherits field which can be set
to any ops table as long as it doesn't create a loop. When the host
is started, the inheritance chain is followed and any operation which
isn't specified is taken from the nearest ancestor which has it
specified. This operation is called finalization and done only once
per an ops table and the LLD doesn't have to do anything special about
it other than making the ops table non-const such that libata can
update it.
libata provides four base ops tables lower drivers can inherit from -
base, sata, pmp, sff and bmdma. To avoid overriding these ops
accidentaly, these ops are declared const and LLDs should always
inherit these instead of using them directly.
After finalization, all the ops table are identical before and after
the patch except for setting .irq_handler to ata_interrupt in drivers
which didn't use to. The .irq_handler doesn't have any actual effect
and the field will soon be removed by later patch.
* sata_sx4 is still using old style EH and currently doesn't take
advantage of ops inheritance.
Signed-off-by: Tejun Heo <htejun@gmail.com>
2008-03-25 11:22:49 +08:00
|
|
|
static struct ata_port_operations ahci_p5wdh_ops = {
|
|
|
|
|
.inherits = &ahci_ops,
|
libata: make reset related methods proper port operations
Currently reset methods are not specified directly in the
ata_port_operations table. If a LLD wants to use custom reset
methods, it should construct and use a error_handler which uses those
reset methods. It's done this way for two reasons.
First, the ops table already contained too many methods and adding
four more of them would noticeably increase the amount of necessary
boilerplate code all over low level drivers.
Second, as ->error_handler uses those reset methods, it can get
confusing. ie. By overriding ->error_handler, those reset ops can be
made useless making layering a bit hazy.
Now that ops table uses inheritance, the first problem doesn't exist
anymore. The second isn't completely solved but is relieved by
providing default values - most drivers can just override what it has
implemented and don't have to concern itself about higher level
callbacks. In fact, there currently is no driver which actually
modifies error handling behavior. Drivers which override
->error_handler just wraps the standard error handler only to prepare
the controller for EH. I don't think making ops layering strict has
any noticeable benefit.
This patch makes ->prereset, ->softreset, ->hardreset, ->postreset and
their PMP counterparts propoer ops. Default ops are provided in the
base ops tables and drivers are converted to override individual reset
methods instead of creating custom error_handler.
* ata_std_error_handler() doesn't use sata_std_hardreset() if SCRs
aren't accessible. sata_promise doesn't need to use separate
error_handlers for PATA and SATA anymore.
* softreset is broken for sata_inic162x and sata_sx4. As libata now
always prefers hardreset, this doesn't really matter but the ops are
forced to NULL using ATA_OP_NULL for documentation purpose.
* pata_hpt374 needs to use different prereset for the first and second
PCI functions. This used to be done by branching from
hpt374_error_handler(). The proper way to do this is to use
separate ops and port_info tables for each function. Converted.
Signed-off-by: Tejun Heo <htejun@gmail.com>
2008-03-25 11:22:50 +08:00
|
|
|
.hardreset = ahci_p5wdh_hardreset,
|
2007-10-25 13:59:16 +08:00
|
|
|
};
|
|
|
|
|
|
2015-05-09 03:23:55 +08:00
|
|
|
static struct ata_port_operations ahci_avn_ops = {
|
|
|
|
|
.inherits = &ahci_ops,
|
|
|
|
|
.hardreset = ahci_avn_hardreset,
|
|
|
|
|
};
|
|
|
|
|
|
2005-11-28 17:06:23 +08:00
|
|
|
static const struct ata_port_info ahci_port_info[] = {
|
2010-03-29 09:32:39 +08:00
|
|
|
/* by features */
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci] = {
|
2007-04-23 01:41:05 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
2009-03-15 04:38:24 +08:00
|
|
|
.pio_mask = ATA_PIO4,
|
2007-07-08 13:13:16 +08:00
|
|
|
.udma_mask = ATA_UDMA6,
|
2005-04-17 06:20:36 +08:00
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
observed that was immediately preceded by the following kernel
messages:
ahci 0000:28:00.0: Using 64-bit DMA addresses
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
The first message is produced by code in drivers/iommu/dma-iommu.c
which is accompanied by the following comment that seems to apply:
/*
* Try to use all the 32-bit PCI addresses first. The original SAC vs.
* DAC reasoning loses relevance with PCIe, but enough hardware and
* firmware bugs are still lurking out there that it's safest not to
* venture into the 64-bit space until necessary.
*
* If your device goes wrong after seeing the notice then likely either
* its driver is not setting DMA masks accurately, the hardware has
* some inherent bug in handling >32-bit addresses, or not all the
* expected address bits are wired up between the device and the IOMMU.
*/
Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
address 0xffffffff00000000 produces the following I/O page faults:
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
Note that the upper 21 bits of the logged DMA address are zero. (When
asking a different PCIe device in the same PCIe slot to DMA to the
same I/O virtual address, we do see all the upper 32 bits of the DMA
address as 1, so this is not an issue with the chipset or IOMMU
configuration on the test system.)
Also, hacking libahci to always set the upper 21 bits of all DMA
addresses to 1 produces no discernible effect on the behavior of the
ASM1061, and mkfs/mount/scrub/etc work as without this hack.
This all strongly suggests that the ASM1061 has a 43 bit DMA address
limit, and this commit therefore adds a quirk to deal with this limit.
This issue probably applies to (some of) the other supported ASMedia
parts as well, but we limit it to the PCI IDs known to refer to
ASM1061 parts, as that's the only part we know for sure to be affected
by this issue at this point.
Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
[cassel: drop date from error messages in commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-01-25 23:04:01 +08:00
|
|
|
[board_ahci_43bit_dma] = {
|
|
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_43BIT_ONLY),
|
|
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci_ign_iferr] = {
|
2010-03-29 09:32:39 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_IGN_IRQ_IF_ERR),
|
2007-09-23 12:19:55 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
2009-03-15 04:38:24 +08:00
|
|
|
.pio_mask = ATA_PIO4,
|
2007-07-08 13:13:16 +08:00
|
|
|
.udma_mask = ATA_UDMA6,
|
2010-03-29 09:32:39 +08:00
|
|
|
.port_ops = &ahci_ops,
|
2006-04-17 20:17:59 +08:00
|
|
|
},
|
2022-01-05 23:36:18 +08:00
|
|
|
[board_ahci_no_debounce_delay] = {
|
2017-12-12 00:52:16 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
2022-01-05 23:36:18 +08:00
|
|
|
.link_flags = ATA_LFLAG_NO_DEBOUNCE_DELAY,
|
2017-12-12 00:52:16 +08:00
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2024-02-14 21:00:12 +08:00
|
|
|
[board_ahci_no_msi] = {
|
2014-10-27 22:22:56 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_NO_MSI),
|
2022-01-05 23:36:18 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2024-02-14 21:00:09 +08:00
|
|
|
[board_ahci_pcs_quirk] = {
|
|
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_INTEL_PCS_QUIRK),
|
2014-10-27 22:22:56 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2024-02-14 21:00:10 +08:00
|
|
|
[board_ahci_pcs_quirk_no_devslp] = {
|
|
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_INTEL_PCS_QUIRK |
|
|
|
|
|
AHCI_HFLAG_NO_DEVSLP),
|
2014-02-18 23:22:17 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2024-02-14 21:00:09 +08:00
|
|
|
[board_ahci_pcs_quirk_no_sntf] = {
|
|
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_INTEL_PCS_QUIRK |
|
|
|
|
|
AHCI_HFLAG_NO_SNTF),
|
2007-09-23 12:19:55 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
2009-03-15 04:38:24 +08:00
|
|
|
.pio_mask = ATA_PIO4,
|
2007-07-08 13:13:16 +08:00
|
|
|
.udma_mask = ATA_UDMA6,
|
2006-11-29 10:33:14 +08:00
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci_yes_fbs] = {
|
2010-07-24 22:53:48 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_YES_FBS),
|
|
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2010-03-29 09:32:39 +08:00
|
|
|
/* by chipsets */
|
2019-10-17 22:46:53 +08:00
|
|
|
[board_ahci_al] = {
|
|
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_NO_PMP | AHCI_HFLAG_NO_MSI),
|
|
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2015-05-09 03:23:55 +08:00
|
|
|
[board_ahci_avn] = {
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_INTEL_PCS_QUIRK),
|
2015-05-09 03:23:55 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_avn_ops,
|
|
|
|
|
},
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci_mcp65] = {
|
2010-03-30 09:28:32 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_NO_FPDMA_AA | AHCI_HFLAG_NO_PMP |
|
|
|
|
|
AHCI_HFLAG_YES_NCQ),
|
2011-03-16 18:14:55 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_DIPM,
|
2010-03-30 09:28:32 +08:00
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci_mcp77] = {
|
2010-03-30 09:28:32 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_NO_FPDMA_AA | AHCI_HFLAG_NO_PMP),
|
|
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci_mcp89] = {
|
2010-03-30 09:28:32 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_NO_FPDMA_AA),
|
2007-09-23 12:19:55 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
2009-03-15 04:38:24 +08:00
|
|
|
.pio_mask = ATA_PIO4,
|
2007-07-08 13:13:16 +08:00
|
|
|
.udma_mask = ATA_UDMA6,
|
2010-03-29 09:32:39 +08:00
|
|
|
.port_ops = &ahci_ops,
|
2007-03-27 18:33:05 +08:00
|
|
|
},
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci_mv] = {
|
2007-09-23 12:19:55 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_NO_NCQ | AHCI_HFLAG_NO_MSI |
|
2008-08-29 22:03:59 +08:00
|
|
|
AHCI_HFLAG_MV_PATA | AHCI_HFLAG_NO_PMP),
|
2011-02-05 03:05:48 +08:00
|
|
|
.flags = ATA_FLAG_SATA | ATA_FLAG_PIO_DMA,
|
2009-03-15 04:38:24 +08:00
|
|
|
.pio_mask = ATA_PIO4,
|
2007-07-08 14:29:42 +08:00
|
|
|
.udma_mask = ATA_UDMA6,
|
|
|
|
|
.port_ops = &ahci_ops,
|
|
|
|
|
},
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci_sb600] = {
|
2010-03-29 09:32:39 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL |
|
|
|
|
|
AHCI_HFLAG_NO_MSI | AHCI_HFLAG_SECT255 |
|
|
|
|
|
AHCI_HFLAG_32BIT_ONLY),
|
2008-02-22 21:00:31 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
2009-03-15 04:38:24 +08:00
|
|
|
.pio_mask = ATA_PIO4,
|
2008-02-22 21:00:31 +08:00
|
|
|
.udma_mask = ATA_UDMA6,
|
2011-06-21 17:17:38 +08:00
|
|
|
.port_ops = &ahci_pmp_retry_srst_ops,
|
2008-02-22 21:00:31 +08:00
|
|
|
},
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci_sb700] = { /* for SB700 and SB800 */
|
2010-03-29 09:32:39 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL),
|
2009-04-09 05:25:31 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
2011-06-21 17:17:38 +08:00
|
|
|
.port_ops = &ahci_pmp_retry_srst_ops,
|
2009-04-09 05:25:31 +08:00
|
|
|
},
|
2012-06-05 04:03:37 +08:00
|
|
|
[board_ahci_vt8251] = {
|
2010-03-29 09:32:39 +08:00
|
|
|
AHCI_HFLAGS (AHCI_HFLAG_NO_NCQ | AHCI_HFLAG_NO_PMP),
|
2009-11-16 09:56:05 +08:00
|
|
|
.flags = AHCI_FLAG_COMMON,
|
|
|
|
|
.pio_mask = ATA_PIO4,
|
|
|
|
|
.udma_mask = ATA_UDMA6,
|
2010-03-29 09:32:39 +08:00
|
|
|
.port_ops = &ahci_vt8251_ops,
|
2009-11-16 09:56:05 +08:00
|
|
|
},
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
2005-11-11 00:04:11 +08:00
|
|
|
static const struct pci_device_id ahci_pci_tbl[] = {
|
2006-06-23 11:05:36 +08:00
|
|
|
/* Intel */
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
{ PCI_VDEVICE(INTEL, 0x06d6), board_ahci_pcs_quirk }, /* Comet Lake PCH-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2652), board_ahci_pcs_quirk }, /* ICH6 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2653), board_ahci_pcs_quirk }, /* ICH6M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x27c1), board_ahci_pcs_quirk }, /* ICH7 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x27c5), board_ahci_pcs_quirk }, /* ICH7M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x27c3), board_ahci_pcs_quirk }, /* ICH7R */
|
2007-01-23 14:13:39 +08:00
|
|
|
{ PCI_VDEVICE(AL, 0x5288), board_ahci_ign_iferr }, /* ULi M5288 */
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
{ PCI_VDEVICE(INTEL, 0x2681), board_ahci_pcs_quirk }, /* ESB2 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2682), board_ahci_pcs_quirk }, /* ESB2 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2683), board_ahci_pcs_quirk }, /* ESB2 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x27c6), board_ahci_pcs_quirk }, /* ICH7-M DH */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2821), board_ahci_pcs_quirk }, /* ICH8 */
|
2024-02-14 21:00:09 +08:00
|
|
|
{ PCI_VDEVICE(INTEL, 0x2822), board_ahci_pcs_quirk_no_sntf }, /* ICH8/Lewisburg RAID*/
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
{ PCI_VDEVICE(INTEL, 0x2824), board_ahci_pcs_quirk }, /* ICH8 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2829), board_ahci_pcs_quirk }, /* ICH8M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x282a), board_ahci_pcs_quirk }, /* ICH8M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2922), board_ahci_pcs_quirk }, /* ICH9 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2923), board_ahci_pcs_quirk }, /* ICH9 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2924), board_ahci_pcs_quirk }, /* ICH9 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2925), board_ahci_pcs_quirk }, /* ICH9 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2927), board_ahci_pcs_quirk }, /* ICH9 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2929), board_ahci_pcs_quirk }, /* ICH9M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x292a), board_ahci_pcs_quirk }, /* ICH9M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x292b), board_ahci_pcs_quirk }, /* ICH9M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x292c), board_ahci_pcs_quirk }, /* ICH9M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x292f), board_ahci_pcs_quirk }, /* ICH9M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x294d), board_ahci_pcs_quirk }, /* ICH9 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x294e), board_ahci_pcs_quirk }, /* ICH9M */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x502a), board_ahci_pcs_quirk }, /* Tolapai */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x502b), board_ahci_pcs_quirk }, /* Tolapai */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3a05), board_ahci_pcs_quirk }, /* ICH10 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3a22), board_ahci_pcs_quirk }, /* ICH10 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3a25), board_ahci_pcs_quirk }, /* ICH10 */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3b22), board_ahci_pcs_quirk }, /* PCH AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3b23), board_ahci_pcs_quirk }, /* PCH AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3b24), board_ahci_pcs_quirk }, /* PCH RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3b25), board_ahci_pcs_quirk }, /* PCH RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3b29), board_ahci_pcs_quirk }, /* PCH M AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3b2b), board_ahci_pcs_quirk }, /* PCH RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3b2c), board_ahci_pcs_quirk }, /* PCH M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x3b2f), board_ahci_pcs_quirk }, /* PCH AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19b0), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19b1), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19b2), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19b3), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19b4), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19b5), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19b6), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19b7), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19bE), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19bF), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19c0), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19c1), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19c2), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19c3), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19c4), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19c5), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19c6), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19c7), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19cE), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x19cF), board_ahci }, /* DNV AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1c02), board_ahci_pcs_quirk }, /* CPT AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1c03), board_ahci_pcs_quirk }, /* CPT M AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1c04), board_ahci_pcs_quirk }, /* CPT RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1c05), board_ahci_pcs_quirk }, /* CPT M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1c06), board_ahci_pcs_quirk }, /* CPT RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1c07), board_ahci_pcs_quirk }, /* CPT RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1d02), board_ahci_pcs_quirk }, /* PBG AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1d04), board_ahci_pcs_quirk }, /* PBG RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1d06), board_ahci_pcs_quirk }, /* PBG RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2323), board_ahci_pcs_quirk }, /* DH89xxCC AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1e02), board_ahci_pcs_quirk }, /* Panther Point AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1e03), board_ahci_pcs_quirk }, /* Panther M AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1e04), board_ahci_pcs_quirk }, /* Panther Point RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1e05), board_ahci_pcs_quirk }, /* Panther Point RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1e06), board_ahci_pcs_quirk }, /* Panther Point RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1e07), board_ahci_pcs_quirk }, /* Panther M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1e0e), board_ahci_pcs_quirk }, /* Panther Point RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c02), board_ahci_pcs_quirk }, /* Lynx Point AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c03), board_ahci_pcs_quirk }, /* Lynx M AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c04), board_ahci_pcs_quirk }, /* Lynx Point RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c05), board_ahci_pcs_quirk }, /* Lynx M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c06), board_ahci_pcs_quirk }, /* Lynx Point RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c07), board_ahci_pcs_quirk }, /* Lynx M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c0e), board_ahci_pcs_quirk }, /* Lynx Point RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c0f), board_ahci_pcs_quirk }, /* Lynx M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c02), board_ahci_pcs_quirk }, /* Lynx LP AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c03), board_ahci_pcs_quirk }, /* Lynx LP AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c04), board_ahci_pcs_quirk }, /* Lynx LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c05), board_ahci_pcs_quirk }, /* Lynx LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c06), board_ahci_pcs_quirk }, /* Lynx LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c07), board_ahci_pcs_quirk }, /* Lynx LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c0e), board_ahci_pcs_quirk }, /* Lynx LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c0f), board_ahci_pcs_quirk }, /* Lynx LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9dd3), board_ahci_pcs_quirk }, /* Cannon Lake PCH-LP AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f22), board_ahci_pcs_quirk }, /* Avoton AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f23), board_ahci_pcs_quirk }, /* Avoton AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f24), board_ahci_pcs_quirk }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f25), board_ahci_pcs_quirk }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f26), board_ahci_pcs_quirk }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f27), board_ahci_pcs_quirk }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f2e), board_ahci_pcs_quirk }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f2f), board_ahci_pcs_quirk }, /* Avoton RAID */
|
2015-05-09 03:23:55 +08:00
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f32), board_ahci_avn }, /* Avoton AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f33), board_ahci_avn }, /* Avoton AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f34), board_ahci_avn }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f35), board_ahci_avn }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f36), board_ahci_avn }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f37), board_ahci_avn }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f3e), board_ahci_avn }, /* Avoton RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x1f3f), board_ahci_avn }, /* Avoton RAID */
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
{ PCI_VDEVICE(INTEL, 0x2823), board_ahci_pcs_quirk }, /* Wellsburg/Lewisburg AHCI*/
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2826), board_ahci_pcs_quirk }, /* *burg SATA0 'RAID' */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x2827), board_ahci_pcs_quirk }, /* *burg SATA1 'RAID' */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x282f), board_ahci_pcs_quirk }, /* *burg SATA2 'RAID' */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x43d4), board_ahci_pcs_quirk }, /* Rocket Lake PCH-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x43d5), board_ahci_pcs_quirk }, /* Rocket Lake PCH-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x43d6), board_ahci_pcs_quirk }, /* Rocket Lake PCH-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x43d7), board_ahci_pcs_quirk }, /* Rocket Lake PCH-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8d02), board_ahci_pcs_quirk }, /* Wellsburg AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8d04), board_ahci_pcs_quirk }, /* Wellsburg RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8d06), board_ahci_pcs_quirk }, /* Wellsburg RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8d0e), board_ahci_pcs_quirk }, /* Wellsburg RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8d62), board_ahci_pcs_quirk }, /* Wellsburg AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8d64), board_ahci_pcs_quirk }, /* Wellsburg RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8d66), board_ahci_pcs_quirk }, /* Wellsburg RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8d6e), board_ahci_pcs_quirk }, /* Wellsburg RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x23a3), board_ahci_pcs_quirk }, /* Coleto Creek AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c83), board_ahci_pcs_quirk }, /* Wildcat LP AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c85), board_ahci_pcs_quirk }, /* Wildcat LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c87), board_ahci_pcs_quirk }, /* Wildcat LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9c8f), board_ahci_pcs_quirk }, /* Wildcat LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c82), board_ahci_pcs_quirk }, /* 9 Series AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c83), board_ahci_pcs_quirk }, /* 9 Series M AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c84), board_ahci_pcs_quirk }, /* 9 Series RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c85), board_ahci_pcs_quirk }, /* 9 Series M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c86), board_ahci_pcs_quirk }, /* 9 Series RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c87), board_ahci_pcs_quirk }, /* 9 Series M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c8e), board_ahci_pcs_quirk }, /* 9 Series RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x8c8f), board_ahci_pcs_quirk }, /* 9 Series M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9d03), board_ahci_pcs_quirk }, /* Sunrise LP AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9d05), board_ahci_pcs_quirk }, /* Sunrise LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x9d07), board_ahci_pcs_quirk }, /* Sunrise LP RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa102), board_ahci_pcs_quirk }, /* Sunrise Point-H AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa103), board_ahci_pcs_quirk }, /* Sunrise M AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa105), board_ahci_pcs_quirk }, /* Sunrise Point-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa106), board_ahci_pcs_quirk }, /* Sunrise Point-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa107), board_ahci_pcs_quirk }, /* Sunrise M RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa10f), board_ahci_pcs_quirk }, /* Sunrise Point-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa182), board_ahci_pcs_quirk }, /* Lewisburg AHCI*/
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa186), board_ahci_pcs_quirk }, /* Lewisburg RAID*/
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa1d2), board_ahci_pcs_quirk }, /* Lewisburg RAID*/
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa1d6), board_ahci_pcs_quirk }, /* Lewisburg RAID*/
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa202), board_ahci_pcs_quirk }, /* Lewisburg AHCI*/
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci_pcs_quirk }, /* Lewisburg RAID*/
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci_pcs_quirk }, /* Lewisburg RAID*/
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci_pcs_quirk }, /* Lewisburg RAID*/
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa356), board_ahci_pcs_quirk }, /* Cannon Lake PCH-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x06d7), board_ahci_pcs_quirk }, /* Comet Lake-H RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0xa386), board_ahci_pcs_quirk }, /* Comet Lake PCH-V RAID */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x0f22), board_ahci_pcs_quirk }, /* Bay Trail AHCI */
|
2024-02-14 21:00:10 +08:00
|
|
|
{ PCI_VDEVICE(INTEL, 0x0f23), board_ahci_pcs_quirk_no_devslp }, /* Bay Trail AHCI */
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
{ PCI_VDEVICE(INTEL, 0x22a3), board_ahci_pcs_quirk }, /* Cherry Tr. AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x5ae3), board_ahci_pcs_quirk }, /* ApolloLake AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x34d3), board_ahci_pcs_quirk }, /* Ice Lake LP AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x02d3), board_ahci_pcs_quirk }, /* Comet Lake PCH-U AHCI */
|
|
|
|
|
{ PCI_VDEVICE(INTEL, 0x02d7), board_ahci_pcs_quirk }, /* Comet Lake PCH RAID */
|
2023-08-29 19:33:58 +08:00
|
|
|
/* Elkhart Lake IDs 0x4b60 & 0x4b62 https://sata-io.org/product/8803 not tested yet */
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
{ PCI_VDEVICE(INTEL, 0x4b63), board_ahci_pcs_quirk }, /* Elkhart Lake AHCI */
|
2006-06-23 11:05:36 +08:00
|
|
|
|
2007-02-26 19:24:03 +08:00
|
|
|
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
|
|
|
|
|
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
|
|
|
|
|
PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci_ign_iferr },
|
2012-09-10 08:09:04 +08:00
|
|
|
/* JMicron 362B and 362C have an AHCI function with IDE class code */
|
|
|
|
|
{ PCI_VDEVICE(JMICRON, 0x2362), board_ahci_ign_iferr },
|
|
|
|
|
{ PCI_VDEVICE(JMICRON, 0x236f), board_ahci_ign_iferr },
|
PCI: Disable async suspend/resume for JMicron multi-function SATA/AHCI
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 76569faa62c4 ("PM / sleep:
Asynchronous threads for resume_noirq"). Prior to that, we powered on
the functions in order, so this problem shouldn't happen.
e6b7e41cdd8c ("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=81551
Reported-and-tested-by: Barto <mister.freeman@laposte.net>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.15+
2015-08-25 04:27:11 +08:00
|
|
|
/* May need to update quirk_jmicron_async_suspend() for additions */
|
2006-06-23 11:05:36 +08:00
|
|
|
|
|
|
|
|
/* ATI */
|
2007-04-11 18:23:14 +08:00
|
|
|
{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
|
2008-02-22 21:00:31 +08:00
|
|
|
{ PCI_VDEVICE(ATI, 0x4390), board_ahci_sb700 }, /* ATI SB700/800 */
|
|
|
|
|
{ PCI_VDEVICE(ATI, 0x4391), board_ahci_sb700 }, /* ATI SB700/800 */
|
|
|
|
|
{ PCI_VDEVICE(ATI, 0x4392), board_ahci_sb700 }, /* ATI SB700/800 */
|
|
|
|
|
{ PCI_VDEVICE(ATI, 0x4393), board_ahci_sb700 }, /* ATI SB700/800 */
|
|
|
|
|
{ PCI_VDEVICE(ATI, 0x4394), board_ahci_sb700 }, /* ATI SB700/800 */
|
|
|
|
|
{ PCI_VDEVICE(ATI, 0x4395), board_ahci_sb700 }, /* ATI SB700/800 */
|
2006-06-23 11:05:36 +08:00
|
|
|
|
2019-10-17 22:46:53 +08:00
|
|
|
/* Amazon's Annapurna Labs support */
|
|
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031),
|
|
|
|
|
.class = PCI_CLASS_STORAGE_SATA_AHCI,
|
|
|
|
|
.class_mask = 0xffffff,
|
|
|
|
|
board_ahci_al },
|
2009-07-29 11:34:49 +08:00
|
|
|
/* AMD */
|
2009-10-13 11:14:00 +08:00
|
|
|
{ PCI_VDEVICE(AMD, 0x7800), board_ahci }, /* AMD Hudson-2 */
|
2022-01-05 23:36:18 +08:00
|
|
|
{ PCI_VDEVICE(AMD, 0x7801), board_ahci_no_debounce_delay }, /* AMD Hudson-2 (AHCI mode) */
|
2013-06-03 18:24:10 +08:00
|
|
|
{ PCI_VDEVICE(AMD, 0x7900), board_ahci }, /* AMD CZ */
|
2024-02-07 05:13:46 +08:00
|
|
|
{ PCI_VDEVICE(AMD, 0x7901), board_ahci }, /* AMD Green Sardine */
|
2009-07-29 11:34:49 +08:00
|
|
|
/* AMD is using RAID class only for ahci controllers */
|
|
|
|
|
{ PCI_VENDOR_ID_AMD, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
|
|
|
|
|
PCI_CLASS_STORAGE_RAID << 8, 0xffffff, board_ahci },
|
2021-06-16 03:08:01 +08:00
|
|
|
|
|
|
|
|
/* Dell S140/S150 */
|
|
|
|
|
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_SUBVENDOR_ID_DELL, PCI_ANY_ID,
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
PCI_CLASS_STORAGE_RAID << 8, 0xffffff, board_ahci_pcs_quirk },
|
2009-07-29 11:34:49 +08:00
|
|
|
|
2006-06-23 11:05:36 +08:00
|
|
|
/* VIA */
|
2006-09-28 10:20:11 +08:00
|
|
|
{ PCI_VDEVICE(VIA, 0x3349), board_ahci_vt8251 }, /* VIA VT8251 */
|
2007-04-11 16:27:14 +08:00
|
|
|
{ PCI_VDEVICE(VIA, 0x6287), board_ahci_vt8251 }, /* VIA VT8251 */
|
2006-06-23 11:05:36 +08:00
|
|
|
|
|
|
|
|
/* NVIDIA */
|
2008-06-09 23:13:04 +08:00
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x044c), board_ahci_mcp65 }, /* MCP65 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x044d), board_ahci_mcp65 }, /* MCP65 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x044e), board_ahci_mcp65 }, /* MCP65 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x044f), board_ahci_mcp65 }, /* MCP65 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x045c), board_ahci_mcp65 }, /* MCP65 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x045d), board_ahci_mcp65 }, /* MCP65 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x045e), board_ahci_mcp65 }, /* MCP65 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x045f), board_ahci_mcp65 }, /* MCP65 */
|
2010-03-29 09:32:39 +08:00
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0550), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0551), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0552), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0553), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0554), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0555), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0556), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0557), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0558), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0559), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x055a), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x055b), board_ahci_mcp67 }, /* MCP67 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0580), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0581), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0582), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0583), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0584), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0585), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0586), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0587), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0588), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0589), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x058a), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x058b), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x058c), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x058d), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x058e), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x058f), board_ahci_mcp_linux }, /* Linux ID */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f0), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f1), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f2), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f3), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f4), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f5), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f6), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f7), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f8), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07f9), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07fa), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x07fb), board_ahci_mcp73 }, /* MCP73 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad0), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad1), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad2), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad3), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad4), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad5), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad6), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad7), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad8), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci_mcp77 }, /* MCP77 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ab4), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ab5), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ab6), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ab7), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ab8), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0ab9), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0aba), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0abb), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0abc), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0abd), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0abe), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0abf), board_ahci_mcp79 }, /* MCP79 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d84), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d85), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d86), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d87), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d88), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d89), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d8a), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d8b), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d8c), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d8d), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d8e), board_ahci_mcp89 }, /* MCP89 */
|
|
|
|
|
{ PCI_VDEVICE(NVIDIA, 0x0d8f), board_ahci_mcp89 }, /* MCP89 */
|
2006-06-23 11:05:36 +08:00
|
|
|
|
2006-07-29 16:10:14 +08:00
|
|
|
/* SiS */
|
2008-08-01 11:51:43 +08:00
|
|
|
{ PCI_VDEVICE(SI, 0x1184), board_ahci }, /* SiS 966 */
|
|
|
|
|
{ PCI_VDEVICE(SI, 0x1185), board_ahci }, /* SiS 968 */
|
|
|
|
|
{ PCI_VDEVICE(SI, 0x0186), board_ahci }, /* SiS 968 */
|
2006-07-29 16:10:14 +08:00
|
|
|
|
2012-01-06 20:33:39 +08:00
|
|
|
/* ST Microelectronics */
|
|
|
|
|
{ PCI_VDEVICE(STMICRO, 0xCC06), board_ahci }, /* ST ConneXt */
|
|
|
|
|
|
2007-07-08 14:29:42 +08:00
|
|
|
/* Marvell */
|
|
|
|
|
{ PCI_VDEVICE(MARVELL, 0x6145), board_ahci_mv }, /* 6145 */
|
2008-03-14 06:22:24 +08:00
|
|
|
{ PCI_VDEVICE(MARVELL, 0x6121), board_ahci_mv }, /* 6121 */
|
2013-04-09 01:32:49 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9123),
|
2011-01-19 09:03:26 +08:00
|
|
|
.class = PCI_CLASS_STORAGE_SATA_AHCI,
|
|
|
|
|
.class_mask = 0xffffff,
|
2010-07-24 22:53:48 +08:00
|
|
|
.driver_data = board_ahci_yes_fbs }, /* 88se9128 */
|
2013-04-09 01:32:49 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9125),
|
2011-02-08 20:54:32 +08:00
|
|
|
.driver_data = board_ahci_yes_fbs }, /* 88se9125 */
|
2013-12-23 20:24:35 +08:00
|
|
|
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_MARVELL_EXT, 0x9178,
|
|
|
|
|
PCI_VENDOR_ID_MARVELL_EXT, 0x9170),
|
|
|
|
|
.driver_data = board_ahci_yes_fbs }, /* 88se9170 */
|
2013-04-09 01:32:49 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x917a),
|
2012-04-27 14:42:30 +08:00
|
|
|
.driver_data = board_ahci_yes_fbs }, /* 88se9172 */
|
2013-05-29 09:20:35 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9172),
|
2014-09-06 01:21:00 +08:00
|
|
|
.driver_data = board_ahci_yes_fbs }, /* 88se9182 */
|
|
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9182),
|
2013-05-29 09:20:35 +08:00
|
|
|
.driver_data = board_ahci_yes_fbs }, /* 88se9172 */
|
2013-04-09 01:32:49 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9192),
|
2012-09-04 23:07:18 +08:00
|
|
|
.driver_data = board_ahci_yes_fbs }, /* 88se9172 on some Gigabyte */
|
2014-05-24 22:35:43 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x91a0),
|
|
|
|
|
.driver_data = board_ahci_yes_fbs },
|
2015-10-20 15:31:22 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x91a2), /* 88se91a2 */
|
|
|
|
|
.driver_data = board_ahci_yes_fbs },
|
2013-04-09 01:32:49 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x91a3),
|
2010-11-29 22:57:14 +08:00
|
|
|
.driver_data = board_ahci_yes_fbs },
|
2013-11-18 06:56:17 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9230),
|
|
|
|
|
.driver_data = board_ahci_yes_fbs },
|
ata: ahci: Skip 200 ms debounce delay for Marvell 88SE9235
The 200 ms delay before debouncing the PHY in `sata_link_resume()` is
not needed for the Marvell 88SE9235.
$ lspci -nn -s 0021:0e:00.0
0021:0e:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11)
So, remove it using the board_ahci_no_debounce_delay board definition.
Tested on IBM S822LC with current Linux 5.17-rc1:
Currently, without this patch (with 200 ms delay), device probe for ata1
takes 485 ms:
[ 3.358158] ata1: SATA max UDMA/133 abar m2048@0x3fe881000000 port 0x3fe881000100 irq 39
[ 3.358175] ata2: SATA max UDMA/133 abar m2048@0x3fe881000000 port 0x3fe881000180 irq 39
[ 3.358191] ata3: SATA max UDMA/133 abar m2048@0x3fe881000000 port 0x3fe881000200 irq 39
[ 3.358207] ata4: SATA max UDMA/133 abar m2048@0x3fe881000000 port 0x3fe881000280 irq 39
[…]
[ 3.677542] ata3: SATA link down (SStatus 0 SControl 300)
[ 3.677719] ata4: SATA link down (SStatus 0 SControl 300)
[ 3.839242] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3.839828] ata2.00: ATA-10: ST1000NX0313 00LY266 00LY265IBM, BE33, max UDMA/133
[ 3.840029] ata2.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[ 3.841796] ata2.00: configured for UDMA/133
[ 3.843231] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3.844083] ata1.00: ATA-10: ST1000NX0313 00LY266 00LY265IBM, BE33, max UDMA/133
[ 3.844313] ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[ 3.846043] ata1.00: configured for UDMA/133
With this patch (no delay) device probe for ata1 takes 273 ms:
[ 3.624259] ata1: SATA max UDMA/133 abar m2048@0x3fe881000000 port 0x3f e881000100 irq 39
[ 3.624436] ata2: SATA max UDMA/133 abar m2048@0x3fe881000000 port 0x3f e881000180 irq 39
[ 3.624452] ata3: SATA max UDMA/133 abar m2048@0x3fe881000000 port 0x3f e881000200 irq 39
[ 3.624468] ata4: SATA max UDMA/133 abar m2048@0x3fe881000000 port 0x3f e881000280 irq 39
[…]
[ 3.731966] ata3: SATA link down (SStatus 0 SControl 300)
[ 3.732069] ata4: SATA link down (SStatus 0 SControl 300)
[ 3.897448] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3.897678] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3.898140] ata1.00: ATA-10: ST1000NX0313 00LY266 00LY265IBM, BE33, max UDMA/133
[ 3.898175] ata2.00: ATA-10: ST1000NX0313 00LY266 00LY265IBM, BE33, max UDMA/133
[ 3.898287] ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[ 3.898349] ata2.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[ 3.900070] ata1.00: configured for UDMA/133
[ 3.900166] ata2.00: configured for UDMA/133
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-02-01 15:12:23 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9235),
|
|
|
|
|
.driver_data = board_ahci_no_debounce_delay },
|
2018-03-02 18:36:32 +08:00
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0642), /* highpoint rocketraid 642L */
|
|
|
|
|
.driver_data = board_ahci_yes_fbs },
|
|
|
|
|
{ PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0645), /* highpoint rocketraid 644L */
|
2014-06-04 02:56:25 +08:00
|
|
|
.driver_data = board_ahci_yes_fbs },
|
2007-07-08 14:29:42 +08:00
|
|
|
|
2008-10-23 11:08:16 +08:00
|
|
|
/* Promise */
|
|
|
|
|
{ PCI_VDEVICE(PROMISE, 0x3f20), board_ahci }, /* PDC42819 */
|
2014-07-12 00:08:13 +08:00
|
|
|
{ PCI_VDEVICE(PROMISE, 0x3781), board_ahci }, /* FastTrak TX8660 ahci-mode */
|
2008-10-23 11:08:16 +08:00
|
|
|
|
ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
observed that was immediately preceded by the following kernel
messages:
ahci 0000:28:00.0: Using 64-bit DMA addresses
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
The first message is produced by code in drivers/iommu/dma-iommu.c
which is accompanied by the following comment that seems to apply:
/*
* Try to use all the 32-bit PCI addresses first. The original SAC vs.
* DAC reasoning loses relevance with PCIe, but enough hardware and
* firmware bugs are still lurking out there that it's safest not to
* venture into the 64-bit space until necessary.
*
* If your device goes wrong after seeing the notice then likely either
* its driver is not setting DMA masks accurately, the hardware has
* some inherent bug in handling >32-bit addresses, or not all the
* expected address bits are wired up between the device and the IOMMU.
*/
Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
address 0xffffffff00000000 produces the following I/O page faults:
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
Note that the upper 21 bits of the logged DMA address are zero. (When
asking a different PCIe device in the same PCIe slot to DMA to the
same I/O virtual address, we do see all the upper 32 bits of the DMA
address as 1, so this is not an issue with the chipset or IOMMU
configuration on the test system.)
Also, hacking libahci to always set the upper 21 bits of all DMA
addresses to 1 produces no discernible effect on the behavior of the
ASM1061, and mkfs/mount/scrub/etc work as without this hack.
This all strongly suggests that the ASM1061 has a 43 bit DMA address
limit, and this commit therefore adds a quirk to deal with this limit.
This issue probably applies to (some of) the other supported ASMedia
parts as well, but we limit it to the PCI IDs known to refer to
ASM1061 parts, as that's the only part we know for sure to be affected
by this issue at this point.
Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
[cassel: drop date from error messages in commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-01-25 23:04:01 +08:00
|
|
|
/* ASMedia */
|
2024-01-30 21:21:51 +08:00
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x0601), board_ahci_43bit_dma }, /* ASM1060 */
|
|
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x0602), board_ahci_43bit_dma }, /* ASM1060 */
|
ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
observed that was immediately preceded by the following kernel
messages:
ahci 0000:28:00.0: Using 64-bit DMA addresses
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
The first message is produced by code in drivers/iommu/dma-iommu.c
which is accompanied by the following comment that seems to apply:
/*
* Try to use all the 32-bit PCI addresses first. The original SAC vs.
* DAC reasoning loses relevance with PCIe, but enough hardware and
* firmware bugs are still lurking out there that it's safest not to
* venture into the 64-bit space until necessary.
*
* If your device goes wrong after seeing the notice then likely either
* its driver is not setting DMA masks accurately, the hardware has
* some inherent bug in handling >32-bit addresses, or not all the
* expected address bits are wired up between the device and the IOMMU.
*/
Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
address 0xffffffff00000000 produces the following I/O page faults:
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
Note that the upper 21 bits of the logged DMA address are zero. (When
asking a different PCIe device in the same PCIe slot to DMA to the
same I/O virtual address, we do see all the upper 32 bits of the DMA
address as 1, so this is not an issue with the chipset or IOMMU
configuration on the test system.)
Also, hacking libahci to always set the upper 21 bits of all DMA
addresses to 1 produces no discernible effect on the behavior of the
ASM1061, and mkfs/mount/scrub/etc work as without this hack.
This all strongly suggests that the ASM1061 has a 43 bit DMA address
limit, and this commit therefore adds a quirk to deal with this limit.
This issue probably applies to (some of) the other supported ASMedia
parts as well, but we limit it to the PCI IDs known to refer to
ASM1061 parts, as that's the only part we know for sure to be affected
by this issue at this point.
Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
[cassel: drop date from error messages in commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-01-25 23:04:01 +08:00
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x0611), board_ahci_43bit_dma }, /* ASM1061 */
|
|
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x0612), board_ahci_43bit_dma }, /* ASM1061/1062 */
|
2024-01-30 21:21:51 +08:00
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x0621), board_ahci_43bit_dma }, /* ASM1061R */
|
|
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x0622), board_ahci_43bit_dma }, /* ASM1062R */
|
|
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x0624), board_ahci_43bit_dma }, /* ASM1062+JMB575 */
|
2023-09-21 17:33:51 +08:00
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x1062), board_ahci }, /* ASM1062A */
|
|
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x1064), board_ahci }, /* ASM1064 */
|
|
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x1164), board_ahci }, /* ASM1164 */
|
|
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x1165), board_ahci }, /* ASM1165 */
|
|
|
|
|
{ PCI_VDEVICE(ASMEDIA, 0x1166), board_ahci }, /* ASM1166 */
|
2011-11-09 14:47:36 +08:00
|
|
|
|
2014-02-18 23:22:17 +08:00
|
|
|
/*
|
2014-10-27 22:22:56 +08:00
|
|
|
* Samsung SSDs found on some macbooks. NCQ times out if MSI is
|
|
|
|
|
* enabled. https://bugzilla.kernel.org/show_bug.cgi?id=60731
|
2014-02-18 23:22:17 +08:00
|
|
|
*/
|
2024-02-14 21:00:12 +08:00
|
|
|
{ PCI_VDEVICE(SAMSUNG, 0x1600), board_ahci_no_msi },
|
|
|
|
|
{ PCI_VDEVICE(SAMSUNG, 0xa800), board_ahci_no_msi },
|
2014-02-18 23:22:17 +08:00
|
|
|
|
2013-01-05 06:39:09 +08:00
|
|
|
/* Enmotus */
|
|
|
|
|
{ PCI_DEVICE(0x1c44, 0x8000), board_ahci },
|
|
|
|
|
|
2020-03-10 20:50:08 +08:00
|
|
|
/* Loongson */
|
|
|
|
|
{ PCI_VDEVICE(LOONGSON, 0x7a08), board_ahci },
|
|
|
|
|
|
2006-11-01 18:10:42 +08:00
|
|
|
/* Generic, PCI class code for AHCI */
|
|
|
|
|
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
|
2007-01-09 18:32:51 +08:00
|
|
|
PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci },
|
2006-11-01 18:10:42 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
{ } /* terminate list */
|
|
|
|
|
};
|
|
|
|
|
|
2016-02-18 16:54:15 +08:00
|
|
|
static const struct dev_pm_ops ahci_pci_pm_ops = {
|
|
|
|
|
SET_SYSTEM_SLEEP_PM_OPS(ahci_pci_device_suspend, ahci_pci_device_resume)
|
2016-02-18 16:54:17 +08:00
|
|
|
SET_RUNTIME_PM_OPS(ahci_pci_device_runtime_suspend,
|
|
|
|
|
ahci_pci_device_runtime_resume, NULL)
|
2016-02-18 16:54:15 +08:00
|
|
|
};
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
static struct pci_driver ahci_pci_driver = {
|
|
|
|
|
.name = DRV_NAME,
|
|
|
|
|
.id_table = ahci_pci_tbl,
|
|
|
|
|
.probe = ahci_init_one,
|
2016-02-18 16:54:17 +08:00
|
|
|
.remove = ahci_remove_one,
|
2020-01-25 11:37:29 +08:00
|
|
|
.shutdown = ahci_shutdown_one,
|
2016-02-18 16:54:15 +08:00
|
|
|
.driver = {
|
|
|
|
|
.pm = &ahci_pci_pm_ops,
|
|
|
|
|
},
|
2010-03-28 12:22:14 +08:00
|
|
|
};
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2016-05-19 04:11:28 +08:00
|
|
|
#if IS_ENABLED(CONFIG_PATA_MARVELL)
|
2010-03-28 12:22:14 +08:00
|
|
|
static int marvell_enable;
|
|
|
|
|
#else
|
|
|
|
|
static int marvell_enable = 1;
|
|
|
|
|
#endif
|
|
|
|
|
module_param(marvell_enable, int, 0644);
|
|
|
|
|
MODULE_PARM_DESC(marvell_enable, "Marvell SATA via AHCI (1 = enabled)");
|
2008-07-05 12:10:50 +08:00
|
|
|
|
2018-07-28 04:47:03 +08:00
|
|
|
static int mobile_lpm_policy = -1;
|
2017-12-12 00:52:16 +08:00
|
|
|
module_param(mobile_lpm_policy, int, 0644);
|
|
|
|
|
MODULE_PARM_DESC(mobile_lpm_policy, "Default LPM policy for mobile chipsets");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
ata: ahci: Add mask_port_map module parameter
Commits 0077a504e1a4 ("ahci: asm1166: correct count of reported ports")
and 9815e3961754 ("ahci: asm1064: correct count of reported ports")
attempted to limit the ports of the ASM1166 and ASM1064 AHCI controllers
to avoid long boot times caused by the fact that these adapters report
a port map larger than the number of physical ports. The excess ports
are "virtual" to hide port multiplier devices and probing these ports
takes time. However, these commits caused a regression for users that do
use PMP devices, as the ATA devices connected to the PMP cannot be
scanned. These commits have thus been reverted by commit 6cd8adc3e18
("ahci: asm1064: asm1166: don't limit reported ports") to allow the
discovery of devices connected through a port multiplier. But this
revert re-introduced the long boot times for users that do not use a
port multiplier setup.
This patch adds the mask_port_map ahci module parameter to allow users
to manually specify port map masks for controllers. In the case of the
ASMedia 1166 and 1064 controllers, users that do not have port
multiplier devices can mask the excess virtual ports exposed by the
controller to speedup port scanning, thus reducing boot time.
The mask_port_map parameter accepts 2 different formats:
- mask_port_map=<mask>
This applies the same mask to all AHCI controllers
present in the system. This format is convenient for small systems
that have only a single AHCI controller.
- mask_port_map=<pci_dev>=<mask>,<pci_dev>=mask,...
This applies the specified masks only to the PCI device listed. The
<pci_dev> field is a regular PCI device ID (domain:bus:dev.func).
This ID can be seen following "ahci" in the kernel messages. E.g.
for "ahci 0000:01:00.0: 2/2 ports implemented (port mask 0x3)", the
<pci_dev> field is "0000:01:00.0".
When used, the function ahci_save_initial_config() indicates that a
port map mask was applied with the message "masking port_map ...".
E.g.: without a mask:
modprobe ahci
dmesg | grep ahci
...
ahci 0000:00:17.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode
ahci 0000:00:17.0: (0000:00:17.0) 8/8 ports implemented (port mask 0xff)
With a mask:
modprobe ahci mask_port_map=0000:00:17.0=0x1
dmesg | grep ahci
...
ahci 0000:00:17.0: masking port_map 0xff -> 0x1
ahci 0000:00:17.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode
ahci 0000:00:17.0: (0000:00:17.0) 1/8 ports implemented (port mask 0x1)
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-04-04 17:30:14 +08:00
|
|
|
static char *ahci_mask_port_map;
|
|
|
|
|
module_param_named(mask_port_map, ahci_mask_port_map, charp, 0444);
|
|
|
|
|
MODULE_PARM_DESC(mask_port_map,
|
|
|
|
|
"32-bits port map masks to ignore controllers ports. "
|
|
|
|
|
"Valid values are: "
|
|
|
|
|
"\"<mask>\" to apply the same mask to all AHCI controller "
|
|
|
|
|
"devices, and \"<pci_dev>=<mask>,<pci_dev>=<mask>,...\" to "
|
|
|
|
|
"specify different masks for the controllers specified, "
|
|
|
|
|
"where <pci_dev> is the PCI ID of an AHCI controller in the "
|
|
|
|
|
"form \"domain:bus:dev.func\"");
|
|
|
|
|
|
|
|
|
|
static void ahci_apply_port_map_mask(struct device *dev,
|
|
|
|
|
struct ahci_host_priv *hpriv, char *mask_s)
|
|
|
|
|
{
|
|
|
|
|
unsigned int mask;
|
|
|
|
|
|
|
|
|
|
if (kstrtouint(mask_s, 0, &mask)) {
|
|
|
|
|
dev_err(dev, "Invalid port map mask\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
hpriv->mask_port_map = mask;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void ahci_get_port_map_mask(struct device *dev,
|
|
|
|
|
struct ahci_host_priv *hpriv)
|
|
|
|
|
{
|
|
|
|
|
char *param, *end, *str, *mask_s;
|
|
|
|
|
char *name;
|
|
|
|
|
|
|
|
|
|
if (!strlen(ahci_mask_port_map))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
str = kstrdup(ahci_mask_port_map, GFP_KERNEL);
|
|
|
|
|
if (!str)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/* Handle single mask case */
|
|
|
|
|
if (!strchr(str, '=')) {
|
|
|
|
|
ahci_apply_port_map_mask(dev, hpriv, str);
|
|
|
|
|
goto free;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Mask list case: parse the parameter to apply the mask only if
|
|
|
|
|
* the device name matches.
|
|
|
|
|
*/
|
|
|
|
|
param = str;
|
|
|
|
|
end = param + strlen(param);
|
|
|
|
|
while (param && param < end && *param) {
|
|
|
|
|
name = param;
|
|
|
|
|
param = strchr(name, '=');
|
|
|
|
|
if (!param)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
*param = '\0';
|
|
|
|
|
param++;
|
|
|
|
|
if (param >= end)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
if (strcmp(dev_name(dev), name) != 0) {
|
|
|
|
|
param = strchr(param, ',');
|
|
|
|
|
if (param)
|
|
|
|
|
param++;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mask_s = param;
|
|
|
|
|
param = strchr(mask_s, ',');
|
|
|
|
|
if (param) {
|
|
|
|
|
*param = '\0';
|
|
|
|
|
param++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ahci_apply_port_map_mask(dev, hpriv, mask_s);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
free:
|
|
|
|
|
kfree(str);
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
static void ahci_pci_save_initial_config(struct pci_dev *pdev,
|
|
|
|
|
struct ahci_host_priv *hpriv)
|
|
|
|
|
{
|
|
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_JMICRON && pdev->device == 0x2361) {
|
|
|
|
|
dev_info(&pdev->dev, "JMB361 has only one port\n");
|
2022-09-10 03:36:11 +08:00
|
|
|
hpriv->saved_port_map = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
/*
|
|
|
|
|
* Temporary Marvell 6145 hack: PATA port presence
|
|
|
|
|
* is asserted through the standard AHCI port
|
|
|
|
|
* presence register, as bit 4 (counting from 0)
|
2008-07-05 12:10:50 +08:00
|
|
|
*/
|
2010-03-28 12:22:14 +08:00
|
|
|
if (hpriv->flags & AHCI_HFLAG_MV_PATA) {
|
|
|
|
|
if (pdev->device == 0x6121)
|
2014-11-03 16:56:11 +08:00
|
|
|
hpriv->mask_port_map = 0x3;
|
2010-03-28 12:22:14 +08:00
|
|
|
else
|
2014-11-03 16:56:11 +08:00
|
|
|
hpriv->mask_port_map = 0xf;
|
2010-03-28 12:22:14 +08:00
|
|
|
dev_info(&pdev->dev,
|
|
|
|
|
"Disabling your PATA port. Use the boot option 'ahci.marvell_enable=0' to avoid this.\n");
|
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
ata: ahci: Add mask_port_map module parameter
Commits 0077a504e1a4 ("ahci: asm1166: correct count of reported ports")
and 9815e3961754 ("ahci: asm1064: correct count of reported ports")
attempted to limit the ports of the ASM1166 and ASM1064 AHCI controllers
to avoid long boot times caused by the fact that these adapters report
a port map larger than the number of physical ports. The excess ports
are "virtual" to hide port multiplier devices and probing these ports
takes time. However, these commits caused a regression for users that do
use PMP devices, as the ATA devices connected to the PMP cannot be
scanned. These commits have thus been reverted by commit 6cd8adc3e18
("ahci: asm1064: asm1166: don't limit reported ports") to allow the
discovery of devices connected through a port multiplier. But this
revert re-introduced the long boot times for users that do not use a
port multiplier setup.
This patch adds the mask_port_map ahci module parameter to allow users
to manually specify port map masks for controllers. In the case of the
ASMedia 1166 and 1064 controllers, users that do not have port
multiplier devices can mask the excess virtual ports exposed by the
controller to speedup port scanning, thus reducing boot time.
The mask_port_map parameter accepts 2 different formats:
- mask_port_map=<mask>
This applies the same mask to all AHCI controllers
present in the system. This format is convenient for small systems
that have only a single AHCI controller.
- mask_port_map=<pci_dev>=<mask>,<pci_dev>=mask,...
This applies the specified masks only to the PCI device listed. The
<pci_dev> field is a regular PCI device ID (domain:bus:dev.func).
This ID can be seen following "ahci" in the kernel messages. E.g.
for "ahci 0000:01:00.0: 2/2 ports implemented (port mask 0x3)", the
<pci_dev> field is "0000:01:00.0".
When used, the function ahci_save_initial_config() indicates that a
port map mask was applied with the message "masking port_map ...".
E.g.: without a mask:
modprobe ahci
dmesg | grep ahci
...
ahci 0000:00:17.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode
ahci 0000:00:17.0: (0000:00:17.0) 8/8 ports implemented (port mask 0xff)
With a mask:
modprobe ahci mask_port_map=0000:00:17.0=0x1
dmesg | grep ahci
...
ahci 0000:00:17.0: masking port_map 0xff -> 0x1
ahci 0000:00:17.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode
ahci 0000:00:17.0: (0000:00:17.0) 1/8 ports implemented (port mask 0x1)
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-04-04 17:30:14 +08:00
|
|
|
/* Handle port map masks passed as module parameter. */
|
|
|
|
|
if (ahci_mask_port_map)
|
|
|
|
|
ahci_get_port_map_mask(&pdev->dev, hpriv);
|
|
|
|
|
|
2014-07-31 02:13:56 +08:00
|
|
|
ahci_save_initial_config(&pdev->dev, hpriv);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2022-12-09 17:26:34 +08:00
|
|
|
static int ahci_pci_reset_controller(struct ata_host *host)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(host->dev);
|
|
|
|
|
struct ahci_host_priv *hpriv = host->private_data;
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
rc = ahci_reset_controller(host);
|
|
|
|
|
if (rc)
|
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If platform firmware failed to enable ports, try to enable
|
|
|
|
|
* them here.
|
|
|
|
|
*/
|
|
|
|
|
ahci_intel_pcs_quirk(pdev, hpriv);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
static void ahci_pci_init_controller(struct ata_host *host)
|
2006-05-15 19:58:29 +08:00
|
|
|
{
|
2010-03-28 12:22:14 +08:00
|
|
|
struct ahci_host_priv *hpriv = host->private_data;
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(host->dev);
|
|
|
|
|
void __iomem *port_mmio;
|
2006-05-15 19:58:29 +08:00
|
|
|
u32 tmp;
|
2010-03-28 12:22:14 +08:00
|
|
|
int mv;
|
2006-05-15 19:58:29 +08:00
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
if (hpriv->flags & AHCI_HFLAG_MV_PATA) {
|
|
|
|
|
if (pdev->device == 0x6121)
|
|
|
|
|
mv = 2;
|
|
|
|
|
else
|
|
|
|
|
mv = 4;
|
2022-09-10 03:36:13 +08:00
|
|
|
port_mmio = __ahci_port_base(hpriv, mv);
|
2006-05-15 19:58:29 +08:00
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
writel(0, port_mmio + PORT_IRQ_MASK);
|
2006-05-15 19:58:29 +08:00
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
/* clear port IRQ */
|
|
|
|
|
tmp = readl(port_mmio + PORT_IRQ_STAT);
|
2021-12-21 15:20:47 +08:00
|
|
|
dev_dbg(&pdev->dev, "PORT_IRQ_STAT 0x%x\n", tmp);
|
2010-03-28 12:22:14 +08:00
|
|
|
if (tmp)
|
|
|
|
|
writel(tmp, port_mmio + PORT_IRQ_STAT);
|
2006-05-15 19:58:29 +08:00
|
|
|
}
|
|
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
ahci_init_controller(host);
|
2007-10-25 13:59:16 +08:00
|
|
|
}
|
|
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
static int ahci_vt8251_hardreset(struct ata_link *link, unsigned int *class,
|
|
|
|
|
unsigned long deadline)
|
2009-12-09 17:23:04 +08:00
|
|
|
{
|
2010-03-28 12:22:14 +08:00
|
|
|
struct ata_port *ap = link->ap;
|
2014-02-22 23:53:30 +08:00
|
|
|
struct ahci_host_priv *hpriv = ap->host->private_data;
|
2010-03-28 12:22:14 +08:00
|
|
|
bool online;
|
2009-12-09 17:23:04 +08:00
|
|
|
int rc;
|
|
|
|
|
|
2018-04-13 12:32:30 +08:00
|
|
|
hpriv->stop_engine(ap);
|
2009-12-09 17:23:04 +08:00
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
rc = sata_link_hardreset(link, sata_ehc_deb_timing(&link->eh_context),
|
|
|
|
|
deadline, &online, NULL);
|
2009-12-09 17:23:04 +08:00
|
|
|
|
2014-02-22 23:53:30 +08:00
|
|
|
hpriv->start_engine(ap);
|
2009-12-09 17:23:04 +08:00
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
/* vt8251 doesn't clear BSY on signature FIS reception,
|
|
|
|
|
* request follow-up softreset.
|
|
|
|
|
*/
|
|
|
|
|
return online ? -EAGAIN : rc;
|
2007-09-23 12:19:54 +08:00
|
|
|
}
|
|
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
static int ahci_p5wdh_hardreset(struct ata_link *link, unsigned int *class,
|
|
|
|
|
unsigned long deadline)
|
2007-09-23 12:19:54 +08:00
|
|
|
{
|
2010-03-28 12:22:14 +08:00
|
|
|
struct ata_port *ap = link->ap;
|
2007-10-09 14:01:37 +08:00
|
|
|
struct ahci_port_priv *pp = ap->private_data;
|
2014-02-22 23:53:30 +08:00
|
|
|
struct ahci_host_priv *hpriv = ap->host->private_data;
|
2010-03-28 12:22:14 +08:00
|
|
|
u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
|
|
|
|
|
struct ata_taskfile tf;
|
|
|
|
|
bool online;
|
|
|
|
|
int rc;
|
2007-09-23 12:19:54 +08:00
|
|
|
|
2018-04-13 12:32:30 +08:00
|
|
|
hpriv->stop_engine(ap);
|
2007-07-18 03:48:48 +08:00
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
/* clear D2H reception area to properly wait for D2H FIS */
|
|
|
|
|
ata_tf_init(link->device, &tf);
|
2022-02-16 02:49:26 +08:00
|
|
|
tf.status = ATA_BUSY;
|
2010-03-28 12:22:14 +08:00
|
|
|
ata_tf_to_fis(&tf, 0, 0, d2h_fis);
|
2007-09-23 12:19:54 +08:00
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
rc = sata_link_hardreset(link, sata_ehc_deb_timing(&link->eh_context),
|
|
|
|
|
deadline, &online, NULL);
|
2007-07-18 03:48:48 +08:00
|
|
|
|
2014-02-22 23:53:30 +08:00
|
|
|
hpriv->start_engine(ap);
|
2006-07-26 14:59:26 +08:00
|
|
|
|
2010-03-28 12:22:14 +08:00
|
|
|
/* The pseudo configuration device on SIMG4726 attached to
|
|
|
|
|
* ASUS P5W-DH Deluxe doesn't send signature FIS after
|
|
|
|
|
* hardreset if no device is attached to the first downstream
|
|
|
|
|
* port && the pseudo device locks up on SRST w/ PMP==0. To
|
|
|
|
|
* work around this, wait for !BSY only briefly. If BSY isn't
|
|
|
|
|
* cleared, perform CLO and proceed to IDENTIFY (achieved by
|
|
|
|
|
* ATA_LFLAG_NO_SRST and ATA_LFLAG_ASSUME_ATA).
|
|
|
|
|
*
|
|
|
|
|
* Wait for two seconds. Devices attached to downstream port
|
|
|
|
|
* which can't process the following IDENTIFY after this will
|
|
|
|
|
* have to be reset again. For most cases, this should
|
|
|
|
|
* suffice while making probing snappish enough.
|
|
|
|
|
*/
|
|
|
|
|
if (online) {
|
|
|
|
|
rc = ata_wait_after_reset(link, jiffies + 2 * HZ,
|
|
|
|
|
ahci_check_ready);
|
|
|
|
|
if (rc)
|
|
|
|
|
ahci_kick_engine(ap);
|
2006-07-26 14:59:26 +08:00
|
|
|
}
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-09 03:23:55 +08:00
|
|
|
/*
|
|
|
|
|
* ahci_avn_hardreset - attempt more aggressive recovery of Avoton ports.
|
|
|
|
|
*
|
|
|
|
|
* It has been observed with some SSDs that the timing of events in the
|
|
|
|
|
* link synchronization phase can leave the port in a state that can not
|
|
|
|
|
* be recovered by a SATA-hard-reset alone. The failing signature is
|
|
|
|
|
* SStatus.DET stuck at 1 ("Device presence detected but Phy
|
|
|
|
|
* communication not established"). It was found that unloading and
|
|
|
|
|
* reloading the driver when this problem occurs allows the drive
|
|
|
|
|
* connection to be recovered (DET advanced to 0x3). The critical
|
|
|
|
|
* component of reloading the driver is that the port state machines are
|
|
|
|
|
* reset by bouncing "port enable" in the AHCI PCS configuration
|
|
|
|
|
* register. So, reproduce that effect by bouncing a port whenever we
|
|
|
|
|
* see DET==1 after a reset.
|
|
|
|
|
*/
|
|
|
|
|
static int ahci_avn_hardreset(struct ata_link *link, unsigned int *class,
|
|
|
|
|
unsigned long deadline)
|
|
|
|
|
{
|
2023-07-30 04:17:49 +08:00
|
|
|
const unsigned int *timing = sata_ehc_deb_timing(&link->eh_context);
|
2015-05-09 03:23:55 +08:00
|
|
|
struct ata_port *ap = link->ap;
|
|
|
|
|
struct ahci_port_priv *pp = ap->private_data;
|
|
|
|
|
struct ahci_host_priv *hpriv = ap->host->private_data;
|
|
|
|
|
u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
|
|
|
|
|
unsigned long tmo = deadline - jiffies;
|
|
|
|
|
struct ata_taskfile tf;
|
|
|
|
|
bool online;
|
|
|
|
|
int rc, i;
|
|
|
|
|
|
2018-04-13 12:32:30 +08:00
|
|
|
hpriv->stop_engine(ap);
|
2015-05-09 03:23:55 +08:00
|
|
|
|
|
|
|
|
for (i = 0; i < 2; i++) {
|
|
|
|
|
u16 val;
|
|
|
|
|
u32 sstatus;
|
|
|
|
|
int port = ap->port_no;
|
|
|
|
|
struct ata_host *host = ap->host;
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(host->dev);
|
|
|
|
|
|
|
|
|
|
/* clear D2H reception area to properly wait for D2H FIS */
|
|
|
|
|
ata_tf_init(link->device, &tf);
|
2022-02-16 02:49:26 +08:00
|
|
|
tf.status = ATA_BUSY;
|
2015-05-09 03:23:55 +08:00
|
|
|
ata_tf_to_fis(&tf, 0, 0, d2h_fis);
|
|
|
|
|
|
|
|
|
|
rc = sata_link_hardreset(link, timing, deadline, &online,
|
|
|
|
|
ahci_check_ready);
|
|
|
|
|
|
|
|
|
|
if (sata_scr_read(link, SCR_STATUS, &sstatus) != 0 ||
|
|
|
|
|
(sstatus & 0xf) != 1)
|
|
|
|
|
break;
|
|
|
|
|
|
2020-08-17 11:29:13 +08:00
|
|
|
ata_link_info(link, "avn bounce port%d\n", port);
|
2015-05-09 03:23:55 +08:00
|
|
|
|
|
|
|
|
pci_read_config_word(pdev, 0x92, &val);
|
|
|
|
|
val &= ~(1 << port);
|
|
|
|
|
pci_write_config_word(pdev, 0x92, val);
|
|
|
|
|
ata_msleep(ap, 1000);
|
|
|
|
|
val |= 1 << port;
|
|
|
|
|
pci_write_config_word(pdev, 0x92, val);
|
|
|
|
|
deadline += tmo;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
hpriv->start_engine(ap);
|
|
|
|
|
|
|
|
|
|
if (online)
|
|
|
|
|
*class = ahci_dev_classify(ap);
|
|
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2016-02-18 16:54:17 +08:00
|
|
|
#ifdef CONFIG_PM
|
|
|
|
|
static void ahci_pci_disable_interrupts(struct ata_host *host)
|
2006-07-26 14:59:26 +08:00
|
|
|
{
|
2009-05-30 19:50:12 +08:00
|
|
|
struct ahci_host_priv *hpriv = host->private_data;
|
2010-03-04 01:17:34 +08:00
|
|
|
void __iomem *mmio = hpriv->mmio;
|
2006-07-26 14:59:26 +08:00
|
|
|
u32 ctl;
|
|
|
|
|
|
2016-02-18 16:54:15 +08:00
|
|
|
/* AHCI spec rev1.1 section 8.3.3:
|
|
|
|
|
* Software must disable interrupts prior to requesting a
|
|
|
|
|
* transition of the HBA to D3 state.
|
|
|
|
|
*/
|
|
|
|
|
ctl = readl(mmio + HOST_CTL);
|
|
|
|
|
ctl &= ~HOST_IRQ_EN;
|
|
|
|
|
writel(ctl, mmio + HOST_CTL);
|
|
|
|
|
readl(mmio + HOST_CTL); /* flush */
|
2016-02-18 16:54:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ahci_pci_device_runtime_suspend(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(dev);
|
|
|
|
|
struct ata_host *host = pci_get_drvdata(pdev);
|
2006-07-26 14:59:26 +08:00
|
|
|
|
2016-02-18 16:54:17 +08:00
|
|
|
ahci_pci_disable_interrupts(host);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ahci_pci_device_runtime_resume(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(dev);
|
|
|
|
|
struct ata_host *host = pci_get_drvdata(pdev);
|
|
|
|
|
int rc;
|
|
|
|
|
|
2022-12-09 17:26:34 +08:00
|
|
|
rc = ahci_pci_reset_controller(host);
|
2016-02-18 16:54:17 +08:00
|
|
|
if (rc)
|
|
|
|
|
return rc;
|
|
|
|
|
ahci_pci_init_controller(host);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
|
static int ahci_pci_device_suspend(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(dev);
|
|
|
|
|
struct ata_host *host = pci_get_drvdata(pdev);
|
|
|
|
|
struct ahci_host_priv *hpriv = host->private_data;
|
|
|
|
|
|
|
|
|
|
if (hpriv->flags & AHCI_HFLAG_NO_SUSPEND) {
|
|
|
|
|
dev_err(&pdev->dev,
|
|
|
|
|
"BIOS update required for suspend/resume\n");
|
|
|
|
|
return -EIO;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ahci_pci_disable_interrupts(host);
|
2022-02-03 04:58:21 +08:00
|
|
|
ata_host_suspend(host, PMSG_SUSPEND);
|
|
|
|
|
return 0;
|
2006-07-26 14:59:26 +08:00
|
|
|
}
|
|
|
|
|
|
2016-02-18 16:54:15 +08:00
|
|
|
static int ahci_pci_device_resume(struct device *dev)
|
2006-07-26 14:59:26 +08:00
|
|
|
{
|
2016-02-18 16:54:15 +08:00
|
|
|
struct pci_dev *pdev = to_pci_dev(dev);
|
2013-06-03 13:05:36 +08:00
|
|
|
struct ata_host *host = pci_get_drvdata(pdev);
|
2006-07-26 14:59:26 +08:00
|
|
|
int rc;
|
|
|
|
|
|
2013-11-19 08:06:38 +08:00
|
|
|
/* Apple BIOS helpfully mangles the registers on resume */
|
|
|
|
|
if (is_mcp89_apple(pdev))
|
|
|
|
|
ahci_mcp89_apple_enable(pdev);
|
|
|
|
|
|
2006-07-26 14:59:26 +08:00
|
|
|
if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
|
2022-12-09 17:26:34 +08:00
|
|
|
rc = ahci_pci_reset_controller(host);
|
2006-07-26 14:59:26 +08:00
|
|
|
if (rc)
|
|
|
|
|
return rc;
|
|
|
|
|
|
2010-03-04 01:17:42 +08:00
|
|
|
ahci_pci_init_controller(host);
|
2006-07-26 14:59:26 +08:00
|
|
|
}
|
|
|
|
|
|
2006-08-24 15:19:22 +08:00
|
|
|
ata_host_resume(host);
|
2006-07-26 14:59:26 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2007-03-02 16:31:26 +08:00
|
|
|
#endif
|
2006-07-26 14:59:26 +08:00
|
|
|
|
2016-02-18 16:54:17 +08:00
|
|
|
#endif /* CONFIG_PM */
|
|
|
|
|
|
ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
observed that was immediately preceded by the following kernel
messages:
ahci 0000:28:00.0: Using 64-bit DMA addresses
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
The first message is produced by code in drivers/iommu/dma-iommu.c
which is accompanied by the following comment that seems to apply:
/*
* Try to use all the 32-bit PCI addresses first. The original SAC vs.
* DAC reasoning loses relevance with PCIe, but enough hardware and
* firmware bugs are still lurking out there that it's safest not to
* venture into the 64-bit space until necessary.
*
* If your device goes wrong after seeing the notice then likely either
* its driver is not setting DMA masks accurately, the hardware has
* some inherent bug in handling >32-bit addresses, or not all the
* expected address bits are wired up between the device and the IOMMU.
*/
Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
address 0xffffffff00000000 produces the following I/O page faults:
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
Note that the upper 21 bits of the logged DMA address are zero. (When
asking a different PCIe device in the same PCIe slot to DMA to the
same I/O virtual address, we do see all the upper 32 bits of the DMA
address as 1, so this is not an issue with the chipset or IOMMU
configuration on the test system.)
Also, hacking libahci to always set the upper 21 bits of all DMA
addresses to 1 produces no discernible effect on the behavior of the
ASM1061, and mkfs/mount/scrub/etc work as without this hack.
This all strongly suggests that the ASM1061 has a 43 bit DMA address
limit, and this commit therefore adds a quirk to deal with this limit.
This issue probably applies to (some of) the other supported ASMedia
parts as well, but we limit it to the PCI IDs known to refer to
ASM1061 parts, as that's the only part we know for sure to be affected
by this issue at this point.
Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
[cassel: drop date from error messages in commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-01-25 23:04:01 +08:00
|
|
|
static int ahci_configure_dma_masks(struct pci_dev *pdev,
|
|
|
|
|
struct ahci_host_priv *hpriv)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
observed that was immediately preceded by the following kernel
messages:
ahci 0000:28:00.0: Using 64-bit DMA addresses
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
The first message is produced by code in drivers/iommu/dma-iommu.c
which is accompanied by the following comment that seems to apply:
/*
* Try to use all the 32-bit PCI addresses first. The original SAC vs.
* DAC reasoning loses relevance with PCIe, but enough hardware and
* firmware bugs are still lurking out there that it's safest not to
* venture into the 64-bit space until necessary.
*
* If your device goes wrong after seeing the notice then likely either
* its driver is not setting DMA masks accurately, the hardware has
* some inherent bug in handling >32-bit addresses, or not all the
* expected address bits are wired up between the device and the IOMMU.
*/
Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
address 0xffffffff00000000 produces the following I/O page faults:
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
Note that the upper 21 bits of the logged DMA address are zero. (When
asking a different PCIe device in the same PCIe slot to DMA to the
same I/O virtual address, we do see all the upper 32 bits of the DMA
address as 1, so this is not an issue with the chipset or IOMMU
configuration on the test system.)
Also, hacking libahci to always set the upper 21 bits of all DMA
addresses to 1 produces no discernible effect on the behavior of the
ASM1061, and mkfs/mount/scrub/etc work as without this hack.
This all strongly suggests that the ASM1061 has a 43 bit DMA address
limit, and this commit therefore adds a quirk to deal with this limit.
This issue probably applies to (some of) the other supported ASMedia
parts as well, but we limit it to the PCI IDs known to refer to
ASM1061 parts, as that's the only part we know for sure to be affected
by this issue at this point.
Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
[cassel: drop date from error messages in commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-01-25 23:04:01 +08:00
|
|
|
int dma_bits;
|
2005-04-17 06:20:36 +08:00
|
|
|
int rc;
|
|
|
|
|
|
ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
observed that was immediately preceded by the following kernel
messages:
ahci 0000:28:00.0: Using 64-bit DMA addresses
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
The first message is produced by code in drivers/iommu/dma-iommu.c
which is accompanied by the following comment that seems to apply:
/*
* Try to use all the 32-bit PCI addresses first. The original SAC vs.
* DAC reasoning loses relevance with PCIe, but enough hardware and
* firmware bugs are still lurking out there that it's safest not to
* venture into the 64-bit space until necessary.
*
* If your device goes wrong after seeing the notice then likely either
* its driver is not setting DMA masks accurately, the hardware has
* some inherent bug in handling >32-bit addresses, or not all the
* expected address bits are wired up between the device and the IOMMU.
*/
Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
address 0xffffffff00000000 produces the following I/O page faults:
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
Note that the upper 21 bits of the logged DMA address are zero. (When
asking a different PCIe device in the same PCIe slot to DMA to the
same I/O virtual address, we do see all the upper 32 bits of the DMA
address as 1, so this is not an issue with the chipset or IOMMU
configuration on the test system.)
Also, hacking libahci to always set the upper 21 bits of all DMA
addresses to 1 produces no discernible effect on the behavior of the
ASM1061, and mkfs/mount/scrub/etc work as without this hack.
This all strongly suggests that the ASM1061 has a 43 bit DMA address
limit, and this commit therefore adds a quirk to deal with this limit.
This issue probably applies to (some of) the other supported ASMedia
parts as well, but we limit it to the PCI IDs known to refer to
ASM1061 parts, as that's the only part we know for sure to be affected
by this issue at this point.
Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
[cassel: drop date from error messages in commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-01-25 23:04:01 +08:00
|
|
|
if (hpriv->cap & HOST_CAP_64) {
|
|
|
|
|
dma_bits = 64;
|
|
|
|
|
if (hpriv->flags & AHCI_HFLAG_43BIT_ONLY)
|
|
|
|
|
dma_bits = 43;
|
|
|
|
|
} else {
|
|
|
|
|
dma_bits = 32;
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-06 20:33:39 +08:00
|
|
|
/*
|
|
|
|
|
* If the device fixup already set the dma_mask to some non-standard
|
|
|
|
|
* value, don't extend it here. This happens on STA2X11, for example.
|
2019-08-26 18:57:19 +08:00
|
|
|
*
|
|
|
|
|
* XXX: manipulating the DMA mask from platform code is completely
|
2019-11-21 17:26:44 +08:00
|
|
|
* bogus, platform code should use dev->bus_dma_limit instead..
|
2012-01-06 20:33:39 +08:00
|
|
|
*/
|
|
|
|
|
if (pdev->dma_mask && pdev->dma_mask < DMA_BIT_MASK(32))
|
|
|
|
|
return 0;
|
|
|
|
|
|
2019-08-26 18:57:19 +08:00
|
|
|
rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(dma_bits));
|
|
|
|
|
if (rc)
|
|
|
|
|
dev_err(&pdev->dev, "DMA enable failed\n");
|
|
|
|
|
return rc;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2010-03-04 01:17:43 +08:00
|
|
|
static void ahci_pci_print_info(struct ata_host *host)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(host->dev);
|
|
|
|
|
u16 cc;
|
|
|
|
|
const char *scc_s;
|
|
|
|
|
|
|
|
|
|
pci_read_config_word(pdev, 0x0a, &cc);
|
|
|
|
|
if (cc == PCI_CLASS_STORAGE_IDE)
|
|
|
|
|
scc_s = "IDE";
|
|
|
|
|
else if (cc == PCI_CLASS_STORAGE_SATA)
|
|
|
|
|
scc_s = "SATA";
|
|
|
|
|
else if (cc == PCI_CLASS_STORAGE_RAID)
|
|
|
|
|
scc_s = "RAID";
|
|
|
|
|
else
|
|
|
|
|
scc_s = "unknown";
|
|
|
|
|
|
|
|
|
|
ahci_print_info(host, scc_s);
|
|
|
|
|
}
|
|
|
|
|
|
2007-10-25 13:59:16 +08:00
|
|
|
/* On ASUS P5W DH Deluxe, the second port of PCI device 00:1f.2 is
|
|
|
|
|
* hardwired to on-board SIMG 4726. The chipset is ICH8 and doesn't
|
|
|
|
|
* support PMP and the 4726 either directly exports the device
|
|
|
|
|
* attached to the first downstream port or acts as a hardware storage
|
|
|
|
|
* controller and emulate a single ATA device (can be RAID 0/1 or some
|
|
|
|
|
* other configuration).
|
|
|
|
|
*
|
|
|
|
|
* When there's no device attached to the first downstream port of the
|
|
|
|
|
* 4726, "Config Disk" appears, which is a pseudo ATA device to
|
|
|
|
|
* configure the 4726. However, ATA emulation of the device is very
|
|
|
|
|
* lame. It doesn't send signature D2H Reg FIS after the initial
|
|
|
|
|
* hardreset, pukes on SRST w/ PMP==0 and has bunch of other issues.
|
|
|
|
|
*
|
|
|
|
|
* The following function works around the problem by always using
|
|
|
|
|
* hardreset on the port and not depending on receiving signature FIS
|
|
|
|
|
* afterward. If signature FIS isn't received soon, ATA class is
|
|
|
|
|
* assumed without follow-up softreset.
|
|
|
|
|
*/
|
|
|
|
|
static void ahci_p5wdh_workaround(struct ata_host *host)
|
|
|
|
|
{
|
2014-08-31 16:57:09 +08:00
|
|
|
static const struct dmi_system_id sysids[] = {
|
2007-10-25 13:59:16 +08:00
|
|
|
{
|
|
|
|
|
.ident = "P5W DH Deluxe",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR,
|
|
|
|
|
"ASUSTEK COMPUTER INC"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "P5W DH Deluxe"),
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
{ }
|
|
|
|
|
};
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(host->dev);
|
|
|
|
|
|
|
|
|
|
if (pdev->bus->number == 0 && pdev->devfn == PCI_DEVFN(0x1f, 2) &&
|
|
|
|
|
dmi_check_system(sysids)) {
|
|
|
|
|
struct ata_port *ap = host->ports[1];
|
|
|
|
|
|
2011-04-16 06:51:58 +08:00
|
|
|
dev_info(&pdev->dev,
|
|
|
|
|
"enabling ASUS P5W DH Deluxe on-board SIMG4726 workaround\n");
|
2007-10-25 13:59:16 +08:00
|
|
|
|
|
|
|
|
ap->ops = &ahci_p5wdh_ops;
|
|
|
|
|
ap->link.flags |= ATA_LFLAG_NO_SRST | ATA_LFLAG_ASSUME_ATA;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-11-19 08:06:38 +08:00
|
|
|
/*
|
|
|
|
|
* Macbook7,1 firmware forcibly disables MCP89 AHCI and changes PCI ID when
|
|
|
|
|
* booting in BIOS compatibility mode. We restore the registers but not ID.
|
|
|
|
|
*/
|
|
|
|
|
static void ahci_mcp89_apple_enable(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
|
|
printk(KERN_INFO "ahci: enabling MCP89 AHCI mode\n");
|
|
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, 0xf8, &val);
|
|
|
|
|
val |= 1 << 0x1b;
|
|
|
|
|
/* the following changes the device ID, but appears not to affect function */
|
|
|
|
|
/* val = (val & ~0xf0000000) | 0x80000000; */
|
|
|
|
|
pci_write_config_dword(pdev, 0xf8, val);
|
|
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, 0x54c, &val);
|
|
|
|
|
val |= 1 << 0xc;
|
|
|
|
|
pci_write_config_dword(pdev, 0x54c, val);
|
|
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, 0x4a4, &val);
|
|
|
|
|
val &= 0xff;
|
|
|
|
|
val |= 0x01060100;
|
|
|
|
|
pci_write_config_dword(pdev, 0x4a4, val);
|
|
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, 0x54c, &val);
|
|
|
|
|
val &= ~(1 << 0xc);
|
|
|
|
|
pci_write_config_dword(pdev, 0x54c, val);
|
|
|
|
|
|
|
|
|
|
pci_read_config_dword(pdev, 0xf8, &val);
|
|
|
|
|
val &= ~(1 << 0x1b);
|
|
|
|
|
pci_write_config_dword(pdev, 0xf8, val);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool is_mcp89_apple(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
return pdev->vendor == PCI_VENDOR_ID_NVIDIA &&
|
|
|
|
|
pdev->device == PCI_DEVICE_ID_NVIDIA_NFORCE_MCP89_SATA &&
|
|
|
|
|
pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE &&
|
|
|
|
|
pdev->subsystem_device == 0xcb89;
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-03 17:27:29 +08:00
|
|
|
/* only some SB600 ahci controllers can do 64bit DMA */
|
|
|
|
|
static bool ahci_sb600_enable_64bit(struct pci_dev *pdev)
|
2009-05-27 15:04:43 +08:00
|
|
|
{
|
|
|
|
|
static const struct dmi_system_id sysids[] = {
|
2009-08-16 20:04:02 +08:00
|
|
|
/*
|
|
|
|
|
* The oldest version known to be broken is 0901 and
|
|
|
|
|
* working is 1501 which was released on 2007-10-26.
|
2009-10-03 17:27:29 +08:00
|
|
|
* Enable 64bit DMA on 1501 and anything newer.
|
|
|
|
|
*
|
2009-08-16 20:04:02 +08:00
|
|
|
* Please read bko#9412 for more info.
|
|
|
|
|
*/
|
2009-05-27 15:04:43 +08:00
|
|
|
{
|
|
|
|
|
.ident = "ASUS M2A-VM",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR,
|
|
|
|
|
"ASUSTeK Computer INC."),
|
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "M2A-VM"),
|
|
|
|
|
},
|
2009-08-16 20:04:02 +08:00
|
|
|
.driver_data = "20071026", /* yyyymmdd */
|
2009-05-27 15:04:43 +08:00
|
|
|
},
|
2009-11-03 17:06:48 +08:00
|
|
|
/*
|
|
|
|
|
* All BIOS versions for the MSI K9A2 Platinum (MS-7376)
|
|
|
|
|
* support 64bit DMA.
|
|
|
|
|
*
|
|
|
|
|
* BIOS versions earlier than 1.5 had the Manufacturer DMI
|
|
|
|
|
* fields as "MICRO-STAR INTERANTIONAL CO.,LTD".
|
|
|
|
|
* This spelling mistake was fixed in BIOS version 1.5, so
|
|
|
|
|
* 1.5 and later have the Manufacturer as
|
|
|
|
|
* "MICRO-STAR INTERNATIONAL CO.,LTD".
|
|
|
|
|
* So try to match on DMI_BOARD_VENDOR of "MICRO-STAR INTER".
|
|
|
|
|
*
|
|
|
|
|
* BIOS versions earlier than 1.9 had a Board Product Name
|
|
|
|
|
* DMI field of "MS-7376". This was changed to be
|
|
|
|
|
* "K9A2 Platinum (MS-7376)" in version 1.9, but we can still
|
|
|
|
|
* match on DMI_BOARD_NAME of "MS-7376".
|
|
|
|
|
*/
|
|
|
|
|
{
|
|
|
|
|
.ident = "MSI K9A2 Platinum",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR,
|
|
|
|
|
"MICRO-STAR INTER"),
|
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "MS-7376"),
|
|
|
|
|
},
|
|
|
|
|
},
|
2012-06-28 10:32:14 +08:00
|
|
|
/*
|
|
|
|
|
* All BIOS versions for the MSI K9AGM2 (MS-7327) support
|
|
|
|
|
* 64bit DMA.
|
|
|
|
|
*
|
|
|
|
|
* This board also had the typo mentioned above in the
|
|
|
|
|
* Manufacturer DMI field (fixed in BIOS version 1.5), so
|
|
|
|
|
* match on DMI_BOARD_VENDOR of "MICRO-STAR INTER" again.
|
|
|
|
|
*/
|
|
|
|
|
{
|
|
|
|
|
.ident = "MSI K9AGM2",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR,
|
|
|
|
|
"MICRO-STAR INTER"),
|
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "MS-7327"),
|
|
|
|
|
},
|
|
|
|
|
},
|
2011-06-27 14:33:44 +08:00
|
|
|
/*
|
|
|
|
|
* All BIOS versions for the Asus M3A support 64bit DMA.
|
|
|
|
|
* (all release versions from 0301 to 1206 were tested)
|
|
|
|
|
*/
|
|
|
|
|
{
|
|
|
|
|
.ident = "ASUS M3A",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR,
|
|
|
|
|
"ASUSTeK Computer INC."),
|
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "M3A"),
|
|
|
|
|
},
|
|
|
|
|
},
|
2009-05-27 15:04:43 +08:00
|
|
|
{ }
|
|
|
|
|
};
|
2009-08-16 20:04:02 +08:00
|
|
|
const struct dmi_system_id *match;
|
2009-10-03 17:27:29 +08:00
|
|
|
int year, month, date;
|
|
|
|
|
char buf[9];
|
2009-05-27 15:04:43 +08:00
|
|
|
|
2009-08-16 20:04:02 +08:00
|
|
|
match = dmi_first_match(sysids);
|
2009-05-27 15:04:43 +08:00
|
|
|
if (pdev->bus->number != 0 || pdev->devfn != PCI_DEVFN(0x12, 0) ||
|
2009-08-16 20:04:02 +08:00
|
|
|
!match)
|
2009-05-27 15:04:43 +08:00
|
|
|
return false;
|
|
|
|
|
|
2009-11-03 17:06:48 +08:00
|
|
|
if (!match->driver_data)
|
|
|
|
|
goto enable_64bit;
|
|
|
|
|
|
2009-10-03 17:27:29 +08:00
|
|
|
dmi_get_date(DMI_BIOS_DATE, &year, &month, &date);
|
|
|
|
|
snprintf(buf, sizeof(buf), "%04d%02d%02d", year, month, date);
|
2009-08-16 20:04:02 +08:00
|
|
|
|
2009-11-03 17:06:48 +08:00
|
|
|
if (strcmp(buf, match->driver_data) >= 0)
|
|
|
|
|
goto enable_64bit;
|
|
|
|
|
else {
|
2011-04-16 06:51:58 +08:00
|
|
|
dev_warn(&pdev->dev,
|
|
|
|
|
"%s: BIOS too old, forcing 32bit DMA, update BIOS\n",
|
|
|
|
|
match->ident);
|
2009-10-03 17:27:29 +08:00
|
|
|
return false;
|
|
|
|
|
}
|
2009-11-03 17:06:48 +08:00
|
|
|
|
|
|
|
|
enable_64bit:
|
2011-04-16 06:51:58 +08:00
|
|
|
dev_warn(&pdev->dev, "%s: enabling 64bit DMA\n", match->ident);
|
2009-11-03 17:06:48 +08:00
|
|
|
return true;
|
2009-05-27 15:04:43 +08:00
|
|
|
}
|
|
|
|
|
|
2009-01-20 03:57:36 +08:00
|
|
|
static bool ahci_broken_system_poweroff(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
static const struct dmi_system_id broken_systems[] = {
|
|
|
|
|
{
|
|
|
|
|
.ident = "HP Compaq nx6310",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6310"),
|
|
|
|
|
},
|
|
|
|
|
/* PCI slot number of the controller */
|
|
|
|
|
.driver_data = (void *)0x1FUL,
|
|
|
|
|
},
|
2009-03-20 07:06:46 +08:00
|
|
|
{
|
|
|
|
|
.ident = "HP Compaq 6720s",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq 6720s"),
|
|
|
|
|
},
|
|
|
|
|
/* PCI slot number of the controller */
|
|
|
|
|
.driver_data = (void *)0x1FUL,
|
|
|
|
|
},
|
2009-01-20 03:57:36 +08:00
|
|
|
|
|
|
|
|
{ } /* terminate list */
|
|
|
|
|
};
|
|
|
|
|
const struct dmi_system_id *dmi = dmi_first_match(broken_systems);
|
|
|
|
|
|
|
|
|
|
if (dmi) {
|
|
|
|
|
unsigned long slot = (unsigned long)dmi->driver_data;
|
|
|
|
|
/* apply the quirk only to on-board controllers */
|
|
|
|
|
return slot == PCI_SLOT(pdev->devfn);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2009-05-30 19:50:12 +08:00
|
|
|
static bool ahci_broken_suspend(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
static const struct dmi_system_id sysids[] = {
|
|
|
|
|
/*
|
|
|
|
|
* On HP dv[4-6] and HDX18 with earlier BIOSen, link
|
|
|
|
|
* to the harddisk doesn't become online after
|
|
|
|
|
* resuming from STR. Warn and fail suspend.
|
2010-03-16 08:50:26 +08:00
|
|
|
*
|
|
|
|
|
* http://bugzilla.kernel.org/show_bug.cgi?id=12276
|
|
|
|
|
*
|
|
|
|
|
* Use dates instead of versions to match as HP is
|
|
|
|
|
* apparently recycling both product and version
|
|
|
|
|
* strings.
|
|
|
|
|
*
|
|
|
|
|
* http://bugzilla.kernel.org/show_bug.cgi?id=15462
|
2009-05-30 19:50:12 +08:00
|
|
|
*/
|
|
|
|
|
{
|
|
|
|
|
.ident = "dv4",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME,
|
|
|
|
|
"HP Pavilion dv4 Notebook PC"),
|
|
|
|
|
},
|
2010-03-16 08:50:26 +08:00
|
|
|
.driver_data = "20090105", /* F.30 */
|
2009-05-30 19:50:12 +08:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.ident = "dv5",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME,
|
|
|
|
|
"HP Pavilion dv5 Notebook PC"),
|
|
|
|
|
},
|
2010-03-16 08:50:26 +08:00
|
|
|
.driver_data = "20090506", /* F.16 */
|
2009-05-30 19:50:12 +08:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.ident = "dv6",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME,
|
|
|
|
|
"HP Pavilion dv6 Notebook PC"),
|
|
|
|
|
},
|
2010-03-16 08:50:26 +08:00
|
|
|
.driver_data = "20090423", /* F.21 */
|
2009-05-30 19:50:12 +08:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.ident = "HDX18",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME,
|
|
|
|
|
"HP HDX18 Notebook PC"),
|
|
|
|
|
},
|
2010-03-16 08:50:26 +08:00
|
|
|
.driver_data = "20090430", /* F.23 */
|
2009-05-30 19:50:12 +08:00
|
|
|
},
|
2010-01-28 15:04:15 +08:00
|
|
|
/*
|
|
|
|
|
* Acer eMachines G725 has the same problem. BIOS
|
|
|
|
|
* V1.03 is known to be broken. V3.04 is known to
|
2011-03-31 09:57:33 +08:00
|
|
|
* work. Between, there are V1.06, V2.06 and V3.03
|
2010-01-28 15:04:15 +08:00
|
|
|
* that we don't have much idea about. For now,
|
2024-07-26 10:07:17 +08:00
|
|
|
* assume that anything older than V3.04 is broken.
|
2010-03-16 08:50:26 +08:00
|
|
|
*
|
|
|
|
|
* http://bugzilla.kernel.org/show_bug.cgi?id=15104
|
2010-01-28 15:04:15 +08:00
|
|
|
*/
|
|
|
|
|
{
|
|
|
|
|
.ident = "G725",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "eMachines"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "eMachines G725"),
|
|
|
|
|
},
|
2010-03-16 08:50:26 +08:00
|
|
|
.driver_data = "20091216", /* V3.04 */
|
2010-01-28 15:04:15 +08:00
|
|
|
},
|
2009-05-30 19:50:12 +08:00
|
|
|
{ } /* terminate list */
|
|
|
|
|
};
|
|
|
|
|
const struct dmi_system_id *dmi = dmi_first_match(sysids);
|
2010-03-16 08:50:26 +08:00
|
|
|
int year, month, date;
|
|
|
|
|
char buf[9];
|
2009-05-30 19:50:12 +08:00
|
|
|
|
|
|
|
|
if (!dmi || pdev->bus->number || pdev->devfn != PCI_DEVFN(0x1f, 2))
|
|
|
|
|
return false;
|
|
|
|
|
|
2010-03-16 08:50:26 +08:00
|
|
|
dmi_get_date(DMI_BIOS_DATE, &year, &month, &date);
|
|
|
|
|
snprintf(buf, sizeof(buf), "%04d%02d%02d", year, month, date);
|
2009-05-30 19:50:12 +08:00
|
|
|
|
2010-03-16 08:50:26 +08:00
|
|
|
return strcmp(buf, dmi->driver_data) < 0;
|
2009-05-30 19:50:12 +08:00
|
|
|
}
|
|
|
|
|
|
2018-07-01 18:15:46 +08:00
|
|
|
static bool ahci_broken_lpm(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
static const struct dmi_system_id sysids[] = {
|
|
|
|
|
/* Various Lenovo 50 series have LPM issues with older BIOSen */
|
|
|
|
|
{
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X250"),
|
|
|
|
|
},
|
|
|
|
|
.driver_data = "20180406", /* 1.31 */
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad L450"),
|
|
|
|
|
},
|
|
|
|
|
.driver_data = "20180420", /* 1.28 */
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T450s"),
|
|
|
|
|
},
|
|
|
|
|
.driver_data = "20180315", /* 1.33 */
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W541"),
|
|
|
|
|
},
|
|
|
|
|
/*
|
|
|
|
|
* Note date based on release notes, 2.35 has been
|
|
|
|
|
* reported to be good, but I've been unable to get
|
|
|
|
|
* a hold of the reporter to get the DMI BIOS date.
|
|
|
|
|
* TODO: fix this.
|
|
|
|
|
*/
|
|
|
|
|
.driver_data = "20180310", /* 2.35 */
|
|
|
|
|
},
|
|
|
|
|
{ } /* terminate list */
|
|
|
|
|
};
|
|
|
|
|
const struct dmi_system_id *dmi = dmi_first_match(sysids);
|
|
|
|
|
int year, month, date;
|
|
|
|
|
char buf[9];
|
|
|
|
|
|
|
|
|
|
if (!dmi)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
dmi_get_date(DMI_BIOS_DATE, &year, &month, &date);
|
|
|
|
|
snprintf(buf, sizeof(buf), "%04d%02d%02d", year, month, date);
|
|
|
|
|
|
|
|
|
|
return strcmp(buf, dmi->driver_data) < 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-08-04 13:30:08 +08:00
|
|
|
static bool ahci_broken_online(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
#define ENCODE_BUSDEVFN(bus, slot, func) \
|
|
|
|
|
(void *)(unsigned long)(((bus) << 8) | PCI_DEVFN((slot), (func)))
|
|
|
|
|
static const struct dmi_system_id sysids[] = {
|
|
|
|
|
/*
|
|
|
|
|
* There are several gigabyte boards which use
|
|
|
|
|
* SIMG5723s configured as hardware RAID. Certain
|
|
|
|
|
* 5723 firmware revisions shipped there keep the link
|
|
|
|
|
* online but fail to answer properly to SRST or
|
|
|
|
|
* IDENTIFY when no device is attached downstream
|
|
|
|
|
* causing libata to retry quite a few times leading
|
|
|
|
|
* to excessive detection delay.
|
|
|
|
|
*
|
|
|
|
|
* As these firmwares respond to the second reset try
|
|
|
|
|
* with invalid device signature, considering unknown
|
|
|
|
|
* sig as offline works around the problem acceptably.
|
|
|
|
|
*/
|
|
|
|
|
{
|
|
|
|
|
.ident = "EP45-DQ6",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR,
|
|
|
|
|
"Gigabyte Technology Co., Ltd."),
|
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "EP45-DQ6"),
|
|
|
|
|
},
|
|
|
|
|
.driver_data = ENCODE_BUSDEVFN(0x0a, 0x00, 0),
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.ident = "EP45-DS5",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR,
|
|
|
|
|
"Gigabyte Technology Co., Ltd."),
|
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "EP45-DS5"),
|
|
|
|
|
},
|
|
|
|
|
.driver_data = ENCODE_BUSDEVFN(0x03, 0x00, 0),
|
|
|
|
|
},
|
|
|
|
|
{ } /* terminate list */
|
|
|
|
|
};
|
|
|
|
|
#undef ENCODE_BUSDEVFN
|
|
|
|
|
const struct dmi_system_id *dmi = dmi_first_match(sysids);
|
|
|
|
|
unsigned int val;
|
|
|
|
|
|
|
|
|
|
if (!dmi)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
val = (unsigned long)dmi->driver_data;
|
|
|
|
|
|
|
|
|
|
return pdev->bus->number == (val >> 8) && pdev->devfn == (val & 0xff);
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-09 11:41:47 +08:00
|
|
|
#ifdef CONFIG_ATA_ACPI
|
2009-09-16 03:18:03 +08:00
|
|
|
static void ahci_gtf_filter_workaround(struct ata_host *host)
|
|
|
|
|
{
|
|
|
|
|
static const struct dmi_system_id sysids[] = {
|
|
|
|
|
/*
|
|
|
|
|
* Aspire 3810T issues a bunch of SATA enable commands
|
|
|
|
|
* via _GTF including an invalid one and one which is
|
|
|
|
|
* rejected by the device. Among the successful ones
|
|
|
|
|
* is FPDMA non-zero offset enable which when enabled
|
|
|
|
|
* only on the drive side leads to NCQ command
|
|
|
|
|
* failures. Filter it out.
|
|
|
|
|
*/
|
|
|
|
|
{
|
|
|
|
|
.ident = "Aspire 3810T",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 3810T"),
|
|
|
|
|
},
|
|
|
|
|
.driver_data = (void *)ATA_ACPI_FILTER_FPDMA_OFFSET,
|
|
|
|
|
},
|
|
|
|
|
{ }
|
|
|
|
|
};
|
|
|
|
|
const struct dmi_system_id *dmi = dmi_first_match(sysids);
|
|
|
|
|
unsigned int filter;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (!dmi)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
filter = (unsigned long)dmi->driver_data;
|
2011-04-16 06:51:58 +08:00
|
|
|
dev_info(host->dev, "applying extra ACPI _GTF filter 0x%x for %s\n",
|
|
|
|
|
filter, dmi->ident);
|
2009-09-16 03:18:03 +08:00
|
|
|
|
|
|
|
|
for (i = 0; i < host->n_ports; i++) {
|
|
|
|
|
struct ata_port *ap = host->ports[i];
|
|
|
|
|
struct ata_link *link;
|
|
|
|
|
struct ata_device *dev;
|
|
|
|
|
|
|
|
|
|
ata_for_each_link(link, ap, EDGE)
|
|
|
|
|
ata_for_each_dev(dev, link, ALL)
|
|
|
|
|
dev->gtf_filter |= filter;
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-10-09 11:41:47 +08:00
|
|
|
#else
|
|
|
|
|
static inline void ahci_gtf_filter_workaround(struct ata_host *host)
|
|
|
|
|
{}
|
|
|
|
|
#endif
|
2009-09-16 03:18:03 +08:00
|
|
|
|
2017-05-09 20:47:22 +08:00
|
|
|
/*
|
|
|
|
|
* On the Acer Aspire Switch Alpha 12, sometimes all SATA ports are detected
|
|
|
|
|
* as DUMMY, or detected but eventually get a "link down" and never get up
|
|
|
|
|
* again. When this happens, CAP.NP may hold a value of 0x00 or 0x01, and the
|
|
|
|
|
* port_map may hold a value of 0x00.
|
|
|
|
|
*
|
|
|
|
|
* Overriding CAP.NP to 0x02 and the port_map to 0x7 will reveal all 3 ports
|
|
|
|
|
* and can significantly reduce the occurrence of the problem.
|
|
|
|
|
*
|
|
|
|
|
* https://bugzilla.kernel.org/show_bug.cgi?id=189471
|
|
|
|
|
*/
|
|
|
|
|
static void acer_sa5_271_workaround(struct ahci_host_priv *hpriv,
|
|
|
|
|
struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
static const struct dmi_system_id sysids[] = {
|
|
|
|
|
{
|
|
|
|
|
.ident = "Acer Switch Alpha 12",
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Switch SA5-271")
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
{ }
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
if (dmi_check_system(sysids)) {
|
|
|
|
|
dev_info(&pdev->dev, "enabling Acer Switch Alpha 12 workaround\n");
|
|
|
|
|
if ((hpriv->saved_cap & 0xC734FF00) == 0xC734FF00) {
|
|
|
|
|
hpriv->port_map = 0x7;
|
|
|
|
|
hpriv->cap = 0xC734FF02;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-17 04:08:49 +08:00
|
|
|
#ifdef CONFIG_ARM64
|
|
|
|
|
/*
|
|
|
|
|
* Due to ERRATA#22536, ThunderX needs to handle HOST_IRQ_STAT differently.
|
|
|
|
|
* Workaround is to make sure all pending IRQs are served before leaving
|
|
|
|
|
* handler.
|
|
|
|
|
*/
|
|
|
|
|
static irqreturn_t ahci_thunderx_irq_handler(int irq, void *dev_instance)
|
|
|
|
|
{
|
|
|
|
|
struct ata_host *host = dev_instance;
|
|
|
|
|
struct ahci_host_priv *hpriv;
|
|
|
|
|
unsigned int rc = 0;
|
|
|
|
|
void __iomem *mmio;
|
|
|
|
|
u32 irq_stat, irq_masked;
|
|
|
|
|
unsigned int handled = 1;
|
|
|
|
|
|
|
|
|
|
hpriv = host->private_data;
|
|
|
|
|
mmio = hpriv->mmio;
|
|
|
|
|
irq_stat = readl(mmio + HOST_IRQ_STAT);
|
|
|
|
|
if (!irq_stat)
|
|
|
|
|
return IRQ_NONE;
|
|
|
|
|
|
|
|
|
|
do {
|
|
|
|
|
irq_masked = irq_stat & hpriv->port_map;
|
|
|
|
|
spin_lock(&host->lock);
|
|
|
|
|
rc = ahci_handle_port_intr(host, irq_masked);
|
|
|
|
|
if (!rc)
|
|
|
|
|
handled = 0;
|
|
|
|
|
writel(irq_stat, mmio + HOST_IRQ_STAT);
|
|
|
|
|
irq_stat = readl(mmio + HOST_IRQ_STAT);
|
|
|
|
|
spin_unlock(&host->lock);
|
|
|
|
|
} while (irq_stat);
|
|
|
|
|
|
|
|
|
|
return IRQ_RETVAL(handled);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-12-03 02:31:03 +08:00
|
|
|
static void ahci_remap_check(struct pci_dev *pdev, int bar,
|
|
|
|
|
struct ahci_host_priv *hpriv)
|
|
|
|
|
{
|
2020-02-07 18:00:16 +08:00
|
|
|
int i;
|
2016-12-03 02:31:03 +08:00
|
|
|
u32 cap;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check if this device might have remapped nvme devices.
|
|
|
|
|
*/
|
|
|
|
|
if (pdev->vendor != PCI_VENDOR_ID_INTEL ||
|
|
|
|
|
pci_resource_len(pdev, bar) < SZ_512K ||
|
|
|
|
|
bar != AHCI_PCI_BAR_STANDARD ||
|
|
|
|
|
!(readl(hpriv->mmio + AHCI_VSCAP) & 1))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
cap = readq(hpriv->mmio + AHCI_REMAP_CAP);
|
|
|
|
|
for (i = 0; i < AHCI_MAX_REMAP; i++) {
|
|
|
|
|
if ((cap & (1 << i)) == 0)
|
|
|
|
|
continue;
|
|
|
|
|
if (readl(hpriv->mmio + ahci_remap_dcc(i))
|
|
|
|
|
!= PCI_CLASS_STORAGE_EXPRESS)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* We've found a remapped device */
|
2020-02-07 18:00:16 +08:00
|
|
|
hpriv->remapped_nvme++;
|
2016-12-03 02:31:03 +08:00
|
|
|
}
|
|
|
|
|
|
2020-02-07 18:00:16 +08:00
|
|
|
if (!hpriv->remapped_nvme)
|
2016-12-03 02:31:03 +08:00
|
|
|
return;
|
|
|
|
|
|
2020-02-07 18:00:16 +08:00
|
|
|
dev_warn(&pdev->dev, "Found %u remapped NVMe devices.\n",
|
|
|
|
|
hpriv->remapped_nvme);
|
2017-09-06 00:46:47 +08:00
|
|
|
dev_warn(&pdev->dev,
|
|
|
|
|
"Switch your BIOS from RAID to AHCI mode to use them.\n");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Don't rely on the msi-x capability in the remap case,
|
|
|
|
|
* share the legacy interrupt across ahci and remapped devices.
|
|
|
|
|
*/
|
|
|
|
|
hpriv->flags |= AHCI_HFLAG_NO_MSI;
|
2016-12-03 02:31:03 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-05 23:21:45 +08:00
|
|
|
static int ahci_get_irq_vector(struct ata_host *host, int port)
|
2012-11-19 23:02:48 +08:00
|
|
|
{
|
2016-09-05 23:21:45 +08:00
|
|
|
return pci_irq_vector(to_pci_dev(host->dev), port);
|
ahci: Add generic MSI-X support for single interrupts to SATA PCI driver
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: Robert Richter <rrichter@cavium.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2015-06-06 01:49:25 +08:00
|
|
|
}
|
|
|
|
|
|
2015-05-31 19:55:17 +08:00
|
|
|
static int ahci_init_msi(struct pci_dev *pdev, unsigned int n_ports,
|
|
|
|
|
struct ahci_host_priv *hpriv)
|
2012-11-19 23:02:48 +08:00
|
|
|
{
|
2016-09-05 23:21:45 +08:00
|
|
|
int nvec;
|
2012-11-19 23:02:48 +08:00
|
|
|
|
2013-12-30 15:28:14 +08:00
|
|
|
if (hpriv->flags & AHCI_HFLAG_NO_MSI)
|
2015-05-31 19:55:17 +08:00
|
|
|
return -ENODEV;
|
2013-12-30 15:28:14 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If number of MSIs is less than number of ports then Sharing Last
|
|
|
|
|
* Message mode could be enforced. In this case assume that advantage
|
|
|
|
|
* of multipe MSIs is negated and use single MSI mode instead.
|
|
|
|
|
*/
|
2016-10-18 15:00:52 +08:00
|
|
|
if (n_ports > 1) {
|
|
|
|
|
nvec = pci_alloc_irq_vectors(pdev, n_ports, INT_MAX,
|
|
|
|
|
PCI_IRQ_MSIX | PCI_IRQ_MSI);
|
|
|
|
|
if (nvec > 0) {
|
|
|
|
|
if (!(readl(hpriv->mmio + HOST_CTL) & HOST_MRSM)) {
|
|
|
|
|
hpriv->get_irq_vector = ahci_get_irq_vector;
|
|
|
|
|
hpriv->flags |= AHCI_HFLAG_MULTI_MSI;
|
|
|
|
|
return nvec;
|
|
|
|
|
}
|
2012-11-19 23:02:48 +08:00
|
|
|
|
2016-10-18 15:00:52 +08:00
|
|
|
/*
|
|
|
|
|
* Fallback to single MSI mode if the controller
|
|
|
|
|
* enforced MRSM mode.
|
|
|
|
|
*/
|
|
|
|
|
printk(KERN_INFO
|
|
|
|
|
"ahci: MRSM is on, fallback to single MSI\n");
|
|
|
|
|
pci_free_irq_vectors(pdev);
|
|
|
|
|
}
|
2016-10-20 23:15:41 +08:00
|
|
|
}
|
2015-11-12 08:27:33 +08:00
|
|
|
|
2016-09-05 23:21:45 +08:00
|
|
|
/*
|
|
|
|
|
* If the host is not capable of supporting per-port vectors, fall
|
|
|
|
|
* back to single MSI before finally attempting single MSI-X.
|
|
|
|
|
*/
|
|
|
|
|
nvec = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
|
|
|
|
|
if (nvec == 1)
|
ahci: Add generic MSI-X support for single interrupts to SATA PCI driver
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: Robert Richter <rrichter@cavium.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2015-06-06 01:49:25 +08:00
|
|
|
return nvec;
|
2016-09-05 23:21:45 +08:00
|
|
|
return pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSIX);
|
2012-11-19 23:02:48 +08:00
|
|
|
}
|
|
|
|
|
|
2024-02-07 05:13:42 +08:00
|
|
|
static void ahci_mark_external_port(struct ata_port *ap)
|
2018-07-28 04:47:03 +08:00
|
|
|
{
|
2024-02-07 05:13:42 +08:00
|
|
|
struct ahci_host_priv *hpriv = ap->host->private_data;
|
|
|
|
|
void __iomem *port_mmio = ahci_port_base(ap);
|
|
|
|
|
u32 tmp;
|
2018-07-28 04:47:03 +08:00
|
|
|
|
2024-02-07 05:13:43 +08:00
|
|
|
/* mark external ports (hotplug-capable, eSATA) */
|
2024-02-07 05:13:42 +08:00
|
|
|
tmp = readl(port_mmio + PORT_CMD);
|
2024-02-07 05:13:43 +08:00
|
|
|
if (((tmp & PORT_CMD_ESP) && (hpriv->cap & HOST_CAP_SXS)) ||
|
|
|
|
|
(tmp & PORT_CMD_HPCP))
|
2024-02-07 05:13:42 +08:00
|
|
|
ap->pflags |= ATA_PFLAG_EXTERNAL;
|
|
|
|
|
}
|
2018-07-28 04:47:03 +08:00
|
|
|
|
2024-02-07 05:13:44 +08:00
|
|
|
static void ahci_update_initial_lpm_policy(struct ata_port *ap)
|
2018-07-28 04:47:03 +08:00
|
|
|
{
|
2024-02-07 05:13:44 +08:00
|
|
|
struct ahci_host_priv *hpriv = ap->host->private_data;
|
2022-04-06 09:57:51 +08:00
|
|
|
int policy = CONFIG_SATA_MOBILE_LPM_POLICY;
|
2018-07-28 04:47:03 +08:00
|
|
|
|
ata: ahci: do not enable LPM on external ports
AHCI 1.3.3, 7.3.1.1 Software Flow for Hot Plug Removal Detection states:
"To reliably detect hot plug removals, software must disable interface
power management.
Software should perform the following initialization on a port after a
device is attached:
-Set PxSCTL.IPM to 3h to disable interface power management state
transitions.
-Set PxCMD.ALPE to ‘0’ to disable aggressive power management.
-Ensure PxIE.PRCE is set to ‘1’ to enable interrupts on hot plug removals.
-Disable device initiated interface power management by issuing the
appropriate SET FEATURES command."
Further, AHCI 1.3.3, 7.3 Native Hot Plug Support states:
"The HBA shall set the PxSERR.DIAG.X bit to ‘1’ when a COMINIT is received
from the device. Hot plug insertions are detected via the PxIS.PCS bit
that directly reflects the PxSERR.DIAG.X bit. The HBA shall set the
PxSERR.DIAG.N bit to ‘1’ when the HBA’s internal PhyRdy signal changes
state.
Hot plug removals are detected via the PxIS.PRCS bit that directly
reflects the PxSERR.DIAG.N bit. Note that PxSERR.DIAG.N is also set
to ‘1’ on insertions and during interface power management entry/exit."
ahci_set_lpm() already disables the PxIS.PRCS interrupt if setting a
LPM policy != ATA_LPM_MAX_POWER, so we cannot detect hot plug removals
when LPM policy != ATA_LPM_MAX_POWER.
We do have PxIS.PCS interrupt enabled even for LPM policy !=
ATA_LPM_MAX_POWER, so we should theoretically still be able to detect
hot plug insertions even when LPM is enabled.
However, in practise, for LPM policy ATA_LPM_MED_POWER_WITH_DIPM,
ATA_LPM_MIN_POWER_WITH_PARTIAL, and ATA_LPM_MIN_POWER, if there is
no link enabled, sata_link_scr_lpm() will set SControl.DET = 0x4,
which will transition the port to the "P:Offline" state.
The P:Offline mode is described in SATA Gold 3.5a:
4.1.1.103 Phy offline:
"In this mode the host Phy is forced off and the host Phy does not
recognize nor respond to COMINIT or COMWAKE. This mode is entered by
setting the DET field of the SControl register to 0100b. This is a
mechanism for the host to turn off its Phy."
So in the P:Offline state the PHY does not recognize the unsolicited
COMINIT which is sent on a hot plug insertion.
While we could change sata_link_scr_lpm() to never power off an external
port for LPM policy != ATA_LPM_MAX_POWER (in order be able to handle hot
plug insertions), we still would not be able to handle hot plug removals.
Thus, simply modify ahci_update_initial_lpm_policy() to not enable LPM if
the port advertises itself as an external port, as this function is
already being used to set/override the initial LPM policy.
Tested-by: Damien Le Moal <dlemoal@kernel.org>
Tested-by: Jian-Hong Pan <jhp@endlessos.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-07 05:13:45 +08:00
|
|
|
/*
|
|
|
|
|
* AHCI contains a known incompatibility between LPM and hot-plug
|
|
|
|
|
* removal events, see 7.3.1 Hot Plug Removal Detection and Power
|
|
|
|
|
* Management Interaction in AHCI 1.3.1. Therefore, do not enable
|
|
|
|
|
* LPM if the port advertises itself as an external port.
|
|
|
|
|
*/
|
2024-07-04 02:44:26 +08:00
|
|
|
if (ap->pflags & ATA_PFLAG_EXTERNAL) {
|
|
|
|
|
ata_port_dbg(ap, "external port, not enabling LPM\n");
|
2018-07-28 04:47:03 +08:00
|
|
|
return;
|
2024-07-04 02:44:26 +08:00
|
|
|
}
|
2018-07-28 04:47:03 +08:00
|
|
|
|
2024-06-18 23:28:29 +08:00
|
|
|
/* If no LPM states are supported by the HBA, do not bother with LPM */
|
|
|
|
|
if ((ap->host->flags & ATA_HOST_NO_PART) &&
|
|
|
|
|
(ap->host->flags & ATA_HOST_NO_SSC) &&
|
|
|
|
|
(ap->host->flags & ATA_HOST_NO_DEVSLP)) {
|
|
|
|
|
ata_port_dbg(ap, "no LPM states supported, not enabling LPM\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-28 04:47:03 +08:00
|
|
|
/* user modified policy via module param */
|
|
|
|
|
if (mobile_lpm_policy != -1) {
|
|
|
|
|
policy = mobile_lpm_policy;
|
|
|
|
|
goto update_policy;
|
|
|
|
|
}
|
|
|
|
|
|
2022-08-26 02:47:28 +08:00
|
|
|
if (policy > ATA_LPM_MED_POWER && pm_suspend_default_s2idle()) {
|
2018-07-28 04:47:03 +08:00
|
|
|
if (hpriv->cap & HOST_CAP_PART)
|
|
|
|
|
policy = ATA_LPM_MIN_POWER_WITH_PARTIAL;
|
|
|
|
|
else if (hpriv->cap & HOST_CAP_SSC)
|
|
|
|
|
policy = ATA_LPM_MIN_POWER;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
update_policy:
|
|
|
|
|
if (policy >= ATA_LPM_UNKNOWN && policy <= ATA_LPM_MIN_POWER)
|
|
|
|
|
ap->target_lpm_policy = policy;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-30 07:30:34 +08:00
|
|
|
static void ahci_intel_pcs_quirk(struct pci_dev *pdev, struct ahci_host_priv *hpriv)
|
|
|
|
|
{
|
|
|
|
|
u16 tmp16;
|
|
|
|
|
|
ahci: clean up intel_pcs_quirk
The comment in front of board_ahci_pcs7 is completely wrong.
It claims that board_ahci_pcs7 is needing the quirk, but in fact,
the logic implemented in ahci_intel_pcs_quirk() is the exact opposite,
only board_ahci_pcs7 is _excluded_ from the quirk.
This way of implementing a quirk is unconventional in several ways:
First of all because it has a board ID for which the quirk should _not_ be
applied (board_ahci_pcs7), instead of the usual way where we have a board
ID for which the quirk should be applied.
The second reason is that other than only excluding board_ahci_pcs7 from
the quirk, PCI devices that make use of the generic entry in ahci_pci_tbl
(which matches on AHCI class code) are also excluded.
This can of course lead to very subtle breakage, and did indeed do so in:
commit 104ff59af73a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"),
which added an explicit entry with board_ahci_low_power to ahci_pci_tbl.
This caused many users to complain that their SATA drives disappeared.
The logical assumption was of course that the issue was related to LPM,
and was therefore reverted in commit 6210038aeaf4 ("ata: ahci: Revert
"ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"").
It took a lot of time to figure out that this was all completely unrelated
to LPM, and was instead caused by an unconventional Intel quirk.
Clean up the quirk so that it behaves like other quirks, i.e. define a
board where the quirk is applied. Platforms that were using
board_ahci_pcs7 are converted to use board_ahci, this is safe since the
boards were identical, and board_ahci_pcs7 did not define any custom
port_ops.
This way, new Intel platforms can be added using the correct "board_ahci"
board, without getting any unexpected quirks applied.
This means that we currently have some modern platforms defined that are
using the Intel PCS quirk, but that is identical to the behavior that
was there before this commit.
No functional changes intended.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217114
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-02-09 21:03:06 +08:00
|
|
|
if (!(hpriv->flags & AHCI_HFLAG_INTEL_PCS_QUIRK))
|
2019-08-30 07:30:34 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* port_map is determined from PORTS_IMPL PCI register which is
|
|
|
|
|
* implemented as write or write-once register. If the register
|
|
|
|
|
* isn't programmed, ahci automatically generates it from number
|
|
|
|
|
* of ports, which is good enough for PCS programming. It is
|
|
|
|
|
* otherwise expected that platform firmware enables the ports
|
|
|
|
|
* before the OS boots.
|
|
|
|
|
*/
|
|
|
|
|
pci_read_config_word(pdev, PCS_6, &tmp16);
|
|
|
|
|
if ((tmp16 & hpriv->port_map) != hpriv->port_map) {
|
|
|
|
|
tmp16 |= hpriv->port_map;
|
|
|
|
|
pci_write_config_word(pdev, PCS_6, tmp16);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-07 18:00:16 +08:00
|
|
|
static ssize_t remapped_nvme_show(struct device *dev,
|
|
|
|
|
struct device_attribute *attr,
|
|
|
|
|
char *buf)
|
|
|
|
|
{
|
|
|
|
|
struct ata_host *host = dev_get_drvdata(dev);
|
|
|
|
|
struct ahci_host_priv *hpriv = host->private_data;
|
|
|
|
|
|
2021-12-02 14:02:17 +08:00
|
|
|
return sysfs_emit(buf, "%u\n", hpriv->remapped_nvme);
|
2020-02-07 18:00:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static DEVICE_ATTR_RO(remapped_nvme);
|
|
|
|
|
|
2007-01-20 15:00:28 +08:00
|
|
|
static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-06-09 23:13:04 +08:00
|
|
|
unsigned int board_id = ent->driver_data;
|
|
|
|
|
struct ata_port_info pi = ahci_port_info[board_id];
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
const struct ata_port_info *ppi[] = { &pi, NULL };
|
2007-01-20 15:00:28 +08:00
|
|
|
struct device *dev = &pdev->dev;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct ahci_host_priv *hpriv;
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
struct ata_host *host;
|
2014-09-25 21:13:21 +08:00
|
|
|
int n_ports, i, rc;
|
2012-01-06 20:33:39 +08:00
|
|
|
int ahci_pci_bar = AHCI_PCI_BAR_STANDARD;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-07-03 22:29:25 +08:00
|
|
|
WARN_ON((int)ATA_MAX_QUEUE > AHCI_MAX_CMDS);
|
2006-05-15 20:03:55 +08:00
|
|
|
|
2011-04-16 06:52:00 +08:00
|
|
|
ata_print_version_once(&pdev->dev, DRV_VERSION);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-09-03 21:48:34 +08:00
|
|
|
/* The AHCI driver can only drive the SATA ports, the PATA driver
|
|
|
|
|
can drive them all so if both drivers are selected make sure
|
|
|
|
|
AHCI stays out of the way */
|
|
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_MARVELL && !marvell_enable)
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
2013-11-19 08:06:38 +08:00
|
|
|
/* Apple BIOS on MCP89 prevents us using AHCI */
|
|
|
|
|
if (is_mcp89_apple(pdev))
|
|
|
|
|
ahci_mcp89_apple_enable(pdev);
|
2010-06-17 17:42:22 +08:00
|
|
|
|
2009-11-22 09:07:41 +08:00
|
|
|
/* Promise's PDC42819 is a SAS/SATA controller that has an AHCI mode.
|
|
|
|
|
* At the moment, we can only use the AHCI mode. Let the users know
|
|
|
|
|
* that for SAS drives they're out of luck.
|
|
|
|
|
*/
|
|
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_PROMISE)
|
2011-04-16 06:51:58 +08:00
|
|
|
dev_info(&pdev->dev,
|
|
|
|
|
"PDC42819 can only drive SATA devices with this driver\n");
|
2009-11-22 09:07:41 +08:00
|
|
|
|
2015-06-06 01:49:26 +08:00
|
|
|
/* Some devices use non-standard BARs */
|
2012-01-06 20:33:39 +08:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_STMICRO && pdev->device == 0xCC06)
|
|
|
|
|
ahci_pci_bar = AHCI_PCI_BAR_STA2X11;
|
2013-01-05 06:39:09 +08:00
|
|
|
else if (pdev->vendor == 0x1c44 && pdev->device == 0x8000)
|
|
|
|
|
ahci_pci_bar = AHCI_PCI_BAR_ENMOTUS;
|
2017-10-11 13:37:51 +08:00
|
|
|
else if (pdev->vendor == PCI_VENDOR_ID_CAVIUM) {
|
|
|
|
|
if (pdev->device == 0xa01c)
|
|
|
|
|
ahci_pci_bar = AHCI_PCI_BAR_CAVIUM;
|
|
|
|
|
if (pdev->device == 0xa084)
|
|
|
|
|
ahci_pci_bar = AHCI_PCI_BAR_CAVIUM_GEN5;
|
2020-03-10 20:50:08 +08:00
|
|
|
} else if (pdev->vendor == PCI_VENDOR_ID_LOONGSON) {
|
|
|
|
|
if (pdev->device == 0x7a08)
|
|
|
|
|
ahci_pci_bar = AHCI_PCI_BAR_LOONGSON;
|
2017-10-11 13:37:51 +08:00
|
|
|
}
|
2012-01-06 20:33:39 +08:00
|
|
|
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
/* acquire resources */
|
2007-01-20 15:00:28 +08:00
|
|
|
rc = pcim_enable_device(pdev);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (rc)
|
|
|
|
|
return rc;
|
|
|
|
|
|
2007-12-06 14:09:43 +08:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
|
|
|
|
|
(pdev->device == 0x2652 || pdev->device == 0x2653)) {
|
|
|
|
|
u8 map;
|
|
|
|
|
|
|
|
|
|
/* ICH6s share the same PCI ID for both piix and ahci
|
|
|
|
|
* modes. Enabling ahci mode while MAP indicates
|
|
|
|
|
* combined mode is a bad idea. Yield to ata_piix.
|
|
|
|
|
*/
|
|
|
|
|
pci_read_config_byte(pdev, ICH_MAP, &map);
|
|
|
|
|
if (map & 0x3) {
|
2011-04-16 06:51:58 +08:00
|
|
|
dev_info(&pdev->dev,
|
|
|
|
|
"controller is in combined mode, can't enable AHCI mode\n");
|
2007-12-06 14:09:43 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-16 18:34:21 +08:00
|
|
|
/* AHCI controllers often implement SFF compatible interface.
|
|
|
|
|
* Grab all PCI BARs just in case.
|
|
|
|
|
*/
|
|
|
|
|
rc = pcim_iomap_regions_request_all(pdev, 1 << ahci_pci_bar, DRV_NAME);
|
|
|
|
|
if (rc == -EBUSY)
|
|
|
|
|
pcim_pin_device(pdev);
|
|
|
|
|
if (rc)
|
|
|
|
|
return rc;
|
|
|
|
|
|
2007-01-20 15:00:28 +08:00
|
|
|
hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
|
|
|
|
|
if (!hpriv)
|
|
|
|
|
return -ENOMEM;
|
2007-09-23 12:19:55 +08:00
|
|
|
hpriv->flags |= (unsigned long)pi.private_data;
|
|
|
|
|
|
2008-06-09 23:13:04 +08:00
|
|
|
/* MCP65 revision A1 and A2 can't do MSI */
|
|
|
|
|
if (board_id == board_ahci_mcp65 &&
|
|
|
|
|
(pdev->revision == 0xa1 || pdev->revision == 0xa2))
|
|
|
|
|
hpriv->flags |= AHCI_HFLAG_NO_MSI;
|
|
|
|
|
|
2008-12-30 10:53:41 +08:00
|
|
|
/* SB800 does NOT need the workaround to ignore SERR_INTERNAL */
|
|
|
|
|
if (board_id == board_ahci_sb700 && pdev->revision >= 0x40)
|
|
|
|
|
hpriv->flags &= ~AHCI_HFLAG_IGN_SERR_INTERNAL;
|
|
|
|
|
|
2009-10-03 17:27:29 +08:00
|
|
|
/* only some SB600s can do 64bit DMA */
|
|
|
|
|
if (ahci_sb600_enable_64bit(pdev))
|
|
|
|
|
hpriv->flags &= ~AHCI_HFLAG_32BIT_ONLY;
|
2009-05-27 15:04:43 +08:00
|
|
|
|
2012-01-06 20:33:39 +08:00
|
|
|
hpriv->mmio = pcim_iomap_table(pdev)[ahci_pci_bar];
|
2010-03-04 01:17:34 +08:00
|
|
|
|
2016-12-03 02:31:03 +08:00
|
|
|
/* detect remapped nvme devices */
|
|
|
|
|
ahci_remap_check(pdev, ahci_pci_bar, hpriv);
|
|
|
|
|
|
2020-02-07 18:00:16 +08:00
|
|
|
sysfs_add_file_to_group(&pdev->dev.kobj,
|
|
|
|
|
&dev_attr_remapped_nvme.attr,
|
|
|
|
|
NULL);
|
|
|
|
|
|
2016-02-17 04:08:49 +08:00
|
|
|
#ifdef CONFIG_ARM64
|
2021-03-12 18:24:36 +08:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_HUAWEI &&
|
|
|
|
|
pdev->device == 0xa235 &&
|
|
|
|
|
pdev->revision < 0x30)
|
|
|
|
|
hpriv->flags |= AHCI_HFLAG_NO_SXS;
|
|
|
|
|
|
2016-02-17 04:08:49 +08:00
|
|
|
if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
|
|
|
|
|
hpriv->irq_handler = ahci_thunderx_irq_handler;
|
|
|
|
|
#endif
|
|
|
|
|
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
/* save initial config */
|
2010-03-04 01:17:36 +08:00
|
|
|
ahci_pci_save_initial_config(pdev, hpriv);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
/* prepare host */
|
2010-01-27 12:33:23 +08:00
|
|
|
if (hpriv->cap & HOST_CAP_NCQ) {
|
|
|
|
|
pi.flags |= ATA_FLAG_NCQ;
|
2010-03-30 09:28:32 +08:00
|
|
|
/*
|
|
|
|
|
* Auto-activate optimization is supposed to be
|
|
|
|
|
* supported on all AHCI controllers indicating NCQ
|
|
|
|
|
* capability, but it seems to be broken on some
|
|
|
|
|
* chipsets including NVIDIAs.
|
|
|
|
|
*/
|
|
|
|
|
if (!(hpriv->flags & AHCI_HFLAG_NO_FPDMA_AA))
|
2010-01-27 12:33:23 +08:00
|
|
|
pi.flags |= ATA_FLAG_FPDMA_AA;
|
2013-08-25 14:22:49 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* All AHCI controllers should be forward-compatible
|
|
|
|
|
* with the new auxiliary field. This code should be
|
|
|
|
|
* conditionalized if any buggy AHCI controllers are
|
|
|
|
|
* encountered.
|
|
|
|
|
*/
|
|
|
|
|
pi.flags |= ATA_FLAG_FPDMA_AUX;
|
2010-01-27 12:33:23 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-09-23 12:19:54 +08:00
|
|
|
if (hpriv->cap & HOST_CAP_PMP)
|
|
|
|
|
pi.flags |= ATA_FLAG_PMP;
|
|
|
|
|
|
2010-03-04 01:17:45 +08:00
|
|
|
ahci_set_em_messages(hpriv, &pi);
|
2008-06-04 01:33:55 +08:00
|
|
|
|
2009-01-20 03:57:36 +08:00
|
|
|
if (ahci_broken_system_poweroff(pdev)) {
|
|
|
|
|
pi.flags |= ATA_FLAG_NO_POWEROFF_SPINDOWN;
|
|
|
|
|
dev_info(&pdev->dev,
|
|
|
|
|
"quirky BIOS, skipping spindown on poweroff\n");
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-01 18:15:46 +08:00
|
|
|
if (ahci_broken_lpm(pdev)) {
|
|
|
|
|
pi.flags |= ATA_FLAG_NO_LPM;
|
|
|
|
|
dev_warn(&pdev->dev,
|
|
|
|
|
"BIOS update required for Link Power Management support\n");
|
|
|
|
|
}
|
|
|
|
|
|
2009-05-30 19:50:12 +08:00
|
|
|
if (ahci_broken_suspend(pdev)) {
|
|
|
|
|
hpriv->flags |= AHCI_HFLAG_NO_SUSPEND;
|
2011-04-16 06:51:58 +08:00
|
|
|
dev_warn(&pdev->dev,
|
|
|
|
|
"BIOS update required for suspend/resume\n");
|
2009-05-30 19:50:12 +08:00
|
|
|
}
|
|
|
|
|
|
2009-08-04 13:30:08 +08:00
|
|
|
if (ahci_broken_online(pdev)) {
|
|
|
|
|
hpriv->flags |= AHCI_HFLAG_SRST_TOUT_IS_OFFLINE;
|
|
|
|
|
dev_info(&pdev->dev,
|
|
|
|
|
"online status unreliable, applying workaround\n");
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-09 20:47:22 +08:00
|
|
|
|
|
|
|
|
/* Acer SA5-271 workaround modifies private_data */
|
|
|
|
|
acer_sa5_271_workaround(hpriv, pdev);
|
|
|
|
|
|
2008-02-06 14:13:51 +08:00
|
|
|
/* CAP.NP sometimes indicate the index of the last enabled
|
|
|
|
|
* port, at other times, that of the last possible port, so
|
|
|
|
|
* determining the maximum port number requires looking at
|
|
|
|
|
* both CAP.NP and port_map.
|
|
|
|
|
*/
|
|
|
|
|
n_ports = max(ahci_nr_ports(hpriv->cap), fls(hpriv->port_map));
|
|
|
|
|
|
|
|
|
|
host = ata_host_alloc_pinfo(&pdev->dev, ppi, n_ports);
|
2024-06-29 20:42:14 +08:00
|
|
|
if (!host) {
|
|
|
|
|
rc = -ENOMEM;
|
|
|
|
|
goto err_rm_sysfs_file;
|
|
|
|
|
}
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
host->private_data = hpriv;
|
2016-09-05 23:21:45 +08:00
|
|
|
|
|
|
|
|
if (ahci_init_msi(pdev, n_ports, hpriv) < 0) {
|
|
|
|
|
/* legacy intx interrupts */
|
|
|
|
|
pci_intx(pdev, 1);
|
|
|
|
|
}
|
2016-10-25 20:04:34 +08:00
|
|
|
hpriv->irq = pci_irq_vector(pdev, 0);
|
2015-05-31 19:55:18 +08:00
|
|
|
|
2009-01-26 18:05:44 +08:00
|
|
|
if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
|
2009-01-10 07:54:07 +08:00
|
|
|
host->flags |= ATA_HOST_PARALLEL_SCAN;
|
2009-01-26 18:05:44 +08:00
|
|
|
else
|
2013-10-05 08:15:16 +08:00
|
|
|
dev_info(&pdev->dev, "SSS flag set, parallel bus scan disabled\n");
|
2009-01-10 07:54:07 +08:00
|
|
|
|
ata: libata: disallow dev-initiated LPM transitions to unsupported states
In AHCI 1.3.1, the register description for CAP.SSC:
"When cleared to ‘0’, software must not allow the HBA to initiate
transitions to the Slumber state via agressive link power management nor
the PxCMD.ICC field in each port, and the PxSCTL.IPM field in each port
must be programmed to disallow device initiated Slumber requests."
In AHCI 1.3.1, the register description for CAP.PSC:
"When cleared to ‘0’, software must not allow the HBA to initiate
transitions to the Partial state via agressive link power management nor
the PxCMD.ICC field in each port, and the PxSCTL.IPM field in each port
must be programmed to disallow device initiated Partial requests."
Ensure that we always set the corresponding bits in PxSCTL.IPM, such that
a device is not allowed to initiate transitions to power states which are
unsupported by the HBA.
DevSleep is always initiated by the HBA, however, for completeness, set the
corresponding bit in PxSCTL.IPM such that agressive link power management
cannot transition to DevSleep if DevSleep is not supported.
sata_link_scr_lpm() is used by libahci, ata_piix and libata-pmp.
However, only libahci has the ability to read the CAP/CAP2 register to see
if these features are supported. Therefore, in order to not introduce any
regressions on ata_piix or libata-pmp, create flags that indicate that the
respective feature is NOT supported. This way, the behavior for ata_piix
and libata-pmp should remain unchanged.
This change is based on a patch originally submitted by Runa Guo-oc.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Fixes: 1152b2617a6e ("libata: implement sata_link_scr_lpm() and make ata_dev_set_feature() global")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2023-09-05 04:42:56 +08:00
|
|
|
if (!(hpriv->cap & HOST_CAP_PART))
|
|
|
|
|
host->flags |= ATA_HOST_NO_PART;
|
|
|
|
|
|
|
|
|
|
if (!(hpriv->cap & HOST_CAP_SSC))
|
|
|
|
|
host->flags |= ATA_HOST_NO_SSC;
|
|
|
|
|
|
|
|
|
|
if (!(hpriv->cap2 & HOST_CAP2_SDS))
|
|
|
|
|
host->flags |= ATA_HOST_NO_DEVSLP;
|
|
|
|
|
|
2008-06-04 01:33:55 +08:00
|
|
|
if (pi.flags & ATA_FLAG_EM)
|
|
|
|
|
ahci_reset_em(host);
|
|
|
|
|
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
for (i = 0; i < host->n_ports; i++) {
|
2007-05-28 20:33:01 +08:00
|
|
|
struct ata_port *ap = host->ports[i];
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
|
2012-01-06 20:33:39 +08:00
|
|
|
ata_port_pbar_desc(ap, ahci_pci_bar, -1, "abar");
|
|
|
|
|
ata_port_pbar_desc(ap, ahci_pci_bar,
|
2007-08-18 12:14:55 +08:00
|
|
|
0x100 + ap->port_no * 0x80, "port");
|
|
|
|
|
|
2008-06-04 01:33:55 +08:00
|
|
|
/* set enclosure management message type */
|
|
|
|
|
if (ap->flags & ATA_FLAG_EM)
|
2010-04-23 17:27:19 +08:00
|
|
|
ap->em_message_type = hpriv->em_msg_type;
|
2008-06-04 01:33:55 +08:00
|
|
|
|
2024-02-07 05:13:42 +08:00
|
|
|
ahci_mark_external_port(ap);
|
|
|
|
|
|
2024-02-07 05:13:44 +08:00
|
|
|
ahci_update_initial_lpm_policy(ap);
|
2008-06-04 01:33:55 +08:00
|
|
|
|
2007-05-28 20:33:01 +08:00
|
|
|
/* disabled/not-implemented port */
|
2008-04-07 21:47:21 +08:00
|
|
|
if (!(hpriv->port_map & (1 << i)))
|
2007-05-28 20:33:01 +08:00
|
|
|
ap->ops = &ata_dummy_port_ops;
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
}
|
2007-03-18 21:15:33 +08:00
|
|
|
|
2007-10-25 13:59:16 +08:00
|
|
|
/* apply workaround for ASUS P5W DH Deluxe mainboard */
|
|
|
|
|
ahci_p5wdh_workaround(host);
|
|
|
|
|
|
2009-09-16 03:18:03 +08:00
|
|
|
/* apply gtf filter quirk */
|
|
|
|
|
ahci_gtf_filter_workaround(host);
|
|
|
|
|
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
/* initialize adapter */
|
ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
observed that was immediately preceded by the following kernel
messages:
ahci 0000:28:00.0: Using 64-bit DMA addresses
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
The first message is produced by code in drivers/iommu/dma-iommu.c
which is accompanied by the following comment that seems to apply:
/*
* Try to use all the 32-bit PCI addresses first. The original SAC vs.
* DAC reasoning loses relevance with PCIe, but enough hardware and
* firmware bugs are still lurking out there that it's safest not to
* venture into the 64-bit space until necessary.
*
* If your device goes wrong after seeing the notice then likely either
* its driver is not setting DMA masks accurately, the hardware has
* some inherent bug in handling >32-bit addresses, or not all the
* expected address bits are wired up between the device and the IOMMU.
*/
Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
address 0xffffffff00000000 produces the following I/O page faults:
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
Note that the upper 21 bits of the logged DMA address are zero. (When
asking a different PCIe device in the same PCIe slot to DMA to the
same I/O virtual address, we do see all the upper 32 bits of the DMA
address as 1, so this is not an issue with the chipset or IOMMU
configuration on the test system.)
Also, hacking libahci to always set the upper 21 bits of all DMA
addresses to 1 produces no discernible effect on the behavior of the
ASM1061, and mkfs/mount/scrub/etc work as without this hack.
This all strongly suggests that the ASM1061 has a 43 bit DMA address
limit, and this commit therefore adds a quirk to deal with this limit.
This issue probably applies to (some of) the other supported ASMedia
parts as well, but we limit it to the PCI IDs known to refer to
ASM1061 parts, as that's the only part we know for sure to be affected
by this issue at this point.
Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
[cassel: drop date from error messages in commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2024-01-25 23:04:01 +08:00
|
|
|
rc = ahci_configure_dma_masks(pdev, hpriv);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (rc)
|
2024-06-29 20:42:14 +08:00
|
|
|
goto err_rm_sysfs_file;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2022-12-09 17:26:34 +08:00
|
|
|
rc = ahci_pci_reset_controller(host);
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
if (rc)
|
2024-06-29 20:42:14 +08:00
|
|
|
goto err_rm_sysfs_file;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-03-04 01:17:42 +08:00
|
|
|
ahci_pci_init_controller(host);
|
2010-03-04 01:17:43 +08:00
|
|
|
ahci_pci_print_info(host);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
libata: convert the remaining SATA drivers to new init model
Convert ahci, sata_sil, sata_sil24, sata_svw, sata_qstor, sata_mv,
sata_sx4, sata_vsc and sata_inic162x to new init model.
Now that host and ap are available during intialization, functions are
converted to take either host or ap instead of low level parameters
which were inevitable for functions shared between init and other
paths. This simplifies code quite a bit.
* init_one()'s now follow more consistent init order
* ahci_setup_port() and ahci_host_init() collapsed into
ahci_init_one() for init order consistency
* sata_vsc uses port_info instead of setting fields manually
* in sata_svw, k2_board_info converted to port_info (info is now in
port flags). port number is honored now.
Tested on ICH7/8 AHCI, jmb360, sil3112, 3114, 3124 and 3132.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-17 22:44:08 +08:00
|
|
|
pci_set_master(pdev);
|
2012-11-19 23:02:48 +08:00
|
|
|
|
2016-02-18 16:54:17 +08:00
|
|
|
rc = ahci_host_activate(host, &ahci_sht);
|
|
|
|
|
if (rc)
|
2024-06-29 20:42:14 +08:00
|
|
|
goto err_rm_sysfs_file;
|
2016-02-18 16:54:17 +08:00
|
|
|
|
|
|
|
|
pm_runtime_put_noidle(&pdev->dev);
|
|
|
|
|
return 0;
|
2024-06-29 20:42:14 +08:00
|
|
|
|
|
|
|
|
err_rm_sysfs_file:
|
|
|
|
|
sysfs_remove_file_from_group(&pdev->dev.kobj,
|
|
|
|
|
&dev_attr_remapped_nvme.attr, NULL);
|
|
|
|
|
return rc;
|
2016-02-18 16:54:17 +08:00
|
|
|
}
|
|
|
|
|
|
2020-01-25 11:37:29 +08:00
|
|
|
static void ahci_shutdown_one(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
ata_pci_shutdown_one(pdev);
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-18 16:54:17 +08:00
|
|
|
static void ahci_remove_one(struct pci_dev *pdev)
|
|
|
|
|
{
|
2020-02-07 18:00:16 +08:00
|
|
|
sysfs_remove_file_from_group(&pdev->dev.kobj,
|
|
|
|
|
&dev_attr_remapped_nvme.attr,
|
|
|
|
|
NULL);
|
2016-02-18 16:54:17 +08:00
|
|
|
pm_runtime_get_noresume(&pdev->dev);
|
|
|
|
|
ata_pci_remove_one(pdev);
|
2005-05-13 03:03:42 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-04-19 13:43:05 +08:00
|
|
|
module_pci_driver(ahci_pci_driver);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Jeff Garzik");
|
|
|
|
|
MODULE_DESCRIPTION("AHCI SATA low-level driver");
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
MODULE_DEVICE_TABLE(pci, ahci_pci_tbl);
|
2005-08-23 14:53:51 +08:00
|
|
|
MODULE_VERSION(DRV_VERSION);
|
