2018-01-26 20:45:16 +03:00
// SPDX-License-Identifier: GPL-2.0
2005-04-17 02:20:36 +04:00
/*
2018-03-10 01:36:33 +03:00
* PCI support in ACPI
2005-04-17 02:20:36 +04:00
*
2005-03-19 02:53:36 +03:00
* Copyright ( C ) 2005 David Shaohua Li < shaohua . li @ intel . com >
* Copyright ( C ) 2004 Tom Long Nguyen < tom . l . nguyen @ intel . com >
* Copyright ( C ) 2004 Intel Corp .
2005-04-17 02:20:36 +04:00
*/
# include <linux/delay.h>
# include <linux/init.h>
2015-12-10 19:55:27 +03:00
# include <linux/irqdomain.h>
2005-04-17 02:20:36 +04:00
# include <linux/pci.h>
2015-12-10 19:55:27 +03:00
# include <linux/msi.h>
2014-09-13 01:23:14 +04:00
# include <linux/pci_hotplug.h>
2005-04-17 02:20:36 +04:00
# include <linux/module.h>
# include <linux/pci-acpi.h>
2010-02-18 01:44:09 +03:00
# include <linux/pm_runtime.h>
2012-10-24 04:08:38 +04:00
# include <linux/pm_qos.h>
2005-03-19 08:15:48 +03:00
# include "pci.h"
2005-04-17 02:20:36 +04:00
2015-03-25 09:31:41 +03:00
/*
2017-06-05 19:40:46 +03:00
* The GUID is defined in the PCI Firmware Specification available here :
2015-03-25 09:31:41 +03:00
* https : //www.pcisig.com/members/downloads/pcifw_r3_1_13Dec10.pdf
*/
2017-06-05 19:40:46 +03:00
const guid_t pci_acpi_dsm_guid =
GUID_INIT ( 0xe5c937d0 , 0x3553 , 0x4d7a ,
0x91 , 0x17 , 0xea , 0x4d , 0x19 , 0xc3 , 0x43 , 0x4d ) ;
2015-03-25 09:31:41 +03:00
2016-12-01 09:33:42 +03:00
# if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_ARM64)
static int acpi_get_rc_addr ( struct acpi_device * adev , struct resource * res )
{
struct device * dev = & adev - > dev ;
struct resource_entry * entry ;
struct list_head list ;
unsigned long flags ;
int ret ;
INIT_LIST_HEAD ( & list ) ;
flags = IORESOURCE_MEM ;
ret = acpi_dev_get_resources ( adev , & list ,
acpi_dev_filter_resource_type_cb ,
( void * ) flags ) ;
if ( ret < 0 ) {
dev_err ( dev , " failed to parse _CRS method, error code %d \n " ,
ret ) ;
return ret ;
}
if ( ret = = 0 ) {
dev_err ( dev , " no IO and memory resources present in _CRS \n " ) ;
return - EINVAL ;
}
entry = list_first_entry ( & list , struct resource_entry , node ) ;
* res = * entry - > res ;
acpi_dev_free_resource_list ( & list ) ;
return 0 ;
}
static acpi_status acpi_match_rc ( acpi_handle handle , u32 lvl , void * context ,
void * * retval )
{
u16 * segment = context ;
unsigned long long uid ;
acpi_status status ;
status = acpi_evaluate_integer ( handle , " _UID " , NULL , & uid ) ;
if ( ACPI_FAILURE ( status ) | | uid ! = * segment )
return AE_CTRL_DEPTH ;
* ( acpi_handle * ) retval = handle ;
return AE_CTRL_TERMINATE ;
}
int acpi_get_rc_resources ( struct device * dev , const char * hid , u16 segment ,
struct resource * res )
{
struct acpi_device * adev ;
acpi_status status ;
acpi_handle handle ;
int ret ;
status = acpi_get_devices ( hid , acpi_match_rc , & segment , & handle ) ;
if ( ACPI_FAILURE ( status ) ) {
dev_err ( dev , " can't find _HID %s device to locate resources \n " ,
hid ) ;
return - ENODEV ;
}
ret = acpi_bus_get_device ( handle , & adev ) ;
if ( ret )
return ret ;
ret = acpi_get_rc_addr ( adev , res ) ;
if ( ret ) {
dev_err ( dev , " can't get resource from %s \n " ,
dev_name ( & adev - > dev ) ) ;
return ret ;
}
return 0 ;
}
# endif
2012-06-22 10:55:16 +04:00
phys_addr_t acpi_pci_root_get_mcfg_addr ( acpi_handle handle )
{
acpi_status status = AE_NOT_EXIST ;
unsigned long long mcfg_addr ;
if ( handle )
status = acpi_evaluate_integer ( handle , METHOD_NAME__CBA ,
NULL , & mcfg_addr ) ;
if ( ACPI_FAILURE ( status ) )
return 0 ;
return ( phys_addr_t ) mcfg_addr ;
}
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
/* _HPX PCI Setting Record (Type 0); same as _HPP */
struct hpx_type0 {
u32 revision ; /* Not present in _HPP */
u8 cache_line_size ; /* Not applicable to PCIe */
u8 latency_timer ; /* Not applicable to PCIe */
u8 enable_serr ;
u8 enable_perr ;
} ;
2019-08-27 12:49:50 +03:00
static struct hpx_type0 pci_default_type0 = {
. revision = 1 ,
. cache_line_size = 8 ,
. latency_timer = 0x40 ,
. enable_serr = 0 ,
. enable_perr = 0 ,
} ;
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
static void program_hpx_type0 ( struct pci_dev * dev , struct hpx_type0 * hpx )
2019-08-27 12:49:50 +03:00
{
u16 pci_cmd , pci_bctl ;
if ( ! hpx )
hpx = & pci_default_type0 ;
if ( hpx - > revision > 1 ) {
pci_warn ( dev , " PCI settings rev %d not supported; using defaults \n " ,
hpx - > revision ) ;
hpx = & pci_default_type0 ;
}
pci_write_config_byte ( dev , PCI_CACHE_LINE_SIZE , hpx - > cache_line_size ) ;
pci_write_config_byte ( dev , PCI_LATENCY_TIMER , hpx - > latency_timer ) ;
pci_read_config_word ( dev , PCI_COMMAND , & pci_cmd ) ;
if ( hpx - > enable_serr )
pci_cmd | = PCI_COMMAND_SERR ;
if ( hpx - > enable_perr )
pci_cmd | = PCI_COMMAND_PARITY ;
pci_write_config_word ( dev , PCI_COMMAND , pci_cmd ) ;
/* Program bridge control value */
if ( ( dev - > class > > 8 ) = = PCI_CLASS_BRIDGE_PCI ) {
pci_write_config_byte ( dev , PCI_SEC_LATENCY_TIMER ,
hpx - > latency_timer ) ;
pci_read_config_word ( dev , PCI_BRIDGE_CONTROL , & pci_bctl ) ;
if ( hpx - > enable_perr )
pci_bctl | = PCI_BRIDGE_CTL_PARITY ;
pci_write_config_word ( dev , PCI_BRIDGE_CONTROL , pci_bctl ) ;
}
}
2014-09-13 01:29:55 +04:00
static acpi_status decode_type0_hpx_record ( union acpi_object * record ,
2019-08-27 12:49:49 +03:00
struct hpx_type0 * hpx0 )
2014-09-13 01:23:14 +04:00
{
int i ;
union acpi_object * fields = record - > package . elements ;
u32 revision = fields [ 1 ] . integer . value ;
switch ( revision ) {
case 1 :
if ( record - > package . count ! = 6 )
return AE_ERROR ;
for ( i = 2 ; i < 6 ; i + + )
if ( fields [ i ] . type ! = ACPI_TYPE_INTEGER )
return AE_ERROR ;
2019-04-19 22:27:36 +03:00
hpx0 - > revision = revision ;
hpx0 - > cache_line_size = fields [ 2 ] . integer . value ;
hpx0 - > latency_timer = fields [ 3 ] . integer . value ;
hpx0 - > enable_serr = fields [ 4 ] . integer . value ;
hpx0 - > enable_perr = fields [ 5 ] . integer . value ;
2014-09-13 01:23:14 +04:00
break ;
default :
2019-04-20 07:03:46 +03:00
pr_warn ( " %s: Type 0 Revision %d record not supported \n " ,
2014-09-13 01:23:14 +04:00
__func__ , revision ) ;
return AE_ERROR ;
}
return AE_OK ;
}
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
/* _HPX PCI-X Setting Record (Type 1) */
struct hpx_type1 {
u32 revision ;
u8 max_mem_read ;
u8 avg_max_split ;
u16 tot_max_split ;
} ;
static void program_hpx_type1 ( struct pci_dev * dev , struct hpx_type1 * hpx )
2019-08-27 12:49:50 +03:00
{
int pos ;
if ( ! hpx )
return ;
pos = pci_find_capability ( dev , PCI_CAP_ID_PCIX ) ;
if ( ! pos )
return ;
pci_warn ( dev , " PCI-X settings not supported \n " ) ;
}
2014-09-13 01:29:55 +04:00
static acpi_status decode_type1_hpx_record ( union acpi_object * record ,
2019-08-27 12:49:49 +03:00
struct hpx_type1 * hpx1 )
2014-09-13 01:23:14 +04:00
{
int i ;
union acpi_object * fields = record - > package . elements ;
u32 revision = fields [ 1 ] . integer . value ;
switch ( revision ) {
case 1 :
if ( record - > package . count ! = 5 )
return AE_ERROR ;
for ( i = 2 ; i < 5 ; i + + )
if ( fields [ i ] . type ! = ACPI_TYPE_INTEGER )
return AE_ERROR ;
2019-04-19 22:27:36 +03:00
hpx1 - > revision = revision ;
hpx1 - > max_mem_read = fields [ 2 ] . integer . value ;
hpx1 - > avg_max_split = fields [ 3 ] . integer . value ;
hpx1 - > tot_max_split = fields [ 4 ] . integer . value ;
2014-09-13 01:23:14 +04:00
break ;
default :
2019-04-20 07:03:46 +03:00
pr_warn ( " %s: Type 1 Revision %d record not supported \n " ,
2014-09-13 01:23:14 +04:00
__func__ , revision ) ;
return AE_ERROR ;
}
return AE_OK ;
}
2019-08-27 12:49:50 +03:00
static bool pcie_root_rcb_set ( struct pci_dev * dev )
{
struct pci_dev * rp = pcie_find_root_port ( dev ) ;
u16 lnkctl ;
if ( ! rp )
return false ;
pcie_capability_read_word ( rp , PCI_EXP_LNKCTL , & lnkctl ) ;
if ( lnkctl & PCI_EXP_LNKCTL_RCB )
return true ;
return false ;
}
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
/* _HPX PCI Express Setting Record (Type 2) */
struct hpx_type2 {
u32 revision ;
u32 unc_err_mask_and ;
u32 unc_err_mask_or ;
u32 unc_err_sever_and ;
u32 unc_err_sever_or ;
u32 cor_err_mask_and ;
u32 cor_err_mask_or ;
u32 adv_err_cap_and ;
u32 adv_err_cap_or ;
u16 pci_exp_devctl_and ;
u16 pci_exp_devctl_or ;
u16 pci_exp_lnkctl_and ;
u16 pci_exp_lnkctl_or ;
u32 sec_unc_err_sever_and ;
u32 sec_unc_err_sever_or ;
u32 sec_unc_err_mask_and ;
u32 sec_unc_err_mask_or ;
} ;
static void program_hpx_type2 ( struct pci_dev * dev , struct hpx_type2 * hpx )
2019-08-27 12:49:50 +03:00
{
int pos ;
u32 reg32 ;
if ( ! hpx )
return ;
if ( ! pci_is_pcie ( dev ) )
return ;
if ( hpx - > revision > 1 ) {
pci_warn ( dev , " PCIe settings rev %d not supported \n " ,
hpx - > revision ) ;
return ;
}
/*
* Don ' t allow _HPX to change MPS or MRRS settings . We manage
* those to make sure they ' re consistent with the rest of the
* platform .
*/
hpx - > pci_exp_devctl_and | = PCI_EXP_DEVCTL_PAYLOAD |
PCI_EXP_DEVCTL_READRQ ;
hpx - > pci_exp_devctl_or & = ~ ( PCI_EXP_DEVCTL_PAYLOAD |
PCI_EXP_DEVCTL_READRQ ) ;
/* Initialize Device Control Register */
pcie_capability_clear_and_set_word ( dev , PCI_EXP_DEVCTL ,
~ hpx - > pci_exp_devctl_and , hpx - > pci_exp_devctl_or ) ;
/* Initialize Link Control Register */
if ( pcie_cap_has_lnkctl ( dev ) ) {
/*
* If the Root Port supports Read Completion Boundary of
* 128 , set RCB to 128. Otherwise , clear it .
*/
hpx - > pci_exp_lnkctl_and | = PCI_EXP_LNKCTL_RCB ;
hpx - > pci_exp_lnkctl_or & = ~ PCI_EXP_LNKCTL_RCB ;
if ( pcie_root_rcb_set ( dev ) )
hpx - > pci_exp_lnkctl_or | = PCI_EXP_LNKCTL_RCB ;
pcie_capability_clear_and_set_word ( dev , PCI_EXP_LNKCTL ,
~ hpx - > pci_exp_lnkctl_and , hpx - > pci_exp_lnkctl_or ) ;
}
/* Find Advanced Error Reporting Enhanced Capability */
pos = pci_find_ext_capability ( dev , PCI_EXT_CAP_ID_ERR ) ;
if ( ! pos )
return ;
/* Initialize Uncorrectable Error Mask Register */
pci_read_config_dword ( dev , pos + PCI_ERR_UNCOR_MASK , & reg32 ) ;
reg32 = ( reg32 & hpx - > unc_err_mask_and ) | hpx - > unc_err_mask_or ;
pci_write_config_dword ( dev , pos + PCI_ERR_UNCOR_MASK , reg32 ) ;
/* Initialize Uncorrectable Error Severity Register */
pci_read_config_dword ( dev , pos + PCI_ERR_UNCOR_SEVER , & reg32 ) ;
reg32 = ( reg32 & hpx - > unc_err_sever_and ) | hpx - > unc_err_sever_or ;
pci_write_config_dword ( dev , pos + PCI_ERR_UNCOR_SEVER , reg32 ) ;
/* Initialize Correctable Error Mask Register */
pci_read_config_dword ( dev , pos + PCI_ERR_COR_MASK , & reg32 ) ;
reg32 = ( reg32 & hpx - > cor_err_mask_and ) | hpx - > cor_err_mask_or ;
pci_write_config_dword ( dev , pos + PCI_ERR_COR_MASK , reg32 ) ;
/* Initialize Advanced Error Capabilities and Control Register */
pci_read_config_dword ( dev , pos + PCI_ERR_CAP , & reg32 ) ;
reg32 = ( reg32 & hpx - > adv_err_cap_and ) | hpx - > adv_err_cap_or ;
/* Don't enable ECRC generation or checking if unsupported */
if ( ! ( reg32 & PCI_ERR_CAP_ECRC_GENC ) )
reg32 & = ~ PCI_ERR_CAP_ECRC_GENE ;
if ( ! ( reg32 & PCI_ERR_CAP_ECRC_CHKC ) )
reg32 & = ~ PCI_ERR_CAP_ECRC_CHKE ;
pci_write_config_dword ( dev , pos + PCI_ERR_CAP , reg32 ) ;
/*
* FIXME : The following two registers are not supported yet .
*
* o Secondary Uncorrectable Error Severity Register
* o Secondary Uncorrectable Error Mask Register
*/
}
2014-09-13 01:29:55 +04:00
static acpi_status decode_type2_hpx_record ( union acpi_object * record ,
2019-08-27 12:49:49 +03:00
struct hpx_type2 * hpx2 )
2014-09-13 01:23:14 +04:00
{
int i ;
union acpi_object * fields = record - > package . elements ;
u32 revision = fields [ 1 ] . integer . value ;
switch ( revision ) {
case 1 :
if ( record - > package . count ! = 18 )
return AE_ERROR ;
for ( i = 2 ; i < 18 ; i + + )
if ( fields [ i ] . type ! = ACPI_TYPE_INTEGER )
return AE_ERROR ;
2019-04-19 22:27:36 +03:00
hpx2 - > revision = revision ;
hpx2 - > unc_err_mask_and = fields [ 2 ] . integer . value ;
hpx2 - > unc_err_mask_or = fields [ 3 ] . integer . value ;
hpx2 - > unc_err_sever_and = fields [ 4 ] . integer . value ;
hpx2 - > unc_err_sever_or = fields [ 5 ] . integer . value ;
hpx2 - > cor_err_mask_and = fields [ 6 ] . integer . value ;
hpx2 - > cor_err_mask_or = fields [ 7 ] . integer . value ;
hpx2 - > adv_err_cap_and = fields [ 8 ] . integer . value ;
hpx2 - > adv_err_cap_or = fields [ 9 ] . integer . value ;
hpx2 - > pci_exp_devctl_and = fields [ 10 ] . integer . value ;
hpx2 - > pci_exp_devctl_or = fields [ 11 ] . integer . value ;
hpx2 - > pci_exp_lnkctl_and = fields [ 12 ] . integer . value ;
hpx2 - > pci_exp_lnkctl_or = fields [ 13 ] . integer . value ;
hpx2 - > sec_unc_err_sever_and = fields [ 14 ] . integer . value ;
hpx2 - > sec_unc_err_sever_or = fields [ 15 ] . integer . value ;
hpx2 - > sec_unc_err_mask_and = fields [ 16 ] . integer . value ;
hpx2 - > sec_unc_err_mask_or = fields [ 17 ] . integer . value ;
2014-09-13 01:23:14 +04:00
break ;
default :
2019-04-20 07:03:46 +03:00
pr_warn ( " %s: Type 2 Revision %d record not supported \n " ,
2014-09-13 01:23:14 +04:00
__func__ , revision ) ;
return AE_ERROR ;
}
return AE_OK ;
}
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
/* _HPX PCI Express Setting Record (Type 3) */
struct hpx_type3 {
u16 device_type ;
u16 function_type ;
u16 config_space_location ;
u16 pci_exp_cap_id ;
u16 pci_exp_cap_ver ;
u16 pci_exp_vendor_id ;
u16 dvsec_id ;
u16 dvsec_rev ;
u16 match_offset ;
u32 match_mask_and ;
u32 match_value ;
u16 reg_offset ;
u32 reg_mask_and ;
u32 reg_mask_or ;
} ;
2019-08-27 12:49:50 +03:00
enum hpx_type3_dev_type {
HPX_TYPE_ENDPOINT = BIT ( 0 ) ,
HPX_TYPE_LEG_END = BIT ( 1 ) ,
HPX_TYPE_RC_END = BIT ( 2 ) ,
HPX_TYPE_RC_EC = BIT ( 3 ) ,
HPX_TYPE_ROOT_PORT = BIT ( 4 ) ,
HPX_TYPE_UPSTREAM = BIT ( 5 ) ,
HPX_TYPE_DOWNSTREAM = BIT ( 6 ) ,
HPX_TYPE_PCI_BRIDGE = BIT ( 7 ) ,
HPX_TYPE_PCIE_BRIDGE = BIT ( 8 ) ,
} ;
static u16 hpx3_device_type ( struct pci_dev * dev )
{
u16 pcie_type = pci_pcie_type ( dev ) ;
2020-02-10 11:52:56 +03:00
static const int pcie_to_hpx3_type [ ] = {
2019-08-27 12:49:50 +03:00
[ PCI_EXP_TYPE_ENDPOINT ] = HPX_TYPE_ENDPOINT ,
[ PCI_EXP_TYPE_LEG_END ] = HPX_TYPE_LEG_END ,
[ PCI_EXP_TYPE_RC_END ] = HPX_TYPE_RC_END ,
[ PCI_EXP_TYPE_RC_EC ] = HPX_TYPE_RC_EC ,
[ PCI_EXP_TYPE_ROOT_PORT ] = HPX_TYPE_ROOT_PORT ,
[ PCI_EXP_TYPE_UPSTREAM ] = HPX_TYPE_UPSTREAM ,
[ PCI_EXP_TYPE_DOWNSTREAM ] = HPX_TYPE_DOWNSTREAM ,
[ PCI_EXP_TYPE_PCI_BRIDGE ] = HPX_TYPE_PCI_BRIDGE ,
[ PCI_EXP_TYPE_PCIE_BRIDGE ] = HPX_TYPE_PCIE_BRIDGE ,
} ;
if ( pcie_type > = ARRAY_SIZE ( pcie_to_hpx3_type ) )
return 0 ;
return pcie_to_hpx3_type [ pcie_type ] ;
}
enum hpx_type3_fn_type {
HPX_FN_NORMAL = BIT ( 0 ) ,
HPX_FN_SRIOV_PHYS = BIT ( 1 ) ,
HPX_FN_SRIOV_VIRT = BIT ( 2 ) ,
} ;
static u8 hpx3_function_type ( struct pci_dev * dev )
{
if ( dev - > is_virtfn )
return HPX_FN_SRIOV_VIRT ;
else if ( pci_find_ext_capability ( dev , PCI_EXT_CAP_ID_SRIOV ) > 0 )
return HPX_FN_SRIOV_PHYS ;
else
return HPX_FN_NORMAL ;
}
static bool hpx3_cap_ver_matches ( u8 pcie_cap_id , u8 hpx3_cap_id )
{
u8 cap_ver = hpx3_cap_id & 0xf ;
if ( ( hpx3_cap_id & BIT ( 4 ) ) & & cap_ver > = pcie_cap_id )
return true ;
else if ( cap_ver = = pcie_cap_id )
return true ;
return false ;
}
enum hpx_type3_cfg_loc {
HPX_CFG_PCICFG = 0 ,
HPX_CFG_PCIE_CAP = 1 ,
HPX_CFG_PCIE_CAP_EXT = 2 ,
HPX_CFG_VEND_CAP = 3 ,
HPX_CFG_DVSEC = 4 ,
HPX_CFG_MAX ,
} ;
static void program_hpx_type3_register ( struct pci_dev * dev ,
const struct hpx_type3 * reg )
{
u32 match_reg , write_reg , header , orig_value ;
u16 pos ;
if ( ! ( hpx3_device_type ( dev ) & reg - > device_type ) )
return ;
if ( ! ( hpx3_function_type ( dev ) & reg - > function_type ) )
return ;
switch ( reg - > config_space_location ) {
case HPX_CFG_PCICFG :
pos = 0 ;
break ;
case HPX_CFG_PCIE_CAP :
pos = pci_find_capability ( dev , reg - > pci_exp_cap_id ) ;
if ( pos = = 0 )
return ;
break ;
case HPX_CFG_PCIE_CAP_EXT :
pos = pci_find_ext_capability ( dev , reg - > pci_exp_cap_id ) ;
if ( pos = = 0 )
return ;
pci_read_config_dword ( dev , pos , & header ) ;
if ( ! hpx3_cap_ver_matches ( PCI_EXT_CAP_VER ( header ) ,
reg - > pci_exp_cap_ver ) )
return ;
break ;
2020-07-07 23:09:37 +03:00
case HPX_CFG_VEND_CAP :
case HPX_CFG_DVSEC :
2019-08-27 12:49:50 +03:00
default :
pci_warn ( dev , " Encountered _HPX type 3 with unsupported config space location " ) ;
return ;
}
pci_read_config_dword ( dev , pos + reg - > match_offset , & match_reg ) ;
if ( ( match_reg & reg - > match_mask_and ) ! = reg - > match_value )
return ;
pci_read_config_dword ( dev , pos + reg - > reg_offset , & write_reg ) ;
orig_value = write_reg ;
write_reg & = reg - > reg_mask_and ;
write_reg | = reg - > reg_mask_or ;
if ( orig_value = = write_reg )
return ;
pci_write_config_dword ( dev , pos + reg - > reg_offset , write_reg ) ;
pci_dbg ( dev , " Applied _HPX3 at [0x%x]: 0x%08x -> 0x%08x " ,
pos , orig_value , write_reg ) ;
}
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
static void program_hpx_type3 ( struct pci_dev * dev , struct hpx_type3 * hpx )
2019-08-27 12:49:50 +03:00
{
if ( ! hpx )
return ;
if ( ! pci_is_pcie ( dev ) )
return ;
program_hpx_type3_register ( dev , hpx ) ;
}
2019-02-08 19:24:13 +03:00
static void parse_hpx3_register ( struct hpx_type3 * hpx3_reg ,
union acpi_object * reg_fields )
{
hpx3_reg - > device_type = reg_fields [ 0 ] . integer . value ;
hpx3_reg - > function_type = reg_fields [ 1 ] . integer . value ;
hpx3_reg - > config_space_location = reg_fields [ 2 ] . integer . value ;
hpx3_reg - > pci_exp_cap_id = reg_fields [ 3 ] . integer . value ;
hpx3_reg - > pci_exp_cap_ver = reg_fields [ 4 ] . integer . value ;
hpx3_reg - > pci_exp_vendor_id = reg_fields [ 5 ] . integer . value ;
hpx3_reg - > dvsec_id = reg_fields [ 6 ] . integer . value ;
hpx3_reg - > dvsec_rev = reg_fields [ 7 ] . integer . value ;
hpx3_reg - > match_offset = reg_fields [ 8 ] . integer . value ;
hpx3_reg - > match_mask_and = reg_fields [ 9 ] . integer . value ;
hpx3_reg - > match_value = reg_fields [ 10 ] . integer . value ;
hpx3_reg - > reg_offset = reg_fields [ 11 ] . integer . value ;
hpx3_reg - > reg_mask_and = reg_fields [ 12 ] . integer . value ;
hpx3_reg - > reg_mask_or = reg_fields [ 13 ] . integer . value ;
}
static acpi_status program_type3_hpx_record ( struct pci_dev * dev ,
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
union acpi_object * record )
2019-02-08 19:24:13 +03:00
{
union acpi_object * fields = record - > package . elements ;
u32 desc_count , expected_length , revision ;
union acpi_object * reg_fields ;
struct hpx_type3 hpx3 ;
int i ;
revision = fields [ 1 ] . integer . value ;
switch ( revision ) {
case 1 :
desc_count = fields [ 2 ] . integer . value ;
expected_length = 3 + desc_count * 14 ;
if ( record - > package . count ! = expected_length )
return AE_ERROR ;
for ( i = 2 ; i < expected_length ; i + + )
if ( fields [ i ] . type ! = ACPI_TYPE_INTEGER )
return AE_ERROR ;
for ( i = 0 ; i < desc_count ; i + + ) {
reg_fields = fields + 3 + i * 14 ;
parse_hpx3_register ( & hpx3 , reg_fields ) ;
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
program_hpx_type3 ( dev , & hpx3 ) ;
2019-02-08 19:24:13 +03:00
}
break ;
default :
printk ( KERN_WARNING
" %s: Type 3 Revision %d record not supported \n " ,
__func__ , revision ) ;
return AE_ERROR ;
}
return AE_OK ;
}
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
static acpi_status acpi_run_hpx ( struct pci_dev * dev , acpi_handle handle )
2014-09-13 01:23:14 +04:00
{
acpi_status status ;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER , NULL } ;
union acpi_object * package , * record , * fields ;
2019-08-27 12:49:49 +03:00
struct hpx_type0 hpx0 ;
struct hpx_type1 hpx1 ;
struct hpx_type2 hpx2 ;
2014-09-13 01:23:14 +04:00
u32 type ;
int i ;
status = acpi_evaluate_object ( handle , " _HPX " , NULL , & buffer ) ;
if ( ACPI_FAILURE ( status ) )
return status ;
package = ( union acpi_object * ) buffer . pointer ;
if ( package - > type ! = ACPI_TYPE_PACKAGE ) {
status = AE_ERROR ;
goto exit ;
}
for ( i = 0 ; i < package - > package . count ; i + + ) {
record = & package - > package . elements [ i ] ;
if ( record - > type ! = ACPI_TYPE_PACKAGE ) {
status = AE_ERROR ;
goto exit ;
}
fields = record - > package . elements ;
if ( fields [ 0 ] . type ! = ACPI_TYPE_INTEGER | |
fields [ 1 ] . type ! = ACPI_TYPE_INTEGER ) {
status = AE_ERROR ;
goto exit ;
}
type = fields [ 0 ] . integer . value ;
switch ( type ) {
case 0 :
2019-04-19 22:27:36 +03:00
memset ( & hpx0 , 0 , sizeof ( hpx0 ) ) ;
status = decode_type0_hpx_record ( record , & hpx0 ) ;
2014-09-13 01:23:14 +04:00
if ( ACPI_FAILURE ( status ) )
goto exit ;
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
program_hpx_type0 ( dev , & hpx0 ) ;
2014-09-13 01:23:14 +04:00
break ;
case 1 :
2019-04-19 22:27:36 +03:00
memset ( & hpx1 , 0 , sizeof ( hpx1 ) ) ;
status = decode_type1_hpx_record ( record , & hpx1 ) ;
2014-09-13 01:23:14 +04:00
if ( ACPI_FAILURE ( status ) )
goto exit ;
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
program_hpx_type1 ( dev , & hpx1 ) ;
2014-09-13 01:23:14 +04:00
break ;
case 2 :
2019-04-19 22:27:36 +03:00
memset ( & hpx2 , 0 , sizeof ( hpx2 ) ) ;
status = decode_type2_hpx_record ( record , & hpx2 ) ;
2014-09-13 01:23:14 +04:00
if ( ACPI_FAILURE ( status ) )
goto exit ;
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
program_hpx_type2 ( dev , & hpx2 ) ;
2014-09-13 01:23:14 +04:00
break ;
2019-02-08 19:24:13 +03:00
case 3 :
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
status = program_type3_hpx_record ( dev , record ) ;
2019-02-08 19:24:13 +03:00
if ( ACPI_FAILURE ( status ) )
goto exit ;
break ;
2014-09-13 01:23:14 +04:00
default :
2019-04-20 07:03:46 +03:00
pr_err ( " %s: Type %d record not supported \n " ,
2014-09-13 01:23:14 +04:00
__func__ , type ) ;
status = AE_ERROR ;
goto exit ;
}
}
exit :
kfree ( buffer . pointer ) ;
return status ;
}
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
static acpi_status acpi_run_hpp ( struct pci_dev * dev , acpi_handle handle )
2014-09-13 01:23:14 +04:00
{
acpi_status status ;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER , NULL } ;
union acpi_object * package , * fields ;
2019-08-27 12:49:49 +03:00
struct hpx_type0 hpx0 ;
2014-09-13 01:23:14 +04:00
int i ;
2019-08-27 12:49:49 +03:00
memset ( & hpx0 , 0 , sizeof ( hpx0 ) ) ;
2014-09-13 01:23:14 +04:00
status = acpi_evaluate_object ( handle , " _HPP " , NULL , & buffer ) ;
if ( ACPI_FAILURE ( status ) )
return status ;
package = ( union acpi_object * ) buffer . pointer ;
if ( package - > type ! = ACPI_TYPE_PACKAGE | |
package - > package . count ! = 4 ) {
status = AE_ERROR ;
goto exit ;
}
fields = package - > package . elements ;
for ( i = 0 ; i < 4 ; i + + ) {
if ( fields [ i ] . type ! = ACPI_TYPE_INTEGER ) {
status = AE_ERROR ;
goto exit ;
}
}
2019-08-27 12:49:49 +03:00
hpx0 . revision = 1 ;
hpx0 . cache_line_size = fields [ 0 ] . integer . value ;
hpx0 . latency_timer = fields [ 1 ] . integer . value ;
hpx0 . enable_serr = fields [ 2 ] . integer . value ;
hpx0 . enable_perr = fields [ 3 ] . integer . value ;
2019-04-19 22:27:36 +03:00
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
program_hpx_type0 ( dev , & hpx0 ) ;
2014-09-13 01:23:14 +04:00
exit :
kfree ( buffer . pointer ) ;
return status ;
}
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
/* pci_acpi_program_hp_params
2014-09-13 01:23:14 +04:00
*
* @ dev - the pci_dev for which we want parameters
*/
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
int pci_acpi_program_hp_params ( struct pci_dev * dev )
2014-09-13 01:23:14 +04:00
{
acpi_status status ;
acpi_handle handle , phandle ;
struct pci_bus * pbus ;
2015-03-24 19:12:45 +03:00
if ( acpi_pci_disabled )
return - ENODEV ;
2014-09-13 01:23:14 +04:00
handle = NULL ;
for ( pbus = dev - > bus ; pbus ; pbus = pbus - > parent ) {
handle = acpi_pci_get_bridge_handle ( pbus ) ;
if ( handle )
break ;
}
/*
* _HPP settings apply to all child buses , until another _HPP is
* encountered . If we don ' t find an _HPP for the input pci dev ,
* look for it in the parent device scope since that would apply to
* this pci dev .
*/
while ( handle ) {
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
status = acpi_run_hpx ( dev , handle ) ;
2014-09-13 01:23:14 +04:00
if ( ACPI_SUCCESS ( status ) )
return 0 ;
PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.
The struct hotplug_program_ops was added by 87fcf12e846a ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a155a ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").
The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.
Previously a programming of _HPX Type 0 was as follows:
drivers/pci/probe.c:
program_hpx_type0()
...
pci_configure_device()
hp_ops = {
.program_type0 = program_hpx_type0,
...
}
pci_acpi_program_hp_params(&hp_ops)
drivers/pci/pci-acpi.c:
pci_acpi_program_hp_params(&hp_ops)
acpi_run_hpx(hp_ops)
decode_type0_hpx_record()
hp_ops->program_type0 # program_hpx_type0() called via hp_ops
After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.
Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-27 12:49:51 +03:00
status = acpi_run_hpp ( dev , handle ) ;
2014-09-13 01:23:14 +04:00
if ( ACPI_SUCCESS ( status ) )
return 0 ;
if ( acpi_is_root_bridge ( handle ) )
break ;
status = acpi_get_parent ( handle , & phandle ) ;
if ( ACPI_FAILURE ( status ) )
break ;
handle = phandle ;
}
return - ENODEV ;
}
2016-10-28 11:52:06 +03:00
/**
* pciehp_is_native - Check whether a hotplug port is handled by the OS
2018-05-24 01:24:08 +03:00
* @ bridge : Hotplug port to check
2016-10-28 11:52:06 +03:00
*
2018-05-24 01:24:08 +03:00
* Returns true if the given @ bridge is handled by the native PCIe hotplug
* driver .
2016-10-28 11:52:06 +03:00
*/
2018-05-24 01:24:08 +03:00
bool pciehp_is_native ( struct pci_dev * bridge )
2016-10-28 11:52:06 +03:00
{
2018-05-24 01:24:08 +03:00
const struct pci_host_bridge * host ;
u32 slot_cap ;
2016-10-28 11:52:06 +03:00
2018-05-24 01:24:08 +03:00
if ( ! IS_ENABLED ( CONFIG_HOTPLUG_PCI_PCIE ) )
2016-10-28 11:52:06 +03:00
return false ;
2018-05-24 01:24:08 +03:00
pcie_capability_read_dword ( bridge , PCI_EXP_SLTCAP , & slot_cap ) ;
if ( ! ( slot_cap & PCI_EXP_SLTCAP_HPC ) )
2016-10-28 11:52:06 +03:00
return false ;
2018-05-24 01:24:08 +03:00
if ( pcie_ports_native )
return true ;
host = pci_find_host_bridge ( bridge - > bus ) ;
return host - > native_pcie_hotplug ;
2016-10-28 11:52:06 +03:00
}
2018-05-31 19:42:11 +03:00
/**
* shpchp_is_native - Check whether a hotplug port is handled by the OS
* @ bridge : Hotplug port to check
*
* Returns true if the given @ bridge is handled by the native SHPC hotplug
* driver .
*/
bool shpchp_is_native ( struct pci_dev * bridge )
{
2018-06-26 00:49:06 +03:00
return bridge - > shpc_managed ;
2018-05-31 19:42:11 +03:00
}
2014-09-13 01:36:29 +04:00
/**
* pci_acpi_wake_bus - Root bus wakeup notification fork function .
2017-06-12 23:48:41 +03:00
* @ context : Device wakeup context .
2014-09-13 01:36:29 +04:00
*/
2017-06-12 23:48:41 +03:00
static void pci_acpi_wake_bus ( struct acpi_device_wakeup_context * context )
2014-09-13 01:36:29 +04:00
{
struct acpi_device * adev ;
struct acpi_pci_root * root ;
2017-06-12 23:48:41 +03:00
adev = container_of ( context , struct acpi_device , wakeup . context ) ;
2014-09-13 01:36:29 +04:00
root = acpi_driver_data ( adev ) ;
pci_pme_wakeup_bus ( root - > bus ) ;
}
/**
* pci_acpi_wake_dev - PCI device wakeup notification work function .
2017-06-12 23:48:41 +03:00
* @ context : Device wakeup context .
2014-09-13 01:36:29 +04:00
*/
2017-06-12 23:48:41 +03:00
static void pci_acpi_wake_dev ( struct acpi_device_wakeup_context * context )
2014-09-13 01:36:29 +04:00
{
struct pci_dev * pci_dev ;
pci_dev = to_pci_dev ( context - > dev ) ;
if ( pci_dev - > pme_poll )
pci_dev - > pme_poll = false ;
if ( pci_dev - > current_state = = PCI_D3cold ) {
pci_wakeup_event ( pci_dev ) ;
2017-06-12 23:48:41 +03:00
pm_request_resume ( & pci_dev - > dev ) ;
2014-09-13 01:36:29 +04:00
return ;
}
/* Clear PME Status if set. */
if ( pci_dev - > pme_support )
pci_check_pme_status ( pci_dev ) ;
pci_wakeup_event ( pci_dev ) ;
2017-06-12 23:48:41 +03:00
pm_request_resume ( & pci_dev - > dev ) ;
2014-09-13 01:36:29 +04:00
2014-11-11 07:02:17 +03:00
pci_pme_wakeup_bus ( pci_dev - > subordinate ) ;
2014-09-13 01:36:29 +04:00
}
/**
* pci_acpi_add_bus_pm_notifier - Register PM notifier for root PCI bus .
* @ dev : PCI root bridge ACPI device .
*/
acpi_status pci_acpi_add_bus_pm_notifier ( struct acpi_device * dev )
{
return acpi_add_pm_notifier ( dev , NULL , pci_acpi_wake_bus ) ;
}
/**
* pci_acpi_add_pm_notifier - Register PM notifier for given PCI device .
* @ dev : ACPI device to add the notifier for .
* @ pci_dev : PCI device to check for the PME status if an event is signaled .
*/
acpi_status pci_acpi_add_pm_notifier ( struct acpi_device * dev ,
struct pci_dev * pci_dev )
{
return acpi_add_pm_notifier ( dev , & pci_dev - > dev , pci_acpi_wake_dev ) ;
}
2005-03-19 08:15:48 +03:00
/*
* _SxD returns the D - state with the highest power
* ( lowest D - state number ) supported in the S - state " x " .
*
* If the devices does not have a _PRW
* ( Power Resources for Wake ) supporting system wakeup from " x "
* then the OS is free to choose a lower power ( higher number
* D - state ) than the return value from _SxD .
*
* But if _PRW is enabled at S - state " x " , the OS
* must not choose a power lower than _SxD - -
* unless the device has an _SxW method specifying
* the lowest power ( highest D - state number ) the device
* may enter while still able to wake the system .
*
* ie . depending on global OS policy :
*
* if ( _PRW at S - state x )
* choose from highest power _SxD to lowest power _SxW
* else // no _PRW at S-state x
2013-11-14 22:28:18 +04:00
* choose highest power _SxD or any lower power
2005-03-19 08:15:48 +03:00
*/
2008-06-05 03:16:37 +04:00
static pci_power_t acpi_pci_choose_state ( struct pci_dev * pdev )
2005-03-19 08:15:48 +03:00
{
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 06:23:51 +04:00
int acpi_state , d_max ;
2005-03-19 08:15:48 +03:00
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 06:23:51 +04:00
if ( pdev - > no_d3cold )
d_max = ACPI_STATE_D3_HOT ;
else
d_max = ACPI_STATE_D3_COLD ;
acpi_state = acpi_pm_device_sleep_state ( & pdev - > dev , NULL , d_max ) ;
2007-07-20 06:03:22 +04:00
if ( acpi_state < 0 )
return PCI_POWER_ERROR ;
switch ( acpi_state ) {
case ACPI_STATE_D0 :
return PCI_D0 ;
case ACPI_STATE_D1 :
return PCI_D1 ;
case ACPI_STATE_D2 :
return PCI_D2 ;
2012-04-23 05:03:49 +04:00
case ACPI_STATE_D3_HOT :
2007-07-20 06:03:22 +04:00
return PCI_D3hot ;
2011-05-04 18:56:43 +04:00
case ACPI_STATE_D3_COLD :
return PCI_D3cold ;
2007-07-20 06:03:22 +04:00
}
return PCI_POWER_ERROR ;
2005-03-19 08:15:48 +03:00
}
2008-07-07 05:32:02 +04:00
2018-09-28 00:57:14 +03:00
static struct acpi_device * acpi_pci_find_companion ( struct device * dev ) ;
static bool acpi_pci_bridge_d3 ( struct pci_dev * dev )
{
const struct fwnode_handle * fwnode ;
struct acpi_device * adev ;
struct pci_dev * root ;
u8 val ;
if ( ! dev - > is_hotplug_bridge )
return false ;
2020-10-02 08:10:12 +03:00
/* Assume D3 support if the bridge is power-manageable by ACPI. */
adev = ACPI_COMPANION ( & dev - > dev ) ;
if ( ! adev & & ! pci_dev_is_added ( dev ) ) {
adev = acpi_pci_find_companion ( & dev - > dev ) ;
ACPI_COMPANION_SET ( & dev - > dev , adev ) ;
}
if ( adev & & acpi_device_power_manageable ( adev ) )
return true ;
2018-09-28 00:57:14 +03:00
/*
* Look for a special _DSD property for the root port and if it
* is set we know the hierarchy behind it supports D3 just fine .
*/
2020-05-09 13:19:28 +03:00
root = pcie_find_root_port ( dev ) ;
2018-09-28 00:57:14 +03:00
if ( ! root )
return false ;
adev = ACPI_COMPANION ( & root - > dev ) ;
if ( root = = dev ) {
/*
* It is possible that the ACPI companion is not yet bound
* for the root port so look it up manually here .
*/
if ( ! adev & & ! pci_dev_is_added ( root ) )
adev = acpi_pci_find_companion ( & root - > dev ) ;
}
if ( ! adev )
return false ;
fwnode = acpi_fwnode_handle ( adev ) ;
if ( fwnode_property_read_u8 ( fwnode , " HotPlugSupportInD3 " , & val ) )
return false ;
return val = = 1 ;
}
2008-07-07 05:32:02 +04:00
static bool acpi_pci_power_manageable ( struct pci_dev * dev )
{
2014-07-24 03:18:53 +04:00
struct acpi_device * adev = ACPI_COMPANION ( & dev - > dev ) ;
return adev ? acpi_device_power_manageable ( adev ) : false ;
2008-07-07 05:32:02 +04:00
}
2005-03-19 08:15:48 +03:00
2005-03-19 08:16:18 +03:00
static int acpi_pci_set_power_state ( struct pci_dev * dev , pci_power_t state )
{
2014-07-24 03:18:53 +04:00
struct acpi_device * adev = ACPI_COMPANION ( & dev - > dev ) ;
2008-02-23 08:41:51 +03:00
static const u8 state_conv [ ] = {
[ PCI_D0 ] = ACPI_STATE_D0 ,
[ PCI_D1 ] = ACPI_STATE_D1 ,
[ PCI_D2 ] = ACPI_STATE_D2 ,
2015-05-16 02:55:35 +03:00
[ PCI_D3hot ] = ACPI_STATE_D3_HOT ,
2013-06-14 02:29:50 +04:00
[ PCI_D3cold ] = ACPI_STATE_D3_COLD ,
2005-03-19 08:16:18 +03:00
} ;
2008-07-07 05:32:52 +04:00
int error = - EINVAL ;
2005-03-19 08:16:18 +03:00
2007-07-20 06:03:25 +04:00
/* If the ACPI device has _EJ0, ignore the device */
2014-07-24 03:18:53 +04:00
if ( ! adev | | acpi_has_method ( adev - > handle , " _EJ0 " ) )
2008-07-07 05:32:52 +04:00
return - ENODEV ;
2008-02-23 08:41:51 +03:00
switch ( state ) {
2012-10-24 04:08:38 +04:00
case PCI_D3cold :
if ( dev_pm_qos_flags ( & dev - > dev , PM_QOS_FLAG_NO_POWER_OFF ) = =
PM_QOS_FLAGS_ALL ) {
error = - EBUSY ;
break ;
}
2020-07-07 23:09:37 +03:00
fallthrough ;
2008-02-23 08:41:51 +03:00
case PCI_D0 :
case PCI_D1 :
case PCI_D2 :
case PCI_D3hot :
2014-07-24 03:18:53 +04:00
error = acpi_device_set_power ( adev , state_conv [ state ] ) ;
2008-02-23 08:41:51 +03:00
}
2008-07-07 05:32:52 +04:00
if ( ! error )
2018-01-18 21:55:24 +03:00
pci_dbg ( dev , " power state changed by ACPI to %s \n " ,
2021-03-25 21:57:51 +03:00
acpi_power_state_string ( adev - > power . state ) ) ;
2008-07-07 05:32:52 +04:00
return error ;
2005-03-19 08:16:18 +03:00
}
2016-09-18 06:39:20 +03:00
static pci_power_t acpi_pci_get_power_state ( struct pci_dev * dev )
{
struct acpi_device * adev = ACPI_COMPANION ( & dev - > dev ) ;
static const pci_power_t state_conv [ ] = {
[ ACPI_STATE_D0 ] = PCI_D0 ,
[ ACPI_STATE_D1 ] = PCI_D1 ,
[ ACPI_STATE_D2 ] = PCI_D2 ,
[ ACPI_STATE_D3_HOT ] = PCI_D3hot ,
[ ACPI_STATE_D3_COLD ] = PCI_D3cold ,
} ;
int state ;
if ( ! adev | | ! acpi_device_power_manageable ( adev ) )
return PCI_UNKNOWN ;
2019-06-25 13:29:40 +03:00
state = adev - > power . state ;
if ( state = = ACPI_STATE_UNKNOWN )
2016-09-18 06:39:20 +03:00
return PCI_UNKNOWN ;
return state_conv [ state ] ;
}
2019-06-25 15:09:12 +03:00
static void acpi_pci_refresh_power_state ( struct pci_dev * dev )
{
struct acpi_device * adev = ACPI_COMPANION ( & dev - > dev ) ;
if ( adev & & acpi_device_power_manageable ( adev ) )
acpi_device_update_power ( adev , NULL ) ;
}
2017-06-24 02:56:13 +03:00
static int acpi_pci_propagate_wakeup ( struct pci_bus * bus , bool enable )
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support
Some PCI devices (not PCI Express), like PCI add-on cards, can
generate PME#, but they don't have any special platform wake-up
support. For this reason, even if they generate PME# to wake up the
system from a sleep state, wake-up events are not generated by the
platform.
It turns out that, at least on some systems, PCI bridges and the PCI
host bridge have ACPI GPEs associated with them that, if enabled to
generate wake-up events, allow the system to wake up if one of the
add-on devices asserts PME# while the system is in a sleep state.
Following this observation, if a PCI device without direct ACPI
wake-up support is prepared to wake up the system during a transition
into a sleep state (eg. suspend to RAM), try to configure the bridges
on the path from the device to the root bridge to wake-up the system.
Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-09-09 01:16:24 +04:00
{
while ( bus - > parent ) {
2017-06-24 02:56:13 +03:00
if ( acpi_pm_device_can_wakeup ( & bus - > self - > dev ) )
PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()
The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
be reference counted for wakeup enabling, because they may be enabled
to signal wakeup on behalf of their subordinate devices and that
may happen for multiple times in a row, whereas for the other devices
it only makes sense to enable wakeup signaling once.
However, this becomes problematic if the bridge itself is suspended,
because it is treated as a "regular" device in that case and the
reference counting doesn't work.
For instance, suppose that there are two devices below a bridge and
they both can signal wakeup. Every time one of them is suspended,
wakeup signaling is enabled for the bridge, so when they both have
been suspended, the bridge's wakeup reference counter value is 2.
Say that the bridge is suspended subsequently and acpi_pci_wakeup()
is called for it. Because the bridge can signal wakeup, that
function will invoke acpi_pm_set_device_wakeup() to configure it
and __acpi_pm_set_device_wakeup() will be called with the last
argument equal to 1. This causes __acpi_device_wakeup_enable()
invoked by it to omit the reference counting, because the reference
counter of the target device (the bridge) is 2 at that time.
Now say that the bridge resumes and one of the device below it
resumes too, so the bridge's reference counter becomes 0 and
wakeup signaling is disabled for it, but there is still the other
suspended device which may need the bridge to signal wakeup on its
behalf and that is not going to work.
To address this scenario, use wakeup enable reference counting for
all devices, not just for bridges, so drop the last argument from
__acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
which causes acpi_pm_set_device_wakeup() and
acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
and use the former instead of it everywhere.
Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
2020-11-24 22:44:00 +03:00
return acpi_pm_set_device_wakeup ( & bus - > self - > dev , enable ) ;
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support
Some PCI devices (not PCI Express), like PCI add-on cards, can
generate PME#, but they don't have any special platform wake-up
support. For this reason, even if they generate PME# to wake up the
system from a sleep state, wake-up events are not generated by the
platform.
It turns out that, at least on some systems, PCI bridges and the PCI
host bridge have ACPI GPEs associated with them that, if enabled to
generate wake-up events, allow the system to wake up if one of the
add-on devices asserts PME# while the system is in a sleep state.
Following this observation, if a PCI device without direct ACPI
wake-up support is prepared to wake up the system during a transition
into a sleep state (eg. suspend to RAM), try to configure the bridges
on the path from the device to the root bridge to wake-up the system.
Reviewed-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-09-09 01:16:24 +04:00
2010-02-18 01:44:09 +03:00
bus = bus - > parent ;
}
/* We have reached the root bus. */
2017-06-24 02:56:13 +03:00
if ( bus - > bridge ) {
if ( acpi_pm_device_can_wakeup ( bus - > bridge ) )
PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()
The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
be reference counted for wakeup enabling, because they may be enabled
to signal wakeup on behalf of their subordinate devices and that
may happen for multiple times in a row, whereas for the other devices
it only makes sense to enable wakeup signaling once.
However, this becomes problematic if the bridge itself is suspended,
because it is treated as a "regular" device in that case and the
reference counting doesn't work.
For instance, suppose that there are two devices below a bridge and
they both can signal wakeup. Every time one of them is suspended,
wakeup signaling is enabled for the bridge, so when they both have
been suspended, the bridge's wakeup reference counter value is 2.
Say that the bridge is suspended subsequently and acpi_pci_wakeup()
is called for it. Because the bridge can signal wakeup, that
function will invoke acpi_pm_set_device_wakeup() to configure it
and __acpi_pm_set_device_wakeup() will be called with the last
argument equal to 1. This causes __acpi_device_wakeup_enable()
invoked by it to omit the reference counting, because the reference
counter of the target device (the bridge) is 2 at that time.
Now say that the bridge resumes and one of the device below it
resumes too, so the bridge's reference counter becomes 0 and
wakeup signaling is disabled for it, but there is still the other
suspended device which may need the bridge to signal wakeup on its
behalf and that is not going to work.
To address this scenario, use wakeup enable reference counting for
all devices, not just for bridges, so drop the last argument from
__acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(),
which causes acpi_pm_set_device_wakeup() and
acpi_pm_set_bridge_wakeup() to become identical, so drop the latter
and use the former instead of it everywhere.
Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
2020-11-24 22:44:00 +03:00
return acpi_pm_set_device_wakeup ( bus - > bridge , enable ) ;
2017-06-24 02:56:13 +03:00
}
return 0 ;
2010-02-18 01:44:09 +03:00
}
2017-06-24 02:56:13 +03:00
static int acpi_pci_wakeup ( struct pci_dev * dev , bool enable )
2010-02-18 01:44:09 +03:00
{
2017-06-24 02:56:13 +03:00
if ( acpi_pm_device_can_wakeup ( & dev - > dev ) )
return acpi_pm_set_device_wakeup ( & dev - > dev , enable ) ;
2010-02-18 01:44:09 +03:00
2017-06-24 02:56:13 +03:00
return acpi_pci_propagate_wakeup ( dev - > bus , enable ) ;
2010-02-18 01:44:09 +03:00
}
2015-01-21 04:17:42 +03:00
static bool acpi_pci_need_resume ( struct pci_dev * dev )
{
struct acpi_device * adev = ACPI_COMPANION ( & dev - > dev ) ;
2018-07-01 00:19:33 +03:00
/*
* In some cases ( eg . Samsung 305 V4A ) leaving a bridge in suspend over
* system - wide suspend / resume confuses the platform firmware , so avoid
2018-08-16 13:56:46 +03:00
* doing that . According to Section 16.1 .6 of ACPI 6.2 , endpoint
2018-07-01 00:19:33 +03:00
* devices are expected to be in D3 before invoking the S3 entry path
* from the firmware , so they should not be affected by this issue .
*/
2018-08-16 13:56:46 +03:00
if ( pci_is_bridge ( dev ) & & acpi_target_system_state ( ) ! = ACPI_STATE_S0 )
2018-07-01 00:19:33 +03:00
return true ;
2015-01-21 04:17:42 +03:00
if ( ! adev | | ! acpi_device_power_manageable ( adev ) )
return false ;
2019-05-16 13:42:20 +03:00
if ( adev - > wakeup . flags . valid & &
device_may_wakeup ( & dev - > dev ) ! = ! ! adev - > wakeup . prepare_count )
2015-01-21 04:17:42 +03:00
return true ;
if ( acpi_target_system_state ( ) = = ACPI_STATE_S0 )
return false ;
return ! ! adev - > power . flags . dsw_present ;
}
2015-12-06 19:33:45 +03:00
static const struct pci_platform_pm_ops acpi_pci_platform_pm = {
2018-09-28 00:57:14 +03:00
. bridge_d3 = acpi_pci_bridge_d3 ,
2008-07-07 05:32:02 +04:00
. is_manageable = acpi_pci_power_manageable ,
. set_state = acpi_pci_set_power_state ,
2016-09-18 06:39:20 +03:00
. get_state = acpi_pci_get_power_state ,
2019-06-25 15:09:12 +03:00
. refresh_state = acpi_pci_refresh_power_state ,
2008-07-07 05:32:02 +04:00
. choose_state = acpi_pci_choose_state ,
2017-06-24 02:57:35 +03:00
. set_wakeup = acpi_pci_wakeup ,
2015-01-21 04:17:42 +03:00
. need_resume = acpi_pci_need_resume ,
2008-07-07 05:32:02 +04:00
} ;
2005-03-19 08:16:18 +03:00
2013-04-12 09:44:21 +04:00
void acpi_pci_add_bus ( struct pci_bus * bus )
{
2015-03-25 09:37:06 +03:00
union acpi_object * obj ;
struct pci_host_bridge * bridge ;
2017-09-14 17:50:14 +03:00
if ( acpi_pci_disabled | | ! bus - > bridge | | ! ACPI_HANDLE ( bus - > bridge ) )
2013-04-12 09:44:21 +04:00
return ;
2013-07-14 01:27:23 +04:00
acpi_pci_slot_enumerate ( bus ) ;
acpiphp_enumerate_slots ( bus ) ;
2015-03-25 09:37:06 +03:00
/*
* For a host bridge , check its _DSM for function 8 and if
* that is available , mark it in pci_host_bridge .
*/
if ( ! pci_is_root_bus ( bus ) )
return ;
2017-06-05 19:40:46 +03:00
obj = acpi_evaluate_dsm ( ACPI_HANDLE ( bus - > bridge ) , & pci_acpi_dsm_guid , 3 ,
2020-05-27 00:39:05 +03:00
DSM_PCI_POWER_ON_RESET_DELAY , NULL ) ;
2015-03-25 09:37:06 +03:00
if ( ! obj )
return ;
if ( obj - > type = = ACPI_TYPE_INTEGER & & obj - > integer . value = = 1 ) {
bridge = pci_find_host_bridge ( bus ) ;
bridge - > ignore_reset_delay = 1 ;
}
ACPI_FREE ( obj ) ;
2013-04-12 09:44:21 +04:00
}
void acpi_pci_remove_bus ( struct pci_bus * bus )
{
2013-07-14 01:27:23 +04:00
if ( acpi_pci_disabled | | ! bus - > bridge )
2013-04-12 09:44:21 +04:00
return ;
2013-04-12 09:44:26 +04:00
acpiphp_remove_slots ( bus ) ;
2013-04-12 09:44:24 +04:00
acpi_pci_slot_remove ( bus ) ;
2013-04-12 09:44:21 +04:00
}
2005-03-19 02:53:36 +03:00
/* ACPI bus type */
2013-11-29 19:27:34 +04:00
static struct acpi_device * acpi_pci_find_companion ( struct device * dev )
2005-03-19 02:53:36 +03:00
{
ACPI: Try harder to resolve _ADR collisions for bridges
In theory, under a given ACPI namespace node there should be only
one child device object with _ADR whose value matches a given bus
address exactly. In practice, however, there are systems in which
multiple child device objects under a given parent have _ADR matching
exactly the same address. In those cases we use _STA to determine
which of the multiple matching devices is enabled, since some systems
are known to indicate which ACPI device object to associate with the
given physical (usually PCI) device this way.
Unfortunately, as it turns out, there are systems in which many
device objects under the same parent have _ADR matching exactly the
same bus address and none of them has _STA, in which case they all
should be regarded as enabled according to the spec. Still, if
those device objects are supposed to represent bridges (e.g. this
is the case for device objects corresponding to PCIe ports), we can
try harder and skip the ones that have no child device objects in the
ACPI namespace. With luck, we can avoid using device objects that we
are not expected to use this way.
Although this only works for bridges whose children also have ACPI
namespace representation, it is sufficient to address graphics
adapter detection issues on some systems, so rework the code finding
a matching device ACPI handle for a given bus address to implement
this idea.
Introduce a new function, acpi_find_child(), taking three arguments:
the ACPI handle of the device's parent, a bus address suitable for
the device's bus type and a bool indicating if the device is a
bridge and make it work as outlined above. Reimplement the function
currently used for this purpose, acpi_get_child(), as a call to
acpi_find_child() with the last argument set to 'false' and make
the PCI subsystem use acpi_find_child() with the bridge information
passed as the last argument to it. [Lan Tianyu notices that it is
not sufficient to use pci_is_bridge() for that, because the device's
subordinate pointer hasn't been set yet at this point, so use
hdr_type instead.]
This change fixes a regression introduced inadvertently by commit
33f767d (ACPI: Rework acpi_get_child() to be more efficient) which
overlooked the fact that for acpi_walk_namespace() "post-order" means
"after all children have been visited" rather than "on the way back",
so for device objects without children and for namespace walks of
depth 1, as in the acpi_get_child() case, the "post-order" callbacks
ordering is actually the same as the ordering of "pre-order" ones.
Since that commit changed the namespace walk in acpi_get_child() to
terminate after finding the first matching object instead of going
through all of them and returning the last one, it effectively
changed the result returned by that function in some rare cases and
that led to problems (the switch from a "pre-order" to a "post-order"
callback was supposed to prevent that from happening, but it was
ineffective).
As it turns out, the systems where the change made by commit
33f767d actually matters are those where there are multiple ACPI
device objects representing the same PCIe port (which effectively
is a bridge). Moreover, only one of them, and the one we are
expected to use, has child device objects in the ACPI namespace,
so the regression can be addressed as described above.
References: https://bugzilla.kernel.org/show_bug.cgi?id=60561
Reported-by: Peter Wu <lekensteyn@gmail.com>
Tested-by: Vladimir Lalov <mail@vlalov.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
2013-08-08 00:55:00 +04:00
struct pci_dev * pci_dev = to_pci_dev ( dev ) ;
2020-12-11 23:17:35 +03:00
struct acpi_device * adev ;
2013-11-29 02:58:08 +04:00
bool check_children ;
ACPI: Try harder to resolve _ADR collisions for bridges
In theory, under a given ACPI namespace node there should be only
one child device object with _ADR whose value matches a given bus
address exactly. In practice, however, there are systems in which
multiple child device objects under a given parent have _ADR matching
exactly the same address. In those cases we use _STA to determine
which of the multiple matching devices is enabled, since some systems
are known to indicate which ACPI device object to associate with the
given physical (usually PCI) device this way.
Unfortunately, as it turns out, there are systems in which many
device objects under the same parent have _ADR matching exactly the
same bus address and none of them has _STA, in which case they all
should be regarded as enabled according to the spec. Still, if
those device objects are supposed to represent bridges (e.g. this
is the case for device objects corresponding to PCIe ports), we can
try harder and skip the ones that have no child device objects in the
ACPI namespace. With luck, we can avoid using device objects that we
are not expected to use this way.
Although this only works for bridges whose children also have ACPI
namespace representation, it is sufficient to address graphics
adapter detection issues on some systems, so rework the code finding
a matching device ACPI handle for a given bus address to implement
this idea.
Introduce a new function, acpi_find_child(), taking three arguments:
the ACPI handle of the device's parent, a bus address suitable for
the device's bus type and a bool indicating if the device is a
bridge and make it work as outlined above. Reimplement the function
currently used for this purpose, acpi_get_child(), as a call to
acpi_find_child() with the last argument set to 'false' and make
the PCI subsystem use acpi_find_child() with the bridge information
passed as the last argument to it. [Lan Tianyu notices that it is
not sufficient to use pci_is_bridge() for that, because the device's
subordinate pointer hasn't been set yet at this point, so use
hdr_type instead.]
This change fixes a regression introduced inadvertently by commit
33f767d (ACPI: Rework acpi_get_child() to be more efficient) which
overlooked the fact that for acpi_walk_namespace() "post-order" means
"after all children have been visited" rather than "on the way back",
so for device objects without children and for namespace walks of
depth 1, as in the acpi_get_child() case, the "post-order" callbacks
ordering is actually the same as the ordering of "pre-order" ones.
Since that commit changed the namespace walk in acpi_get_child() to
terminate after finding the first matching object instead of going
through all of them and returning the last one, it effectively
changed the result returned by that function in some rare cases and
that led to problems (the switch from a "pre-order" to a "post-order"
callback was supposed to prevent that from happening, but it was
ineffective).
As it turns out, the systems where the change made by commit
33f767d actually matters are those where there are multiple ACPI
device objects representing the same PCIe port (which effectively
is a bridge). Moreover, only one of them, and the one we are
expected to use, has child device objects in the ACPI namespace,
so the regression can be addressed as described above.
References: https://bugzilla.kernel.org/show_bug.cgi?id=60561
Reported-by: Peter Wu <lekensteyn@gmail.com>
Tested-by: Vladimir Lalov <mail@vlalov.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
2013-08-08 00:55:00 +04:00
u64 addr ;
2005-03-19 02:53:36 +03:00
2014-05-04 08:23:38 +04:00
check_children = pci_is_bridge ( pci_dev ) ;
2005-03-19 02:53:36 +03:00
/* Please ref to ACPI spec for the syntax of _ADR */
addr = ( PCI_SLOT ( pci_dev - > devfn ) < < 16 ) | PCI_FUNC ( pci_dev - > devfn ) ;
2020-12-11 23:17:35 +03:00
adev = acpi_find_child_device ( ACPI_COMPANION ( dev - > parent ) , addr ,
2013-11-29 02:58:08 +04:00
check_children ) ;
2020-12-11 23:17:35 +03:00
/*
* There may be ACPI device objects in the ACPI namespace that are
* children of the device object representing the host bridge , but don ' t
* represent PCI devices . Both _HID and _ADR may be present for them ,
* even though that is against the specification ( for example , see
* Section 6.1 of ACPI 6.3 ) , but in many cases the _ADR returns 0 which
* appears to indicate that they should not be taken into consideration
* as potential companions of PCI devices on the root bus .
*
* To catch this special case , disregard the returned device object if
* it has a valid _HID , addr is 0 and the PCI device at hand is on the
* root bus .
*/
if ( adev & & adev - > pnp . type . platform_id & & ! addr & &
pci_is_root_bus ( pci_dev - > bus ) )
return NULL ;
return adev ;
2005-03-19 02:53:36 +03:00
}
2015-03-25 09:37:06 +03:00
/**
* pci_acpi_optimize_delay - optimize PCI D3 and D3cold delay from ACPI
* @ pdev : the PCI device whose delay is to be updated
2015-07-15 12:29:46 +03:00
* @ handle : ACPI handle of this device
2015-03-25 09:37:06 +03:00
*
2020-07-31 00:08:48 +03:00
* Update the d3hot_delay and d3cold_delay of a PCI device from the ACPI _DSM
2015-03-25 09:37:06 +03:00
* control method of either the device itself or the PCI host bridge .
*
* Function 8 , " Reset Delay, " applies to the entire hierarchy below a PCI
* host bridge . If it returns one , the OS may assume that all devices in
* the hierarchy have already completed power - on reset delays .
*
* Function 9 , " Device Readiness Durations, " applies only to the object
* where it is located . It returns delay durations required after various
* events if the device requires less time than the spec requires . Delays
* from this function take precedence over the Reset Delay function .
*
* These _DSM functions are defined by the draft ECN of January 28 , 2014 ,
* titled " ACPI additions for FW latency optimizations. "
*/
static void pci_acpi_optimize_delay ( struct pci_dev * pdev ,
acpi_handle handle )
{
struct pci_host_bridge * bridge = pci_find_host_bridge ( pdev - > bus ) ;
int value ;
union acpi_object * obj , * elements ;
if ( bridge - > ignore_reset_delay )
pdev - > d3cold_delay = 0 ;
2017-06-05 19:40:46 +03:00
obj = acpi_evaluate_dsm ( handle , & pci_acpi_dsm_guid , 3 ,
2020-05-27 00:39:05 +03:00
DSM_PCI_DEVICE_READINESS_DURATIONS , NULL ) ;
2015-03-25 09:37:06 +03:00
if ( ! obj )
return ;
if ( obj - > type = = ACPI_TYPE_PACKAGE & & obj - > package . count = = 5 ) {
elements = obj - > package . elements ;
if ( elements [ 0 ] . type = = ACPI_TYPE_INTEGER ) {
value = ( int ) elements [ 0 ] . integer . value / 1000 ;
if ( value < PCI_PM_D3COLD_WAIT )
pdev - > d3cold_delay = value ;
}
if ( elements [ 3 ] . type = = ACPI_TYPE_INTEGER ) {
value = ( int ) elements [ 3 ] . integer . value / 1000 ;
2020-07-31 00:08:48 +03:00
if ( value < PCI_PM_D3HOT_WAIT )
pdev - > d3hot_delay = value ;
2015-03-25 09:37:06 +03:00
}
}
ACPI_FREE ( obj ) ;
}
2020-07-08 01:46:03 +03:00
static void pci_acpi_set_external_facing ( struct pci_dev * dev )
2018-08-16 12:28:48 +03:00
{
u8 val ;
if ( pci_pcie_type ( dev ) ! = PCI_EXP_TYPE_ROOT_PORT )
return ;
if ( device_property_read_u8 ( & dev - > dev , " ExternalFacingPort " , & val ) )
return ;
/*
* These root ports expose PCIe ( including DMA ) outside of the
2020-07-08 01:46:03 +03:00
* system . Everything downstream from them is external .
2018-08-16 12:28:48 +03:00
*/
if ( val )
2020-07-08 01:46:03 +03:00
dev - > external_facing = 1 ;
2018-08-16 12:28:48 +03:00
}
2012-12-23 03:02:54 +04:00
static void pci_acpi_setup ( struct device * dev )
2012-12-23 03:02:44 +04:00
{
struct pci_dev * pci_dev = to_pci_dev ( dev ) ;
2013-12-30 02:37:15 +04:00
struct acpi_device * adev = ACPI_COMPANION ( dev ) ;
2012-12-23 03:02:54 +04:00
2013-12-30 02:37:15 +04:00
if ( ! adev )
return ;
2015-03-25 09:37:06 +03:00
pci_acpi_optimize_delay ( pci_dev , adev - > handle ) ;
2020-07-08 01:46:03 +03:00
pci_acpi_set_external_facing ( pci_dev ) ;
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 03:26:07 +03:00
pci_acpi_add_edr_notifier ( pci_dev ) ;
2015-03-25 09:37:06 +03:00
2013-12-30 02:37:15 +04:00
pci_acpi_add_pm_notifier ( adev , pci_dev ) ;
if ( ! adev - > wakeup . flags . valid )
2012-12-23 03:02:44 +04:00
return ;
device_set_wakeup_capable ( dev , true ) ;
2018-09-28 00:54:13 +03:00
/*
* For bridges that can do D3 we enable wake automatically ( as
* we do for the power management itself in that case ) . The
* reason is that the bridge may have additional methods such as
* _DSW that need to be called .
*/
if ( pci_dev - > bridge_d3 )
device_wakeup_enable ( dev ) ;
2017-06-24 02:56:13 +03:00
acpi_pci_wakeup ( pci_dev , false ) ;
2019-06-25 13:29:42 +03:00
acpi_device_power_add_dependent ( adev , dev ) ;
2012-12-23 03:02:44 +04:00
}
2012-12-23 03:02:54 +04:00
static void pci_acpi_cleanup ( struct device * dev )
2012-12-23 03:02:44 +04:00
{
2013-12-30 02:37:15 +04:00
struct acpi_device * adev = ACPI_COMPANION ( dev ) ;
2018-09-28 00:54:13 +03:00
struct pci_dev * pci_dev = to_pci_dev ( dev ) ;
2013-12-30 02:37:15 +04:00
if ( ! adev )
return ;
2012-12-23 03:02:44 +04:00
PCI/DPC: Add Error Disconnect Recover (EDR) support
Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
notify OSPM that a device has been disconnected due to an error condition
(ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices
via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler
should invalidate software state associated with disconnected devices and
may attempt to recover them. OSPM communicates the status of recovery to
the firmware via _OST (sec 6.3.5.2).
For PCIe, firmware may use Downstream Port Containment (DPC) to support
EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
of DPC, OSPM may read/write DPC control and status registers during the EDR
notification processing window, i.e., from the time it receives an EDR
notification until it clears the DPC Trigger Status.
Note that per [1], sec 4.5.1 and 4.5.2.4,
1. If the OS supports EDR, it should advertise that to firmware by
setting OSC_PCI_EDR_SUPPORT in _OSC Support.
2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
_OSC Support.
Add an EDR notify handler to attempt recovery.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
affecting PCI Firmware Specification, Rev. 3.2
https://members.pcisig.com/wg/PCI-SIG/document/12888
[bhelgaas: squash add/enable patches into one]
Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
2020-03-24 03:26:07 +03:00
pci_acpi_remove_edr_notifier ( pci_dev ) ;
2013-12-30 02:37:15 +04:00
pci_acpi_remove_pm_notifier ( adev ) ;
2018-09-28 00:54:13 +03:00
if ( adev - > wakeup . flags . valid ) {
2019-06-25 13:29:42 +03:00
acpi_device_power_remove_dependent ( adev , dev ) ;
2018-09-28 00:54:13 +03:00
if ( pci_dev - > bridge_d3 )
device_wakeup_disable ( dev ) ;
2012-12-23 03:02:44 +04:00
device_set_wakeup_capable ( dev , false ) ;
2018-09-28 00:54:13 +03:00
}
2012-12-23 03:02:44 +04:00
}
2013-03-04 01:35:20 +04:00
static bool pci_acpi_bus_match ( struct device * dev )
{
2013-12-05 15:52:53 +04:00
return dev_is_pci ( dev ) ;
2013-03-04 01:35:20 +04:00
}
2006-04-28 11:42:21 +04:00
static struct acpi_bus_type acpi_pci_bus = {
2013-03-04 01:35:20 +04:00
. name = " PCI " ,
. match = pci_acpi_bus_match ,
2013-11-29 19:27:34 +04:00
. find_companion = acpi_pci_find_companion ,
2012-12-23 03:02:54 +04:00
. setup = pci_acpi_setup ,
. cleanup = pci_acpi_cleanup ,
2005-03-19 02:53:36 +03:00
} ;
2015-12-10 19:55:27 +03:00
static struct fwnode_handle * ( * pci_msi_get_fwnode_cb ) ( struct device * dev ) ;
/**
* pci_msi_register_fwnode_provider - Register callback to retrieve fwnode
* @ fn : Callback matching a device to a fwnode that identifies a PCI
* MSI domain .
*
* This should be called by irqchip driver , which is the parent of
* the MSI domain to provide callback interface to query fwnode .
*/
void
pci_msi_register_fwnode_provider ( struct fwnode_handle * ( * fn ) ( struct device * ) )
{
pci_msi_get_fwnode_cb = fn ;
}
/**
* pci_host_bridge_acpi_msi_domain - Retrieve MSI domain of a PCI host bridge
* @ bus : The PCI host bridge bus .
*
* This function uses the callback function registered by
* pci_msi_register_fwnode_provider ( ) to retrieve the irq_domain with
* type DOMAIN_BUS_PCI_MSI of the specified host bridge bus .
* This returns NULL on error or when the domain is not found .
*/
struct irq_domain * pci_host_bridge_acpi_msi_domain ( struct pci_bus * bus )
{
struct fwnode_handle * fwnode ;
if ( ! pci_msi_get_fwnode_cb )
return NULL ;
fwnode = pci_msi_get_fwnode_cb ( & bus - > dev ) ;
if ( ! fwnode )
return NULL ;
return irq_find_matching_fwnode ( fwnode , DOMAIN_BUS_PCI_MSI ) ;
}
2006-04-28 11:42:21 +04:00
static int __init acpi_pci_init ( void )
2005-03-19 02:53:36 +03:00
{
int ret ;
2009-02-03 10:14:33 +03:00
if ( acpi_gbl_FADT . boot_flags & ACPI_FADT_NO_MSI ) {
2013-05-28 12:03:46 +04:00
pr_info ( " ACPI FADT declares the system doesn't support MSI, so disable it \n " ) ;
2007-04-25 07:05:12 +04:00
pci_no_msi ( ) ;
}
2008-07-23 06:32:24 +04:00
2009-02-03 10:14:33 +03:00
if ( acpi_gbl_FADT . boot_flags & ACPI_FADT_NO_ASPM ) {
2013-05-28 12:03:46 +04:00
pr_info ( " ACPI FADT declares the system doesn't support PCIe ASPM, so disable it \n " ) ;
2008-07-23 06:32:24 +04:00
pcie_no_aspm ( ) ;
}
2006-04-28 11:42:21 +04:00
ret = register_acpi_bus_type ( & acpi_pci_bus ) ;
2005-03-19 02:53:36 +03:00
if ( ret )
return 0 ;
2013-04-12 09:44:24 +04:00
2008-07-07 05:32:02 +04:00
pci_set_platform_pm ( & acpi_pci_platform_pm ) ;
2013-04-12 09:44:24 +04:00
acpi_pci_slot_init ( ) ;
2013-04-12 09:44:26 +04:00
acpiphp_init ( ) ;
2013-04-12 09:44:24 +04:00
2005-03-19 02:53:36 +03:00
return 0 ;
}
2006-04-28 11:42:21 +04:00
arch_initcall ( acpi_pci_init ) ;