2019-05-27 09:55:05 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
2012-02-28 00:03:53 +04:00
/*
* The file intends to implement the platform dependent EEH operations on pseries .
* Actually , the pseries platform is built based on RTAS heavily . That means the
* pseries platform dependent EEH operations will be built on RTAS calls . The functions
2016-06-01 09:34:37 +03:00
* are derived from arch / powerpc / platforms / pseries / eeh . c and necessary cleanup has
2012-02-28 00:03:53 +04:00
* been done .
*
* Copyright Benjamin Herrenschmidt & Gavin Shan , IBM Corporation 2011.
* Copyright IBM Corporation 2001 , 2005 , 2006
* Copyright Dave Engebretsen & Todd Inglett 2001
* Copyright Linas Vepstas 2005 , 2006
*/
# include <linux/atomic.h>
# include <linux/delay.h>
# include <linux/export.h>
# include <linux/init.h>
# include <linux/list.h>
# include <linux/of.h>
# include <linux/pci.h>
# include <linux/proc_fs.h>
# include <linux/rbtree.h>
# include <linux/sched.h>
# include <linux/seq_file.h>
# include <linux/spinlock.h>
2020-07-13 17:39:33 +03:00
# include <linux/crash_dump.h>
2012-02-28 00:03:53 +04:00
# include <asm/eeh.h>
# include <asm/eeh_event.h>
# include <asm/io.h>
# include <asm/machdep.h>
# include <asm/ppc-pci.h>
# include <asm/rtas.h>
2012-02-28 00:03:54 +04:00
/* RTAS tokens */
static int ibm_set_eeh_option ;
static int ibm_set_slot_reset ;
static int ibm_read_slot_reset_state ;
static int ibm_read_slot_reset_state2 ;
static int ibm_slot_error_detail ;
static int ibm_get_config_addr_info ;
static int ibm_get_config_addr_info2 ;
static int ibm_configure_pe ;
2022-03-16 13:42:39 +03:00
static void pseries_eeh_init_edev ( struct pci_dn * pdn ) ;
2021-01-04 17:31:46 +03:00
static void pseries_pcibios_bus_add_device ( struct pci_dev * pdev )
2017-11-09 17:00:34 +03:00
{
struct pci_dn * pdn = pci_get_pdn ( pdev ) ;
2019-08-16 07:48:09 +03:00
if ( eeh_has_flag ( EEH_FORCE_DISABLED ) )
2017-11-09 17:00:34 +03:00
return ;
2019-08-16 07:48:13 +03:00
dev_dbg ( & pdev - > dev , " EEH: Setting up device \n " ) ;
2019-08-16 07:48:09 +03:00
# ifdef CONFIG_PCI_IOV
if ( pdev - > is_virtfn ) {
pdn - > device_id = pdev - > device ;
pdn - > vendor_id = pdev - > vendor ;
pdn - > class_code = pdev - > class ;
/*
* Last allow unfreeze return code used for retrieval
* by user space in eeh - sysfs to show the last command
* completion from platform .
*/
pdn - > last_allow_rc = 0 ;
}
# endif
2020-03-06 10:39:03 +03:00
pseries_eeh_init_edev ( pdn ) ;
2019-08-16 07:48:09 +03:00
# ifdef CONFIG_PCI_IOV
if ( pdev - > is_virtfn ) {
2020-07-25 11:12:31 +03:00
/*
* FIXME : This really should be handled by choosing the right
2022-07-18 12:51:58 +03:00
* parent PE in pseries_eeh_init_edev ( ) .
2020-07-25 11:12:31 +03:00
*/
struct eeh_pe * physfn_pe = pci_dev_to_eeh_dev ( pdev - > physfn ) - > pe ;
2019-08-16 07:48:09 +03:00
struct eeh_dev * edev = pdn_to_eeh_dev ( pdn ) ;
2017-11-09 17:00:34 +03:00
2019-08-16 07:48:09 +03:00
edev - > pe_config_addr = ( pdn - > busno < < 16 ) | ( pdn - > devfn < < 8 ) ;
2020-07-25 11:12:29 +03:00
eeh_pe_tree_remove ( edev ) ; /* Remove as it is adding to bus pe */
2020-07-25 11:12:31 +03:00
eeh_pe_tree_insert ( edev , physfn_pe ) ; /* Add as VF PE type */
2019-08-16 07:48:09 +03:00
}
2018-01-05 19:45:48 +03:00
# endif
2020-03-06 10:39:04 +03:00
eeh_probe_device ( pdev ) ;
2019-08-16 07:48:09 +03:00
}
2017-11-09 17:00:34 +03:00
2020-07-13 17:39:33 +03:00
/**
2020-09-18 12:30:47 +03:00
* pseries_eeh_get_pe_config_addr - Find the pe_config_addr for a device
* @ pdn : pci_dn of the input device
2020-07-13 17:39:33 +03:00
*
2020-09-18 12:30:49 +03:00
* The EEH RTAS calls use a tuple consisting of : ( buid_hi , buid_lo ,
* pe_config_addr ) as a handle to a given PE . This function finds the
* pe_config_addr based on the device ' s config addr .
2020-07-13 17:39:33 +03:00
*
2020-09-18 12:30:49 +03:00
* Keep in mind that the pe_config_addr * might * be numerically identical to the
* device ' s config addr , but the two are conceptually distinct .
*
* Returns the pe_config_addr , or a negative error code .
2020-07-13 17:39:33 +03:00
*/
2020-09-18 12:30:47 +03:00
static int pseries_eeh_get_pe_config_addr ( struct pci_dn * pdn )
2020-07-13 17:39:33 +03:00
{
2020-09-18 12:30:47 +03:00
int config_addr = rtas_config_addr ( pdn - > busno , pdn - > devfn , 0 ) ;
struct pci_controller * phb = pdn - > phb ;
2020-09-18 12:30:49 +03:00
int ret , rets [ 3 ] ;
2020-07-13 17:39:33 +03:00
if ( ibm_get_config_addr_info2 ! = RTAS_UNKNOWN_SERVICE ) {
/*
2020-09-18 12:30:47 +03:00
* First of all , use function 1 to determine if this device is
* part of a PE or not . ret [ 0 ] being zero indicates it ' s not .
2020-07-13 17:39:33 +03:00
*/
ret = rtas_call ( ibm_get_config_addr_info2 , 4 , 2 , rets ,
config_addr , BUID_HI ( phb - > buid ) ,
BUID_LO ( phb - > buid ) , 1 ) ;
if ( ret | | ( rets [ 0 ] = = 0 ) )
2020-09-18 12:30:49 +03:00
return - ENOENT ;
2020-07-13 17:39:33 +03:00
2020-09-18 12:30:49 +03:00
/* Retrieve the associated PE config address with function 0 */
2020-07-13 17:39:33 +03:00
ret = rtas_call ( ibm_get_config_addr_info2 , 4 , 2 , rets ,
config_addr , BUID_HI ( phb - > buid ) ,
BUID_LO ( phb - > buid ) , 0 ) ;
if ( ret ) {
pr_warn ( " %s: Failed to get address for PHB#%x-PE#%x \n " ,
__func__ , phb - > global_number , config_addr ) ;
2020-09-18 12:30:49 +03:00
return - ENXIO ;
2020-07-13 17:39:33 +03:00
}
return rets [ 0 ] ;
}
if ( ibm_get_config_addr_info ! = RTAS_UNKNOWN_SERVICE ) {
ret = rtas_call ( ibm_get_config_addr_info , 4 , 2 , rets ,
config_addr , BUID_HI ( phb - > buid ) ,
BUID_LO ( phb - > buid ) , 0 ) ;
if ( ret ) {
pr_warn ( " %s: Failed to get address for PHB#%x-PE#%x \n " ,
__func__ , phb - > global_number , config_addr ) ;
2020-09-18 12:30:49 +03:00
return - ENXIO ;
2020-07-13 17:39:33 +03:00
}
return rets [ 0 ] ;
}
2020-09-18 12:30:49 +03:00
/*
* PAPR does describe a process for finding the pe_config_addr that was
* used before the ibm , get - config - addr - info calls were added . However ,
* I haven ' t found * any * systems that don ' t have that RTAS call
* implemented . If you happen to find one that needs the old DT based
* process , patches are welcome !
*/
return - ENOENT ;
2020-07-13 17:39:33 +03:00
}
/**
* pseries_eeh_phb_reset - Reset the specified PHB
* @ phb : PCI controller
2022-10-31 09:37:06 +03:00
* @ config_addr : the associated config address
2020-07-13 17:39:33 +03:00
* @ option : reset option
*
* Reset the specified PHB / PE
*/
static int pseries_eeh_phb_reset ( struct pci_controller * phb , int config_addr , int option )
{
int ret ;
/* Reset PE through RTAS call */
ret = rtas_call ( ibm_set_slot_reset , 4 , 1 , NULL ,
config_addr , BUID_HI ( phb - > buid ) ,
BUID_LO ( phb - > buid ) , option ) ;
/* If fundamental-reset not supported, try hot-reset */
2020-08-18 07:45:57 +03:00
if ( option = = EEH_RESET_FUNDAMENTAL & & ret = = - 8 ) {
2020-07-13 17:39:33 +03:00
option = EEH_RESET_HOT ;
ret = rtas_call ( ibm_set_slot_reset , 4 , 1 , NULL ,
config_addr , BUID_HI ( phb - > buid ) ,
BUID_LO ( phb - > buid ) , option ) ;
}
/* We need reset hold or settlement delay */
2020-08-18 07:45:57 +03:00
if ( option = = EEH_RESET_FUNDAMENTAL | | option = = EEH_RESET_HOT )
2020-07-13 17:39:33 +03:00
msleep ( EEH_PE_RST_HOLD_TIME ) ;
else
msleep ( EEH_PE_RST_SETTLE_TIME ) ;
return ret ;
}
/**
* pseries_eeh_phb_configure_bridge - Configure PCI bridges in the indicated PE
* @ phb : PCI controller
2022-10-31 09:37:06 +03:00
* @ config_addr : the associated config address
2020-07-13 17:39:33 +03:00
*
* The function will be called to reconfigure the bridges included
* in the specified PE so that the mulfunctional PE would be recovered
* again .
*/
static int pseries_eeh_phb_configure_bridge ( struct pci_controller * phb , int config_addr )
{
int ret ;
/* Waiting 0.2s maximum before skipping configuration */
int max_wait = 200 ;
while ( max_wait > 0 ) {
ret = rtas_call ( ibm_configure_pe , 3 , 1 , NULL ,
config_addr , BUID_HI ( phb - > buid ) ,
BUID_LO ( phb - > buid ) ) ;
if ( ! ret )
return ret ;
if ( ret < 0 )
break ;
/*
* If RTAS returns a delay value that ' s above 100 ms , cut it
* down to 100 ms in case firmware made a mistake . For more
* on how these delay values work see rtas_busy_delay_time
*/
if ( ret > RTAS_EXTENDED_DELAY_MIN + 2 & &
ret < = RTAS_EXTENDED_DELAY_MAX )
ret = RTAS_EXTENDED_DELAY_MIN + 2 ;
max_wait - = rtas_busy_delay_time ( ret ) ;
if ( max_wait < 0 )
break ;
rtas_busy_delay ( ret ) ;
}
pr_warn ( " %s: Unable to configure bridge PHB#%x-PE#%x (%d) \n " ,
__func__ , phb - > global_number , config_addr , ret ) ;
/* PAPR defines -3 as "Parameter Error" for this function: */
if ( ret = = - 3 )
return - EINVAL ;
else
return - EIO ;
}
2012-02-28 00:04:00 +04:00
/*
* Buffer for reporting slot - error - detail rtas calls . Its here
* in BSS , and not dynamically alloced , so that it ends up in
* RMO where RTAS can access it .
*/
static unsigned char slot_errbuf [ RTAS_ERROR_LOG_MAX ] ;
static DEFINE_SPINLOCK ( slot_errbuf_lock ) ;
static int eeh_error_buf_size ;
2015-03-17 08:15:06 +03:00
static int pseries_eeh_cap_start ( struct pci_dn * pdn )
2013-07-24 06:24:59 +04:00
{
u32 status ;
if ( ! pdn )
return 0 ;
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-28 03:40:09 +03:00
rtas_pci_dn_read_config ( pdn , PCI_STATUS , 2 , & status ) ;
2013-07-24 06:24:59 +04:00
if ( ! ( status & PCI_STATUS_CAP_LIST ) )
return 0 ;
return PCI_CAPABILITY_LIST ;
}
2015-03-17 08:15:06 +03:00
static int pseries_eeh_find_cap ( struct pci_dn * pdn , int cap )
2013-07-24 06:24:59 +04:00
{
2015-03-17 08:15:06 +03:00
int pos = pseries_eeh_cap_start ( pdn ) ;
2013-07-24 06:24:59 +04:00
int cnt = 48 ; /* Maximal number of capabilities */
u32 id ;
if ( ! pos )
return 0 ;
while ( cnt - - ) {
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-28 03:40:09 +03:00
rtas_pci_dn_read_config ( pdn , pos , 1 , & pos ) ;
2013-07-24 06:24:59 +04:00
if ( pos < 0x40 )
break ;
pos & = ~ 3 ;
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-28 03:40:09 +03:00
rtas_pci_dn_read_config ( pdn , pos + PCI_CAP_LIST_ID , 1 , & id ) ;
2013-07-24 06:24:59 +04:00
if ( id = = 0xff )
break ;
if ( id = = cap )
return pos ;
pos + = PCI_CAP_LIST_NEXT ;
}
return 0 ;
}
2015-03-17 08:15:06 +03:00
static int pseries_eeh_find_ecap ( struct pci_dn * pdn , int cap )
2014-04-24 12:00:16 +04:00
{
2015-03-17 08:15:06 +03:00
struct eeh_dev * edev = pdn_to_eeh_dev ( pdn ) ;
2014-04-24 12:00:16 +04:00
u32 header ;
int pos = 256 ;
int ttl = ( 4096 - 256 ) / 8 ;
if ( ! edev | | ! edev - > pcie_cap )
return 0 ;
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-28 03:40:09 +03:00
if ( rtas_pci_dn_read_config ( pdn , pos , 4 , & header ) ! = PCIBIOS_SUCCESSFUL )
2014-04-24 12:00:16 +04:00
return 0 ;
else if ( ! header )
return 0 ;
while ( ttl - - > 0 ) {
if ( PCI_EXT_CAP_ID ( header ) = = cap & & pos )
return pos ;
pos = PCI_EXT_CAP_NEXT ( header ) ;
if ( pos < 256 )
break ;
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-28 03:40:09 +03:00
if ( rtas_pci_dn_read_config ( pdn , pos , 4 , & header ) ! = PCIBIOS_SUCCESSFUL )
2014-04-24 12:00:16 +04:00
break ;
}
return 0 ;
}
2020-07-25 11:12:31 +03:00
/**
* pseries_eeh_pe_get_parent - Retrieve the parent PE
* @ edev : EEH device
*
* The whole PEs existing in the system are organized as hierarchy
* tree . The function is used to retrieve the parent PE according
* to the parent EEH device .
*/
static struct eeh_pe * pseries_eeh_pe_get_parent ( struct eeh_dev * edev )
{
struct eeh_dev * parent ;
struct pci_dn * pdn = eeh_dev_to_pdn ( edev ) ;
/*
* It might have the case for the indirect parent
* EEH device already having associated PE , but
* the direct parent EEH device doesn ' t have yet .
*/
if ( edev - > physfn )
pdn = pci_get_pdn ( edev - > physfn ) ;
else
pdn = pdn ? pdn - > parent : NULL ;
while ( pdn ) {
/* We're poking out of PCI territory */
parent = pdn_to_eeh_dev ( pdn ) ;
if ( ! parent )
return NULL ;
if ( parent - > pe )
return parent - > pe ;
pdn = pdn - > parent ;
}
return NULL ;
}
2012-09-08 02:44:21 +04:00
/**
2020-03-06 10:39:03 +03:00
* pseries_eeh_init_edev - initialise the eeh_dev and eeh_pe for a pci_dn
*
2015-03-17 08:15:06 +03:00
* @ pdn : PCI device node
2012-09-08 02:44:21 +04:00
*
2020-03-06 10:39:03 +03:00
* When we discover a new PCI device via the device - tree we create a
* corresponding pci_dn and we allocate , but don ' t initialise , an eeh_dev .
* This function takes care of the initialisation and inserts the eeh_dev
* into the correct eeh_pe . If no eeh_pe exists we ' ll allocate one .
2012-09-08 02:44:21 +04:00
*/
2022-03-16 13:42:39 +03:00
static void pseries_eeh_init_edev ( struct pci_dn * pdn )
2012-09-08 02:44:21 +04:00
{
2020-09-18 12:30:48 +03:00
struct eeh_pe pe , * parent ;
2012-09-08 02:44:21 +04:00
struct eeh_dev * edev ;
2013-07-24 06:24:59 +04:00
u32 pcie_flags ;
2012-09-08 02:44:21 +04:00
int ret ;
2020-03-06 10:39:03 +03:00
if ( WARN_ON_ONCE ( ! eeh_has_flag ( EEH_PROBE_MODE_DEVTREE ) ) )
return ;
/*
* Find the eeh_dev for this pdn . The storage for the eeh_dev was
* allocated at the same time as the pci_dn .
*
* XXX : We should probably re - visit that .
*/
2015-03-17 08:15:06 +03:00
edev = pdn_to_eeh_dev ( pdn ) ;
2020-03-06 10:39:03 +03:00
if ( ! edev )
return ;
/*
* If - > pe is set then we ' ve already probed this device . We hit
* this path when a pci_dev is removed and rescanned while recovering
* a PE ( i . e . for devices where the driver doesn ' t support error
* recovery ) .
*/
if ( edev - > pe )
return ;
2012-09-08 02:44:21 +04:00
2015-03-17 08:15:06 +03:00
/* Check class/vendor/device IDs */
if ( ! pdn - > vendor_id | | ! pdn - > device_id | | ! pdn - > class_code )
2020-03-06 10:39:03 +03:00
return ;
2012-09-08 02:44:21 +04:00
2015-03-17 08:15:06 +03:00
/* Skip for PCI-ISA bridge */
if ( ( pdn - > class_code > > 8 ) = = PCI_CLASS_BRIDGE_ISA )
2020-03-06 10:39:03 +03:00
return ;
2013-11-20 15:14:58 +04:00
2019-08-16 07:48:13 +03:00
eeh_edev_dbg ( edev , " Probing device \n " ) ;
2013-07-24 06:24:59 +04:00
/*
* Update class code and mode of eeh device . We need
* correctly reflects that current device is root port
* or PCIe switch downstream port .
*/
2015-03-17 08:15:06 +03:00
edev - > pcix_cap = pseries_eeh_find_cap ( pdn , PCI_CAP_ID_PCIX ) ;
edev - > pcie_cap = pseries_eeh_find_cap ( pdn , PCI_CAP_ID_EXP ) ;
edev - > aer_cap = pseries_eeh_find_ecap ( pdn , PCI_EXT_CAP_ID_ERR ) ;
2013-07-24 06:25:01 +04:00
edev - > mode & = 0xFFFFFF00 ;
2020-07-25 11:12:28 +03:00
if ( ( pdn - > class_code > > 8 ) = = PCI_CLASS_BRIDGE_PCI ) {
2013-07-24 06:24:59 +04:00
edev - > mode | = EEH_DEV_BRIDGE ;
if ( edev - > pcie_cap ) {
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-28 03:40:09 +03:00
rtas_pci_dn_read_config ( pdn , edev - > pcie_cap + PCI_EXP_FLAGS ,
2 , & pcie_flags ) ;
2013-07-24 06:24:59 +04:00
pcie_flags = ( pcie_flags & PCI_EXP_FLAGS_TYPE ) > > 4 ;
if ( pcie_flags = = PCI_EXP_TYPE_ROOT_PORT )
edev - > mode | = EEH_DEV_ROOT_PORT ;
else if ( pcie_flags = = PCI_EXP_TYPE_DOWNSTREAM )
edev - > mode | = EEH_DEV_DS_PORT ;
}
}
2012-09-08 02:44:21 +04:00
2020-09-18 12:30:48 +03:00
/* first up, find the pe_config_addr for the PE containing the device */
2020-10-07 07:09:03 +03:00
ret = pseries_eeh_get_pe_config_addr ( pdn ) ;
if ( ret < 0 ) {
2020-09-18 12:30:48 +03:00
eeh_edev_dbg ( edev , " Unable to find pe_config_addr \n " ) ;
goto err ;
}
/* Try enable EEH on the fake PE */
2012-09-08 02:44:21 +04:00
memset ( & pe , 0 , sizeof ( struct eeh_pe ) ) ;
2017-08-29 10:34:01 +03:00
pe . phb = pdn - > phb ;
2020-10-07 07:09:03 +03:00
pe . addr = ret ;
2012-09-08 02:44:21 +04:00
2019-08-16 07:48:13 +03:00
eeh_edev_dbg ( edev , " Enabling EEH on device \n " ) ;
2012-09-08 02:44:21 +04:00
ret = eeh_ops - > set_option ( & pe , EEH_OPT_ENABLE ) ;
2019-08-16 07:48:07 +03:00
if ( ret ) {
2019-08-16 07:48:13 +03:00
eeh_edev_dbg ( edev , " EEH failed to enable on device (code %d) \n " , ret ) ;
2020-09-18 12:30:48 +03:00
goto err ;
}
2020-07-25 11:12:31 +03:00
2020-10-07 07:09:03 +03:00
edev - > pe_config_addr = pe . addr ;
2012-09-08 02:44:21 +04:00
2020-09-18 12:30:48 +03:00
eeh_add_flag ( EEH_ENABLED ) ;
2012-09-08 02:44:21 +04:00
2020-09-18 12:30:48 +03:00
parent = pseries_eeh_pe_get_parent ( edev ) ;
eeh_pe_tree_insert ( edev , parent ) ;
eeh_save_bars ( edev ) ;
eeh_edev_dbg ( edev , " EEH enabled for device " ) ;
2020-07-25 11:12:31 +03:00
2020-09-18 12:30:48 +03:00
return ;
2012-09-08 02:44:21 +04:00
2020-09-18 12:30:48 +03:00
err :
eeh_edev_dbg ( edev , " EEH is unsupported on device (code = %d) \n " , ret ) ;
2020-03-06 10:39:03 +03:00
}
2020-03-06 10:39:04 +03:00
static struct eeh_dev * pseries_eeh_probe ( struct pci_dev * pdev )
{
struct eeh_dev * edev ;
struct pci_dn * pdn ;
pdn = pci_get_pdn_by_devfn ( pdev - > bus , pdev - > devfn ) ;
if ( ! pdn )
return NULL ;
/*
* If the system supports EEH on this device then the eeh_dev was
* configured and inserted into a PE in pseries_eeh_init_edev ( )
*/
edev = pdn_to_eeh_dev ( pdn ) ;
if ( ! edev | | ! edev - > pe )
return NULL ;
return edev ;
}
2020-03-06 10:39:03 +03:00
/**
* pseries_eeh_init_edev_recursive - Enable EEH for the indicated device
* @ pdn : PCI device node
*
* This routine must be used to perform EEH initialization for the
* indicated PCI device that was added after system boot ( e . g .
* hotplug , dlpar ) .
*/
void pseries_eeh_init_edev_recursive ( struct pci_dn * pdn )
{
struct pci_dn * n ;
if ( ! pdn )
return ;
list_for_each_entry ( n , & pdn - > child_list , list )
pseries_eeh_init_edev_recursive ( n ) ;
2012-09-08 02:44:21 +04:00
2020-03-06 10:39:03 +03:00
pseries_eeh_init_edev ( pdn ) ;
2012-09-08 02:44:21 +04:00
}
2020-03-06 10:39:03 +03:00
EXPORT_SYMBOL_GPL ( pseries_eeh_init_edev_recursive ) ;
2012-09-08 02:44:21 +04:00
2012-02-28 00:03:53 +04:00
/**
* pseries_eeh_set_option - Initialize EEH or MMIO / DMA reenable
2012-09-08 02:44:14 +04:00
* @ pe : EEH PE
2012-02-28 00:03:53 +04:00
* @ option : operation to be issued
*
* The function is used to control the EEH functionality globally .
* Currently , following options are support according to PAPR :
* Enable EEH , Disable EEH , Enable MMIO and Enable DMA
*/
2012-09-08 02:44:14 +04:00
static int pseries_eeh_set_option ( struct eeh_pe * pe , int option )
2012-02-28 00:03:53 +04:00
{
2012-02-28 00:03:55 +04:00
int ret = 0 ;
/*
2022-04-30 21:56:54 +03:00
* When we ' re enabling or disabling EEH functionality on
2012-02-28 00:03:55 +04:00
* the particular PE , the PE config address is possibly
* unavailable . Therefore , we have to figure it out from
* the FDT node .
*/
switch ( option ) {
case EEH_OPT_DISABLE :
case EEH_OPT_ENABLE :
case EEH_OPT_THAW_MMIO :
case EEH_OPT_THAW_DMA :
break ;
2014-09-30 06:38:52 +04:00
case EEH_OPT_FREEZE_PE :
/* Not support */
return 0 ;
2012-02-28 00:03:55 +04:00
default :
2020-08-18 07:45:57 +03:00
pr_err ( " %s: Invalid option %d \n " , __func__ , option ) ;
2012-02-28 00:03:55 +04:00
return - EINVAL ;
}
ret = rtas_call ( ibm_set_eeh_option , 4 , 1 , NULL ,
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 12:30:50 +03:00
pe - > addr , BUID_HI ( pe - > phb - > buid ) ,
2012-09-08 02:44:14 +04:00
BUID_LO ( pe - > phb - > buid ) , option ) ;
2012-02-28 00:03:55 +04:00
return ret ;
2012-02-28 00:03:53 +04:00
}
/**
* pseries_eeh_get_state - Retrieve PE state
2012-09-08 02:44:14 +04:00
* @ pe : EEH PE
2018-09-12 04:23:32 +03:00
* @ delay : suggested time to wait if state is unavailable
2012-02-28 00:03:53 +04:00
*
* Retrieve the state of the specified PE . On RTAS compliant
* pseries platform , there already has one dedicated RTAS function
* for the purpose . It ' s notable that the associated PE config address
* might be ready when calling the function . Therefore , endeavour to
* use the PE config address if possible . Further more , there ' re 2
* RTAS calls for the purpose , we need to try the new one and back
* to the old one if the new one couldn ' t work properly .
*/
2018-09-12 04:23:32 +03:00
static int pseries_eeh_get_state ( struct eeh_pe * pe , int * delay )
2012-02-28 00:03:53 +04:00
{
2012-02-28 00:03:57 +04:00
int ret ;
int rets [ 4 ] ;
int result ;
if ( ibm_read_slot_reset_state2 ! = RTAS_UNKNOWN_SERVICE ) {
ret = rtas_call ( ibm_read_slot_reset_state2 , 3 , 4 , rets ,
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 12:30:50 +03:00
pe - > addr , BUID_HI ( pe - > phb - > buid ) ,
2012-09-08 02:44:14 +04:00
BUID_LO ( pe - > phb - > buid ) ) ;
2012-02-28 00:03:57 +04:00
} else if ( ibm_read_slot_reset_state ! = RTAS_UNKNOWN_SERVICE ) {
/* Fake PE unavailable info */
rets [ 2 ] = 0 ;
ret = rtas_call ( ibm_read_slot_reset_state , 3 , 3 , rets ,
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 12:30:50 +03:00
pe - > addr , BUID_HI ( pe - > phb - > buid ) ,
2012-09-08 02:44:14 +04:00
BUID_LO ( pe - > phb - > buid ) ) ;
2012-02-28 00:03:57 +04:00
} else {
return EEH_STATE_NOT_SUPPORT ;
}
if ( ret )
return ret ;
/* Parse the result out */
2015-10-08 06:58:56 +03:00
if ( ! rets [ 1 ] )
return EEH_STATE_NOT_SUPPORT ;
switch ( rets [ 0 ] ) {
case 0 :
result = EEH_STATE_MMIO_ACTIVE |
EEH_STATE_DMA_ACTIVE ;
break ;
case 1 :
result = EEH_STATE_RESET_ACTIVE |
EEH_STATE_MMIO_ACTIVE |
EEH_STATE_DMA_ACTIVE ;
break ;
case 2 :
result = 0 ;
break ;
case 4 :
result = EEH_STATE_MMIO_ENABLED ;
break ;
case 5 :
if ( rets [ 2 ] ) {
2018-09-12 04:23:32 +03:00
if ( delay )
* delay = rets [ 2 ] ;
2015-10-08 06:58:56 +03:00
result = EEH_STATE_UNAVAILABLE ;
} else {
2012-02-28 00:03:57 +04:00
result = EEH_STATE_NOT_SUPPORT ;
}
2015-10-08 06:58:56 +03:00
break ;
default :
2012-02-28 00:03:57 +04:00
result = EEH_STATE_NOT_SUPPORT ;
}
return result ;
2012-02-28 00:03:53 +04:00
}
/**
* pseries_eeh_reset - Reset the specified PE
2012-09-08 02:44:14 +04:00
* @ pe : EEH PE
2012-02-28 00:03:53 +04:00
* @ option : reset option
*
* Reset the specified PE
*/
2012-09-08 02:44:14 +04:00
static int pseries_eeh_reset ( struct eeh_pe * pe , int option )
2012-02-28 00:03:53 +04:00
{
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 12:30:50 +03:00
return pseries_eeh_phb_reset ( pe - > phb , pe - > addr , option ) ;
2012-02-28 00:03:53 +04:00
}
/**
* pseries_eeh_get_log - Retrieve error log
2012-09-08 02:44:14 +04:00
* @ pe : EEH PE
2012-02-28 00:03:53 +04:00
* @ severity : temporary or permanent error log
* @ drv_log : driver log to be combined with retrieved error log
* @ len : length of driver log
*
* Retrieve the temporary or permanent error from the PE .
* Actually , the error will be retrieved through the dedicated
* RTAS call .
*/
2012-09-08 02:44:14 +04:00
static int pseries_eeh_get_log ( struct eeh_pe * pe , int severity , char * drv_log , unsigned long len )
2012-02-28 00:03:53 +04:00
{
2012-02-28 00:04:00 +04:00
unsigned long flags ;
int ret ;
spin_lock_irqsave ( & slot_errbuf_lock , flags ) ;
memset ( slot_errbuf , 0 , eeh_error_buf_size ) ;
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 12:30:50 +03:00
ret = rtas_call ( ibm_slot_error_detail , 8 , 1 , NULL , pe - > addr ,
2012-09-08 02:44:14 +04:00
BUID_HI ( pe - > phb - > buid ) , BUID_LO ( pe - > phb - > buid ) ,
2012-02-28 00:04:00 +04:00
virt_to_phys ( drv_log ) , len ,
virt_to_phys ( slot_errbuf ) , eeh_error_buf_size ,
severity ) ;
if ( ! ret )
log_error ( slot_errbuf , ERR_TYPE_RTAS_LOG , 0 ) ;
spin_unlock_irqrestore ( & slot_errbuf_lock , flags ) ;
return ret ;
2012-02-28 00:03:53 +04:00
}
/**
* pseries_eeh_configure_bridge - Configure PCI bridges in the indicated PE
2012-09-08 02:44:14 +04:00
* @ pe : EEH PE
2012-02-28 00:03:53 +04:00
*
*/
2012-09-08 02:44:14 +04:00
static int pseries_eeh_configure_bridge ( struct eeh_pe * pe )
2012-02-28 00:03:53 +04:00
{
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 12:30:50 +03:00
return pseries_eeh_phb_configure_bridge ( pe - > phb , pe - > addr ) ;
2012-02-28 00:03:53 +04:00
}
2012-02-28 00:04:11 +04:00
/**
* pseries_eeh_read_config - Read PCI config space
2020-07-25 11:12:26 +03:00
* @ edev : EEH device handle
* @ where : PCI config space offset
2012-02-28 00:04:11 +04:00
* @ size : size to read
* @ val : return value
*
* Read config space from the speicifed device
*/
2020-07-25 11:12:26 +03:00
static int pseries_eeh_read_config ( struct eeh_dev * edev , int where , int size , u32 * val )
2012-02-28 00:04:11 +04:00
{
2020-07-25 11:12:26 +03:00
struct pci_dn * pdn = eeh_dev_to_pdn ( edev ) ;
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-28 03:40:09 +03:00
return rtas_pci_dn_read_config ( pdn , where , size , val ) ;
2012-02-28 00:04:11 +04:00
}
/**
* pseries_eeh_write_config - Write PCI config space
2020-07-25 11:12:26 +03:00
* @ edev : EEH device handle
* @ where : PCI config space offset
2012-02-28 00:04:11 +04:00
* @ size : size to write
* @ val : value to be written
*
* Write config space to the specified device
*/
2020-07-25 11:12:26 +03:00
static int pseries_eeh_write_config ( struct eeh_dev * edev , int where , int size , u32 val )
2012-02-28 00:04:11 +04:00
{
2020-07-25 11:12:26 +03:00
struct pci_dn * pdn = eeh_dev_to_pdn ( edev ) ;
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-28 03:40:09 +03:00
return rtas_pci_dn_write_config ( pdn , where , size , val ) ;
2012-02-28 00:04:11 +04:00
}
2018-01-05 19:45:49 +03:00
# ifdef CONFIG_PCI_IOV
2021-01-04 17:32:06 +03:00
static int pseries_send_allow_unfreeze ( struct pci_dn * pdn , u16 * vf_pe_array , int cur_vfs )
2018-01-05 19:45:49 +03:00
{
int rc ;
2023-02-10 21:42:08 +03:00
int ibm_allow_unfreeze = rtas_function_token ( RTAS_FN_IBM_OPEN_SRIOV_ALLOW_UNFREEZE ) ;
2018-01-05 19:45:49 +03:00
unsigned long buid , addr ;
addr = rtas_config_addr ( pdn - > busno , pdn - > devfn , 0 ) ;
buid = pdn - > phb - > buid ;
spin_lock ( & rtas_data_buf_lock ) ;
memcpy ( rtas_data_buf , vf_pe_array , RTAS_DATA_BUF_SIZE ) ;
rc = rtas_call ( ibm_allow_unfreeze , 5 , 1 , NULL ,
addr ,
BUID_HI ( buid ) ,
BUID_LO ( buid ) ,
rtas_data_buf , cur_vfs * sizeof ( u16 ) ) ;
spin_unlock ( & rtas_data_buf_lock ) ;
if ( rc )
pr_warn ( " %s: Failed to allow unfreeze for PHB#%x-PE#%lx, rc=%x \n " ,
__func__ ,
pdn - > phb - > global_number , addr , rc ) ;
return rc ;
}
static int pseries_call_allow_unfreeze ( struct eeh_dev * edev )
{
2020-07-25 11:12:21 +03:00
int cur_vfs = 0 , rc = 0 , vf_index , bus , devfn , vf_pe_num ;
2018-01-05 19:45:49 +03:00
struct pci_dn * pdn , * tmp , * parent , * physfn_pdn ;
u16 * vf_pe_array ;
vf_pe_array = kzalloc ( RTAS_DATA_BUF_SIZE , GFP_KERNEL ) ;
if ( ! vf_pe_array )
return - ENOMEM ;
if ( pci_num_vf ( edev - > physfn ? edev - > physfn : edev - > pdev ) ) {
if ( edev - > pdev - > is_physfn ) {
cur_vfs = pci_num_vf ( edev - > pdev ) ;
pdn = eeh_dev_to_pdn ( edev ) ;
parent = pdn - > parent ;
for ( vf_index = 0 ; vf_index < cur_vfs ; vf_index + + )
vf_pe_array [ vf_index ] =
cpu_to_be16 ( pdn - > pe_num_map [ vf_index ] ) ;
rc = pseries_send_allow_unfreeze ( pdn , vf_pe_array ,
cur_vfs ) ;
pdn - > last_allow_rc = rc ;
for ( vf_index = 0 ; vf_index < cur_vfs ; vf_index + + ) {
list_for_each_entry_safe ( pdn , tmp ,
& parent - > child_list ,
list ) {
bus = pci_iov_virtfn_bus ( edev - > pdev ,
vf_index ) ;
devfn = pci_iov_virtfn_devfn ( edev - > pdev ,
vf_index ) ;
if ( pdn - > busno ! = bus | |
pdn - > devfn ! = devfn )
continue ;
pdn - > last_allow_rc = rc ;
}
}
} else {
pdn = pci_get_pdn ( edev - > pdev ) ;
physfn_pdn = pci_get_pdn ( edev - > physfn ) ;
2020-07-25 11:12:21 +03:00
vf_pe_num = physfn_pdn - > pe_num_map [ edev - > vf_index ] ;
vf_pe_array [ 0 ] = cpu_to_be16 ( vf_pe_num ) ;
2018-01-05 19:45:49 +03:00
rc = pseries_send_allow_unfreeze ( physfn_pdn ,
vf_pe_array , 1 ) ;
pdn - > last_allow_rc = rc ;
}
}
kfree ( vf_pe_array ) ;
return rc ;
}
2020-07-25 11:12:25 +03:00
static int pseries_notify_resume ( struct eeh_dev * edev )
2018-01-05 19:45:49 +03:00
{
if ( ! edev )
return - EEXIST ;
2023-02-10 21:42:08 +03:00
if ( rtas_function_token ( RTAS_FN_IBM_OPEN_SRIOV_ALLOW_UNFREEZE ) = = RTAS_UNKNOWN_SERVICE )
2018-01-05 19:45:49 +03:00
return - EINVAL ;
if ( edev - > pdev - > is_physfn | | edev - > pdev - > is_virtfn )
return pseries_call_allow_unfreeze ( edev ) ;
return 0 ;
}
# endif
2012-02-28 00:03:53 +04:00
static struct eeh_ops pseries_eeh_ops = {
. name = " pseries " ,
2020-03-06 10:39:04 +03:00
. probe = pseries_eeh_probe ,
2012-02-28 00:03:53 +04:00
. set_option = pseries_eeh_set_option ,
. get_state = pseries_eeh_get_state ,
. reset = pseries_eeh_reset ,
. get_log = pseries_eeh_get_log ,
2012-02-28 00:04:11 +04:00
. configure_bridge = pseries_eeh_configure_bridge ,
2014-09-30 06:38:56 +04:00
. err_inject = NULL ,
2012-02-28 00:04:11 +04:00
. read_config = pseries_eeh_read_config ,
2014-01-03 13:47:12 +04:00
. write_config = pseries_eeh_write_config ,
. next_error = NULL ,
2020-07-25 11:12:23 +03:00
. restore_config = NULL , /* NB: configure_bridge() does this */
2018-01-05 19:45:49 +03:00
# ifdef CONFIG_PCI_IOV
. notify_resume = pseries_notify_resume
# endif
2012-02-28 00:03:53 +04:00
} ;
/**
* eeh_pseries_init - Register platform dependent EEH operations
*
* EEH initialization on pseries platform . This function should be
* called before any EEH related functions .
*/
2012-09-08 02:44:02 +04:00
static int __init eeh_pseries_init ( void )
2012-02-28 00:03:53 +04:00
{
2020-09-18 12:30:44 +03:00
struct pci_controller * phb ;
struct pci_dn * pdn ;
2020-09-18 12:30:47 +03:00
int ret , config_addr ;
2020-09-18 12:30:44 +03:00
/* figure out EEH RTAS function call tokens */
2023-02-10 21:42:08 +03:00
ibm_set_eeh_option = rtas_function_token ( RTAS_FN_IBM_SET_EEH_OPTION ) ;
ibm_set_slot_reset = rtas_function_token ( RTAS_FN_IBM_SET_SLOT_RESET ) ;
ibm_read_slot_reset_state2 = rtas_function_token ( RTAS_FN_IBM_READ_SLOT_RESET_STATE2 ) ;
ibm_read_slot_reset_state = rtas_function_token ( RTAS_FN_IBM_READ_SLOT_RESET_STATE ) ;
ibm_slot_error_detail = rtas_function_token ( RTAS_FN_IBM_SLOT_ERROR_DETAIL ) ;
ibm_get_config_addr_info2 = rtas_function_token ( RTAS_FN_IBM_GET_CONFIG_ADDR_INFO2 ) ;
ibm_get_config_addr_info = rtas_function_token ( RTAS_FN_IBM_GET_CONFIG_ADDR_INFO ) ;
ibm_configure_pe = rtas_function_token ( RTAS_FN_IBM_CONFIGURE_PE ) ;
2020-09-18 12:30:44 +03:00
/*
* ibm , configure - pe and ibm , configure - bridge have the same semantics ,
* however ibm , configure - pe can be faster . If we can ' t find
* ibm , configure - pe then fall back to using ibm , configure - bridge .
*/
if ( ibm_configure_pe = = RTAS_UNKNOWN_SERVICE )
2023-02-10 21:42:08 +03:00
ibm_configure_pe = rtas_function_token ( RTAS_FN_IBM_CONFIGURE_BRIDGE ) ;
2020-09-18 12:30:44 +03:00
/*
* Necessary sanity check . We needn ' t check " get-config-addr-info "
* and its variant since the old firmware probably support address
* of domain / bus / slot / function for EEH RTAS operations .
*/
if ( ibm_set_eeh_option = = RTAS_UNKNOWN_SERVICE | |
ibm_set_slot_reset = = RTAS_UNKNOWN_SERVICE | |
( ibm_read_slot_reset_state2 = = RTAS_UNKNOWN_SERVICE & &
ibm_read_slot_reset_state = = RTAS_UNKNOWN_SERVICE ) | |
ibm_slot_error_detail = = RTAS_UNKNOWN_SERVICE | |
ibm_configure_pe = = RTAS_UNKNOWN_SERVICE ) {
pr_info ( " EEH functionality not supported \n " ) ;
return - EINVAL ;
}
2022-05-11 04:27:56 +03:00
/* Initialize error log size */
2022-11-18 18:07:43 +03:00
eeh_error_buf_size = rtas_get_error_log_max ( ) ;
2020-09-18 12:30:44 +03:00
/* Set EEH probe mode */
eeh_add_flag ( EEH_PROBE_MODE_DEVTREE | EEH_ENABLE_IO_FOR_LOG ) ;
/* Set EEH machine dependent code */
ppc_md . pcibios_bus_add_device = pseries_pcibios_bus_add_device ;
if ( is_kdump_kernel ( ) | | reset_devices ) {
pr_info ( " Issue PHB reset ... \n " ) ;
list_for_each_entry ( phb , & hose_list , list_node ) {
pseries/eeh: Fix the kdump kernel crash during eeh_pseries_init
On pseries LPAR when an empty slot is assigned to partition OR in single
LPAR mode, kdump kernel crashes during issuing PHB reset.
In the kdump scenario, we traverse all PHBs and issue reset using the
pe_config_addr of the first child device present under each PHB. However
the code assumes that none of the PHB slots can be empty and uses
list_first_entry() to get the first child device under the PHB. Since
list_first_entry() expects the list to be non-empty, it returns an
invalid pci_dn entry and ends up accessing NULL phb pointer under
pci_dn->phb causing kdump kernel crash.
This patch fixes the below kdump kernel crash by skipping empty slots:
audit: initializing netlink subsys (disabled)
thermal_sys: Registered thermal governor 'fair_share'
thermal_sys: Registered thermal governor 'step_wise'
cpuidle: using governor menu
pstore: Registered nvram as persistent store backend
Issue PHB reset ...
audit: type=2000 audit(1631267818.000:1): state=initialized audit_enabled=0 res=1
BUG: Kernel NULL pointer dereference on read at 0x00000268
Faulting instruction address: 0xc000000008101fb0
Oops: Kernel access of bad area, sig: 7 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 7 PID: 1 Comm: swapper/7 Not tainted 5.14.0 #1
NIP: c000000008101fb0 LR: c000000009284ccc CTR: c000000008029d70
REGS: c00000001161b840 TRAP: 0300 Not tainted (5.14.0)
MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28000224 XER: 20040002
CFAR: c000000008101f0c DAR: 0000000000000268 DSISR: 00080000 IRQMASK: 0
...
NIP pseries_eeh_get_pe_config_addr+0x100/0x1b0
LR __machine_initcall_pseries_eeh_pseries_init+0x2cc/0x350
Call Trace:
0xc00000001161bb80 (unreliable)
__machine_initcall_pseries_eeh_pseries_init+0x2cc/0x350
do_one_initcall+0x60/0x2d0
kernel_init_freeable+0x350/0x3f8
kernel_init+0x3c/0x17c
ret_from_kernel_thread+0x5c/0x64
Fixes: 5a090f7c363fd ("powerpc/pseries: PCIE PHB reset")
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
[mpe: Tweak wording and trim oops]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/163215558252.413351.8600189949820258982.stgit@jupiter
2021-09-20 19:33:26 +03:00
// Skip if the slot is empty
if ( list_empty ( & PCI_DN ( phb - > dn ) - > child_list ) )
continue ;
2020-09-18 12:30:44 +03:00
pdn = list_first_entry ( & PCI_DN ( phb - > dn ) - > child_list , struct pci_dn , list ) ;
2020-09-18 12:30:47 +03:00
config_addr = pseries_eeh_get_pe_config_addr ( pdn ) ;
2020-09-18 12:30:44 +03:00
/* invalid PE config addr */
2020-09-18 12:30:49 +03:00
if ( config_addr < 0 )
2020-09-18 12:30:44 +03:00
continue ;
pseries_eeh_phb_reset ( phb , config_addr , EEH_RESET_FUNDAMENTAL ) ;
pseries_eeh_phb_reset ( phb , config_addr , EEH_RESET_DEACTIVATE ) ;
pseries_eeh_phb_configure_bridge ( phb , config_addr ) ;
}
}
2012-09-08 02:44:04 +04:00
2020-09-18 12:30:42 +03:00
ret = eeh_init ( & pseries_eeh_ops ) ;
2012-09-08 02:44:04 +04:00
if ( ! ret )
pr_info ( " EEH: pSeries platform initialized \n " ) ;
else
pr_info ( " EEH: pSeries platform initialization failure (%d) \n " ,
ret ) ;
return ret ;
2012-02-28 00:03:53 +04:00
}
2020-09-18 12:30:46 +03:00
machine_arch_initcall ( pseries , eeh_pseries_init ) ;