linux-toradex.git/include/linux/pci_hotplug.h, branch v4.19-rc5

PCI: hotplug: Demidlayer registration with the core

2018-07-23T22:04:13+00:00

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 
Signed-off-by: Bjorn Helgaas 
Acked-by: Andy Shevchenko   # drivers/platform/x86
Cc: Rafael J. Wysocki 
Cc: Len Brown 
Cc: Scott Murray 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Gavin Shan 
Cc: Sebastian Ott 
Cc: Gerald Schaefer 
Cc: Corentin Chary 
Cc: Darren Hart 
Cc: Andy Shevchenko

PCI: hotplug: Add hotplug_is_native()

2018-06-04T17:08:06+00:00

Add hotplug_is_native() to find out whether the OS is supposed to handle
native hotplug of a given bridge.

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Andy Shevchenko

PCI: shpchp: Add shpchp_is_native()

2018-06-04T17:08:06+00:00

In the same way we do for pciehp, add shpchp_is_native(), which returns
true if the bridge should be handled by the native SHPC driver.  Then
convert the driver to use this function.

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas

PCI: shpchp: Remove get_hp_hw_control_from_firmware() wrapper

2018-06-02T05:18:28+00:00

get_hp_hw_control_from_firmware() is a trivial wrapper around
acpi_get_hp_hw_control_from_firmware(), probably intended to be generic in
case other firmware needed similar OS/platform negotiation.

Remove get_hp_hw_control_from_firmware() and call
acpi_get_hp_hw_control_from_firmware() directly.  Add a stub for
acpi_get_hp_hw_control_from_firmware() for the non-ACPI case.

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki

PCI: shpchp: Remove acpi_get_hp_hw_control_from_firmware() flags

2018-06-02T05:18:28+00:00

acpi_get_hp_hw_control_from_firmware() no longer uses the flags parameter,
so remove it.

Signed-off-by: Mika Westerberg 
[bhelgaas: split to separate patch]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki

PCI: pciehp: Make pciehp_is_native() stricter

2018-06-02T05:18:28+00:00

Previously pciehp_is_native() returned true for any PCI device in a
hierarchy where _OSC says we can use pciehp.  This is incorrect because
bridges without PCI_EXP_SLTCAP_HPC capability should be managed by acpiphp
instead.

Improve pciehp_is_native() to return true only when PCI_EXP_SLTCAP_HPC is
set and the pciehp driver is present.  In any other case return false
to let acpiphp handle those.

Suggested-by: Bjorn Helgaas 
Signed-off-by: Mika Westerberg 
[bhelgaas: remove NULL pointer check]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki

PCI: Add SPDX GPL-2.0+ to replace GPL v2 or later boilerplate

2018-01-28T21:49:06+00:00

Add SPDX GPL-2.0+ to all PCI files that specified the GPL and allowed
either GPL version 2 or any later version.

Remove the boilerplate GPL version 2 or later language, relying on the
assertion in b24413180f56 ("License cleanup: add SPDX GPL-2.0 license
identifier to files with no license") that the SPDX identifier may be used
instead of the full boilerplate text.

Signed-off-by: Bjorn Helgaas 
Reviewed-by: Greg Kroah-Hartman

ACPI / hotplug / PCI: Make device_is_managed_by_native_pciehp() public

2016-11-18T00:47:58+00:00

We're about to add runtime PM of hotplug ports, but we need to restrict it
to ports that are handled natively by the OS:  If they're handled by the
firmware (which is the case for Thunderbolt on non-Macs), things would
break if the OS put the ports into D3hot behind the firmware's back.

To determine if a hotplug port is handled natively, one has to walk up from
the port to the root bridge and check the cached _OSC Control Field for the
value of the "PCI Express Native Hot Plug control" bit.  There's already a
function to do that, device_is_managed_by_native_pciehp(), but it's private
to drivers/pci/hotplug/acpiphp_glue.c and only compiled in if
CONFIG_HOTPLUG_PCI_ACPI is enabled.

Make it public and move it to drivers/pci/pci-acpi.c, so that it is
available in the more general CONFIG_ACPI case.

The function contains a check if the device in question is a hotplug port
and returns false if it's not.  The caller we're going to add doesn't need
this as it only calls the function if it actually *is* a hotplug port.
Move the check out of the function into the single existing caller.

Rename it to pciehp_is_native() and add some kerneldoc and polish.

No functional change intended.

Tested-by: Mika Westerberg 
Signed-off-by: Lukas Wunner 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki

PCI: Remove unused and broken to_hotplug_slot()

2014-11-13T17:35:25+00:00

to_hotplug_slot() is unused and wouldn't work anyway, because struct
hotplug_slot no longer contains a struct kobject (it was removed by
f46753c5e354 ("PCI: introduce pci_slot")).

Remove to_hotplug_slot().

[bhelgaas: changelog]
Signed-off-by: Gavin Shan 
Signed-off-by: Bjorn Helgaas

PCI: Remove unused pci_configure_slot()

2014-09-13T02:09:52+00:00

All pci_configure_slot() uses have been removed, so remove the definition
as well.

Signed-off-by: Bjorn Helgaas 
Acked-by: Yinghai Lu