2019-05-27 14:55:05 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2005-11-04 08:50:04 +08:00
|
|
|
/*
|
2005-04-17 06:20:36 +08:00
|
|
|
* Copyright (C) 2001 Dave Engebretsen & Todd Inglett IBM Corporation.
|
2012-02-28 04:03:51 +08:00
|
|
|
* Copyright 2001-2012 IBM Corporation.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
2008-10-28 03:48:37 +08:00
|
|
|
#ifndef _POWERPC_EEH_H
|
|
|
|
#define _POWERPC_EEH_H
|
2005-12-17 05:43:46 +08:00
|
|
|
#ifdef __KERNEL__
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/string.h>
|
2013-06-20 13:21:01 +08:00
|
|
|
#include <linux/time.h>
|
2014-06-10 09:41:55 +08:00
|
|
|
#include <linux/atomic.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-03-26 13:42:07 +08:00
|
|
|
#include <uapi/asm/eeh.h>
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
struct pci_dev;
|
2006-02-25 01:34:23 +08:00
|
|
|
struct pci_bus;
|
2015-03-17 13:15:05 +08:00
|
|
|
struct pci_dn;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_EEH
|
|
|
|
|
2014-04-24 16:00:17 +08:00
|
|
|
/* EEH subsystem flags */
|
2018-03-23 10:10:52 +08:00
|
|
|
#define EEH_ENABLED 0x01 /* EEH enabled */
|
|
|
|
#define EEH_FORCE_DISABLED 0x02 /* EEH disabled */
|
|
|
|
#define EEH_PROBE_MODE_DEV 0x04 /* From PCI device */
|
|
|
|
#define EEH_PROBE_MODE_DEVTREE 0x08 /* From device tree */
|
|
|
|
#define EEH_ENABLE_IO_FOR_LOG 0x20 /* Enable IO for log */
|
|
|
|
#define EEH_EARLY_DUMP_LOG 0x40 /* Dump log immediately */
|
2014-04-24 16:00:17 +08:00
|
|
|
|
2014-04-24 16:00:23 +08:00
|
|
|
/*
|
|
|
|
* Delay for PE reset, all in ms
|
|
|
|
*
|
|
|
|
* PCI specification has reset hold time of 100 milliseconds.
|
|
|
|
* We have 250 milliseconds here. The PCI bus settlement time
|
|
|
|
* is specified as 1.5 seconds and we have 1.8 seconds.
|
|
|
|
*/
|
|
|
|
#define EEH_PE_RST_HOLD_TIME 250
|
|
|
|
#define EEH_PE_RST_SETTLE_TIME 1800
|
|
|
|
|
2012-09-08 06:44:05 +08:00
|
|
|
/*
|
|
|
|
* The struct is used to trace PE related EEH functionality.
|
|
|
|
* In theory, there will have one instance of the struct to
|
2016-06-01 14:34:37 +08:00
|
|
|
* be created against particular PE. In nature, PEs correlate
|
2012-09-08 06:44:05 +08:00
|
|
|
* to each other. the struct has to reflect that hierarchy in
|
|
|
|
* order to easily pick up those affected PEs when one particular
|
|
|
|
* PE has EEH errors.
|
|
|
|
*
|
|
|
|
* Also, one particular PE might be composed of PCI device, PCI
|
|
|
|
* bus and its subordinate components. The struct also need ship
|
|
|
|
* the information. Further more, one particular PE is only meaingful
|
|
|
|
* in the corresponding PHB. Therefore, the root PEs should be created
|
|
|
|
* against existing PHBs in on-to-one fashion.
|
|
|
|
*/
|
2012-09-12 03:16:16 +08:00
|
|
|
#define EEH_PE_INVALID (1 << 0) /* Invalid */
|
|
|
|
#define EEH_PE_PHB (1 << 1) /* PHB PE */
|
|
|
|
#define EEH_PE_DEVICE (1 << 2) /* Device PE */
|
|
|
|
#define EEH_PE_BUS (1 << 3) /* Bus PE */
|
2016-03-04 07:53:08 +08:00
|
|
|
#define EEH_PE_VF (1 << 4) /* VF PE */
|
2012-09-08 06:44:05 +08:00
|
|
|
|
|
|
|
#define EEH_PE_ISOLATED (1 << 0) /* Isolated PE */
|
|
|
|
#define EEH_PE_RECOVERING (1 << 1) /* Recovering PE */
|
2014-10-01 15:07:50 +08:00
|
|
|
#define EEH_PE_CFG_BLOCKED (1 << 2) /* Block config access */
|
2014-11-14 07:47:29 +08:00
|
|
|
#define EEH_PE_RESET (1 << 3) /* PE reset in progress */
|
2012-09-08 06:44:05 +08:00
|
|
|
|
2013-07-24 10:24:55 +08:00
|
|
|
#define EEH_PE_KEEP (1 << 8) /* Keep PE on hotplug */
|
2014-10-01 15:07:53 +08:00
|
|
|
#define EEH_PE_CFG_RESTRICTED (1 << 9) /* Block config on error */
|
2014-12-11 11:28:55 +08:00
|
|
|
#define EEH_PE_REMOVED (1 << 10) /* Removed permanently */
|
2016-02-09 12:50:21 +08:00
|
|
|
#define EEH_PE_PRI_BUS (1 << 11) /* Cached primary bus */
|
2013-07-24 10:24:55 +08:00
|
|
|
|
2012-09-08 06:44:05 +08:00
|
|
|
struct eeh_pe {
|
|
|
|
int type; /* PE type: PHB/Bus/Device */
|
|
|
|
int state; /* PE EEH dependent mode */
|
|
|
|
int addr; /* PE configuration address */
|
|
|
|
struct pci_controller *phb; /* Associated PHB */
|
2013-06-20 13:20:55 +08:00
|
|
|
struct pci_bus *bus; /* Top PCI bus for bus PE */
|
2012-09-08 06:44:05 +08:00
|
|
|
int check_count; /* Times of ignored error */
|
|
|
|
int freeze_count; /* Times of froze up */
|
2017-11-05 05:26:52 +08:00
|
|
|
time64_t tstamp; /* Time on first-time freeze */
|
2012-09-08 06:44:05 +08:00
|
|
|
int false_positives; /* Times of reported #ff's */
|
2014-06-10 09:41:55 +08:00
|
|
|
atomic_t pass_dev_cnt; /* Count of passed through devs */
|
2012-09-08 06:44:05 +08:00
|
|
|
struct eeh_pe *parent; /* Parent PE */
|
2014-07-17 12:41:43 +08:00
|
|
|
void *data; /* PE auxillary data */
|
2018-09-12 09:23:26 +08:00
|
|
|
struct list_head child_list; /* List of PEs below this PE */
|
|
|
|
struct list_head child; /* Memb. child_list/eeh_phb_pe */
|
|
|
|
struct list_head edevs; /* List of eeh_dev in this PE */
|
2019-09-03 18:15:56 +08:00
|
|
|
|
2019-09-13 21:32:13 +08:00
|
|
|
#ifdef CONFIG_STACKTRACE
|
2019-09-03 18:15:56 +08:00
|
|
|
/*
|
|
|
|
* Saved stack trace. When we find a PE freeze in eeh_dev_check_failure
|
|
|
|
* the stack trace is saved here so we can print it in the recovery
|
|
|
|
* thread if it turns out to due to a real problem rather than
|
|
|
|
* a hot-remove.
|
|
|
|
*
|
|
|
|
* A max of 64 entries might be overkill, but it also might not be.
|
|
|
|
*/
|
|
|
|
unsigned long stack_trace[64];
|
|
|
|
int trace_entries;
|
2019-09-13 21:32:13 +08:00
|
|
|
#endif /* CONFIG_STACKTRACE */
|
2012-09-08 06:44:05 +08:00
|
|
|
};
|
|
|
|
|
2013-07-24 10:24:56 +08:00
|
|
|
#define eeh_pe_for_each_dev(pe, edev, tmp) \
|
2018-09-12 09:23:26 +08:00
|
|
|
list_for_each_entry_safe(edev, tmp, &pe->edevs, entry)
|
2012-09-08 06:44:12 +08:00
|
|
|
|
2018-05-25 11:11:35 +08:00
|
|
|
#define eeh_for_each_pe(root, pe) \
|
|
|
|
for (pe = root; pe; pe = eeh_pe_next(pe, root))
|
|
|
|
|
2014-06-10 09:41:55 +08:00
|
|
|
static inline bool eeh_pe_passed(struct eeh_pe *pe)
|
|
|
|
{
|
|
|
|
return pe ? !!atomic_read(&pe->pass_dev_cnt) : false;
|
|
|
|
}
|
|
|
|
|
powerpc/eeh: Introduce EEH device
Original EEH implementation depends on struct pci_dn heavily. However,
EEH shouldn't depend on that actually because EEH needn't share much
information with other PCI components. That's to say, EEH should have
worked independently.
The patch introduces struct eeh_dev so that EEH core components needn't
be working based on struct pci_dn in future. Also, struct pci_dn, struct
eeh_dev instances are created in dynamic fasion and the binding with EEH
device, OF node, PCI device is implemented as well.
The EEH devices are created after PHBs are detected and initialized, but
PCI emunation hasn't started yet. Apart from that, PHB might be created
dynamically through DLPAR component and the EEH devices should be creatd
as well. Another case might be OF node is created dynamically by DR
(Dynamic Reconfiguration), which has been defined by PAPR. For those OF
nodes created by DR, EEH devices should be also created accordingly. The
binding between EEH device and OF node is done while the EEH device is
initially created.
The binding between EEH device and PCI device should be done after PCI
emunation is done. Besides, PCI hotplug also needs the binding so that
the EEH devices could be traced from the newly coming PCI buses or PCI
devices.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-02-28 04:04:04 +08:00
|
|
|
/*
|
|
|
|
* The struct is used to trace EEH state for the associated
|
|
|
|
* PCI device node or PCI device. In future, it might
|
|
|
|
* represent PE as well so that the EEH device to form
|
|
|
|
* another tree except the currently existing tree of PCI
|
|
|
|
* buses and PCI devices
|
|
|
|
*/
|
2013-07-24 10:24:59 +08:00
|
|
|
#define EEH_DEV_BRIDGE (1 << 0) /* PCI bridge */
|
|
|
|
#define EEH_DEV_ROOT_PORT (1 << 1) /* PCIe root port */
|
|
|
|
#define EEH_DEV_DS_PORT (1 << 2) /* Downstream port */
|
|
|
|
#define EEH_DEV_IRQ_DISABLED (1 << 3) /* Interrupt disabled */
|
|
|
|
#define EEH_DEV_DISCONNECTED (1 << 4) /* Removing from PE */
|
powerpc/eeh: Introduce EEH device
Original EEH implementation depends on struct pci_dn heavily. However,
EEH shouldn't depend on that actually because EEH needn't share much
information with other PCI components. That's to say, EEH should have
worked independently.
The patch introduces struct eeh_dev so that EEH core components needn't
be working based on struct pci_dn in future. Also, struct pci_dn, struct
eeh_dev instances are created in dynamic fasion and the binding with EEH
device, OF node, PCI device is implemented as well.
The EEH devices are created after PHBs are detected and initialized, but
PCI emunation hasn't started yet. Apart from that, PHB might be created
dynamically through DLPAR component and the EEH devices should be creatd
as well. Another case might be OF node is created dynamically by DR
(Dynamic Reconfiguration), which has been defined by PAPR. For those OF
nodes created by DR, EEH devices should be also created accordingly. The
binding between EEH device and OF node is done while the EEH device is
initially created.
The binding between EEH device and PCI device should be done after PCI
emunation is done. Besides, PCI hotplug also needs the binding so that
the EEH devices could be traced from the newly coming PCI buses or PCI
devices.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-02-28 04:04:04 +08:00
|
|
|
|
2014-01-12 14:13:45 +08:00
|
|
|
#define EEH_DEV_NO_HANDLER (1 << 8) /* No error handler */
|
|
|
|
#define EEH_DEV_SYSFS (1 << 9) /* Sysfs created */
|
powerpc/eeh: No hotplug on permanently removed dev
The issue was detected in a bit complicated test case where
we have multiple hierarchical PEs shown as following figure:
+-----------------+
| PE#3 p2p#0 |
| p2p#1 |
+-----------------+
|
+-----------------+
| PE#4 pdev#0 |
| pdev#1 |
+-----------------+
PE#4 (have 2 PCI devices) is the child of PE#3, which has 2 p2p
bridges. We accidentally had less-known scenario: PE#4 was removed
permanently from the system because of permanent failure (e.g.
exceeding the max allowd failure times in last hour), then we detects
EEH errors on PE#3 and tried to recover it. However, eeh_dev instances
for pdev#0/1 were not detached from PE#4, which was still connected to
PE#3. All of that was because of the fact that we rely on count-based
pcibios_release_device(), which isn't reliable enough. When doing
recovery for PE#3, we still apply hotplug on PE#4 and pdev#0/1, which
are not valid any more. Eventually, we run into kernel crash.
The patch fixes above issue from two aspects. For unplug, we simply
skip those permanently removed PE, whose state is (EEH_PE_STATE_ISOLATED
&& !EEH_PE_STATE_RECOVERING) and its frozen count should be greater
than EEH_MAX_ALLOWED_FREEZES. For plug, we marked all permanently
removed EEH devices with EEH_DEV_REMOVED and return 0xFF's on read
its PCI config so that PCI core will omit them.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-04-24 16:00:19 +08:00
|
|
|
#define EEH_DEV_REMOVED (1 << 10) /* Removed permanently */
|
2013-07-24 10:25:01 +08:00
|
|
|
|
powerpc/eeh: Introduce EEH device
Original EEH implementation depends on struct pci_dn heavily. However,
EEH shouldn't depend on that actually because EEH needn't share much
information with other PCI components. That's to say, EEH should have
worked independently.
The patch introduces struct eeh_dev so that EEH core components needn't
be working based on struct pci_dn in future. Also, struct pci_dn, struct
eeh_dev instances are created in dynamic fasion and the binding with EEH
device, OF node, PCI device is implemented as well.
The EEH devices are created after PHBs are detected and initialized, but
PCI emunation hasn't started yet. Apart from that, PHB might be created
dynamically through DLPAR component and the EEH devices should be creatd
as well. Another case might be OF node is created dynamically by DR
(Dynamic Reconfiguration), which has been defined by PAPR. For those OF
nodes created by DR, EEH devices should be also created accordingly. The
binding between EEH device and OF node is done while the EEH device is
initially created.
The binding between EEH device and PCI device should be done after PCI
emunation is done. Besides, PCI hotplug also needs the binding so that
the EEH devices could be traced from the newly coming PCI buses or PCI
devices.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-02-28 04:04:04 +08:00
|
|
|
struct eeh_dev {
|
|
|
|
int mode; /* EEH mode */
|
2019-08-16 12:48:11 +08:00
|
|
|
int bdfn; /* bdfn of device (for cfg ops) */
|
|
|
|
struct pci_controller *controller;
|
powerpc/eeh: Introduce EEH device
Original EEH implementation depends on struct pci_dn heavily. However,
EEH shouldn't depend on that actually because EEH needn't share much
information with other PCI components. That's to say, EEH should have
worked independently.
The patch introduces struct eeh_dev so that EEH core components needn't
be working based on struct pci_dn in future. Also, struct pci_dn, struct
eeh_dev instances are created in dynamic fasion and the binding with EEH
device, OF node, PCI device is implemented as well.
The EEH devices are created after PHBs are detected and initialized, but
PCI emunation hasn't started yet. Apart from that, PHB might be created
dynamically through DLPAR component and the EEH devices should be creatd
as well. Another case might be OF node is created dynamically by DR
(Dynamic Reconfiguration), which has been defined by PAPR. For those OF
nodes created by DR, EEH devices should be also created accordingly. The
binding between EEH device and OF node is done while the EEH device is
initially created.
The binding between EEH device and PCI device should be done after PCI
emunation is done. Besides, PCI hotplug also needs the binding so that
the EEH devices could be traced from the newly coming PCI buses or PCI
devices.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-02-28 04:04:04 +08:00
|
|
|
int pe_config_addr; /* PE config address */
|
|
|
|
u32 config_space[16]; /* Saved PCI config space */
|
2014-04-24 16:00:16 +08:00
|
|
|
int pcix_cap; /* Saved PCIx capability */
|
|
|
|
int pcie_cap; /* Saved PCIe capability */
|
|
|
|
int aer_cap; /* Saved AER capability */
|
2016-03-04 07:53:09 +08:00
|
|
|
int af_cap; /* Saved AF capability */
|
2012-09-08 06:44:05 +08:00
|
|
|
struct eeh_pe *pe; /* Associated PE */
|
2018-09-12 09:23:26 +08:00
|
|
|
struct list_head entry; /* Membership in eeh_pe.edevs */
|
|
|
|
struct list_head rmv_entry; /* Membership in rmv_list */
|
2015-03-17 13:15:05 +08:00
|
|
|
struct pci_dn *pdn; /* Associated PCI device node */
|
powerpc/eeh: Introduce EEH device
Original EEH implementation depends on struct pci_dn heavily. However,
EEH shouldn't depend on that actually because EEH needn't share much
information with other PCI components. That's to say, EEH should have
worked independently.
The patch introduces struct eeh_dev so that EEH core components needn't
be working based on struct pci_dn in future. Also, struct pci_dn, struct
eeh_dev instances are created in dynamic fasion and the binding with EEH
device, OF node, PCI device is implemented as well.
The EEH devices are created after PHBs are detected and initialized, but
PCI emunation hasn't started yet. Apart from that, PHB might be created
dynamically through DLPAR component and the EEH devices should be creatd
as well. Another case might be OF node is created dynamically by DR
(Dynamic Reconfiguration), which has been defined by PAPR. For those OF
nodes created by DR, EEH devices should be also created accordingly. The
binding between EEH device and OF node is done while the EEH device is
initially created.
The binding between EEH device and PCI device should be done after PCI
emunation is done. Besides, PCI hotplug also needs the binding so that
the EEH devices could be traced from the newly coming PCI buses or PCI
devices.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-02-28 04:04:04 +08:00
|
|
|
struct pci_dev *pdev; /* Associated PCI device */
|
2016-03-04 07:53:11 +08:00
|
|
|
bool in_error; /* Error flag for edev */
|
2020-07-25 16:12:20 +08:00
|
|
|
|
|
|
|
/* VF specific properties */
|
2016-03-04 07:53:07 +08:00
|
|
|
struct pci_dev *physfn; /* Associated SRIOV PF */
|
2020-07-25 16:12:20 +08:00
|
|
|
int vf_index; /* Index of this VF */
|
powerpc/eeh: Introduce EEH device
Original EEH implementation depends on struct pci_dn heavily. However,
EEH shouldn't depend on that actually because EEH needn't share much
information with other PCI components. That's to say, EEH should have
worked independently.
The patch introduces struct eeh_dev so that EEH core components needn't
be working based on struct pci_dn in future. Also, struct pci_dn, struct
eeh_dev instances are created in dynamic fasion and the binding with EEH
device, OF node, PCI device is implemented as well.
The EEH devices are created after PHBs are detected and initialized, but
PCI emunation hasn't started yet. Apart from that, PHB might be created
dynamically through DLPAR component and the EEH devices should be creatd
as well. Another case might be OF node is created dynamically by DR
(Dynamic Reconfiguration), which has been defined by PAPR. For those OF
nodes created by DR, EEH devices should be also created accordingly. The
binding between EEH device and OF node is done while the EEH device is
initially created.
The binding between EEH device and PCI device should be done after PCI
emunation is done. Besides, PCI hotplug also needs the binding so that
the EEH devices could be traced from the newly coming PCI buses or PCI
devices.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-02-28 04:04:04 +08:00
|
|
|
};
|
|
|
|
|
2019-08-16 12:48:12 +08:00
|
|
|
/* "fmt" must be a simple literal string */
|
|
|
|
#define EEH_EDEV_PRINT(level, edev, fmt, ...) \
|
|
|
|
pr_##level("PCI %04x:%02x:%02x.%x#%04x: EEH: " fmt, \
|
|
|
|
(edev)->controller->global_number, PCI_BUSNO((edev)->bdfn), \
|
|
|
|
PCI_SLOT((edev)->bdfn), PCI_FUNC((edev)->bdfn), \
|
|
|
|
((edev)->pe ? (edev)->pe_config_addr : 0xffff), ##__VA_ARGS__)
|
|
|
|
#define eeh_edev_dbg(edev, fmt, ...) EEH_EDEV_PRINT(debug, (edev), fmt, ##__VA_ARGS__)
|
|
|
|
#define eeh_edev_info(edev, fmt, ...) EEH_EDEV_PRINT(info, (edev), fmt, ##__VA_ARGS__)
|
|
|
|
#define eeh_edev_warn(edev, fmt, ...) EEH_EDEV_PRINT(warn, (edev), fmt, ##__VA_ARGS__)
|
|
|
|
#define eeh_edev_err(edev, fmt, ...) EEH_EDEV_PRINT(err, (edev), fmt, ##__VA_ARGS__)
|
|
|
|
|
2015-03-17 13:15:05 +08:00
|
|
|
static inline struct pci_dn *eeh_dev_to_pdn(struct eeh_dev *edev)
|
|
|
|
{
|
|
|
|
return edev ? edev->pdn : NULL;
|
|
|
|
}
|
|
|
|
|
powerpc/eeh: Introduce EEH device
Original EEH implementation depends on struct pci_dn heavily. However,
EEH shouldn't depend on that actually because EEH needn't share much
information with other PCI components. That's to say, EEH should have
worked independently.
The patch introduces struct eeh_dev so that EEH core components needn't
be working based on struct pci_dn in future. Also, struct pci_dn, struct
eeh_dev instances are created in dynamic fasion and the binding with EEH
device, OF node, PCI device is implemented as well.
The EEH devices are created after PHBs are detected and initialized, but
PCI emunation hasn't started yet. Apart from that, PHB might be created
dynamically through DLPAR component and the EEH devices should be creatd
as well. Another case might be OF node is created dynamically by DR
(Dynamic Reconfiguration), which has been defined by PAPR. For those OF
nodes created by DR, EEH devices should be also created accordingly. The
binding between EEH device and OF node is done while the EEH device is
initially created.
The binding between EEH device and PCI device should be done after PCI
emunation is done. Besides, PCI hotplug also needs the binding so that
the EEH devices could be traced from the newly coming PCI buses or PCI
devices.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-02-28 04:04:04 +08:00
|
|
|
static inline struct pci_dev *eeh_dev_to_pci_dev(struct eeh_dev *edev)
|
|
|
|
{
|
2013-06-05 15:34:03 +08:00
|
|
|
return edev ? edev->pdev : NULL;
|
powerpc/eeh: Introduce EEH device
Original EEH implementation depends on struct pci_dn heavily. However,
EEH shouldn't depend on that actually because EEH needn't share much
information with other PCI components. That's to say, EEH should have
worked independently.
The patch introduces struct eeh_dev so that EEH core components needn't
be working based on struct pci_dn in future. Also, struct pci_dn, struct
eeh_dev instances are created in dynamic fasion and the binding with EEH
device, OF node, PCI device is implemented as well.
The EEH devices are created after PHBs are detected and initialized, but
PCI emunation hasn't started yet. Apart from that, PHB might be created
dynamically through DLPAR component and the EEH devices should be creatd
as well. Another case might be OF node is created dynamically by DR
(Dynamic Reconfiguration), which has been defined by PAPR. For those OF
nodes created by DR, EEH devices should be also created accordingly. The
binding between EEH device and OF node is done while the EEH device is
initially created.
The binding between EEH device and PCI device should be done after PCI
emunation is done. Besides, PCI hotplug also needs the binding so that
the EEH devices could be traced from the newly coming PCI buses or PCI
devices.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-02-28 04:04:04 +08:00
|
|
|
}
|
|
|
|
|
2014-09-17 10:48:26 +08:00
|
|
|
static inline struct eeh_pe *eeh_dev_to_pe(struct eeh_dev* edev)
|
|
|
|
{
|
|
|
|
return edev ? edev->pe : NULL;
|
|
|
|
}
|
|
|
|
|
2014-01-15 13:16:11 +08:00
|
|
|
/* Return values from eeh_ops::next_error */
|
|
|
|
enum {
|
|
|
|
EEH_NEXT_ERR_NONE = 0,
|
|
|
|
EEH_NEXT_ERR_INF,
|
|
|
|
EEH_NEXT_ERR_FROZEN_PE,
|
|
|
|
EEH_NEXT_ERR_FENCED_PHB,
|
|
|
|
EEH_NEXT_ERR_DEAD_PHB,
|
|
|
|
EEH_NEXT_ERR_DEAD_IOC
|
|
|
|
};
|
|
|
|
|
2012-02-28 04:03:53 +08:00
|
|
|
/*
|
|
|
|
* The struct is used to trace the registered EEH operation
|
|
|
|
* callback functions. Actually, those operation callback
|
|
|
|
* functions are heavily platform dependent. That means the
|
|
|
|
* platform should register its own EEH operation callback
|
|
|
|
* functions before any EEH further operations.
|
|
|
|
*/
|
2012-02-28 04:03:55 +08:00
|
|
|
#define EEH_OPT_DISABLE 0 /* EEH disable */
|
|
|
|
#define EEH_OPT_ENABLE 1 /* EEH enable */
|
|
|
|
#define EEH_OPT_THAW_MMIO 2 /* MMIO enable */
|
|
|
|
#define EEH_OPT_THAW_DMA 3 /* DMA enable */
|
2014-09-30 10:38:52 +08:00
|
|
|
#define EEH_OPT_FREEZE_PE 4 /* Freeze PE */
|
2012-02-28 04:03:57 +08:00
|
|
|
#define EEH_STATE_UNAVAILABLE (1 << 0) /* State unavailable */
|
|
|
|
#define EEH_STATE_NOT_SUPPORT (1 << 1) /* EEH not supported */
|
|
|
|
#define EEH_STATE_RESET_ACTIVE (1 << 2) /* Active reset */
|
|
|
|
#define EEH_STATE_MMIO_ACTIVE (1 << 3) /* Active MMIO */
|
|
|
|
#define EEH_STATE_DMA_ACTIVE (1 << 4) /* Active DMA */
|
|
|
|
#define EEH_STATE_MMIO_ENABLED (1 << 5) /* MMIO enabled */
|
|
|
|
#define EEH_STATE_DMA_ENABLED (1 << 6) /* DMA enabled */
|
2012-02-28 04:03:59 +08:00
|
|
|
#define EEH_RESET_DEACTIVATE 0 /* Deactivate the PE reset */
|
|
|
|
#define EEH_RESET_HOT 1 /* Hot reset */
|
|
|
|
#define EEH_RESET_FUNDAMENTAL 3 /* Fundamental reset */
|
2012-02-28 04:04:00 +08:00
|
|
|
#define EEH_LOG_TEMP 1 /* EEH temporary error log */
|
|
|
|
#define EEH_LOG_PERM 2 /* EEH permanent error log */
|
2012-02-28 04:03:57 +08:00
|
|
|
|
2012-02-28 04:03:53 +08:00
|
|
|
struct eeh_ops {
|
|
|
|
char *name;
|
2020-03-06 15:39:04 +08:00
|
|
|
struct eeh_dev *(*probe)(struct pci_dev *pdev);
|
2012-09-08 06:44:14 +08:00
|
|
|
int (*set_option)(struct eeh_pe *pe, int option);
|
2018-09-12 09:23:32 +08:00
|
|
|
int (*get_state)(struct eeh_pe *pe, int *delay);
|
2012-09-08 06:44:14 +08:00
|
|
|
int (*reset)(struct eeh_pe *pe, int option);
|
|
|
|
int (*get_log)(struct eeh_pe *pe, int severity, char *drv_log, unsigned long len);
|
|
|
|
int (*configure_bridge)(struct eeh_pe *pe);
|
2014-09-30 10:38:56 +08:00
|
|
|
int (*err_inject)(struct eeh_pe *pe, int type, int func,
|
|
|
|
unsigned long addr, unsigned long mask);
|
2020-07-25 16:12:26 +08:00
|
|
|
int (*read_config)(struct eeh_dev *edev, int where, int size, u32 *val);
|
|
|
|
int (*write_config)(struct eeh_dev *edev, int where, int size, u32 val);
|
2013-06-20 13:21:04 +08:00
|
|
|
int (*next_error)(struct eeh_pe **pe);
|
2020-07-25 16:12:24 +08:00
|
|
|
int (*restore_config)(struct eeh_dev *edev);
|
2020-07-25 16:12:25 +08:00
|
|
|
int (*notify_resume)(struct eeh_dev *edev);
|
2012-02-28 04:03:53 +08:00
|
|
|
};
|
|
|
|
|
2014-04-24 16:00:17 +08:00
|
|
|
extern int eeh_subsystem_flags;
|
2019-02-15 08:48:11 +08:00
|
|
|
extern u32 eeh_max_freezes;
|
2019-02-15 08:48:16 +08:00
|
|
|
extern bool eeh_debugfs_no_recover;
|
2012-02-28 04:03:53 +08:00
|
|
|
extern struct eeh_ops *eeh_ops;
|
2013-06-20 13:21:03 +08:00
|
|
|
extern raw_spinlock_t confirm_error_lock;
|
2012-09-08 06:44:21 +08:00
|
|
|
|
2014-07-17 12:41:38 +08:00
|
|
|
static inline void eeh_add_flag(int flag)
|
2014-02-12 15:24:55 +08:00
|
|
|
{
|
2014-07-17 12:41:38 +08:00
|
|
|
eeh_subsystem_flags |= flag;
|
2014-02-12 15:24:55 +08:00
|
|
|
}
|
|
|
|
|
2014-07-17 12:41:38 +08:00
|
|
|
static inline void eeh_clear_flag(int flag)
|
2014-02-12 15:24:55 +08:00
|
|
|
{
|
2014-07-17 12:41:38 +08:00
|
|
|
eeh_subsystem_flags &= ~flag;
|
2014-02-12 15:24:55 +08:00
|
|
|
}
|
|
|
|
|
2014-07-17 12:41:38 +08:00
|
|
|
static inline bool eeh_has_flag(int flag)
|
2012-09-08 06:44:21 +08:00
|
|
|
{
|
2014-07-17 12:41:38 +08:00
|
|
|
return !!(eeh_subsystem_flags & flag);
|
2012-09-08 06:44:21 +08:00
|
|
|
}
|
|
|
|
|
2014-07-17 12:41:38 +08:00
|
|
|
static inline bool eeh_enabled(void)
|
2012-09-08 06:44:21 +08:00
|
|
|
{
|
2018-09-12 09:23:29 +08:00
|
|
|
return eeh_has_flag(EEH_ENABLED) && !eeh_has_flag(EEH_FORCE_DISABLED);
|
2012-09-08 06:44:21 +08:00
|
|
|
}
|
2012-09-08 06:44:06 +08:00
|
|
|
|
2013-06-20 13:21:03 +08:00
|
|
|
static inline void eeh_serialize_lock(unsigned long *flags)
|
|
|
|
{
|
|
|
|
raw_spin_lock_irqsave(&confirm_error_lock, *flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void eeh_serialize_unlock(unsigned long flags)
|
|
|
|
{
|
|
|
|
raw_spin_unlock_irqrestore(&confirm_error_lock, flags);
|
|
|
|
}
|
|
|
|
|
2018-03-19 10:49:23 +08:00
|
|
|
static inline bool eeh_state_active(int state)
|
|
|
|
{
|
|
|
|
return (state & (EEH_STATE_MMIO_ACTIVE | EEH_STATE_DMA_ACTIVE))
|
|
|
|
== (EEH_STATE_MMIO_ACTIVE | EEH_STATE_DMA_ACTIVE);
|
|
|
|
}
|
|
|
|
|
2019-08-16 12:48:15 +08:00
|
|
|
typedef void (*eeh_edev_traverse_func)(struct eeh_dev *edev, void *flag);
|
2018-05-25 11:11:32 +08:00
|
|
|
typedef void *(*eeh_pe_traverse_func)(struct eeh_pe *pe, void *flag);
|
2014-07-17 12:41:43 +08:00
|
|
|
void eeh_set_pe_aux_size(int size);
|
2012-12-22 06:04:10 +08:00
|
|
|
int eeh_phb_pe_create(struct pci_controller *phb);
|
2018-09-12 09:23:32 +08:00
|
|
|
int eeh_wait_state(struct eeh_pe *pe, int max_wait);
|
2013-06-20 13:20:53 +08:00
|
|
|
struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb);
|
2018-05-25 11:11:35 +08:00
|
|
|
struct eeh_pe *eeh_pe_next(struct eeh_pe *pe, struct eeh_pe *root);
|
powerpc/eeh: Clean up PE addressing
When support for EEH on PowerNV was added a lot of pseries specific code
was made "generic" and some of the quirks of pseries EEH came along for the
ride. One of the stranger quirks is eeh_pe containing two types of PE
address: pe->addr and pe->config_addr. There reason for this appears to be
historical baggage rather than any real requirements.
On pseries EEH PEs are manipulated using RTAS calls. Each EEH RTAS call
takes a "PE configuration address" as an input which is used to identify
which EEH PE is being manipulated by the call. When initialising the EEH
state for a device the first thing we need to do is determine the
configuration address for the PE which contains the device so we can enable
EEH on that PE. This process is outlined in PAPR which is the modern
(i.e post-2003) FW specification for pseries. However, EEH support was
first described in the pSeries RISC Platform Architecture (RPA) and
although they are mostly compatible EEH is one of the areas where they are
not.
The major difference is that RPA doesn't actually have the concept of a PE.
On RPA systems the EEH RTAS calls are done on a per-device basis using the
same config_addr that would be passed to the RTAS functions to access PCI
config space (e.g. ibm,read-pci-config). The config_addr is not identical
since the function and config register offsets of the config_addr must be
set to zero. EEH operations being done on a per-device basis doesn't make a
whole lot of sense when you consider how EEH was implemented on legacy PCI
systems.
For legacy PCI(-X) systems EEH was implemented using special PCI-PCI
bridges which contained logic to detect errors and freeze the secondary
bus when one occurred. This means that the EEH enabled state is shared
among all devices behind that EEH bridge. As a result there's no way to
implement the per-device control required for the semantics specified by
RPA. It can be made to work if we assume that a separate EEH bridge exists
for each EEH capable PCI slot and there are no bridges behind those slots.
However, RPA also specifies the ibm,configure-bridge RTAS call for
re-initalising bridges behind EEH capable slots after they are reset due
to an EEH event so that is probably not a valid assumption. This
incoherence was fixed in later PAPR, which succeeded RPA. Unfortunately,
since Linux EEH support seems to have been implemented based on the RPA
spec some of the legacy assumptions were carried over (probably for POWER4
compatibility).
The fix made in PAPR was the introduction of the "PE" concept and
redefining the EEH RTAS calls (set-eeh-option, reset-slot, etc) to operate
on a per-PE basis so all devices behind an EEH bride would share the same
EEH state. The "config_addr" argument to the EEH RTAS calls became the
"PE_config_addr" and the OS was required to use the
ibm,get-config-addr-info RTAS call to find the correct PE address for the
device. When support for the new interfaces was added to Linux it was
implemented using something like:
At probe time:
pdn->eeh_config_addr = rtas_config_addr(pdn);
pdn->eeh_pe_config_addr = rtas_get_config_addr_info(pdn);
When performing an RTAS call:
config_addr = pdn->eeh_config_addr;
if (pdn->eeh_pe_config_addr)
config_addr = pdn->eeh_pe_config_addr;
rtas_call(..., config_addr, ...);
In other words, if the ibm,get-config-addr-info RTAS call is implemented
and returned a valid result we'd use that as the argument to the EEH
RTAS calls. If not, Linux would fall back to using the device's
config_addr. Over time these addresses have moved around going from pci_dn
to eeh_dev and finally into eeh_pe. Today the users look like this:
config_addr = pe->config_addr;
if (pe->addr)
config_addr = pe->addr;
rtas_call(..., config_addr, ...);
However, considering the EEH core always operates on a per-PE basis and
even on pseries the only per-device operation is the initial call to
ibm,set-eeh-option I'm not sure if any of this actually works on an RPA
system today. It doesn't make much sense to have the fallback address in
a generic structure either since the bulk of the code which reference it
is in pseries anyway.
The EEH core makes a token effort to support looking up a PE using the
config_addr by having two arguments to eeh_pe_get(). However, a survey of
all the callers to eeh_pe_get() shows that all bar one have the config_addr
argument hard-coded to zero.The only caller that doesn't is in
eeh_pe_tree_insert() which has:
if (!eeh_has_flag(EEH_VALID_PE_ZERO) && !edev->pe_config_addr)
return -EINVAL;
pe = eeh_pe_get(hose, edev->pe_config_addr, edev->bdfn);
The third argument (config_addr) is only used if the second (pe->addr)
argument is invalid. The preceding check ensures that the call to
eeh_pe_get() will never happen if edev->pe_config_addr is invalid so there
is no situation where eeh_pe_get() will search for a PE based on the 3rd
argument. The check also means that we'll never insert a PE into the tree
where pe_config_addr is zero since EEH_VALID_PE_ZERO is never set on
pseries. All the users of the fallback address on pseries never actually
use the fallback and all the only caller that supplies something for the
config_addr argument to eeh_pe_get() never use it either. It's all dead
code.
This patch removes the fallback address from eeh_pe since nothing uses it.
Specificly, we do this by:
1) Removing pe->config_addr
2) Removing the EEH_VALID_PE_ZERO flag
3) Removing the fallback address argument to eeh_pe_get().
4) Removing all the checks for pe->addr being zero in the pseries EEH code.
This leaves us with PE's only being identified by what's in their pe->addr
field and the EEH core relying on the platform to ensure that eeh_dev's are
only inserted into the EEH tree if they're actually inside a PE.
No functional changes, I hope.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200918093050.37344-9-oohall@gmail.com
2020-09-18 17:30:50 +08:00
|
|
|
struct eeh_pe *eeh_pe_get(struct pci_controller *phb, int pe_no);
|
2020-07-25 16:12:31 +08:00
|
|
|
int eeh_pe_tree_insert(struct eeh_dev *edev, struct eeh_pe *new_pe_parent);
|
2020-07-25 16:12:29 +08:00
|
|
|
int eeh_pe_tree_remove(struct eeh_dev *edev);
|
2013-06-20 13:21:01 +08:00
|
|
|
void eeh_pe_update_time_stamp(struct eeh_pe *pe);
|
powerpc/eeh: Use partial hotplug for EEH unaware drivers
When EEH error happens to one specific PE, some devices with drivers
supporting EEH won't except hotplug on the device. However, there
might have other deivces without driver, or with driver without EEH
support. For the case, we need do partial hotplug in order to make
sure that the PE becomes absolutely quite during reset. Otherise,
the PE reset might fail and leads to failure of error recovery.
The current code doesn't handle that 'mixed' case properly, it either
uses the error callbacks to the drivers, or tries hotplug, but doesn't
handle a PE (EEH domain) composed of a combination of the two.
The patch intends to support so-called "partial" hotplug for EEH:
Before we do reset, we stop and remove those PCI devices without
EEH sensitive driver. The corresponding EEH devices are not detached
from its PE, but with special flag. After the reset is done, those
EEH devices with the special flag will be scanned one by one.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-07-24 10:24:58 +08:00
|
|
|
void *eeh_pe_traverse(struct eeh_pe *root,
|
2018-05-25 11:11:32 +08:00
|
|
|
eeh_pe_traverse_func fn, void *flag);
|
2019-08-16 12:48:15 +08:00
|
|
|
void eeh_pe_dev_traverse(struct eeh_pe *root,
|
|
|
|
eeh_edev_traverse_func fn, void *flag);
|
2012-09-08 06:44:15 +08:00
|
|
|
void eeh_pe_restore_bars(struct eeh_pe *pe);
|
2014-06-11 16:26:44 +08:00
|
|
|
const char *eeh_pe_loc_get(struct eeh_pe *pe);
|
2012-09-08 06:44:19 +08:00
|
|
|
struct pci_bus *eeh_pe_bus_get(struct eeh_pe *pe);
|
2012-09-08 06:44:07 +08:00
|
|
|
|
2019-08-16 12:48:10 +08:00
|
|
|
void eeh_show_enabled(void);
|
2020-09-18 17:30:42 +08:00
|
|
|
int __init eeh_init(struct eeh_ops *ops);
|
2014-09-30 10:38:50 +08:00
|
|
|
int eeh_check_failure(const volatile void __iomem *token);
|
2012-09-08 06:44:22 +08:00
|
|
|
int eeh_dev_check_failure(struct eeh_dev *edev);
|
2019-08-16 12:48:08 +08:00
|
|
|
void eeh_addr_cache_init(void);
|
2020-03-06 15:39:04 +08:00
|
|
|
void eeh_probe_device(struct pci_dev *pdev);
|
2013-07-24 10:24:55 +08:00
|
|
|
void eeh_remove_device(struct pci_dev *);
|
2018-11-29 11:16:38 +08:00
|
|
|
int eeh_unfreeze_pe(struct eeh_pe *pe);
|
2014-09-30 10:39:07 +08:00
|
|
|
int eeh_pe_reset_and_recover(struct eeh_pe *pe);
|
2014-06-10 09:41:56 +08:00
|
|
|
int eeh_dev_open(struct pci_dev *pdev);
|
|
|
|
void eeh_dev_release(struct pci_dev *pdev);
|
|
|
|
struct eeh_pe *eeh_iommu_group_to_pe(struct iommu_group *group);
|
|
|
|
int eeh_pe_set_option(struct eeh_pe *pe, int option);
|
|
|
|
int eeh_pe_get_state(struct eeh_pe *pe);
|
2018-11-29 11:16:41 +08:00
|
|
|
int eeh_pe_reset(struct eeh_pe *pe, int option, bool include_passed);
|
2014-06-10 09:41:56 +08:00
|
|
|
int eeh_pe_configure(struct eeh_pe *pe);
|
2015-03-26 13:42:08 +08:00
|
|
|
int eeh_pe_inject_err(struct eeh_pe *pe, int type, int func,
|
|
|
|
unsigned long addr, unsigned long mask);
|
2005-11-04 08:51:31 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/**
|
|
|
|
* EEH_POSSIBLE_ERROR() -- test for possible MMIO failure.
|
|
|
|
*
|
|
|
|
* If this macro yields TRUE, the caller relays to eeh_check_failure()
|
|
|
|
* which does further tests out of line.
|
|
|
|
*/
|
2014-02-12 15:24:55 +08:00
|
|
|
#define EEH_POSSIBLE_ERROR(val, type) ((val) == (type)~0 && eeh_enabled())
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Reads from a device which has been isolated by EEH will return
|
|
|
|
* all 1s. This macro gives an all-1s value of the given size (in
|
|
|
|
* bytes: 1, 2, or 4) for comparing with the result of a read.
|
|
|
|
*/
|
|
|
|
#define EEH_IO_ERROR_VALUE(size) (~0U >> ((4 - (size)) * 8))
|
|
|
|
|
|
|
|
#else /* !CONFIG_EEH */
|
powerpc/eeh: Introduce EEH device
Original EEH implementation depends on struct pci_dn heavily. However,
EEH shouldn't depend on that actually because EEH needn't share much
information with other PCI components. That's to say, EEH should have
worked independently.
The patch introduces struct eeh_dev so that EEH core components needn't
be working based on struct pci_dn in future. Also, struct pci_dn, struct
eeh_dev instances are created in dynamic fasion and the binding with EEH
device, OF node, PCI device is implemented as well.
The EEH devices are created after PHBs are detected and initialized, but
PCI emunation hasn't started yet. Apart from that, PHB might be created
dynamically through DLPAR component and the EEH devices should be creatd
as well. Another case might be OF node is created dynamically by DR
(Dynamic Reconfiguration), which has been defined by PAPR. For those OF
nodes created by DR, EEH devices should be also created accordingly. The
binding between EEH device and OF node is done while the EEH device is
initially created.
The binding between EEH device and PCI device should be done after PCI
emunation is done. Besides, PCI hotplug also needs the binding so that
the EEH devices could be traced from the newly coming PCI buses or PCI
devices.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-02-28 04:04:04 +08:00
|
|
|
|
2014-02-12 15:24:55 +08:00
|
|
|
static inline bool eeh_enabled(void)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-08-16 12:48:10 +08:00
|
|
|
static inline void eeh_show_enabled(void) { }
|
2013-06-20 13:20:56 +08:00
|
|
|
|
2014-09-30 10:38:50 +08:00
|
|
|
static inline int eeh_check_failure(const volatile void __iomem *token)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2014-09-30 10:38:50 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2012-09-08 06:44:22 +08:00
|
|
|
#define eeh_dev_check_failure(x) (0)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2019-08-16 12:48:08 +08:00
|
|
|
static inline void eeh_addr_cache_init(void) { }
|
|
|
|
|
2020-03-06 15:39:04 +08:00
|
|
|
static inline void eeh_probe_device(struct pci_dev *dev) { }
|
2013-07-24 10:24:52 +08:00
|
|
|
|
2013-07-24 10:24:55 +08:00
|
|
|
static inline void eeh_remove_device(struct pci_dev *dev) { }
|
2012-09-08 06:44:06 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#define EEH_POSSIBLE_ERROR(val, type) (0)
|
|
|
|
#define EEH_IO_ERROR_VALUE(size) (-1UL)
|
2020-07-25 16:12:18 +08:00
|
|
|
static inline int eeh_phb_pe_create(struct pci_controller *phb) { return 0; }
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif /* CONFIG_EEH */
|
|
|
|
|
2020-03-06 15:39:03 +08:00
|
|
|
#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_EEH)
|
|
|
|
void pseries_eeh_init_edev_recursive(struct pci_dn *pdn);
|
|
|
|
#endif
|
|
|
|
|
2008-10-28 03:48:37 +08:00
|
|
|
#ifdef CONFIG_PPC64
|
2005-11-04 08:50:04 +08:00
|
|
|
/*
|
2005-04-17 06:20:36 +08:00
|
|
|
* MMIO read/write operations with EEH support.
|
|
|
|
*/
|
|
|
|
static inline u8 eeh_readb(const volatile void __iomem *addr)
|
|
|
|
{
|
|
|
|
u8 val = in_8(addr);
|
|
|
|
if (EEH_POSSIBLE_ERROR(val, u8))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u16 eeh_readw(const volatile void __iomem *addr)
|
|
|
|
{
|
|
|
|
u16 val = in_le16(addr);
|
|
|
|
if (EEH_POSSIBLE_ERROR(val, u16))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u32 eeh_readl(const volatile void __iomem *addr)
|
|
|
|
{
|
|
|
|
u32 val = in_le32(addr);
|
|
|
|
if (EEH_POSSIBLE_ERROR(val, u32))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
return val;
|
|
|
|
}
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
|
|
|
|
static inline u64 eeh_readq(const volatile void __iomem *addr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
u64 val = in_le64(addr);
|
|
|
|
if (EEH_POSSIBLE_ERROR(val, u64))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
static inline u16 eeh_readw_be(const volatile void __iomem *addr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
u16 val = in_be16(addr);
|
|
|
|
if (EEH_POSSIBLE_ERROR(val, u16))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
return val;
|
|
|
|
}
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
|
|
|
|
static inline u32 eeh_readl_be(const volatile void __iomem *addr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
u32 val = in_be32(addr);
|
|
|
|
if (EEH_POSSIBLE_ERROR(val, u32))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
return val;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
|
|
|
|
static inline u64 eeh_readq_be(const volatile void __iomem *addr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
u64 val = in_be64(addr);
|
|
|
|
if (EEH_POSSIBLE_ERROR(val, u64))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
2006-11-13 06:27:39 +08:00
|
|
|
static inline void eeh_memcpy_fromio(void *dest, const
|
|
|
|
volatile void __iomem *src,
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned long n)
|
|
|
|
{
|
2006-11-13 06:27:39 +08:00
|
|
|
_memcpy_fromio(dest, src, n);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* Look for ffff's here at dest[n]. Assume that at least 4 bytes
|
|
|
|
* were copied. Check all four bytes.
|
|
|
|
*/
|
2006-11-13 06:27:39 +08:00
|
|
|
if (n >= 4 && EEH_POSSIBLE_ERROR(*((u32 *)(dest + n - 4)), u32))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(src);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* in-string eeh macros */
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
static inline void eeh_readsb(const volatile void __iomem *addr, void * buf,
|
|
|
|
int ns)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
_insb(addr, buf, ns);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (EEH_POSSIBLE_ERROR((*(((u8*)buf)+ns-1)), u8))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
static inline void eeh_readsw(const volatile void __iomem *addr, void * buf,
|
|
|
|
int ns)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
_insw(addr, buf, ns);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (EEH_POSSIBLE_ERROR((*(((u16*)buf)+ns-1)), u16))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
static inline void eeh_readsl(const volatile void __iomem *addr, void * buf,
|
|
|
|
int nl)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
_insl(addr, buf, nl);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (EEH_POSSIBLE_ERROR((*(((u32*)buf)+nl-1)), u32))
|
2014-09-30 10:38:50 +08:00
|
|
|
eeh_check_failure(addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2019-02-15 08:48:13 +08:00
|
|
|
|
2021-12-17 06:00:16 +08:00
|
|
|
void __init eeh_cache_debugfs_init(void);
|
2019-02-15 08:48:13 +08:00
|
|
|
|
2008-10-28 03:48:37 +08:00
|
|
|
#endif /* CONFIG_PPC64 */
|
2005-12-17 05:43:46 +08:00
|
|
|
#endif /* __KERNEL__ */
|
2008-10-28 03:48:37 +08:00
|
|
|
#endif /* _POWERPC_EEH_H */
|