29 Aug, 2019

2 commits

  • Move program_hpx_type0(), program_hpx_type1(), etc., and enums
    hpx_type3_dev_type, hpx_type3_fn_type and hpx_type3_cfg_loc to
    drivers/pci/pci-acpi.c as these functions and enums are ACPI-specific.

    Move structs hpx_type0, hpx_type1, hpx_type2 and hpx_type3 to
    drivers/pci/pci.h as these are shared between drivers/pci/pci-acpi.c and
    drivers/pci/probe.c.

    Link: https://lore.kernel.org/r/20190827094951.10613-3-kw@linux.com
    Signed-off-by: Krzysztof Wilczynski
    Signed-off-by: Bjorn Helgaas

    Krzysztof Wilczynski
     
  • The names of the hpp_type0, hpp_type1 and hpp_type2 structs suggest that
    they're related to _HPP, when in fact they're related to _HPX.

    The struct hpp_type0 denotes an _HPX Type 0 setting record that supersedes
    the _HPP setting record, and it has been used interchangeably for _HPP as
    per the ACPI specification (see version 6.3, section 6.2.9.1) which states
    that it should be applied to PCI, PCI-X and PCI Express devices, with
    settings being ignored if they are not applicable.

    Rename them to hpx_type0, hpx_type1 and hpx_type2 to reflect their relation
    to _HPX rather than _HPP.

    Link: https://lore.kernel.org/r/20190827094951.10613-2-kw@linux.com
    Signed-off-by: Krzysztof Wilczynski
    Signed-off-by: Bjorn Helgaas

    Krzysztof Wilczynski
     

24 Apr, 2019

2 commits

  • The _HPX Type 3 Setting Record is intended to be more generic and allow
    configuration of settings not possible with Type 2 records. For example,
    firmware could ensure that the completion timeout value is set accordingly
    throughout the PCI tree.

    Implement support for _HPX Type 3 Setting Records, which were added in the
    ACPI 6.3 spec.

    Link: https://lore.kernel.org/lkml/20190208162414.3996-4-mr.nuke.me@gmail.com
    Signed-off-by: Alexandru Gagniuc
    Signed-off-by: Bjorn Helgaas

    Alexandru Gagniuc
     
  • We used to first parse all the _HPP and _HPX tables before using the
    information to program registers of PCIe devices. Up through HPX Type 2,
    there was only one structure of each type, so we could cheat and store it
    on the stack.

    With HPX Type 3 we get an arbitrary number of entries, so the above model
    doesn't scale that well. Instead of parsing all tables at once, parse and
    program each entry separately. For _HPP and _HPX Types 0 through 2, this
    is functionally equivalent. The change enables the upcoming _HPX Type 3 to
    integrate more easily.

    Link: https://lore.kernel.org/lkml/20190208162414.3996-3-mr.nuke.me@gmail.com
    Signed-off-by: Alexandru Gagniuc
    [bhelgaas: fix build errors]
    Signed-off-by: Bjorn Helgaas

    Alexandru Gagniuc
     

19 Sep, 2018

3 commits

  • When the PCI hotplug core and its first user, cpqphp, were introduced in
    February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot
    struct for its internal use plus a hotplug_slot struct to be registered
    with the hotplug core and linked the two with pointers:
    https://git.kernel.org/tglx/history/c/a8a2069f432c

    Nowadays, the predominant pattern in the tree is to embed ("subclass")
    such structures in one another and cast to the containing struct with
    container_of(). But it wasn't until July 2002 that container_of() was
    introduced with historic commit ec4f214232cf:
    https://git.kernel.org/tglx/history/c/ec4f214232cf

    pnv_php, introduced in 2016, did the right thing and embedded struct
    hotplug_slot in its internal struct pnv_php_slot, but all other drivers
    cargo-culted cpqphp's design and linked separate structs with pointers.

    Embedding structs is preferrable to linking them with pointers because
    it requires fewer allocations, thereby reducing overhead and simplifying
    error paths. Casting an embedded struct to the containing struct
    becomes a cheap subtraction rather than a dereference. And having fewer
    pointers reduces the risk of them pointing nowhere either accidentally
    or due to an attack.

    Convert all drivers to embed struct hotplug_slot in their internal slot
    struct. The "private" pointer in struct hotplug_slot thereby becomes
    unused, so drop it.

    Signed-off-by: Lukas Wunner
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Rafael J. Wysocki
    Acked-by: Tyrel Datwyler # drivers/pci/hotplug/rpa*
    Acked-by: Sebastian Ott # drivers/pci/hotplug/s390*
    Acked-by: Andy Shevchenko # drivers/platform/x86
    Cc: Len Brown
    Cc: Scott Murray
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Michael Ellerman
    Cc: Oliver OHalloran
    Cc: Gavin Shan
    Cc: Gerald Schaefer
    Cc: Corentin Chary
    Cc: Darren Hart

    Lukas Wunner
     
  • Ever since the PCI hotplug core was introduced in 2002, drivers had to
    allocate and register a struct hotplug_slot_info for every slot:
    https://git.kernel.org/tglx/history/c/a8a2069f432c

    Apparently the idea was that drivers furnish the hotplug core with an
    up-to-date card presence status, power status, latch status and
    attention indicator status as well as notify the hotplug core of changes
    thereof. However only 4 out of 12 hotplug drivers bother to notify the
    hotplug core with pci_hp_change_slot_info() and the hotplug core never
    made any use of the information: There is just a single macro in
    pci_hotplug_core.c, GET_STATUS(), which uses the hotplug_slot_info if
    the driver lacks the corresponding callback in hotplug_slot_ops. The
    macro is called when the user reads the attribute via sysfs.

    Now, if the callback isn't defined, the attribute isn't exposed in sysfs
    in the first place (see e.g. has_power_file()). There are only two
    situations when the hotplug_slot_info would actually be accessed:

    * If the driver defines ->enable_slot or ->disable_slot but not
    ->get_power_status.

    * If the driver defines ->set_attention_status but not
    ->get_attention_status.

    There is no driver doing the former and just a single driver doing the
    latter, namely pnv_php.c. Amend it with a ->get_attention_status
    callback. With that, the hotplug_slot_info becomes completely unused by
    the PCI hotplug core. But a few drivers use it internally as a cache:

    cpcihp uses it to cache the latch_status and adapter_status.
    cpqhp uses it to cache the adapter_status.
    pnv_php and rpaphp use it to cache the attention_status.
    shpchp uses it to cache all four values.

    Amend these drivers to cache the information in their private slot
    struct. shpchp's slot struct already contains members to cache the
    power_status and adapter_status, so additional members are only needed
    for the other two values. In the case of cpqphp, the cached value is
    only accessed in a single place, so instead of caching it, read the
    current value from the hardware.

    Caution: acpiphp, cpci, cpqhp, shpchp, asus-wmi and eeepc-laptop
    populate the hotplug_slot_info with initial values on probe. That code
    is herewith removed. There is a theoretical chance that the code has
    side effects without which the driver fails to function, e.g. if the
    ACPI method to read the adapter status needs to be executed at least
    once on probe. That seems unlikely to me, still maintainers should
    review the changes carefully for this possibility.

    Rafael adds: "I'm not aware of any case in which it will break anything,
    [...] but if that happens, it may be necessary to add the execution of
    the control methods in question directly to the initialization part."

    Signed-off-by: Lukas Wunner
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Rafael J. Wysocki
    Acked-by: Tyrel Datwyler # drivers/pci/hotplug/rpa*
    Acked-by: Sebastian Ott # drivers/pci/hotplug/s390*
    Acked-by: Andy Shevchenko # drivers/platform/x86
    Cc: Len Brown
    Cc: Scott Murray
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Michael Ellerman
    Cc: Oliver OHalloran
    Cc: Gavin Shan
    Cc: Gerald Schaefer
    Cc: Corentin Chary
    Cc: Darren Hart

    Lukas Wunner
     
  • Hotplug drivers cannot declare their hotplug_slot_ops const, making them
    attractive targets for attackers, because upon registration of a hotplug
    slot, __pci_hp_initialize() writes to the "owner" and "mod_name" members
    in that struct.

    Fix by moving these members to struct hotplug_slot and constify every
    driver's hotplug_slot_ops except for pciehp.

    pciehp constructs its hotplug_slot_ops at runtime based on the PCIe
    port's capabilities, hence cannot declare them const. It can be
    converted to __write_rarely once that's mainlined:
    http://www.openwall.com/lists/kernel-hardening/2016/11/16/3

    Signed-off-by: Lukas Wunner
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Rafael J. Wysocki
    Acked-by: Tyrel Datwyler # drivers/pci/hotplug/rpa*
    Acked-by: Andy Shevchenko # drivers/platform/x86
    Cc: Len Brown
    Cc: Scott Murray
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Michael Ellerman
    Cc: Oliver OHalloran
    Cc: Gavin Shan
    Cc: Sebastian Ott
    Cc: Gerald Schaefer
    Cc: Corentin Chary
    Cc: Darren Hart

    Lukas Wunner
     

24 Jul, 2018

1 commit

  • 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

    Lukas Wunner
     

05 Jun, 2018

2 commits


02 Jun, 2018

3 commits

  • 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

    Mika Westerberg
     
  • 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

    Mika Westerberg
     
  • 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

    Mika Westerberg
     

29 Jan, 2018

1 commit

  • 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

    Bjorn Helgaas
     

18 Nov, 2016

1 commit

  • 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

    Lukas Wunner
     

14 Nov, 2014

1 commit

  • 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

    Gavin Shan
     

13 Sep, 2014

1 commit


07 Dec, 2013

1 commit

  • Replace direct inclusions of , and
    , which are incorrect, with
    inclusions and remove some inclusions of those files that aren't
    necessary.

    First of all, , and
    should not be included directly from any files that are built for
    CONFIG_ACPI unset, because that generally leads to build warnings about
    undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set,
    includes those files and for CONFIG_ACPI unset it
    provides stub ACPI symbols to be used in that case.

    Second, there are ordering dependencies between those files that always
    have to be met. Namely, it is required that be included
    prior to so that the acpi_pci_root declarations the
    latter depends on are always there. And which provides
    basic ACPICA type declarations should always be included prior to any other
    ACPI headers in CONFIG_ACPI builds. That also is taken care of including
    as appropriate.

    Signed-off-by: Lv Zheng
    Cc: Greg Kroah-Hartman
    Cc: Matthew Garrett
    Cc: Tony Luck
    Cc: "H. Peter Anvin"
    Acked-by: Bjorn Helgaas (drivers/pci stuff)
    Acked-by: Konrad Rzeszutek Wilk (Xen stuff)
    Signed-off-by: Rafael J. Wysocki

    Lv Zheng
     

15 Nov, 2013

1 commit


06 Sep, 2013

1 commit

  • Pull networking changes from David Miller:
    "Noteworthy changes this time around:

    1) Multicast rejoin support for team driver, from Jiri Pirko.

    2) Centralize and simplify TCP RTT measurement handling in order to
    reduce the impact of bad RTO seeding from SYN/ACKs. Also, when
    both timestamps and local RTT measurements are available prefer
    the later because there are broken middleware devices which
    scramble the timestamp.

    From Yuchung Cheng.

    3) Add TCP_NOTSENT_LOWAT socket option to limit the amount of kernel
    memory consumed to queue up unsend user data. From Eric Dumazet.

    4) Add a "physical port ID" abstraction for network devices, from
    Jiri Pirko.

    5) Add a "suppress" operation to influence fib_rules lookups, from
    Stefan Tomanek.

    6) Add a networking development FAQ, from Paul Gortmaker.

    7) Extend the information provided by tcp_probe and add ipv6 support,
    from Daniel Borkmann.

    8) Use RCU locking more extensively in openvswitch data paths, from
    Pravin B Shelar.

    9) Add SCTP support to openvswitch, from Joe Stringer.

    10) Add EF10 chip support to SFC driver, from Ben Hutchings.

    11) Add new SYNPROXY netfilter target, from Patrick McHardy.

    12) Compute a rate approximation for sending in TCP sockets, and use
    this to more intelligently coalesce TSO frames. Furthermore, add
    a new packet scheduler which takes advantage of this estimate when
    available. From Eric Dumazet.

    13) Allow AF_PACKET fanouts with random selection, from Daniel
    Borkmann.

    14) Add ipv6 support to vxlan driver, from Cong Wang"

    Resolved conflicts as per discussion.

    * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1218 commits)
    openvswitch: Fix alignment of struct sw_flow_key.
    netfilter: Fix build errors with xt_socket.c
    tcp: Add missing braces to do_tcp_setsockopt
    caif: Add missing braces to multiline if in cfctrl_linkup_request
    bnx2x: Add missing braces in bnx2x:bnx2x_link_initialize
    vxlan: Fix kernel panic on device delete.
    net: mvneta: implement ->ndo_do_ioctl() to support PHY ioctls
    net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
    icplus: Use netif_running to determine device state
    ethernet/arc/arc_emac: Fix huge delays in large file copies
    tuntap: orphan frags before trying to set tx timestamp
    tuntap: purge socket error queue on detach
    qlcnic: use standard NAPI weights
    ipv6:introduce function to find route for redirect
    bnx2x: VF RSS support - VF side
    bnx2x: VF RSS support - PF side
    vxlan: Notify drivers for listening UDP port changes
    net: usbnet: update addr_assign_type if appropriate
    driver/net: enic: update enic maintainers and driver
    driver/net: enic: Exposing symbols for Cisco's low latency driver
    ...

    Linus Torvalds
     

15 Aug, 2013

1 commit

  • This optional callback allows hotplug controllers to perform slot
    specific resets. These may be necessary in cases where a normal
    secondary bus reset can interact with controller logic and expose
    spurious hotplugs.

    Signed-off-by: Alex Williamson
    Signed-off-by: Bjorn Helgaas

    Alex Williamson
     

31 Jul, 2013

1 commit

  • pcie_link_width is the enum used to define the link width values for a pcie
    device. This enum should not be contained solely in pci_hotplug.h, and this
    patch moves it next to pci_bus_speed in pci.h

    Signed-off-by: Jacob Keller
    Tested-by: Phil Schmitt
    Acked-by: Bjorn Helgaas
    Signed-off-by: Jeff Kirsher

    Jacob Keller
     

18 Apr, 2013

1 commit


01 Nov, 2011

1 commit

  • The original implementations reference THIS_MODULE in an inline.
    We could include , but it is better to avoid chaining.

    Fortunately someone else already thought of this, and made a similar
    inline into a #define in for device_schedule_callback(),
    [see commit 523ded71de0] so follow that precedent here.

    Also bubble up any __must_check that were used on the prev. wrapper inline
    functions up one to the real __register functions, to preserve any prev.
    sanity checks that were used in those instances.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

23 Feb, 2010

2 commits


15 Sep, 2009

3 commits

  • Use the generic pci_configure_slot() rather than the acpiphp-specific
    decode_hpp() and program_hpp().

    Unlike the previous acpiphp-specific code, pci_configure_slot() programs
    PCIe settings when an _HPX method provides them, so acpiphp-managed PCIe
    devices can now be configured.

    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Kenji Kaneshige
    Acked-by: Kenji Kaneshige
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • This patch adds a new pci_configure_slot() function that programs the
    PCI bus characteristics for a newly-added device. This is based on
    code in pciehp_pci.c, but should be generic enough to be used by pciehp,
    shpchp, and acpiphp.

    The hotplug_params struct and the program_hpp_typeX() functions are based
    on the ACPI definitions, but they aren't really ACPI-specific, and there's
    no alternate implementation, so I don't see the need to abstract them yet.

    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Alex Chiang
    Reviewed-by: Kenji Kaneshige
    Acked-by: Kenji Kaneshige
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • This patch makes acpi_get_hp_params_from_firmware() take a
    pci_dev rather than a pci_bus and makes it return a standard
    int errno rather than acpi_status.

    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Kenji Kaneshige
    Acked-by: Kenji Kaneshige
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     

