2018-01-27 04:12:23 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-07-07 06:29:53 +08:00
|
|
|
/*
|
2006-03-09 03:21:34 +08:00
|
|
|
* Copyright (C) 2005-2006 Silicon Graphics, Inc. All rights reserved.
|
2005-07-07 06:29:53 +08:00
|
|
|
*
|
|
|
|
|
* This work was based on the 2.4/2.6 kernel development by Dick Reigner.
|
|
|
|
|
* Work to add BIOS PROM support was completed by Mike Habeck.
|
|
|
|
|
*/
|
|
|
|
|
|
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
2013-11-12 05:41:56 +08:00
|
|
|
#include <linux/acpi.h>
|
2005-07-07 06:29:53 +08:00
|
|
|
#include <linux/init.h>
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/pci.h>
|
2006-10-14 11:05:19 +08:00
|
|
|
#include <linux/pci_hotplug.h>
|
2005-07-07 06:29:53 +08:00
|
|
|
#include <linux/proc_fs.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2005-07-07 06:29:53 +08:00
|
|
|
#include <linux/types.h>
|
2006-03-26 17:37:14 +08:00
|
|
|
#include <linux/mutex.h>
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
#include <asm/sn/addrs.h>
|
2006-04-04 21:26:46 +08:00
|
|
|
#include <asm/sn/geo.h>
|
2005-07-07 06:29:53 +08:00
|
|
|
#include <asm/sn/l1.h>
|
|
|
|
|
#include <asm/sn/module.h>
|
|
|
|
|
#include <asm/sn/pcibr_provider.h>
|
|
|
|
|
#include <asm/sn/pcibus_provider_defs.h>
|
|
|
|
|
#include <asm/sn/pcidev.h>
|
2006-04-04 21:26:46 +08:00
|
|
|
#include <asm/sn/sn_feature_sets.h>
|
2005-07-07 06:29:53 +08:00
|
|
|
#include <asm/sn/sn_sal.h>
|
|
|
|
|
#include <asm/sn/types.h>
|
2007-01-30 14:18:38 +08:00
|
|
|
#include <asm/sn/acpi.h>
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
#include "../pci.h"
|
|
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
MODULE_AUTHOR("SGI (prarit@sgi.com, dickie@sgi.com, habeck@sgi.com)");
|
|
|
|
|
MODULE_DESCRIPTION("SGI Altix Hot Plug PCI Controller Driver");
|
|
|
|
|
|
2007-01-30 14:18:38 +08:00
|
|
|
|
|
|
|
|
/* SAL call error codes. Keep in sync with prom header io/include/pcibr.h */
|
2005-08-12 22:13:34 +08:00
|
|
|
#define PCI_SLOT_ALREADY_UP 2 /* slot already up */
|
|
|
|
|
#define PCI_SLOT_ALREADY_DOWN 3 /* slot already down */
|
|
|
|
|
#define PCI_L1_ERR 7 /* L1 console command error */
|
|
|
|
|
#define PCI_EMPTY_33MHZ 15 /* empty 33 MHz bus */
|
2007-01-30 14:18:38 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
#define PCIIO_ASIC_TYPE_TIOCA 4
|
2005-08-12 22:13:34 +08:00
|
|
|
#define PCI_L1_QSIZE 128 /* our L1 message buffer size */
|
|
|
|
|
#define SN_MAX_HP_SLOTS 32 /* max hotplug slots */
|
|
|
|
|
#define SN_SLOT_NAME_SIZE 33 /* size of name string */
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
/* internal list head */
|
|
|
|
|
static struct list_head sn_hp_list;
|
|
|
|
|
|
|
|
|
|
/* hotplug_slot struct's private pointer */
|
|
|
|
|
struct slot {
|
|
|
|
|
int device_num;
|
|
|
|
|
struct pci_bus *pci_bus;
|
|
|
|
|
/* this struct for glue internal only */
|
2018-09-08 15:59:01 +08:00
|
|
|
struct hotplug_slot hotplug_slot;
|
2005-07-07 06:29:53 +08:00
|
|
|
struct list_head hp_list;
|
2005-08-12 22:13:34 +08:00
|
|
|
char physical_path[SN_SLOT_NAME_SIZE];
|
2005-07-07 06:29:53 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct pcibr_slot_enable_resp {
|
|
|
|
|
int resp_sub_errno;
|
|
|
|
|
char resp_l1_msg[PCI_L1_QSIZE + 1];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct pcibr_slot_disable_resp {
|
|
|
|
|
int resp_sub_errno;
|
|
|
|
|
char resp_l1_msg[PCI_L1_QSIZE + 1];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum sn_pci_req_e {
|
|
|
|
|
PCI_REQ_SLOT_ELIGIBLE,
|
|
|
|
|
PCI_REQ_SLOT_DISABLE
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int enable_slot(struct hotplug_slot *slot);
|
|
|
|
|
static int disable_slot(struct hotplug_slot *slot);
|
2005-08-12 22:13:34 +08:00
|
|
|
static inline int get_power_status(struct hotplug_slot *slot, u8 *value);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
2018-09-08 15:59:01 +08:00
|
|
|
static const struct hotplug_slot_ops sn_hotplug_slot_ops = {
|
2005-07-07 06:29:53 +08:00
|
|
|
.enable_slot = enable_slot,
|
|
|
|
|
.disable_slot = disable_slot,
|
|
|
|
|
.get_power_status = get_power_status,
|
|
|
|
|
};
|
|
|
|
|
|
2006-03-26 17:37:14 +08:00
|
|
|
static DEFINE_MUTEX(sn_hotplug_mutex);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
2018-09-08 15:59:01 +08:00
|
|
|
static struct slot *to_slot(struct hotplug_slot *bss_hotplug_slot)
|
|
|
|
|
{
|
|
|
|
|
return container_of(bss_hotplug_slot, struct slot, hotplug_slot);
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-27 11:06:46 +08:00
|
|
|
static ssize_t path_show(struct pci_slot *pci_slot, char *buf)
|
2005-08-12 22:13:34 +08:00
|
|
|
{
|
|
|
|
|
int retval = -ENOENT;
|
2018-09-08 15:59:01 +08:00
|
|
|
struct slot *slot = to_slot(pci_slot->hotplug);
|
2005-08-12 22:13:34 +08:00
|
|
|
|
|
|
|
|
if (!slot)
|
|
|
|
|
return retval;
|
|
|
|
|
|
2015-12-28 05:21:11 +08:00
|
|
|
retval = sprintf(buf, "%s\n", slot->physical_path);
|
2005-08-12 22:13:34 +08:00
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-27 11:06:46 +08:00
|
|
|
static struct pci_slot_attribute sn_slot_path_attr = __ATTR_RO(path);
|
2005-08-12 22:13:34 +08:00
|
|
|
|
2005-07-07 06:29:53 +08:00
|
|
|
static int sn_pci_slot_valid(struct pci_bus *pci_bus, int device)
|
|
|
|
|
{
|
|
|
|
|
struct pcibus_info *pcibus_info;
|
2006-04-04 21:26:46 +08:00
|
|
|
u16 busnum, segment, ioboard_type;
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
pcibus_info = SN_PCIBUS_BUSSOFT_INFO(pci_bus);
|
|
|
|
|
|
|
|
|
|
/* Check to see if this is a valid slot on 'pci_bus' */
|
|
|
|
|
if (!(pcibus_info->pbi_valid_devices & (1 << device)))
|
|
|
|
|
return -EPERM;
|
|
|
|
|
|
2006-04-04 21:26:46 +08:00
|
|
|
ioboard_type = sn_ioboard_to_pci_bus(pci_bus);
|
|
|
|
|
busnum = pcibus_info->pbi_buscommon.bs_persist_busnum;
|
|
|
|
|
segment = pci_domain_nr(pci_bus) & 0xf;
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
/* Do not allow hotplug operations on base I/O cards */
|
2006-04-04 21:26:46 +08:00
|
|
|
if ((ioboard_type == L1_BRICKTYPE_IX ||
|
|
|
|
|
ioboard_type == L1_BRICKTYPE_IA) &&
|
|
|
|
|
(segment == 1 && busnum == 0 && device != 1))
|
2005-07-07 06:29:53 +08:00
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int sn_pci_bus_valid(struct pci_bus *pci_bus)
|
|
|
|
|
{
|
|
|
|
|
struct pcibus_info *pcibus_info;
|
2006-04-04 21:26:46 +08:00
|
|
|
u32 asic_type;
|
|
|
|
|
u16 ioboard_type;
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
/* Don't register slots hanging off the TIOCA bus */
|
2006-04-04 21:26:46 +08:00
|
|
|
pcibus_info = SN_PCIBUS_BUSSOFT_INFO(pci_bus);
|
2005-07-07 06:29:53 +08:00
|
|
|
asic_type = pcibus_info->pbi_buscommon.bs_asic_type;
|
|
|
|
|
if (asic_type == PCIIO_ASIC_TYPE_TIOCA)
|
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
|
|
/* Only register slots in I/O Bricks that support hotplug */
|
2006-04-04 21:26:46 +08:00
|
|
|
ioboard_type = sn_ioboard_to_pci_bus(pci_bus);
|
|
|
|
|
switch (ioboard_type) {
|
2005-08-12 22:13:34 +08:00
|
|
|
case L1_BRICKTYPE_IX:
|
|
|
|
|
case L1_BRICKTYPE_PX:
|
|
|
|
|
case L1_BRICKTYPE_IA:
|
|
|
|
|
case L1_BRICKTYPE_PA:
|
2006-04-04 21:26:46 +08:00
|
|
|
case L1_BOARDTYPE_PCIX3SLOT:
|
2005-08-12 22:13:34 +08:00
|
|
|
return 1;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return -EPERM;
|
|
|
|
|
break;
|
2005-07-07 06:29:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return -EIO;
|
|
|
|
|
}
|
|
|
|
|
|
2018-09-08 15:59:01 +08:00
|
|
|
static int sn_hp_slot_private_alloc(struct hotplug_slot **bss_hotplug_slot,
|
2008-10-21 07:41:48 +08:00
|
|
|
struct pci_bus *pci_bus, int device,
|
|
|
|
|
char *name)
|
2005-07-07 06:29:53 +08:00
|
|
|
{
|
|
|
|
|
struct pcibus_info *pcibus_info;
|
|
|
|
|
struct slot *slot;
|
|
|
|
|
|
|
|
|
|
pcibus_info = SN_PCIBUS_BUSSOFT_INFO(pci_bus);
|
|
|
|
|
|
2005-09-22 15:48:11 +08:00
|
|
|
slot = kzalloc(sizeof(*slot), GFP_KERNEL);
|
2005-08-12 22:13:34 +08:00
|
|
|
if (!slot)
|
2005-07-07 06:29:53 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
slot->device_num = device;
|
|
|
|
|
slot->pci_bus = pci_bus;
|
2008-10-21 07:41:48 +08:00
|
|
|
sprintf(name, "%04x:%02x:%02x",
|
2005-08-12 22:13:34 +08:00
|
|
|
pci_domain_nr(pci_bus),
|
2006-04-04 21:26:46 +08:00
|
|
|
((u16)pcibus_info->pbi_buscommon.bs_persist_busnum),
|
2005-08-12 22:13:34 +08:00
|
|
|
device + 1);
|
2006-04-04 21:26:46 +08:00
|
|
|
|
|
|
|
|
sn_generate_path(pci_bus, slot->physical_path);
|
|
|
|
|
|
2005-07-07 06:29:53 +08:00
|
|
|
list_add(&slot->hp_list, &sn_hp_list);
|
2018-09-08 15:59:01 +08:00
|
|
|
*bss_hotplug_slot = &slot->hotplug_slot;
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-04-19 08:13:49 +08:00
|
|
|
static struct hotplug_slot *sn_hp_destroy(void)
|
2005-07-07 06:29:53 +08:00
|
|
|
{
|
|
|
|
|
struct slot *slot;
|
2008-06-11 05:28:50 +08:00
|
|
|
struct pci_slot *pci_slot;
|
2005-07-07 06:29:53 +08:00
|
|
|
struct hotplug_slot *bss_hotplug_slot = NULL;
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
list_for_each_entry(slot, &sn_hp_list, hp_list) {
|
2018-09-08 15:59:01 +08:00
|
|
|
bss_hotplug_slot = &slot->hotplug_slot;
|
2008-06-11 05:28:50 +08:00
|
|
|
pci_slot = bss_hotplug_slot->pci_slot;
|
2018-09-08 15:59:01 +08:00
|
|
|
list_del(&slot->hp_list);
|
2008-06-11 05:28:50 +08:00
|
|
|
sysfs_remove_file(&pci_slot->kobj,
|
2005-08-12 22:13:34 +08:00
|
|
|
&sn_slot_path_attr.attr);
|
2005-07-07 06:29:53 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
return bss_hotplug_slot;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void sn_bus_free_data(struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pci_bus *subordinate_bus;
|
|
|
|
|
struct pci_dev *child;
|
|
|
|
|
|
|
|
|
|
/* Recursively clean up sn_irq_info structs */
|
|
|
|
|
if (dev->subordinate) {
|
|
|
|
|
subordinate_bus = dev->subordinate;
|
2005-08-12 22:13:34 +08:00
|
|
|
list_for_each_entry(child, &subordinate_bus->devices, bus_list)
|
2005-07-07 06:29:53 +08:00
|
|
|
sn_bus_free_data(child);
|
|
|
|
|
}
|
2006-03-09 03:21:34 +08:00
|
|
|
/*
|
|
|
|
|
* Some drivers may use dma accesses during the
|
|
|
|
|
* driver remove function. We release the sysdata
|
|
|
|
|
* areas after the driver remove functions have
|
|
|
|
|
* been called.
|
|
|
|
|
*/
|
|
|
|
|
sn_bus_store_sysdata(dev);
|
2005-07-07 06:29:53 +08:00
|
|
|
sn_pci_unfixup_slot(dev);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int sn_slot_enable(struct hotplug_slot *bss_hotplug_slot,
|
2007-01-30 14:18:38 +08:00
|
|
|
int device_num, char **ssdt)
|
2005-07-07 06:29:53 +08:00
|
|
|
{
|
2018-09-08 15:59:01 +08:00
|
|
|
struct slot *slot = to_slot(bss_hotplug_slot);
|
2005-07-07 06:29:53 +08:00
|
|
|
struct pcibus_info *pcibus_info;
|
|
|
|
|
struct pcibr_slot_enable_resp resp;
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
pcibus_info = SN_PCIBUS_BUSSOFT_INFO(slot->pci_bus);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Power-on and initialize the slot in the SN
|
|
|
|
|
* PCI infrastructure.
|
|
|
|
|
*/
|
2007-01-30 14:18:38 +08:00
|
|
|
rc = sal_pcibr_slot_enable(pcibus_info, device_num, &resp, ssdt);
|
|
|
|
|
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
if (rc == PCI_SLOT_ALREADY_UP) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "is already active\n");
|
2005-08-12 22:13:34 +08:00
|
|
|
return 1; /* return 1 to user */
|
2005-07-07 06:29:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (rc == PCI_L1_ERR) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "L1 failure %d with message: %s",
|
2005-07-07 06:29:53 +08:00
|
|
|
resp.resp_sub_errno, resp.resp_l1_msg);
|
|
|
|
|
return -EPERM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (rc) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "insert failed with error %d sub-error %d\n",
|
2005-07-07 06:29:53 +08:00
|
|
|
rc, resp.resp_sub_errno);
|
|
|
|
|
return -EIO;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
pcibus_info = SN_PCIBUS_BUSSOFT_INFO(slot->pci_bus);
|
|
|
|
|
pcibus_info->pbi_enabled_devices |= (1 << device_num);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int sn_slot_disable(struct hotplug_slot *bss_hotplug_slot,
|
|
|
|
|
int device_num, int action)
|
|
|
|
|
{
|
2018-09-08 15:59:01 +08:00
|
|
|
struct slot *slot = to_slot(bss_hotplug_slot);
|
2005-07-07 06:29:53 +08:00
|
|
|
struct pcibus_info *pcibus_info;
|
|
|
|
|
struct pcibr_slot_disable_resp resp;
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
pcibus_info = SN_PCIBUS_BUSSOFT_INFO(slot->pci_bus);
|
|
|
|
|
|
|
|
|
|
rc = sal_pcibr_slot_disable(pcibus_info, device_num, action, &resp);
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
if ((action == PCI_REQ_SLOT_ELIGIBLE) &&
|
|
|
|
|
(rc == PCI_SLOT_ALREADY_DOWN)) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "Slot %s already inactive\n", slot->physical_path);
|
2005-08-12 22:13:34 +08:00
|
|
|
return 1; /* return 1 to user */
|
2005-07-07 06:29:53 +08:00
|
|
|
}
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
if ((action == PCI_REQ_SLOT_ELIGIBLE) && (rc == PCI_EMPTY_33MHZ)) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "Cannot remove last 33MHz card\n");
|
2005-07-07 06:29:53 +08:00
|
|
|
return -EPERM;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
if ((action == PCI_REQ_SLOT_ELIGIBLE) && (rc == PCI_L1_ERR)) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "L1 failure %d with message \n%s\n",
|
2005-07-07 06:29:53 +08:00
|
|
|
resp.resp_sub_errno, resp.resp_l1_msg);
|
|
|
|
|
return -EPERM;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
if ((action == PCI_REQ_SLOT_ELIGIBLE) && rc) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "remove failed with error %d sub-error %d\n",
|
2005-07-07 06:29:53 +08:00
|
|
|
rc, resp.resp_sub_errno);
|
|
|
|
|
return -EIO;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
if ((action == PCI_REQ_SLOT_ELIGIBLE) && !rc)
|
2005-07-07 06:29:53 +08:00
|
|
|
return 0;
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
if ((action == PCI_REQ_SLOT_DISABLE) && !rc) {
|
|
|
|
|
pcibus_info = SN_PCIBUS_BUSSOFT_INFO(slot->pci_bus);
|
|
|
|
|
pcibus_info->pbi_enabled_devices &= ~(1 << device_num);
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "remove successful\n");
|
2005-07-07 06:29:53 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
if ((action == PCI_REQ_SLOT_DISABLE) && rc) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "remove failed rc = %d\n", rc);
|
2005-07-07 06:29:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2006-10-05 05:49:35 +08:00
|
|
|
/*
|
|
|
|
|
* Power up and configure the slot via a SAL call to PROM.
|
|
|
|
|
* Scan slot (and any children), do any platform specific fixup,
|
|
|
|
|
* and find device driver.
|
|
|
|
|
*/
|
2005-07-07 06:29:53 +08:00
|
|
|
static int enable_slot(struct hotplug_slot *bss_hotplug_slot)
|
|
|
|
|
{
|
2018-09-08 15:59:01 +08:00
|
|
|
struct slot *slot = to_slot(bss_hotplug_slot);
|
2005-07-07 06:29:53 +08:00
|
|
|
struct pci_bus *new_bus = NULL;
|
|
|
|
|
struct pci_dev *dev;
|
2013-01-15 11:12:21 +08:00
|
|
|
int num_funcs;
|
2005-07-07 06:29:53 +08:00
|
|
|
int new_ppb = 0;
|
|
|
|
|
int rc;
|
2007-01-30 14:18:38 +08:00
|
|
|
char *ssdt = NULL;
|
2006-10-05 05:49:35 +08:00
|
|
|
void pcibios_fixup_device_resources(struct pci_dev *);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
/* Serialize the Linux PCI infrastructure */
|
2006-03-26 17:37:14 +08:00
|
|
|
mutex_lock(&sn_hotplug_mutex);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Power-on and initialize the slot in the SN
|
2007-01-30 14:18:38 +08:00
|
|
|
* PCI infrastructure. Also, retrieve the ACPI SSDT
|
|
|
|
|
* table for the slot (if ACPI capable PROM).
|
2005-07-07 06:29:53 +08:00
|
|
|
*/
|
2007-01-30 14:18:38 +08:00
|
|
|
rc = sn_slot_enable(bss_hotplug_slot, slot->device_num, &ssdt);
|
2005-07-07 06:29:53 +08:00
|
|
|
if (rc) {
|
2006-03-26 17:37:14 +08:00
|
|
|
mutex_unlock(&sn_hotplug_mutex);
|
2005-07-07 06:29:53 +08:00
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2007-01-30 14:18:38 +08:00
|
|
|
if (ssdt)
|
|
|
|
|
ssdt = __va(ssdt);
|
|
|
|
|
/* Add the new SSDT for the slot to the ACPI namespace */
|
|
|
|
|
if (SN_ACPI_BASE_SUPPORT() && ssdt) {
|
|
|
|
|
acpi_status ret;
|
|
|
|
|
|
|
|
|
|
ret = acpi_load_table((struct acpi_table_header *)ssdt);
|
|
|
|
|
if (ACPI_FAILURE(ret)) {
|
|
|
|
|
printk(KERN_ERR "%s: acpi_load_table failed (0x%x)\n",
|
2008-03-04 11:09:46 +08:00
|
|
|
__func__, ret);
|
2007-01-30 14:18:38 +08:00
|
|
|
/* try to continue on */
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
num_funcs = pci_scan_slot(slot->pci_bus,
|
|
|
|
|
PCI_DEVFN(slot->device_num + 1, 0));
|
2005-07-07 06:29:53 +08:00
|
|
|
if (!num_funcs) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "no device in slot\n");
|
2006-03-26 17:37:14 +08:00
|
|
|
mutex_unlock(&sn_hotplug_mutex);
|
2005-07-07 06:29:53 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Map SN resources for all functions on the card
|
|
|
|
|
* to the Linux PCI interface and tell the drivers
|
|
|
|
|
* about them.
|
|
|
|
|
*/
|
2013-01-15 11:12:21 +08:00
|
|
|
list_for_each_entry(dev, &slot->pci_bus->devices, bus_list) {
|
|
|
|
|
if (PCI_SLOT(dev->devfn) != slot->device_num + 1)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Need to do slot fixup on PPB before fixup of children
|
|
|
|
|
* (PPB's pcidev_info needs to be in pcidev_info list
|
|
|
|
|
* before child's SN_PCIDEV_INFO() call to setup
|
|
|
|
|
* pdi_host_pcidev_info).
|
|
|
|
|
*/
|
|
|
|
|
pcibios_fixup_device_resources(dev);
|
|
|
|
|
if (SN_ACPI_BASE_SUPPORT())
|
|
|
|
|
sn_acpi_slot_fixup(dev);
|
|
|
|
|
else
|
|
|
|
|
sn_io_slot_fixup(dev);
|
|
|
|
|
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
|
|
|
|
|
pci_hp_add_bridge(dev);
|
|
|
|
|
if (dev->subordinate) {
|
|
|
|
|
new_bus = dev->subordinate;
|
|
|
|
|
new_ppb = 1;
|
2005-07-07 06:29:53 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-01-30 14:18:38 +08:00
|
|
|
/*
|
|
|
|
|
* Add the slot's devices to the ACPI infrastructure */
|
|
|
|
|
if (SN_ACPI_BASE_SUPPORT() && ssdt) {
|
2008-10-10 14:22:59 +08:00
|
|
|
unsigned long long adr;
|
2007-01-30 14:18:38 +08:00
|
|
|
struct acpi_device *pdevice;
|
|
|
|
|
acpi_handle phandle;
|
|
|
|
|
acpi_handle chandle = NULL;
|
|
|
|
|
acpi_handle rethandle;
|
|
|
|
|
acpi_status ret;
|
|
|
|
|
|
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
2013-11-12 05:41:56 +08:00
|
|
|
phandle = acpi_device_handle(PCI_CONTROLLER(slot->pci_bus)->companion);
|
2007-01-30 14:18:38 +08:00
|
|
|
|
|
|
|
|
if (acpi_bus_get_device(phandle, &pdevice)) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "no parent device, assuming NULL\n");
|
2007-01-30 14:18:38 +08:00
|
|
|
pdevice = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 21:36:47 +08:00
|
|
|
acpi_scan_lock_acquire();
|
2007-01-30 14:18:38 +08:00
|
|
|
/*
|
|
|
|
|
* Walk the rootbus node's immediate children looking for
|
|
|
|
|
* the slot's device node(s). There can be more than
|
|
|
|
|
* one for multifunction devices.
|
|
|
|
|
*/
|
|
|
|
|
for (;;) {
|
|
|
|
|
rethandle = NULL;
|
|
|
|
|
ret = acpi_get_next_object(ACPI_TYPE_DEVICE,
|
|
|
|
|
phandle, chandle,
|
|
|
|
|
&rethandle);
|
|
|
|
|
|
|
|
|
|
if (ret == AE_NOT_FOUND || rethandle == NULL)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
chandle = rethandle;
|
|
|
|
|
|
|
|
|
|
ret = acpi_evaluate_integer(chandle, METHOD_NAME__ADR,
|
|
|
|
|
NULL, &adr);
|
|
|
|
|
|
|
|
|
|
if (ACPI_SUCCESS(ret) &&
|
|
|
|
|
(adr>>16) == (slot->device_num + 1)) {
|
|
|
|
|
|
2013-01-19 08:27:35 +08:00
|
|
|
ret = acpi_bus_scan(chandle);
|
2007-01-30 14:18:38 +08:00
|
|
|
if (ACPI_FAILURE(ret)) {
|
2014-04-19 08:13:50 +08:00
|
|
|
printk(KERN_ERR "%s: acpi_bus_scan failed (0x%x) for slot %d func %d\n",
|
|
|
|
|
__func__, ret, (int)(adr>>16),
|
2007-01-30 14:18:38 +08:00
|
|
|
(int)(adr&0xffff));
|
|
|
|
|
/* try to continue on */
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 21:36:47 +08:00
|
|
|
acpi_scan_lock_release();
|
2007-01-30 14:18:38 +08:00
|
|
|
}
|
|
|
|
|
|
2014-01-15 03:03:14 +08:00
|
|
|
pci_lock_rescan_remove();
|
|
|
|
|
|
2005-07-07 06:29:53 +08:00
|
|
|
/* Call the driver for the new device */
|
|
|
|
|
pci_bus_add_devices(slot->pci_bus);
|
|
|
|
|
/* Call the drivers for the new devices subordinate to PPB */
|
|
|
|
|
if (new_ppb)
|
|
|
|
|
pci_bus_add_devices(new_bus);
|
|
|
|
|
|
2014-01-15 03:03:14 +08:00
|
|
|
pci_unlock_rescan_remove();
|
2006-03-26 17:37:14 +08:00
|
|
|
mutex_unlock(&sn_hotplug_mutex);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
if (rc == 0)
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "insert operation successful\n");
|
2005-07-07 06:29:53 +08:00
|
|
|
else
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(slot->pci_bus->self, "insert operation failed rc = %d\n", rc);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int disable_slot(struct hotplug_slot *bss_hotplug_slot)
|
|
|
|
|
{
|
2018-09-08 15:59:01 +08:00
|
|
|
struct slot *slot = to_slot(bss_hotplug_slot);
|
2013-01-15 11:12:21 +08:00
|
|
|
struct pci_dev *dev, *temp;
|
2005-07-07 06:29:53 +08:00
|
|
|
int rc;
|
2015-01-26 16:58:48 +08:00
|
|
|
acpi_handle ssdt_hdl = NULL;
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
/* Acquire update access to the bus */
|
2006-03-26 17:37:14 +08:00
|
|
|
mutex_lock(&sn_hotplug_mutex);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
/* is it okay to bring this slot down? */
|
|
|
|
|
rc = sn_slot_disable(bss_hotplug_slot, slot->device_num,
|
|
|
|
|
PCI_REQ_SLOT_ELIGIBLE);
|
|
|
|
|
if (rc)
|
|
|
|
|
goto leaving;
|
|
|
|
|
|
2007-01-30 14:18:38 +08:00
|
|
|
/* free the ACPI resources for the slot */
|
|
|
|
|
if (SN_ACPI_BASE_SUPPORT() &&
|
2015-12-28 05:21:11 +08:00
|
|
|
PCI_CONTROLLER(slot->pci_bus)->companion) {
|
2008-10-10 14:22:59 +08:00
|
|
|
unsigned long long adr;
|
2007-01-30 14:18:38 +08:00
|
|
|
struct acpi_device *device;
|
|
|
|
|
acpi_handle phandle;
|
|
|
|
|
acpi_handle chandle = NULL;
|
|
|
|
|
acpi_handle rethandle;
|
|
|
|
|
acpi_status ret;
|
|
|
|
|
|
|
|
|
|
/* Get the rootbus node pointer */
|
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
2013-11-12 05:41:56 +08:00
|
|
|
phandle = acpi_device_handle(PCI_CONTROLLER(slot->pci_bus)->companion);
|
2007-01-30 14:18:38 +08:00
|
|
|
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 21:36:47 +08:00
|
|
|
acpi_scan_lock_acquire();
|
2007-01-30 14:18:38 +08:00
|
|
|
/*
|
|
|
|
|
* Walk the rootbus node's immediate children looking for
|
|
|
|
|
* the slot's device node(s). There can be more than
|
|
|
|
|
* one for multifunction devices.
|
|
|
|
|
*/
|
|
|
|
|
for (;;) {
|
|
|
|
|
rethandle = NULL;
|
|
|
|
|
ret = acpi_get_next_object(ACPI_TYPE_DEVICE,
|
|
|
|
|
phandle, chandle,
|
|
|
|
|
&rethandle);
|
|
|
|
|
|
|
|
|
|
if (ret == AE_NOT_FOUND || rethandle == NULL)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
chandle = rethandle;
|
|
|
|
|
|
|
|
|
|
ret = acpi_evaluate_integer(chandle,
|
|
|
|
|
METHOD_NAME__ADR,
|
|
|
|
|
NULL, &adr);
|
|
|
|
|
if (ACPI_SUCCESS(ret) &&
|
|
|
|
|
(adr>>16) == (slot->device_num + 1)) {
|
|
|
|
|
/* retain the owner id */
|
2015-01-26 16:58:48 +08:00
|
|
|
ssdt_hdl = chandle;
|
2007-01-30 14:18:38 +08:00
|
|
|
|
|
|
|
|
ret = acpi_bus_get_device(chandle,
|
|
|
|
|
&device);
|
|
|
|
|
if (ACPI_SUCCESS(ret))
|
2013-01-15 20:23:53 +08:00
|
|
|
acpi_bus_trim(device);
|
2007-01-30 14:18:38 +08:00
|
|
|
}
|
|
|
|
|
}
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 21:36:47 +08:00
|
|
|
acpi_scan_lock_release();
|
2007-01-30 14:18:38 +08:00
|
|
|
}
|
|
|
|
|
|
2014-01-15 03:03:14 +08:00
|
|
|
pci_lock_rescan_remove();
|
2005-07-07 06:29:53 +08:00
|
|
|
/* Free the SN resources assigned to the Linux device.*/
|
2013-01-15 11:12:21 +08:00
|
|
|
list_for_each_entry_safe(dev, temp, &slot->pci_bus->devices, bus_list) {
|
|
|
|
|
if (PCI_SLOT(dev->devfn) != slot->device_num + 1)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
pci_dev_get(dev);
|
|
|
|
|
sn_bus_free_data(dev);
|
|
|
|
|
pci_stop_and_remove_bus_device(dev);
|
|
|
|
|
pci_dev_put(dev);
|
2005-07-07 06:29:53 +08:00
|
|
|
}
|
2014-01-15 03:03:14 +08:00
|
|
|
pci_unlock_rescan_remove();
|
2005-07-07 06:29:53 +08:00
|
|
|
|
2007-01-30 14:18:38 +08:00
|
|
|
/* Remove the SSDT for the slot from the ACPI namespace */
|
2015-01-26 16:58:48 +08:00
|
|
|
if (SN_ACPI_BASE_SUPPORT() && ssdt_hdl) {
|
2007-01-30 14:18:38 +08:00
|
|
|
acpi_status ret;
|
2015-01-26 16:58:48 +08:00
|
|
|
ret = acpi_unload_parent_table(ssdt_hdl);
|
2007-01-30 14:18:38 +08:00
|
|
|
if (ACPI_FAILURE(ret)) {
|
2015-01-26 16:58:48 +08:00
|
|
|
acpi_handle_err(ssdt_hdl,
|
|
|
|
|
"%s: acpi_unload_parent_table failed (0x%x)\n",
|
|
|
|
|
__func__, ret);
|
2007-01-30 14:18:38 +08:00
|
|
|
/* try to continue on */
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-07-07 06:29:53 +08:00
|
|
|
/* free the collected sysdata pointers */
|
|
|
|
|
sn_bus_free_sysdata();
|
|
|
|
|
|
|
|
|
|
/* Deactivate slot */
|
|
|
|
|
rc = sn_slot_disable(bss_hotplug_slot, slot->device_num,
|
|
|
|
|
PCI_REQ_SLOT_DISABLE);
|
|
|
|
|
leaving:
|
|
|
|
|
/* Release the bus lock */
|
2006-03-26 17:37:14 +08:00
|
|
|
mutex_unlock(&sn_hotplug_mutex);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
static inline int get_power_status(struct hotplug_slot *bss_hotplug_slot,
|
|
|
|
|
u8 *value)
|
2005-07-07 06:29:53 +08:00
|
|
|
{
|
2018-09-08 15:59:01 +08:00
|
|
|
struct slot *slot = to_slot(bss_hotplug_slot);
|
2005-08-12 22:13:34 +08:00
|
|
|
struct pcibus_info *pcibus_info;
|
2006-05-06 22:01:59 +08:00
|
|
|
u32 power;
|
2005-08-12 22:13:34 +08:00
|
|
|
|
|
|
|
|
pcibus_info = SN_PCIBUS_BUSSOFT_INFO(slot->pci_bus);
|
2006-03-26 17:37:14 +08:00
|
|
|
mutex_lock(&sn_hotplug_mutex);
|
2006-05-06 22:01:59 +08:00
|
|
|
power = pcibus_info->pbi_enabled_devices & (1 << slot->device_num);
|
|
|
|
|
*value = power ? 1 : 0;
|
2006-03-26 17:37:14 +08:00
|
|
|
mutex_unlock(&sn_hotplug_mutex);
|
2005-07-07 06:29:53 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void sn_release_slot(struct hotplug_slot *bss_hotplug_slot)
|
|
|
|
|
{
|
2018-09-08 15:59:01 +08:00
|
|
|
kfree(to_slot(bss_hotplug_slot));
|
2005-07-07 06:29:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int sn_hotplug_slot_register(struct pci_bus *pci_bus)
|
|
|
|
|
{
|
|
|
|
|
int device;
|
2008-06-11 05:28:50 +08:00
|
|
|
struct pci_slot *pci_slot;
|
2005-07-07 06:29:53 +08:00
|
|
|
struct hotplug_slot *bss_hotplug_slot;
|
2008-10-21 07:41:48 +08:00
|
|
|
char name[SN_SLOT_NAME_SIZE];
|
2005-07-07 06:29:53 +08:00
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Currently only four devices are supported,
|
|
|
|
|
* in the future there maybe more -- up to 32.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
for (device = 0; device < SN_MAX_HP_SLOTS ; device++) {
|
|
|
|
|
if (sn_pci_slot_valid(pci_bus, device) != 1)
|
|
|
|
|
continue;
|
|
|
|
|
|
2018-09-08 15:59:01 +08:00
|
|
|
if (sn_hp_slot_private_alloc(&bss_hotplug_slot,
|
2008-10-21 07:41:48 +08:00
|
|
|
pci_bus, device, name)) {
|
2005-07-07 06:29:53 +08:00
|
|
|
rc = -ENOMEM;
|
|
|
|
|
goto alloc_err;
|
|
|
|
|
}
|
|
|
|
|
bss_hotplug_slot->ops = &sn_hotplug_slot_ops;
|
|
|
|
|
|
2008-10-21 07:41:48 +08:00
|
|
|
rc = pci_hp_register(bss_hotplug_slot, pci_bus, device, name);
|
2005-07-07 06:29:53 +08:00
|
|
|
if (rc)
|
|
|
|
|
goto register_err;
|
2005-08-12 22:13:34 +08:00
|
|
|
|
2008-06-11 05:28:50 +08:00
|
|
|
pci_slot = bss_hotplug_slot->pci_slot;
|
|
|
|
|
rc = sysfs_create_file(&pci_slot->kobj,
|
2005-08-12 22:13:34 +08:00
|
|
|
&sn_slot_path_attr.attr);
|
|
|
|
|
if (rc)
|
2018-09-08 15:59:01 +08:00
|
|
|
goto alloc_err;
|
2005-07-07 06:29:53 +08:00
|
|
|
}
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(pci_bus->self, "Registered bus with hotplug\n");
|
2005-07-07 06:29:53 +08:00
|
|
|
return rc;
|
|
|
|
|
|
|
|
|
|
register_err:
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(pci_bus->self, "bus failed to register with err = %d\n",
|
2008-06-11 05:30:42 +08:00
|
|
|
rc);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
/* destroy THIS element */
|
2018-09-08 15:59:01 +08:00
|
|
|
sn_hp_destroy();
|
|
|
|
|
sn_release_slot(bss_hotplug_slot);
|
2005-07-07 06:29:53 +08:00
|
|
|
|
2018-09-08 15:59:01 +08:00
|
|
|
alloc_err:
|
2005-07-07 06:29:53 +08:00
|
|
|
/* destroy anything else on the list */
|
PCI: hotplug: Demidlayer registration with the core
When a hotplug driver calls pci_hp_register(), all steps necessary for
registration are carried out in one go, including creation of a kobject
and addition to sysfs. That's a problem for pciehp once it's converted
to enable/disable the slot exclusively from the IRQ thread: The thread
needs to be spawned after creation of the kobject (because it uses the
kobject's name), but before addition to sysfs (because it will handle
enable/disable requests submitted via sysfs).
pci_hp_deregister() does offer a ->release callback that's invoked
after deletion from sysfs and before destruction of the kobject. But
because pci_hp_register() doesn't offer a counterpart, hotplug drivers'
->probe and ->remove code becomes asymmetric, which is error prone
as recently discovered use-after-free bugs in pciehp's ->remove hook
have shown.
In a sense, this appears to be a case of the midlayer antipattern:
"The core thesis of the "midlayer mistake" is that midlayers are
bad and should not exist. That common functionality which it is
so tempting to put in a midlayer should instead be provided as
library routines which can [be] used, augmented, or ignored by
each bottom level driver independently. Thus every subsystem
that supports multiple implementations (or drivers) should
provide a very thin top layer which calls directly into the
bottom layer drivers, and a rich library of support code that
eases the implementation of those drivers. This library is
available to, but not forced upon, those drivers."
-- Neil Brown (2009), https://lwn.net/Articles/336262/
The presence of midlayer traits in the PCI hotplug core might be ascribed
to its age: When it was introduced in February 2002, the blessings of a
library approach might not have been well known:
https://git.kernel.org/tglx/history/c/a8a2069f432c
For comparison, the driver core does offer split functions for creating
a kobject (device_initialize()) and addition to sysfs (device_add()) as
an alternative to carrying out everything at once (device_register()).
This was introduced in October 2002:
https://git.kernel.org/tglx/history/c/8b290eb19962
The odd ->release callback in the PCI hotplug core was added in 2003:
https://git.kernel.org/tglx/history/c/69f8d663b595
Clearly, a library approach would not force every hotplug driver to
implement a ->release callback, but rather allow the driver to remove
the sysfs files, release its data structures and finally destroy the
kobject. Alternatively, a driver may choose to remove everything with
pci_hp_deregister(), then release its data structures.
To this end, offer drivers pci_hp_initialize() and pci_hp_add() as a
split-up version of pci_hp_register(). Likewise, offer pci_hp_del()
and pci_hp_destroy() as a split-up version of pci_hp_deregister().
Eliminate the ->release callback and move its code into each driver's
teardown routine.
Declare pci_hp_deregister() void, in keeping with the usual kernel
pattern that enablement can fail, but disablement cannot. It only
returned an error if the caller passed in a NULL pointer or a slot which
has never or is no longer registered or is sharing its name with another
slot. Those would be bugs, so WARN about them. Few hotplug drivers
actually checked the return value and those that did only printed a
useless error message to dmesg. Remove that.
For most drivers the conversion was straightforward since it doesn't
matter whether the code in the ->release callback is executed before or
after destruction of the kobject. But in the case of ibmphp, it was
unclear to me whether setting slot_cur->ctrl and slot_cur->bus_on to
NULL needs to happen before the kobject is destroyed, so I erred on
the side of caution and ensured that the order stays the same. Another
nontrivial case is pnv_php, I've found the list and kref logic difficult
to understand, however my impression was that it is safe to delete the
list element and drop the references until after the kobject is
destroyed.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Scott Murray <scott@spiteful.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
2018-07-20 06:27:43 +08:00
|
|
|
while ((bss_hotplug_slot = sn_hp_destroy())) {
|
2005-07-07 06:29:53 +08:00
|
|
|
pci_hp_deregister(bss_hotplug_slot);
|
PCI: hotplug: Demidlayer registration with the core
When a hotplug driver calls pci_hp_register(), all steps necessary for
registration are carried out in one go, including creation of a kobject
and addition to sysfs. That's a problem for pciehp once it's converted
to enable/disable the slot exclusively from the IRQ thread: The thread
needs to be spawned after creation of the kobject (because it uses the
kobject's name), but before addition to sysfs (because it will handle
enable/disable requests submitted via sysfs).
pci_hp_deregister() does offer a ->release callback that's invoked
after deletion from sysfs and before destruction of the kobject. But
because pci_hp_register() doesn't offer a counterpart, hotplug drivers'
->probe and ->remove code becomes asymmetric, which is error prone
as recently discovered use-after-free bugs in pciehp's ->remove hook
have shown.
In a sense, this appears to be a case of the midlayer antipattern:
"The core thesis of the "midlayer mistake" is that midlayers are
bad and should not exist. That common functionality which it is
so tempting to put in a midlayer should instead be provided as
library routines which can [be] used, augmented, or ignored by
each bottom level driver independently. Thus every subsystem
that supports multiple implementations (or drivers) should
provide a very thin top layer which calls directly into the
bottom layer drivers, and a rich library of support code that
eases the implementation of those drivers. This library is
available to, but not forced upon, those drivers."
-- Neil Brown (2009), https://lwn.net/Articles/336262/
The presence of midlayer traits in the PCI hotplug core might be ascribed
to its age: When it was introduced in February 2002, the blessings of a
library approach might not have been well known:
https://git.kernel.org/tglx/history/c/a8a2069f432c
For comparison, the driver core does offer split functions for creating
a kobject (device_initialize()) and addition to sysfs (device_add()) as
an alternative to carrying out everything at once (device_register()).
This was introduced in October 2002:
https://git.kernel.org/tglx/history/c/8b290eb19962
The odd ->release callback in the PCI hotplug core was added in 2003:
https://git.kernel.org/tglx/history/c/69f8d663b595
Clearly, a library approach would not force every hotplug driver to
implement a ->release callback, but rather allow the driver to remove
the sysfs files, release its data structures and finally destroy the
kobject. Alternatively, a driver may choose to remove everything with
pci_hp_deregister(), then release its data structures.
To this end, offer drivers pci_hp_initialize() and pci_hp_add() as a
split-up version of pci_hp_register(). Likewise, offer pci_hp_del()
and pci_hp_destroy() as a split-up version of pci_hp_deregister().
Eliminate the ->release callback and move its code into each driver's
teardown routine.
Declare pci_hp_deregister() void, in keeping with the usual kernel
pattern that enablement can fail, but disablement cannot. It only
returned an error if the caller passed in a NULL pointer or a slot which
has never or is no longer registered or is sharing its name with another
slot. Those would be bugs, so WARN about them. Few hotplug drivers
actually checked the return value and those that did only printed a
useless error message to dmesg. Remove that.
For most drivers the conversion was straightforward since it doesn't
matter whether the code in the ->release callback is executed before or
after destruction of the kobject. But in the case of ibmphp, it was
unclear to me whether setting slot_cur->ctrl and slot_cur->bus_on to
NULL needs to happen before the kobject is destroyed, so I erred on
the side of caution and ensured that the order stays the same. Another
nontrivial case is pnv_php, I've found the list and kref logic difficult
to understand, however my impression was that it is safe to delete the
list element and drop the references until after the kobject is
destroyed.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Scott Murray <scott@spiteful.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
2018-07-20 06:27:43 +08:00
|
|
|
sn_release_slot(bss_hotplug_slot);
|
|
|
|
|
}
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-06 20:58:56 +08:00
|
|
|
static int __init sn_pci_hotplug_init(void)
|
2005-07-07 06:29:53 +08:00
|
|
|
{
|
|
|
|
|
struct pci_bus *pci_bus = NULL;
|
|
|
|
|
int rc;
|
|
|
|
|
int registered = 0;
|
|
|
|
|
|
2006-04-04 21:26:46 +08:00
|
|
|
if (!sn_prom_feature_available(PRF_HOTPLUG_SUPPORT)) {
|
|
|
|
|
printk(KERN_ERR "%s: PROM version does not support hotplug.\n",
|
2008-03-04 11:09:46 +08:00
|
|
|
__func__);
|
2005-07-07 06:29:53 +08:00
|
|
|
return -EPERM;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-12 22:13:34 +08:00
|
|
|
INIT_LIST_HEAD(&sn_hp_list);
|
|
|
|
|
|
2005-07-07 06:29:53 +08:00
|
|
|
while ((pci_bus = pci_find_next_bus(pci_bus))) {
|
|
|
|
|
if (!pci_bus->sysdata)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
rc = sn_pci_bus_valid(pci_bus);
|
|
|
|
|
if (rc != 1) {
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(pci_bus->self, "not a valid hotplug bus\n");
|
2005-07-07 06:29:53 +08:00
|
|
|
continue;
|
|
|
|
|
}
|
2018-01-19 02:55:24 +08:00
|
|
|
pci_dbg(pci_bus->self, "valid hotplug bus\n");
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
rc = sn_hotplug_slot_register(pci_bus);
|
2005-08-12 22:13:34 +08:00
|
|
|
if (!rc) {
|
2005-07-07 06:29:53 +08:00
|
|
|
registered = 1;
|
2005-08-12 22:13:34 +08:00
|
|
|
} else {
|
2005-07-07 06:29:53 +08:00
|
|
|
registered = 0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return registered == 1 ? 0 : -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-06 20:58:56 +08:00
|
|
|
static void __exit sn_pci_hotplug_exit(void)
|
2005-07-07 06:29:53 +08:00
|
|
|
{
|
|
|
|
|
struct hotplug_slot *bss_hotplug_slot;
|
|
|
|
|
|
PCI: hotplug: Demidlayer registration with the core
When a hotplug driver calls pci_hp_register(), all steps necessary for
registration are carried out in one go, including creation of a kobject
and addition to sysfs. That's a problem for pciehp once it's converted
to enable/disable the slot exclusively from the IRQ thread: The thread
needs to be spawned after creation of the kobject (because it uses the
kobject's name), but before addition to sysfs (because it will handle
enable/disable requests submitted via sysfs).
pci_hp_deregister() does offer a ->release callback that's invoked
after deletion from sysfs and before destruction of the kobject. But
because pci_hp_register() doesn't offer a counterpart, hotplug drivers'
->probe and ->remove code becomes asymmetric, which is error prone
as recently discovered use-after-free bugs in pciehp's ->remove hook
have shown.
In a sense, this appears to be a case of the midlayer antipattern:
"The core thesis of the "midlayer mistake" is that midlayers are
bad and should not exist. That common functionality which it is
so tempting to put in a midlayer should instead be provided as
library routines which can [be] used, augmented, or ignored by
each bottom level driver independently. Thus every subsystem
that supports multiple implementations (or drivers) should
provide a very thin top layer which calls directly into the
bottom layer drivers, and a rich library of support code that
eases the implementation of those drivers. This library is
available to, but not forced upon, those drivers."
-- Neil Brown (2009), https://lwn.net/Articles/336262/
The presence of midlayer traits in the PCI hotplug core might be ascribed
to its age: When it was introduced in February 2002, the blessings of a
library approach might not have been well known:
https://git.kernel.org/tglx/history/c/a8a2069f432c
For comparison, the driver core does offer split functions for creating
a kobject (device_initialize()) and addition to sysfs (device_add()) as
an alternative to carrying out everything at once (device_register()).
This was introduced in October 2002:
https://git.kernel.org/tglx/history/c/8b290eb19962
The odd ->release callback in the PCI hotplug core was added in 2003:
https://git.kernel.org/tglx/history/c/69f8d663b595
Clearly, a library approach would not force every hotplug driver to
implement a ->release callback, but rather allow the driver to remove
the sysfs files, release its data structures and finally destroy the
kobject. Alternatively, a driver may choose to remove everything with
pci_hp_deregister(), then release its data structures.
To this end, offer drivers pci_hp_initialize() and pci_hp_add() as a
split-up version of pci_hp_register(). Likewise, offer pci_hp_del()
and pci_hp_destroy() as a split-up version of pci_hp_deregister().
Eliminate the ->release callback and move its code into each driver's
teardown routine.
Declare pci_hp_deregister() void, in keeping with the usual kernel
pattern that enablement can fail, but disablement cannot. It only
returned an error if the caller passed in a NULL pointer or a slot which
has never or is no longer registered or is sharing its name with another
slot. Those would be bugs, so WARN about them. Few hotplug drivers
actually checked the return value and those that did only printed a
useless error message to dmesg. Remove that.
For most drivers the conversion was straightforward since it doesn't
matter whether the code in the ->release callback is executed before or
after destruction of the kobject. But in the case of ibmphp, it was
unclear to me whether setting slot_cur->ctrl and slot_cur->bus_on to
NULL needs to happen before the kobject is destroyed, so I erred on
the side of caution and ensured that the order stays the same. Another
nontrivial case is pnv_php, I've found the list and kref logic difficult
to understand, however my impression was that it is safe to delete the
list element and drop the references until after the kobject is
destroyed.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Scott Murray <scott@spiteful.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
2018-07-20 06:27:43 +08:00
|
|
|
while ((bss_hotplug_slot = sn_hp_destroy())) {
|
2005-07-07 06:29:53 +08:00
|
|
|
pci_hp_deregister(bss_hotplug_slot);
|
PCI: hotplug: Demidlayer registration with the core
When a hotplug driver calls pci_hp_register(), all steps necessary for
registration are carried out in one go, including creation of a kobject
and addition to sysfs. That's a problem for pciehp once it's converted
to enable/disable the slot exclusively from the IRQ thread: The thread
needs to be spawned after creation of the kobject (because it uses the
kobject's name), but before addition to sysfs (because it will handle
enable/disable requests submitted via sysfs).
pci_hp_deregister() does offer a ->release callback that's invoked
after deletion from sysfs and before destruction of the kobject. But
because pci_hp_register() doesn't offer a counterpart, hotplug drivers'
->probe and ->remove code becomes asymmetric, which is error prone
as recently discovered use-after-free bugs in pciehp's ->remove hook
have shown.
In a sense, this appears to be a case of the midlayer antipattern:
"The core thesis of the "midlayer mistake" is that midlayers are
bad and should not exist. That common functionality which it is
so tempting to put in a midlayer should instead be provided as
library routines which can [be] used, augmented, or ignored by
each bottom level driver independently. Thus every subsystem
that supports multiple implementations (or drivers) should
provide a very thin top layer which calls directly into the
bottom layer drivers, and a rich library of support code that
eases the implementation of those drivers. This library is
available to, but not forced upon, those drivers."
-- Neil Brown (2009), https://lwn.net/Articles/336262/
The presence of midlayer traits in the PCI hotplug core might be ascribed
to its age: When it was introduced in February 2002, the blessings of a
library approach might not have been well known:
https://git.kernel.org/tglx/history/c/a8a2069f432c
For comparison, the driver core does offer split functions for creating
a kobject (device_initialize()) and addition to sysfs (device_add()) as
an alternative to carrying out everything at once (device_register()).
This was introduced in October 2002:
https://git.kernel.org/tglx/history/c/8b290eb19962
The odd ->release callback in the PCI hotplug core was added in 2003:
https://git.kernel.org/tglx/history/c/69f8d663b595
Clearly, a library approach would not force every hotplug driver to
implement a ->release callback, but rather allow the driver to remove
the sysfs files, release its data structures and finally destroy the
kobject. Alternatively, a driver may choose to remove everything with
pci_hp_deregister(), then release its data structures.
To this end, offer drivers pci_hp_initialize() and pci_hp_add() as a
split-up version of pci_hp_register(). Likewise, offer pci_hp_del()
and pci_hp_destroy() as a split-up version of pci_hp_deregister().
Eliminate the ->release callback and move its code into each driver's
teardown routine.
Declare pci_hp_deregister() void, in keeping with the usual kernel
pattern that enablement can fail, but disablement cannot. It only
returned an error if the caller passed in a NULL pointer or a slot which
has never or is no longer registered or is sharing its name with another
slot. Those would be bugs, so WARN about them. Few hotplug drivers
actually checked the return value and those that did only printed a
useless error message to dmesg. Remove that.
For most drivers the conversion was straightforward since it doesn't
matter whether the code in the ->release callback is executed before or
after destruction of the kobject. But in the case of ibmphp, it was
unclear to me whether setting slot_cur->ctrl and slot_cur->bus_on to
NULL needs to happen before the kobject is destroyed, so I erred on
the side of caution and ensured that the order stays the same. Another
nontrivial case is pnv_php, I've found the list and kref logic difficult
to understand, however my impression was that it is safe to delete the
list element and drop the references until after the kobject is
destroyed.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Scott Murray <scott@spiteful.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
2018-07-20 06:27:43 +08:00
|
|
|
sn_release_slot(bss_hotplug_slot);
|
|
|
|
|
}
|
2005-07-07 06:29:53 +08:00
|
|
|
|
|
|
|
|
if (!list_empty(&sn_hp_list))
|
|
|
|
|
printk(KERN_ERR "%s: internal list is not empty\n", __FILE__);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
module_init(sn_pci_hotplug_init);
|
|
|
|
|
module_exit(sn_pci_hotplug_exit);
|