2019-05-27 08:55:01 +02:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2005-04-16 15:20:36 -07:00
|
|
|
/*
|
|
|
|
* c 2001 PPC 64 Team, IBM Corp
|
|
|
|
*/
|
2005-09-28 02:50:25 +10:00
|
|
|
#ifndef _ASM_POWERPC_PPC_PCI_H
|
|
|
|
#define _ASM_POWERPC_PPC_PCI_H
|
2005-12-16 22:43:46 +01:00
|
|
|
#ifdef __KERNEL__
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-03-04 17:04:44 +11:00
|
|
|
#ifdef CONFIG_PCI
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <asm/pci-bridge.h>
|
|
|
|
|
|
|
|
extern unsigned long isa_io_base;
|
|
|
|
|
|
|
|
extern struct list_head hose_list;
|
|
|
|
|
[POWERPC] Rewrite IO allocation & mapping on powerpc64
This rewrites pretty much from scratch the handling of MMIO and PIO
space allocations on powerpc64. The main goals are:
- Get rid of imalloc and use more common code where possible
- Simplify the current mess so that PIO space is allocated and
mapped in a single place for PCI bridges
- Handle allocation constraints of PIO for all bridges including
hot plugged ones within the 2GB space reserved for IO ports,
so that devices on hotplugged busses will now work with drivers
that assume IO ports fit in an int.
- Cleanup and separate tracking of the ISA space in the reserved
low 64K of IO space. No ISA -> Nothing mapped there.
I booted a cell blade with IDE on PIO and MMIO and a dual G5 so
far, that's it :-)
With this patch, all allocations are done using the code in
mm/vmalloc.c, though we use the low level __get_vm_area with
explicit start/stop constraints in order to manage separate
areas for vmalloc/vmap, ioremap, and PCI IOs.
This greatly simplifies a lot of things, as you can see in the
diffstat of that patch :-)
A new pair of functions pcibios_map/unmap_io_space() now replace
all of the previous code that used to manipulate PCI IOs space.
The allocation is done at mapping time, which is now called from
scan_phb's, just before the devices are probed (instead of after,
which is by itself a bug fix). The only other caller is the PCI
hotplug code for hot adding PCI-PCI bridges (slots).
imalloc is gone, as is the "sub-allocation" thing, but I do beleive
that hotplug should still work in the sense that the space allocation
is always done by the PHB, but if you unmap a child bus of this PHB
(which seems to be possible), then the code should properly tear
down all the HPTE mappings for that area of the PHB allocated IO space.
I now always reserve the first 64K of IO space for the bridge with
the ISA bus on it. I have moved the code for tracking ISA in a separate
file which should also make it smarter if we ever are capable of
hot unplugging or re-plugging an ISA bridge.
This should have a side effect on platforms like powermac where VGA IOs
will no longer work. This is done on purpose though as they would have
worked semi-randomly before. The idea at this point is to isolate drivers
that might need to access those and fix them by providing a proper
function to obtain an offset to the legacy IOs of a given bus.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-04 15:15:36 +10:00
|
|
|
extern struct pci_dev *isa_bridge_pcidev; /* may be NULL if no ISA bus */
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-03 18:42:26 -06:00
|
|
|
/** Bus Unit ID macros; get low and hi 32-bits of the 64-bit BUID */
|
2010-09-15 08:13:19 +00:00
|
|
|
#define BUID_HI(buid) upper_32_bits(buid)
|
|
|
|
#define BUID_LO(buid) lower_32_bits(buid)
|
2005-11-03 18:42:26 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/* PCI device_node operations */
|
|
|
|
struct device_node;
|
2015-03-17 16:15:05 +11:00
|
|
|
struct pci_dn;
|
|
|
|
|
2016-05-03 15:41:42 +10:00
|
|
|
void *pci_traverse_device_nodes(struct device_node *start,
|
|
|
|
void *(*fn)(struct device_node *, void *),
|
|
|
|
void *data);
|
2006-11-11 17:25:08 +11:00
|
|
|
extern void pci_devs_phb_init_dynamic(struct pci_controller *phb);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
powerpc/pseries/iommu: DLPAR add doesn't completely initialize pci_controller
When a PCI device is dynamically added, the kernel oopses with a NULL
pointer dereference:
BUG: Kernel NULL pointer dereference on read at 0x00000030
Faulting instruction address: 0xc0000000006bbe5c
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse
CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66
Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries
NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8
REGS: c00000009924f240 TRAP: 0300 Not tainted (6.7.0-203405+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24002220 XER: 20040006
CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0
...
NIP sysfs_add_link_to_group+0x34/0x94
LR iommu_device_link+0x5c/0x118
Call Trace:
iommu_init_device+0x26c/0x318 (unreliable)
iommu_device_link+0x5c/0x118
iommu_init_device+0xa8/0x318
iommu_probe_device+0xc0/0x134
iommu_bus_notifier+0x44/0x104
notifier_call_chain+0xb8/0x19c
blocking_notifier_call_chain+0x64/0x98
bus_notify+0x50/0x7c
device_add+0x640/0x918
pci_device_add+0x23c/0x298
of_create_pci_dev+0x400/0x884
of_scan_pci_dev+0x124/0x1b0
__of_scan_bus+0x78/0x18c
pcibios_scan_phb+0x2a4/0x3b0
init_phb_dynamic+0xb8/0x110
dlpar_add_slot+0x170/0x3b8 [rpadlpar_io]
add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]
kobj_attr_store+0x2c/0x48
sysfs_kf_write+0x64/0x78
kernfs_fop_write_iter+0x1b0/0x290
vfs_write+0x350/0x4a0
ksys_write+0x84/0x140
system_call_exception+0x124/0x330
system_call_vectored_common+0x15c/0x2ec
Commit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities
and allow blocking domains") broke DLPAR add of PCI devices.
The above added iommu_device structure to pci_controller. During
system boot, PCI devices are discovered and this newly added iommu_device
structure is initialized by a call to iommu_device_register().
During DLPAR add of a PCI device, a new pci_controller structure is
allocated but there are no calls made to iommu_device_register()
interface.
Fix is to register the iommu device during DLPAR add as well.
Fixes: a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains")
Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240215221833.4817-1-gbatra@linux.ibm.com
2024-02-15 16:18:33 -06:00
|
|
|
#if defined(CONFIG_IOMMU_API) && (defined(CONFIG_PPC_PSERIES) || \
|
|
|
|
defined(CONFIG_PPC_POWERNV))
|
|
|
|
extern void ppc_iommu_register_device(struct pci_controller *phb);
|
|
|
|
extern void ppc_iommu_unregister_device(struct pci_controller *phb);
|
|
|
|
#else
|
|
|
|
static inline void ppc_iommu_register_device(struct pci_controller *phb) { }
|
|
|
|
static inline void ppc_iommu_unregister_device(struct pci_controller *phb) { }
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
2005-06-23 17:09:54 +10:00
|
|
|
/* From rtas_pci.h */
|
2006-11-11 17:25:08 +11:00
|
|
|
extern void init_pci_config_tokens (void);
|
|
|
|
extern unsigned long get_phb_buid (struct device_node *);
|
|
|
|
extern int rtas_setup_phb(struct pci_controller *phb);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
powerpc/rtas_pci: rename and properly expose config access APIs
The rtas_read_config() and rtas_write_config() functions in
kernel/rtas_pci.c have external linkage and two users in arch/powerpc:
the rtas_pci code itself and the pseries platform's "enhanced error
handling" (EEH) support code.
The prototypes for these functions in asm/ppc-pci.h have until now
been guarded by CONFIG_EEH since the only external caller is the
pseries EEH code. However, this presumably has always generated
warnings when built with !CONFIG_EEH and -Wmissing-prototypes:
arch/powerpc/kernel/rtas_pci.c:46:5: error: no previous prototype for
function 'rtas_read_config' [-Werror,-Wmissing-prototypes]
46 | int rtas_read_config(struct pci_dn *pdn, int where,
int size, u32 *val)
arch/powerpc/kernel/rtas_pci.c:98:5: error: no previous prototype for
function 'rtas_write_config' [-Werror,-Wmissing-prototypes]
98 | int rtas_write_config(struct pci_dn *pdn, int where,
int size, u32 val)
The introduction of commit c6345dfa6e3e ("Makefile.extrawarn: turn on
missing-prototypes globally") forces the issue.
The efika and chrp platform code have (static) functions with the same
names but different signatures. We may as well eliminate the potential
for conflicts and confusion by renaming the globally visible versions
as their prototypes get moved out of the CONFIG_EEH-guarded region;
their current names are too generic anyway. Since they operate on
objects of the type 'struct pci_dn *', give them the slightly more
verbose prefix "rtas_pci_dn_" and fix up all the call sites.
Fixes: c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally")
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
Closes: https://lore.kernel.org/linuxppc-dev/CA+G9fYt0LLXtjSz+Hkf3Fhm-kf0ZQanrhUS+zVZGa3O+Wt2+vg@mail.gmail.com/
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231127-rtas-pci-rw-config-v1-1-385d29ace3df@linux.ibm.com
2023-11-27 18:40:09 -06:00
|
|
|
int rtas_pci_dn_read_config(struct pci_dn *pdn, int where, int size, u32 *val);
|
|
|
|
int rtas_pci_dn_write_config(struct pci_dn *pdn, int where, int size, u32 val);
|
|
|
|
|
2005-11-03 18:50:10 -06:00
|
|
|
#ifdef CONFIG_EEH
|
2005-11-03 18:53:07 -06:00
|
|
|
|
2012-09-07 22:44:23 +00:00
|
|
|
void eeh_addr_cache_insert_dev(struct pci_dev *dev);
|
|
|
|
void eeh_addr_cache_rmv_dev(struct pci_dev *dev);
|
|
|
|
struct eeh_dev *eeh_addr_cache_get_dev(unsigned long addr);
|
2012-09-07 22:44:16 +00:00
|
|
|
void eeh_slot_error_detail(struct eeh_pe *pe, int severity);
|
|
|
|
int eeh_pci_enable(struct eeh_pe *pe, int function);
|
2018-11-29 14:16:41 +11:00
|
|
|
int eeh_pe_reset_full(struct eeh_pe *pe, bool include_passed);
|
2012-09-07 22:44:21 +00:00
|
|
|
void eeh_save_bars(struct eeh_dev *edev);
|
2012-09-07 22:44:12 +00:00
|
|
|
void eeh_pe_state_mark(struct eeh_pe *pe, int state);
|
2018-09-12 11:23:31 +10:00
|
|
|
void eeh_pe_mark_isolated(struct eeh_pe *pe);
|
2018-11-29 14:16:39 +11:00
|
|
|
void eeh_pe_state_clear(struct eeh_pe *pe, int state, bool include_passed);
|
2015-07-30 09:26:51 +10:00
|
|
|
void eeh_pe_state_mark_with_cfg(struct eeh_pe *pe, int state);
|
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 18:00:19 +10:00
|
|
|
void eeh_pe_dev_mode_mark(struct eeh_pe *pe, int mode);
|
2005-11-03 18:54:29 -06:00
|
|
|
|
2007-05-24 03:16:46 +10:00
|
|
|
void eeh_sysfs_add_device(struct pci_dev *pdev);
|
|
|
|
void eeh_sysfs_remove_device(struct pci_dev *pdev);
|
|
|
|
|
2007-05-10 02:38:11 +10:00
|
|
|
#endif /* CONFIG_EEH */
|
2005-11-03 18:50:10 -06:00
|
|
|
|
2023-04-09 02:08:05 +02:00
|
|
|
#ifdef CONFIG_FSL_ULI1575
|
2023-04-09 02:08:08 +02:00
|
|
|
void __init uli_init(void);
|
2023-04-09 02:08:05 +02:00
|
|
|
#endif /* CONFIG_FSL_ULI1575 */
|
|
|
|
|
2019-08-16 14:48:11 +10:00
|
|
|
#define PCI_BUSNO(bdfn) ((bdfn >> 8) & 0xff)
|
|
|
|
|
2007-03-04 17:04:44 +11:00
|
|
|
#else /* CONFIG_PCI */
|
|
|
|
static inline void init_pci_config_tokens(void) { }
|
|
|
|
#endif /* !CONFIG_PCI */
|
|
|
|
|
2023-04-09 02:08:05 +02:00
|
|
|
#if !defined(CONFIG_PCI) || !defined(CONFIG_FSL_ULI1575)
|
2023-04-09 02:08:08 +02:00
|
|
|
static inline void __init uli_init(void) {}
|
2023-04-09 02:08:05 +02:00
|
|
|
#endif /* !defined(CONFIG_PCI) || !defined(CONFIG_FSL_ULI1575) */
|
|
|
|
|
2005-12-16 22:43:46 +01:00
|
|
|
#endif /* __KERNEL__ */
|
2005-09-28 02:50:25 +10:00
|
|
|
#endif /* _ASM_POWERPC_PPC_PCI_H */
|