15 Aug, 2013
1 commit
-
PCIe hotplug has a bus per slot, so we can just use a normal
secondary bus reset. However, if a slot supports surprise removal,
a bus reset can be seen as a presence detection change triggering
a hot-remove followed by a hot-add. Disable presence detection from
triggering an interrupt or being polled around the bus reset.Signed-off-by: Alex Williamson
Signed-off-by: Bjorn Helgaas
04 Jul, 2013
1 commit
-
For the workqueue creation interfaces that do not expect format strings,
make sure they cannot accidently be parsed that way. Additionally, clean
up calls made with a single parameter that would be handled as a format
string. Many callers are passing potentially dynamic string content, so
use "%s" in those cases to avoid any potential accidents.Signed-off-by: Kees Cook
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Jan, 2013
1 commit
-
When we have a hotplug-capable PCIe port with a second hotplug-capable
PCIe port below it, removing the device below the upstream port causes
a deadlock.The deadlock happens because we use the pciehp_wq workqueue to run
pciehp_power_thread(), which uses pciehp_disable_slot() to remove devices
below the upstream port. When we remove the downstream PCIe port, we call
pciehp_remove(), the pciehp driver's .remove() method. That calls
flush_workqueue(pciehp_wq), which deadlocks because the
pciehp_power_thread() work item is still running.This patch avoids the deadlock by creating a workqueue for every PCIe port
and removing the single shared workqueue.Here's the call path that leads to the deadlock:
pciehp_queue_pushbutton_work
queue_work(pciehp_wq) # queue pciehp_power_thread
...pciehp_power_thread
pciehp_disable_slot
remove_board
pciehp_unconfigure_device
pci_stop_and_remove_bus_device
...
pciehp_remove # pciehp driver .remove method
pciehp_release_ctrl
pcie_cleanup_slot
flush_workqueue(pciehp_wq)This is fairly urgent because it can be caused by simply unplugging a
Thunderbolt adapter, as reported by Daniel below.[bhelgaas: changelog]
Reference: http://lkml.kernel.org/r/CAMVG2ssiRgcTD1bej2tkUUfsWmpL5eNtPcNif9va2-Gzb2u8nQ@mail.gmail.com
Reported-and-tested-by: Daniel J Blueman
Reviewed-by: Kenji Kaneshige
Signed-off-by: Yijing Wang
Signed-off-by: Bjorn Helgaas
CC: stable@vger.kernel.org
24 Aug, 2012
1 commit
-
Use PCI Express Capability access functions to simplify pciehp.
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
Signed-off-by: Bjorn Helgaas
Reviewed-by: Kenji Kaneshige
13 Jul, 2012
1 commit
-
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Cc: Kenji Kaneshige
15 Feb, 2012
5 commits
-
On a system with a repeater on the system board to support gen2 hotplug,
we found that when an ExpressModule is removed from some slots,
/var/log/messages will be full of "card present/not present" warnings.It turns out the root complex is continually trying to train the link to
the repeater because the repeater has not been reset.This patch will disable the link at removal time to allow the repeater
to be reset properly. This also prevents a potential AER message at
removal time.Also, when testing hotplug on a system under development, we found if we
boot the system without an EM installed, and later hot-add an EM, it
does not work with Linux, but another OS is ok. The root cause is that
BIOS left link disabled when slot was empty at boot time, and other OS
is modifying the link disable bit in link ctrl during power on/off.So we should do the same thing to disable/enable link during power off/on.
-v2: check link DLLA bit instead of 100ms waiting.
Separate link disable/enable functions to another patch.Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
Will use it during power off/on of slots
Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
Will use it for link disable status checking.
Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
A few changes:
- remove the 'inline' and let the complier decide
- return a bool to indicate whether the link was active
- add a debug message to indicate link state when it beocmes activeSigned-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes -
During reviewing
| PCI: pciehp: wait 1000 ms before Link Training check
Linus said:
>...
> That's a *long* time, and it's irritating to the user. It makes the
> user think "the machine is slow".
>...
> And quite frankly, an unconditional one-second delay here seems bad.
>Two seconds was unacceptable, one second is just bad.Try to access the pci conf of a pci device that is supposed to show up
in 1s. If we can read back a valid vendor/device id, we can return
early.Related discussion could be found:
https://lkml.org/lkml/2011/12/6/339-v2: seperate code to pci_bus_read_dev_vendor_id() from pci_scan_device()
and reuse it from pciehp code. Suggested by Matthew Wilcox.
-v3: According to Kenj, don't use array in stack, and don't wait too long
for crs, also return fail status if not found.
Also separate pci_bus_dev_read_vendor_id() change to another patch.Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes
06 Dec, 2011
1 commit
-
Use non-ordered workqueue for attention button events.
Attention button events on each slot can be handled asynchronously. So
we should use non-ordered workqueue. This patch also removes ordered
workqueue in pciehp as a result.Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
12 Nov, 2011
2 commits
-
If the port supports Link speeds greater than 5.0 GT/s, we must wait
for 100 ms after Link training completes before sending configuration
request.Acked-by: Yinghai Lu
Tested-by: Yinghai Lu
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
We need to wait for 1000 ms after Data Link Layer Link Active (DLLLA)
bit reads 1b before sending configuration request. Currently pciehp
does this wait after checking Link Training (LT) bit. But we need it
before checking LT bit because LT is still set even after DLLLA bit is
set on some platforms.Acked-by: Yinghai Lu
Tested-by: Yinghai Lu
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
08 Nov, 2011
1 commit
-
During hot plug, board_added will call pciehp_power_on_slot().
But link speed is updated in pciehp_power_on_slot().We should not update link speed there, because that is too early.
So move the link speed update to pciehp_check_link_status() after making
sure the link has been trained.-v2: fix compile warning that Kenji found.
Signed-off-by: Yinghai Lu
Reviewed-by: Kenji Kaneshige
Tested-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
23 Jul, 2011
1 commit
-
Naoki Yanagimoto reported that configuration read on some hot-added
PCIe device returns invalid value. This patch fixes this problem.According to the PCIe spec, software must wait for at least 1 second
to judge if the hot-added device is broken after Data Link Layer State
Changed Event. This patch changes pciehp driver to wait for 1 second
after the Data Link Layer State Changed Event is detected before
initiating a configuration access instead of 100 ms.Signed-off-by: Kenji Kaneshige
Tested-by: Naoki Yanagimoto
Signed-off-by: Jesse Barnes
18 Oct, 2010
1 commit
-
* Rename pciehp_wq to pciehp_ordered_wq and add non-ordered pciehp_wq
which is used instead of the system workqueue. This is to remove
the use of flush_scheduled_work() which is deprecated and scheduled
for removal.* With cmwq in place, there's no point in creating workqueues lazily.
Create both pciehp_wq and pciehp_ordered_wq upfront.* Include workqueue.h from pciehp.h.
Signed-off-by: Tejun Heo
Acked-by: Jesse Barnes
30 Mar, 2010
1 commit
-
…it 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 allmodconfig8. 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>
25 Mar, 2010
1 commit
-
No functional change; just print resources in the conventional style.
Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes
23 Feb, 2010
2 commits
-
Move the max_bus_speed and cur_bus_speed into the pci_bus. Expose the
values through the PCI slot driver instead of the hotplug slot driver.
Update all the hotplug drivers to use the pci_bus instead of their own
data structures.Signed-off-by: Matthew Wilcox
Signed-off-by: Jesse Barnes -
These enums must not overlap anyway, since we only have a single
pci_bus_speed_strings array. Use a single enum, and move it to
pci.h. Add 'SPEED' to the pcie names to make it clear what they are.Signed-off-by: Matthew Wilcox
Signed-off-by: Jesse Barnes
25 Nov, 2009
2 commits
-
Enabling power fault detected event notification in current pciehp
might cause power fault interrupt storm on some machines. On those
machines. On those machines, power fault detected bit in the slot
status register was set again immediately when it is cleared in the
interrupt service routine, and next power fault detected interrupt was
notified again. Therefore, disable power fault detected event
notification for now.This patch also removes unnecessary handling for power fault cleared
event because this event is not supported by PCIe spec.Tested-by: Jens Axboe
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability
offset in pciehp driver. This avoids unnecessary search in PCI
configuration space. This patch also removes 'cap_base' field in
struct controller, that was used to hold PCIe capability offset by
pciehp itself.Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
05 Nov, 2009
3 commits
-
Current pciehp returns successfully on read/write failure with dummy
state values. It should return error instead.With this patch, pciehp no longer uses hotplug_slot_info data
structure. So this also removes hotplug_slot_info related code. But
note that it still allocates hotplug_slot_info because it is required
by pci hotplug core.Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Remove wrong workaround for BAD DLLP error, which confused surprise
down error with DLL errors.Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Current pciehp doesn't handle Data Link Layer State Changed Event
notification. So it needs to be disabled at initialization time,
otherwise other event notifications are not generated.Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
18 Sep, 2009
11 commits
-
Since slot_cap field in struct controller contains physical slot
number informationq, we don't need number field in struct slot.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
The struct hpc_ops seems a set of hooks to controller specific
routines. But, it is meaningless because no hotplug controller driver
follows this framework.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Since we have a pointer to pcie_device in struct controller, we don't
need a pointer to pci_dev.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
The crit_sect mutex defined in struct controller is to serialize
hot-plug operations against multiple slots under the same bus. But,
since PCIe doesnstream port has only one slot at most, it is
meaningless and we don't need it.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
The slot number can be calculated only by physical slot number field
in the slot capabilities register. So the first_slot field in struct
controller is meaningless and we don't need it.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Since the device number of the hot-slot under the PCIe downstream port
is always 0, the slot_device_offset field in the slot is meaningless
and we don't need it.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
The hp_slot field is to identify the slot under the same
controller. But, since PCIe downstream port has only one slot at most,
it is meaningless and we don't need it.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
The device field in the struct slot is not necessary because it is
always 0 in pciehp driver.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
The bus field in struct slot is not necessary.
Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Since PCIe downstream port has only one slot at most, we don't need
num_slots field in struct controller. Note that struct controller
itself doesn't exist if PCIe downstream port has no slot.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Since PCIe downstream port has only one slot at most, we don't need
'slot_list' linked list to manage multiple slots under the port.Acked-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
10 Sep, 2009
1 commit
-
Add support for PCI-E 5.0 GT/s in max_bus_speed and cur_bus_speed.
Reviewed-by: Matthew Wilcox
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
17 Jun, 2009
1 commit
-
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
20 Mar, 2009
2 commits
-
Current pciehp disables software notification of adapter presence
changed event and MRL changed event when slot is turned off. Because
of this, there is no way to detect those events on empty slots in the
current pciehp implementation.According to the past discussion(*), this behavior was introduced to
prevent endless loop that could happen if pcie_isr() runs after power
fault is detected on a certain platform whose stickey power-fault bit
remains on till the slot is powered on again.(*) http://sourceforge.net/mailarchive/message.php?msg_id=20051130135409.A14918%40unix-os.sc.intel.com
I think this endless loop can be avoided using one bit flag that
indicates power fault had been detected, instead of disabling software
notification of adapter present changed event and MRL changed event.With this patch, we can enable software notification mechanism of
presence changed and MRL changed event on the empty slots again.Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Fix possible endless loop in pcie_isr.
Currently, pcie_isr() (interrupt service routine of pciehp) can end up in an
endless loop if the Slot Status register is set again immediately after being
cleared. According to the past discussion (see below URL) this case can happen
if the power fault detected bit is set during handling.http://sourceforge.net/mailarchive/message.php?msg_id=20051130135409.A14918%40unix-os.sc.intel.com
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes