2018-01-27 04:22:04 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ */
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* PCI Express Hot Plug Controller Driver
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 1995,2001 Compaq Computer Corporation
|
|
|
|
|
* Copyright (C) 2001 Greg Kroah-Hartman (greg@kroah.com)
|
|
|
|
|
* Copyright (C) 2001 IBM Corp.
|
|
|
|
|
* Copyright (C) 2003-2004 Intel Corporation
|
|
|
|
|
*
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
2005-08-17 06:16:10 +08:00
|
|
|
* Send feedback to <greg@kroah.com>, <kristen.c.accardi@intel.com>
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
#ifndef _PCIEHP_H
|
|
|
|
|
#define _PCIEHP_H
|
|
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
#include <linux/pci.h>
|
2006-10-14 11:05:19 +08:00
|
|
|
#include <linux/pci_hotplug.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/delay.h>
|
2006-01-13 23:02:15 +08:00
|
|
|
#include <linux/mutex.h>
|
2018-07-28 13:18:00 +08:00
|
|
|
#include <linux/rwsem.h>
|
2010-10-18 14:31:02 +08:00
|
|
|
#include <linux/workqueue.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-03-10 01:42:01 +08:00
|
|
|
#include "../pcie/portdrv.h"
|
2018-02-14 11:52:18 +08:00
|
|
|
|
2012-01-13 07:02:20 +08:00
|
|
|
extern bool pciehp_poll_mode;
|
2005-04-17 06:20:36 +08:00
|
|
|
extern int pciehp_poll_time;
|
|
|
|
|
|
2019-05-08 07:24:52 +08:00
|
|
|
/*
|
|
|
|
|
* Set CONFIG_DYNAMIC_DEBUG=y and boot with 'dyndbg="file pciehp* +p"' to
|
|
|
|
|
* enable debug messages.
|
|
|
|
|
*/
|
2008-09-05 11:11:26 +08:00
|
|
|
#define ctrl_dbg(ctrl, format, arg...) \
|
2019-05-08 07:24:51 +08:00
|
|
|
pci_dbg(ctrl->pcie->port, format, ## arg)
|
2008-09-05 11:11:26 +08:00
|
|
|
#define ctrl_err(ctrl, format, arg...) \
|
2019-05-08 07:24:51 +08:00
|
|
|
pci_err(ctrl->pcie->port, format, ## arg)
|
2008-09-05 11:11:26 +08:00
|
|
|
#define ctrl_info(ctrl, format, arg...) \
|
2019-05-08 07:24:51 +08:00
|
|
|
pci_info(ctrl->pcie->port, format, ## arg)
|
2008-09-05 11:11:26 +08:00
|
|
|
#define ctrl_warn(ctrl, format, arg...) \
|
2019-05-08 07:24:51 +08:00
|
|
|
pci_warn(ctrl->pcie->port, format, ## arg)
|
2008-09-05 11:11:26 +08:00
|
|
|
|
2006-12-22 09:01:02 +08:00
|
|
|
#define SLOT_NAME_SIZE 10
|
2018-07-20 06:27:36 +08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* struct controller - PCIe hotplug controller
|
|
|
|
|
* @pcie: pointer to the controller's PCIe port service device
|
|
|
|
|
* @slot_cap: cached copy of the Slot Capabilities register
|
|
|
|
|
* @slot_ctrl: cached copy of the Slot Control register
|
2018-09-08 15:59:01 +08:00
|
|
|
* @ctrl_lock: serializes writes to the Slot Control register
|
2018-07-20 06:27:36 +08:00
|
|
|
* @cmd_started: jiffies when the Slot Control register was last written;
|
|
|
|
|
* the next write is allowed 1 second later, absent a Command Completed
|
|
|
|
|
* interrupt (PCIe r4.0, sec 6.7.3.2)
|
|
|
|
|
* @cmd_busy: flag set on Slot Control register write, cleared by IRQ handler
|
|
|
|
|
* on reception of a Command Completed event
|
2018-09-08 15:59:01 +08:00
|
|
|
* @queue: wait queue to wake up on reception of a Command Completed event,
|
|
|
|
|
* used for synchronous writes to the Slot Control register
|
|
|
|
|
* @pending_events: used by the IRQ handler to save events retrieved from the
|
|
|
|
|
* Slot Status register for later consumption by the IRQ thread
|
2018-07-20 06:27:36 +08:00
|
|
|
* @notification_enabled: whether the IRQ was requested successfully
|
|
|
|
|
* @power_fault_detected: whether a power fault was detected by the hardware
|
|
|
|
|
* that has not yet been cleared by the user
|
2018-09-08 15:59:01 +08:00
|
|
|
* @poll_thread: thread to poll for slot events if no IRQ is available,
|
|
|
|
|
* enabled with pciehp_poll_mode module parameter
|
2018-09-19 03:46:17 +08:00
|
|
|
* @state: current state machine position
|
2018-09-08 15:59:01 +08:00
|
|
|
* @state_lock: protects reads and writes of @state;
|
|
|
|
|
* protects scheduling, execution and cancellation of @button_work
|
|
|
|
|
* @button_work: work item to turn the slot on or off after 5 seconds
|
2018-09-19 03:46:17 +08:00
|
|
|
* in response to an Attention Button press
|
2018-09-08 15:59:01 +08:00
|
|
|
* @hotplug_slot: structure registered with the PCI hotplug core
|
2018-09-08 15:59:01 +08:00
|
|
|
* @reset_lock: prevents access to the Data Link Layer Link Active bit in the
|
|
|
|
|
* Link Status register and to the Presence Detect State bit in the Slot
|
|
|
|
|
* Status register during a slot reset which may cause them to flap
|
PCI: pciehp: Enable/disable exclusively from IRQ thread
Besides the IRQ thread, there are several other places in the driver
which enable or disable the slot:
- pciehp_probe() enables the slot if it's occupied and the pciehp_force
module parameter is used.
- pciehp_resume() enables or disables the slot after system sleep.
- pciehp_queue_pushbutton_work() enables or disables the slot after the
5 second delay following an Attention Button press.
- pciehp_sysfs_enable_slot() and pciehp_sysfs_disable_slot() enable or
disable the slot on sysfs write.
This requires locking and complicates pciehp's state machine.
A simplification can be achieved by enabling and disabling the slot
exclusively from the IRQ thread.
Amend the functions listed above to request slot enable/disablement from
the IRQ thread by either synthesizing a Presence Detect Changed event or,
in the case of a disable user request (via sysfs or an Attention Button
press), submitting a newly introduced force disable request. The latter
is needed because the slot shall be forced off despite being occupied.
For this force disable request, avoid colliding with Slot Status register
bits by using a bit number greater than 16.
For synchronous execution of requests (on sysfs write), wait for the
request to finish and retrieve the result. There can only ever be one
sysfs write in flight due to the locking in kernfs_fop_write(), hence
there is no risk of returning the result of a different sysfs request to
user space.
The POWERON_STATE and POWEROFF_STATE is now no longer entered by the
above-listed functions, but solely by the IRQ thread when it begins a
power transition. Afterwards, it moves to STATIC_STATE. The same
applies to canceling the Attention Button work, it likewise becomes an
IRQ thread only operation.
An immediate consequence is that the POWERON_STATE and POWEROFF_STATE is
never observed by the IRQ thread itself, only by functions called in a
different context, such as pciehp_sysfs_enable_slot(). So remove
handling of these states from pciehp_handle_button_press() and
pciehp_handle_link_change() which are exclusively called from the IRQ
thread.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-20 06:27:46 +08:00
|
|
|
* @request_result: result of last user request submitted to the IRQ thread
|
|
|
|
|
* @requester: wait queue to wake up on completion of user request,
|
|
|
|
|
* used for synchronous slot enable/disable request via sysfs
|
2018-09-19 03:46:17 +08:00
|
|
|
*
|
|
|
|
|
* PCIe hotplug has a 1:1 relationship between controller and slot, hence
|
|
|
|
|
* unlike other drivers, the two aren't represented by separate structures.
|
2018-07-20 06:27:36 +08:00
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
struct controller {
|
2018-07-20 06:27:36 +08:00
|
|
|
struct pcie_device *pcie;
|
2018-09-08 15:59:01 +08:00
|
|
|
|
|
|
|
|
u32 slot_cap; /* capabilities and quirks */
|
|
|
|
|
|
|
|
|
|
u16 slot_ctrl; /* control register access */
|
|
|
|
|
struct mutex ctrl_lock;
|
|
|
|
|
unsigned long cmd_started;
|
|
|
|
|
unsigned int cmd_busy:1;
|
|
|
|
|
wait_queue_head_t queue;
|
|
|
|
|
|
|
|
|
|
atomic_t pending_events; /* event handling */
|
2009-01-29 11:31:18 +08:00
|
|
|
unsigned int notification_enabled:1;
|
2009-02-03 14:06:16 +08:00
|
|
|
unsigned int power_fault_detected;
|
2018-09-08 15:59:01 +08:00
|
|
|
struct task_struct *poll_thread;
|
|
|
|
|
|
|
|
|
|
u8 state; /* state machine */
|
2018-09-08 15:59:01 +08:00
|
|
|
struct mutex state_lock;
|
|
|
|
|
struct delayed_work button_work;
|
2018-09-08 15:59:01 +08:00
|
|
|
|
2018-09-08 15:59:01 +08:00
|
|
|
struct hotplug_slot hotplug_slot; /* hotplug core interface */
|
2018-09-08 15:59:01 +08:00
|
|
|
struct rw_semaphore reset_lock;
|
PCI: pciehp: Enable/disable exclusively from IRQ thread
Besides the IRQ thread, there are several other places in the driver
which enable or disable the slot:
- pciehp_probe() enables the slot if it's occupied and the pciehp_force
module parameter is used.
- pciehp_resume() enables or disables the slot after system sleep.
- pciehp_queue_pushbutton_work() enables or disables the slot after the
5 second delay following an Attention Button press.
- pciehp_sysfs_enable_slot() and pciehp_sysfs_disable_slot() enable or
disable the slot on sysfs write.
This requires locking and complicates pciehp's state machine.
A simplification can be achieved by enabling and disabling the slot
exclusively from the IRQ thread.
Amend the functions listed above to request slot enable/disablement from
the IRQ thread by either synthesizing a Presence Detect Changed event or,
in the case of a disable user request (via sysfs or an Attention Button
press), submitting a newly introduced force disable request. The latter
is needed because the slot shall be forced off despite being occupied.
For this force disable request, avoid colliding with Slot Status register
bits by using a bit number greater than 16.
For synchronous execution of requests (on sysfs write), wait for the
request to finish and retrieve the result. There can only ever be one
sysfs write in flight due to the locking in kernfs_fop_write(), hence
there is no risk of returning the result of a different sysfs request to
user space.
The POWERON_STATE and POWEROFF_STATE is now no longer entered by the
above-listed functions, but solely by the IRQ thread when it begins a
power transition. Afterwards, it moves to STATIC_STATE. The same
applies to canceling the Attention Button work, it likewise becomes an
IRQ thread only operation.
An immediate consequence is that the POWERON_STATE and POWEROFF_STATE is
never observed by the IRQ thread itself, only by functions called in a
different context, such as pciehp_sysfs_enable_slot(). So remove
handling of these states from pciehp_handle_button_press() and
pciehp_handle_link_change() which are exclusively called from the IRQ
thread.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-20 06:27:46 +08:00
|
|
|
int request_result;
|
|
|
|
|
wait_queue_head_t requester;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
2018-07-20 06:27:45 +08:00
|
|
|
/**
|
|
|
|
|
* DOC: Slot state
|
|
|
|
|
*
|
|
|
|
|
* @OFF_STATE: slot is powered off, no subordinate devices are enumerated
|
|
|
|
|
* @BLINKINGON_STATE: slot will be powered on after the 5 second delay,
|
|
|
|
|
* green led is blinking
|
|
|
|
|
* @BLINKINGOFF_STATE: slot will be powered off after the 5 second delay,
|
|
|
|
|
* green led is blinking
|
|
|
|
|
* @POWERON_STATE: slot is currently powering on
|
|
|
|
|
* @POWEROFF_STATE: slot is currently powering off
|
|
|
|
|
* @ON_STATE: slot is powered on, subordinate devices have been enumerated
|
|
|
|
|
*/
|
|
|
|
|
#define OFF_STATE 0
|
2005-04-17 06:20:36 +08:00
|
|
|
#define BLINKINGON_STATE 1
|
|
|
|
|
#define BLINKINGOFF_STATE 2
|
|
|
|
|
#define POWERON_STATE 3
|
|
|
|
|
#define POWEROFF_STATE 4
|
2018-07-20 06:27:45 +08:00
|
|
|
#define ON_STATE 5
|
2005-04-17 06:20:36 +08:00
|
|
|
|
PCI: pciehp: Enable/disable exclusively from IRQ thread
Besides the IRQ thread, there are several other places in the driver
which enable or disable the slot:
- pciehp_probe() enables the slot if it's occupied and the pciehp_force
module parameter is used.
- pciehp_resume() enables or disables the slot after system sleep.
- pciehp_queue_pushbutton_work() enables or disables the slot after the
5 second delay following an Attention Button press.
- pciehp_sysfs_enable_slot() and pciehp_sysfs_disable_slot() enable or
disable the slot on sysfs write.
This requires locking and complicates pciehp's state machine.
A simplification can be achieved by enabling and disabling the slot
exclusively from the IRQ thread.
Amend the functions listed above to request slot enable/disablement from
the IRQ thread by either synthesizing a Presence Detect Changed event or,
in the case of a disable user request (via sysfs or an Attention Button
press), submitting a newly introduced force disable request. The latter
is needed because the slot shall be forced off despite being occupied.
For this force disable request, avoid colliding with Slot Status register
bits by using a bit number greater than 16.
For synchronous execution of requests (on sysfs write), wait for the
request to finish and retrieve the result. There can only ever be one
sysfs write in flight due to the locking in kernfs_fop_write(), hence
there is no risk of returning the result of a different sysfs request to
user space.
The POWERON_STATE and POWEROFF_STATE is now no longer entered by the
above-listed functions, but solely by the IRQ thread when it begins a
power transition. Afterwards, it moves to STATIC_STATE. The same
applies to canceling the Attention Button work, it likewise becomes an
IRQ thread only operation.
An immediate consequence is that the POWERON_STATE and POWEROFF_STATE is
never observed by the IRQ thread itself, only by functions called in a
different context, such as pciehp_sysfs_enable_slot(). So remove
handling of these states from pciehp_handle_button_press() and
pciehp_handle_link_change() which are exclusively called from the IRQ
thread.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-20 06:27:46 +08:00
|
|
|
/**
|
|
|
|
|
* DOC: Flags to request an action from the IRQ thread
|
|
|
|
|
*
|
|
|
|
|
* These are stored together with events read from the Slot Status register,
|
|
|
|
|
* hence must be greater than its 16-bit width.
|
|
|
|
|
*
|
|
|
|
|
* %DISABLE_SLOT: Disable the slot in response to a user request via sysfs or
|
|
|
|
|
* an Attention Button press after the 5 second delay
|
PCI: pciehp: Support interrupts sent from D3hot
If a hotplug port is able to send an interrupt, one would naively assume
that it is accessible at that moment. After all, if it wouldn't be
accessible, i.e. if its parent is in D3hot and the link to the hotplug
port is thus down, how should an interrupt come through?
It turns out that assumption is wrong at least for Thunderbolt: Even
though its parents are in D3hot, a Thunderbolt hotplug port is able to
signal interrupts. Because the port's config space is inaccessible and
resuming the parents may sleep, the hard IRQ handler has to defer
runtime resuming the parents and reading the Slot Status register to the
IRQ thread.
If the hotplug port uses a level-triggered INTx interrupt, it needs to
be masked until the IRQ thread has cleared the signaled events. For
simplicity, this commit also masks edge-triggered MSI/MSI-X interrupts.
Note that if the interrupt is shared (which can only happen for INTx),
other devices are starved from receiving interrupts until the IRQ thread
is scheduled, has runtime resumed the hotplug port's parents and has
read and cleared the Slot Status register.
That delay is dominated by the 10 ms D3hot->D0 transition time of each
parent port. The worst case is a Thunderbolt downstream port at the
end of a daisy chain: There may be up to six Thunderbolt controllers
in-between it and the root port, each comprising an upstream and
downstream port, plus its own upstream port. That's 13 x 10 = 130 ms.
Possible mitigations are polling the interrupt while it's disabled or
reducing the d3_delay of Thunderbolt ports if possible.
Open code masking of the interrupt instead of requesting it with the
IRQF_ONESHOT flag to minimize the period during which it is masked.
(IRQF_ONESHOT unmasks the IRQ only after the IRQ thread has finished.)
PCIe r4.0 sec 6.7.3.4 states that "If wake generation is required by the
associated form factor specification, a hotplug capable Downstream Port
must support generation of a wakeup event (using the PME mechanism) on
hotplug events that occur when the system is in a sleep state or the
Port is in device state D1, D2, or D3Hot."
This would seem to imply that PME needs to be enabled on the hotplug
port when it is runtime suspended. pci_enable_wake() currently doesn't
enable PME on bridges, it may be necessary to add an exemption for
hotplug bridges there. On "Light Ridge" Thunderbolt controllers, the
PME_Status bit is not set when an interrupt occurs while the hotplug
port is in D3hot, even if PME is enabled. (I've tested this on a Mac
and we hardcode the OSC_PCI_EXPRESS_PME_CONTROL bit to 0 on Macs in
negotiate_os_control(), modifying it to 1 didn't change the behavior.)
(Side note: Section 6.7.3.4 also states that "PME and Hot-Plug Event
interrupts (when both are implemented) always share the same MSI or
MSI-X vector". That would only seem to apply to Root Ports, however
the section never mentions Root Ports, only Downstream Ports. This is
explained in the definition of "Downstream Port" in the "Terms and
Acronyms" section of the PCIe Base Spec: "The Ports on a Switch that
are not the Upstream Port are Downstream Ports. All Ports on a Root
Complex are Downstream Ports.")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Keith Busch <keith.busch@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
2018-07-28 13:18:00 +08:00
|
|
|
* %RERUN_ISR: Used by the IRQ handler to inform the IRQ thread that the
|
|
|
|
|
* hotplug port was inaccessible when the interrupt occurred, requiring
|
|
|
|
|
* that the IRQ handler is rerun by the IRQ thread after it has made the
|
|
|
|
|
* hotplug port accessible by runtime resuming its parents to D0
|
PCI: pciehp: Enable/disable exclusively from IRQ thread
Besides the IRQ thread, there are several other places in the driver
which enable or disable the slot:
- pciehp_probe() enables the slot if it's occupied and the pciehp_force
module parameter is used.
- pciehp_resume() enables or disables the slot after system sleep.
- pciehp_queue_pushbutton_work() enables or disables the slot after the
5 second delay following an Attention Button press.
- pciehp_sysfs_enable_slot() and pciehp_sysfs_disable_slot() enable or
disable the slot on sysfs write.
This requires locking and complicates pciehp's state machine.
A simplification can be achieved by enabling and disabling the slot
exclusively from the IRQ thread.
Amend the functions listed above to request slot enable/disablement from
the IRQ thread by either synthesizing a Presence Detect Changed event or,
in the case of a disable user request (via sysfs or an Attention Button
press), submitting a newly introduced force disable request. The latter
is needed because the slot shall be forced off despite being occupied.
For this force disable request, avoid colliding with Slot Status register
bits by using a bit number greater than 16.
For synchronous execution of requests (on sysfs write), wait for the
request to finish and retrieve the result. There can only ever be one
sysfs write in flight due to the locking in kernfs_fop_write(), hence
there is no risk of returning the result of a different sysfs request to
user space.
The POWERON_STATE and POWEROFF_STATE is now no longer entered by the
above-listed functions, but solely by the IRQ thread when it begins a
power transition. Afterwards, it moves to STATIC_STATE. The same
applies to canceling the Attention Button work, it likewise becomes an
IRQ thread only operation.
An immediate consequence is that the POWERON_STATE and POWEROFF_STATE is
never observed by the IRQ thread itself, only by functions called in a
different context, such as pciehp_sysfs_enable_slot(). So remove
handling of these states from pciehp_handle_button_press() and
pciehp_handle_link_change() which are exclusively called from the IRQ
thread.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-20 06:27:46 +08:00
|
|
|
*/
|
|
|
|
|
#define DISABLE_SLOT (1 << 16)
|
PCI: pciehp: Support interrupts sent from D3hot
If a hotplug port is able to send an interrupt, one would naively assume
that it is accessible at that moment. After all, if it wouldn't be
accessible, i.e. if its parent is in D3hot and the link to the hotplug
port is thus down, how should an interrupt come through?
It turns out that assumption is wrong at least for Thunderbolt: Even
though its parents are in D3hot, a Thunderbolt hotplug port is able to
signal interrupts. Because the port's config space is inaccessible and
resuming the parents may sleep, the hard IRQ handler has to defer
runtime resuming the parents and reading the Slot Status register to the
IRQ thread.
If the hotplug port uses a level-triggered INTx interrupt, it needs to
be masked until the IRQ thread has cleared the signaled events. For
simplicity, this commit also masks edge-triggered MSI/MSI-X interrupts.
Note that if the interrupt is shared (which can only happen for INTx),
other devices are starved from receiving interrupts until the IRQ thread
is scheduled, has runtime resumed the hotplug port's parents and has
read and cleared the Slot Status register.
That delay is dominated by the 10 ms D3hot->D0 transition time of each
parent port. The worst case is a Thunderbolt downstream port at the
end of a daisy chain: There may be up to six Thunderbolt controllers
in-between it and the root port, each comprising an upstream and
downstream port, plus its own upstream port. That's 13 x 10 = 130 ms.
Possible mitigations are polling the interrupt while it's disabled or
reducing the d3_delay of Thunderbolt ports if possible.
Open code masking of the interrupt instead of requesting it with the
IRQF_ONESHOT flag to minimize the period during which it is masked.
(IRQF_ONESHOT unmasks the IRQ only after the IRQ thread has finished.)
PCIe r4.0 sec 6.7.3.4 states that "If wake generation is required by the
associated form factor specification, a hotplug capable Downstream Port
must support generation of a wakeup event (using the PME mechanism) on
hotplug events that occur when the system is in a sleep state or the
Port is in device state D1, D2, or D3Hot."
This would seem to imply that PME needs to be enabled on the hotplug
port when it is runtime suspended. pci_enable_wake() currently doesn't
enable PME on bridges, it may be necessary to add an exemption for
hotplug bridges there. On "Light Ridge" Thunderbolt controllers, the
PME_Status bit is not set when an interrupt occurs while the hotplug
port is in D3hot, even if PME is enabled. (I've tested this on a Mac
and we hardcode the OSC_PCI_EXPRESS_PME_CONTROL bit to 0 on Macs in
negotiate_os_control(), modifying it to 1 didn't change the behavior.)
(Side note: Section 6.7.3.4 also states that "PME and Hot-Plug Event
interrupts (when both are implemented) always share the same MSI or
MSI-X vector". That would only seem to apply to Root Ports, however
the section never mentions Root Ports, only Downstream Ports. This is
explained in the definition of "Downstream Port" in the "Terms and
Acronyms" section of the PCIe Base Spec: "The Ports on a Switch that
are not the Upstream Port are Downstream Ports. All Ports on a Root
Complex are Downstream Ports.")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Keith Busch <keith.busch@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
2018-07-28 13:18:00 +08:00
|
|
|
#define RERUN_ISR (1 << 17)
|
PCI: pciehp: Enable/disable exclusively from IRQ thread
Besides the IRQ thread, there are several other places in the driver
which enable or disable the slot:
- pciehp_probe() enables the slot if it's occupied and the pciehp_force
module parameter is used.
- pciehp_resume() enables or disables the slot after system sleep.
- pciehp_queue_pushbutton_work() enables or disables the slot after the
5 second delay following an Attention Button press.
- pciehp_sysfs_enable_slot() and pciehp_sysfs_disable_slot() enable or
disable the slot on sysfs write.
This requires locking and complicates pciehp's state machine.
A simplification can be achieved by enabling and disabling the slot
exclusively from the IRQ thread.
Amend the functions listed above to request slot enable/disablement from
the IRQ thread by either synthesizing a Presence Detect Changed event or,
in the case of a disable user request (via sysfs or an Attention Button
press), submitting a newly introduced force disable request. The latter
is needed because the slot shall be forced off despite being occupied.
For this force disable request, avoid colliding with Slot Status register
bits by using a bit number greater than 16.
For synchronous execution of requests (on sysfs write), wait for the
request to finish and retrieve the result. There can only ever be one
sysfs write in flight due to the locking in kernfs_fop_write(), hence
there is no risk of returning the result of a different sysfs request to
user space.
The POWERON_STATE and POWEROFF_STATE is now no longer entered by the
above-listed functions, but solely by the IRQ thread when it begins a
power transition. Afterwards, it moves to STATIC_STATE. The same
applies to canceling the Attention Button work, it likewise becomes an
IRQ thread only operation.
An immediate consequence is that the POWERON_STATE and POWEROFF_STATE is
never observed by the IRQ thread itself, only by functions called in a
different context, such as pciehp_sysfs_enable_slot(). So remove
handling of these states from pciehp_handle_button_press() and
pciehp_handle_link_change() which are exclusively called from the IRQ
thread.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-20 06:27:46 +08:00
|
|
|
|
2009-09-15 16:34:05 +08:00
|
|
|
#define ATTN_BUTTN(ctrl) ((ctrl)->slot_cap & PCI_EXP_SLTCAP_ABP)
|
|
|
|
|
#define POWER_CTRL(ctrl) ((ctrl)->slot_cap & PCI_EXP_SLTCAP_PCP)
|
|
|
|
|
#define MRL_SENS(ctrl) ((ctrl)->slot_cap & PCI_EXP_SLTCAP_MRLSP)
|
|
|
|
|
#define ATTN_LED(ctrl) ((ctrl)->slot_cap & PCI_EXP_SLTCAP_AIP)
|
|
|
|
|
#define PWR_LED(ctrl) ((ctrl)->slot_cap & PCI_EXP_SLTCAP_PIP)
|
|
|
|
|
#define HP_SUPR_RM(ctrl) ((ctrl)->slot_cap & PCI_EXP_SLTCAP_HPS)
|
|
|
|
|
#define EMI(ctrl) ((ctrl)->slot_cap & PCI_EXP_SLTCAP_EIP)
|
|
|
|
|
#define NO_CMD_CMPL(ctrl) ((ctrl)->slot_cap & PCI_EXP_SLTCAP_NCCS)
|
2014-04-06 05:05:07 +08:00
|
|
|
#define PSN(ctrl) (((ctrl)->slot_cap & PCI_EXP_SLTCAP_PSN) >> 19)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
PCI: pciehp: Enable/disable exclusively from IRQ thread
Besides the IRQ thread, there are several other places in the driver
which enable or disable the slot:
- pciehp_probe() enables the slot if it's occupied and the pciehp_force
module parameter is used.
- pciehp_resume() enables or disables the slot after system sleep.
- pciehp_queue_pushbutton_work() enables or disables the slot after the
5 second delay following an Attention Button press.
- pciehp_sysfs_enable_slot() and pciehp_sysfs_disable_slot() enable or
disable the slot on sysfs write.
This requires locking and complicates pciehp's state machine.
A simplification can be achieved by enabling and disabling the slot
exclusively from the IRQ thread.
Amend the functions listed above to request slot enable/disablement from
the IRQ thread by either synthesizing a Presence Detect Changed event or,
in the case of a disable user request (via sysfs or an Attention Button
press), submitting a newly introduced force disable request. The latter
is needed because the slot shall be forced off despite being occupied.
For this force disable request, avoid colliding with Slot Status register
bits by using a bit number greater than 16.
For synchronous execution of requests (on sysfs write), wait for the
request to finish and retrieve the result. There can only ever be one
sysfs write in flight due to the locking in kernfs_fop_write(), hence
there is no risk of returning the result of a different sysfs request to
user space.
The POWERON_STATE and POWEROFF_STATE is now no longer entered by the
above-listed functions, but solely by the IRQ thread when it begins a
power transition. Afterwards, it moves to STATIC_STATE. The same
applies to canceling the Attention Button work, it likewise becomes an
IRQ thread only operation.
An immediate consequence is that the POWERON_STATE and POWEROFF_STATE is
never observed by the IRQ thread itself, only by functions called in a
different context, such as pciehp_sysfs_enable_slot(). So remove
handling of these states from pciehp_handle_button_press() and
pciehp_handle_link_change() which are exclusively called from the IRQ
thread.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-20 06:27:46 +08:00
|
|
|
void pciehp_request(struct controller *ctrl, int action);
|
2018-09-19 03:46:17 +08:00
|
|
|
void pciehp_handle_button_press(struct controller *ctrl);
|
|
|
|
|
void pciehp_handle_disable_request(struct controller *ctrl);
|
|
|
|
|
void pciehp_handle_presence_or_link_change(struct controller *ctrl, u32 events);
|
|
|
|
|
int pciehp_configure_device(struct controller *ctrl);
|
|
|
|
|
void pciehp_unconfigure_device(struct controller *ctrl, bool presence);
|
2013-04-13 02:02:59 +08:00
|
|
|
void pciehp_queue_pushbutton_work(struct work_struct *work);
|
2008-06-20 11:07:08 +08:00
|
|
|
struct controller *pcie_init(struct pcie_device *dev);
|
2009-01-29 11:31:18 +08:00
|
|
|
int pcie_init_notification(struct controller *ctrl);
|
2018-07-20 06:27:32 +08:00
|
|
|
void pcie_shutdown_notification(struct controller *ctrl);
|
2018-07-20 06:27:53 +08:00
|
|
|
void pcie_clear_hotplug_events(struct controller *ctrl);
|
2018-09-28 05:38:19 +08:00
|
|
|
void pcie_enable_interrupt(struct controller *ctrl);
|
|
|
|
|
void pcie_disable_interrupt(struct controller *ctrl);
|
2018-09-19 03:46:17 +08:00
|
|
|
int pciehp_power_on_slot(struct controller *ctrl);
|
|
|
|
|
void pciehp_power_off_slot(struct controller *ctrl);
|
|
|
|
|
void pciehp_get_power_status(struct controller *ctrl, u8 *status);
|
|
|
|
|
|
|
|
|
|
void pciehp_set_attention_status(struct controller *ctrl, u8 status);
|
|
|
|
|
void pciehp_get_latch_status(struct controller *ctrl, u8 *status);
|
|
|
|
|
int pciehp_query_power_fault(struct controller *ctrl);
|
|
|
|
|
void pciehp_green_led_on(struct controller *ctrl);
|
|
|
|
|
void pciehp_green_led_off(struct controller *ctrl);
|
|
|
|
|
void pciehp_green_led_blink(struct controller *ctrl);
|
2018-09-08 15:59:01 +08:00
|
|
|
bool pciehp_card_present(struct controller *ctrl);
|
|
|
|
|
bool pciehp_card_present_or_link_active(struct controller *ctrl);
|
2009-09-15 16:30:48 +08:00
|
|
|
int pciehp_check_link_status(struct controller *ctrl);
|
2014-02-05 10:28:43 +08:00
|
|
|
bool pciehp_check_link_active(struct controller *ctrl);
|
2009-09-15 16:30:48 +08:00
|
|
|
void pciehp_release_ctrl(struct controller *ctrl);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-08-19 22:29:00 +08:00
|
|
|
int pciehp_sysfs_enable_slot(struct hotplug_slot *hotplug_slot);
|
|
|
|
|
int pciehp_sysfs_disable_slot(struct hotplug_slot *hotplug_slot);
|
|
|
|
|
int pciehp_reset_slot(struct hotplug_slot *hotplug_slot, int probe);
|
|
|
|
|
int pciehp_get_attention_status(struct hotplug_slot *hotplug_slot, u8 *status);
|
PCI: pciehp: Allow exclusive userspace control of indicators
PCIe hotplug supports optional Attention and Power Indicators, which are
used internally by pciehp. Users can't control the Power Indicator, but
they can control the Attention Indicator by writing to a sysfs "attention"
file.
The Slot Control register has two bits for each indicator, and the PCIe
spec defines the encodings for each as (Reserved/On/Blinking/Off). For
sysfs "attention" writes, pciehp_set_attention_status() maps into these
encodings, so the only useful write values are 0 (Off), 1 (On), and 2
(Blinking).
However, some platforms use all four bits for platform-specific indicators,
and they need to allow direct user control of them while preventing pciehp
from using them at all.
Add a "hotplug_user_indicators" flag to the pci_dev structure. When set,
pciehp does not use either the Attention Indicator or the Power Indicator,
and the low four bits (values 0x0 - 0xf) of sysfs "attention" write values
are written directly to the Attention Indicator Control and Power Indicator
Control fields.
[bhelgaas: changelog, rename flag and accessors to s/attention/indicator/]
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-09-14 00:31:59 +08:00
|
|
|
int pciehp_set_raw_indicator_status(struct hotplug_slot *h_slot, u8 status);
|
|
|
|
|
int pciehp_get_raw_indicator_status(struct hotplug_slot *h_slot, u8 *status);
|
|
|
|
|
|
2018-09-19 03:46:17 +08:00
|
|
|
static inline const char *slot_name(struct controller *ctrl)
|
2008-10-21 07:41:38 +08:00
|
|
|
{
|
2018-09-08 15:59:01 +08:00
|
|
|
return hotplug_slot_name(&ctrl->hotplug_slot);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct controller *to_ctrl(struct hotplug_slot *hotplug_slot)
|
|
|
|
|
{
|
|
|
|
|
return container_of(hotplug_slot, struct controller, hotplug_slot);
|
2008-10-21 07:41:38 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif /* _PCIEHP_H */
|