14 Sep, 2009

1 commit


10 Sep, 2009

1 commit


24 Jun, 2009

1 commit


18 Jun, 2009

1 commit

  • Returns whether an ACPI CA node is a PCI root bridge or not.

    This API is generically useful, and shouldn't just be a hotplug function.

    The implementation becomes much simpler as well.

    Signed-off-by: Alex Chiang
    Acked-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Alexander Chiang
     

17 Jun, 2009

2 commits

  • Create symbolic link to hotplug driver module in the PCI slot
    directory (/sys/bus/pci/slots/). In the past, we need to load
    hotplug drivers one by one to identify the hotplug driver that handles
    the slot, and it was very inconvenient especially for trouble shooting.
    With this change, we can easily identify the hotplug driver.

    Signed-off-by: Taku Izumi
    Signed-off-by: Kenji Kaneshige
    Reviewed-by: Alex Chiang
    Signed-off-by: Jesse Barnes

    Kenji Kaneshige
     
  • The EMI support in pciehp is obviously broken. It is implemented using
    struct hotplug_slot_attribute, but sysfs_ops for pci_slot_ktype is NOT
    for struct hotplug_slot_attribute, but for struct pci_slot_attribute.
    This bug had been there for a long time, maybe it was introduced when
    PCI slot framework was introduced. The reason why this bug didn't
    cause any problem is maybe the EMI support is not tested at all
    because of lack of test environment.

    As described above, the EMI support in pciehp seems not to be tested
    at all. So this patch removes EMI support from pciehp, instead of
    fixing the bug.

    Signed-off-by: Kenji Kaneshige
    Signed-off-by: Jesse Barnes

    Kenji Kaneshige
     

09 Jan, 2009

1 commit


08 Jan, 2009

1 commit

  • Some ACPI related PCI hotplug code can be shared among PCI hotplug
    drivers. This patch introduces the following functions in
    drivers/pci/hotplug/acpi_pcihp.c to share the code, and changes
    acpiphp and pciehp to use them.

    - int acpi_pci_detect_ejectable(struct pci_bus *pbus)
    This checks if the specified PCI bus has ejectable slots.

    - int acpi_pci_check_ejectable(struct pci_bus *pbus, acpi_handle handle)
    This checks if the specified handle is ejectable ACPI PCI slot. The
    'pbus' parameter is needed to check if 'handle' is PCI related ACPI
    object.

    This patch also introduces the following inline function in
    include/linux/pci-acpi.h, which is useful to get ACPI handle of the
    PCI bridge from struct pci_bus of the bridge's secondary bus.

    - static inline acpi_handle acpi_pci_get_bridge_handle(struct pci_bus *pbus)
    This returns ACPI handle of the PCI bridge which generates PCI bus
    specified by 'pbus'.

    Signed-off-by: Kenji Kaneshige
    Signed-off-by: Jesse Barnes

    Kenji Kaneshige
     

31 Dec, 2008

1 commit


23 Oct, 2008

2 commits

  • Now that the PCI core manages the 'name' for each individual
    hotplug driver, and all drivers (except rpaphp) have been converted
    to use hotplug_slot_name(), there is no need for the PCI hotplug
    core to drag around its own copy of name either.

    Cc: kristen.c.accardi@intel.com
    Cc: matthew@wil.cx
    Acked-by: Kenji Kaneshige
    Signed-off-by: Alex Chiang
    Signed-off-by: Jesse Barnes

    Alex Chiang
     
  • In preparation for cleaning up the various hotplug drivers
    such that they don't have to manage their own 'name' parameters
    anymore, we provide the following convenience functions:

    pci_slot_name()
    hotplug_slot_name()

    These helpers will be used by individual hotplug drivers.

    Cc: kristen.c.accardi@intel.com
    Cc: matthew@wil.cx
    Acked-by: Kenji Kaneshige
    Signed-off-by: Alex Chiang
    Signed-off-by: Jesse Barnes

    Alex Chiang