linux-toradex.git/drivers/pci/hotplug/pciehp.h, branch v2.6.27.31

PCI: pciehp: remove 'name' parameter

2008-12-05T18:55:18+00:00

commit e1acb24f059defdaa0264e925f19cc21b0a3e592 upstream.

We do not need to manage our own name parameter, especially since
the PCI core can change it on our behalf, in the case of duplicate
slot names.

Remove 'name' from pciehp's version of struct slot, and remove
unused 'task_list' as well.

Cc: kristen.c.accardi@intel.com
Acked-by: Kenji Kaneshige 
Signed-off-by: Alex Chiang 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Rename duplicate slot name N as N-1, N-2, N-M...

2008-08-21T22:15:10+00:00

Commit 3800345f723fd130d50434d4717b99d4a9f383c8 (pciehp: fix slot name)
introduces the pciehp_slot_with_bus module parameter, which was intended
to help work around broken firmware that assigns the same name to multiple
slots.

Commit 9e4f2e8d4ddb04ad16a3828cd9a369a5a5287009 (pciehp: add message about
pciehp_slot_with_bus option) tells the user to use the above parameter
in the event of a name collision.

This approach is sub-optimal because it requires too much work from
the user.

Instead, let's rename the slot on behalf of the user. If firmware
assigns the name N to multiple slots, then:

	The first registered slot is assigned N
	The second registered slot is assigned N-1
	The third registered slot is assigned N-2
	The Mth registered slot becomes N-M

In the event we overflow the slot->name parameter, we report an
error to the user.

This is a temporary fix until the entire PCI core can be reworked
such that individual drivers no longer have to manage their own
slot names.

Tested-by: Kenji Kaneshige 
Acked-by: Kenji Kaneshige 
Signed-off-by: Alex Chiang 
Signed-off-by: Jesse Barnes

PCI: remove unnecessary volatile in PCIe hotplug struct controller

2008-07-16T15:46:43+00:00

Proper memory barriers have been added to order accesses
to ->cmd_busy, so volatile declaration for cmd_busy can
be removed.

Signed-off-by: Ming Lei 
Signed-off-by: Jesse Barnes

pciehp: fix interrupt initialization

2008-06-27T20:00:43+00:00

Current pciehp driver's intialization sequence is as follows:

(1) initialize controller data structure
(2) install interrupt handler
(3) enable software notification
(4) initialize controller specific slot data structure
(5) initialize generic slot data structure and register it to pci hotplug core

The interrupt handler of pciehp assumes that controller specific slot
data structure is already initialized. However, it is installed at (2)
before initializing controller specific slot data structure at
(4). Because of this, pciehp driver cannot handle the following cases
properly.

- If devices that shares IRQ with pciehp raise interrupts between (2) and (4).
- If hotplug events (e.g. MRL open) happen between (3) and (4).

We already have a workaround for this problem ("pciehp: fix NULL
dereference in interrupt handler: dbd79aed1aea2bece0bf43cc2ff3b2f9baf48a08).
But we still need fundamental fix.

This patch fix the problem by changing the initilization sequence as follows:

(1) initialize controller data structure
(2) initialize controller specific slot data structure
(3) install interrupt handler
(4) enable software notification
(5) initialize generic slot data structure and register it to pci hotplug core

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

shpchp: check firmware before taking control

2008-06-10T17:59:53+00:00

Fix the following problems of shpchp driver about getting hotplug
control from firmware.

  - The shpchp driver must not control the hotplug controller if it
    fails to get control from the firmware. But current shpchp
    controls the hotplug controller regardless the result, because it
    doesn't check the return value of get_hp_hw_control_from_firmware().

  - Current shpchp driver doesn't support _OSC.

The pciehp driver already have the code for evaluating _OSC and OSHP
and shpchp and pciehp can share it. So this patch move that code from
pciehp to acpi_pcihp.c.

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

pciehp: evaluate _OSC/OSHP before controller init

2008-06-10T17:59:53+00:00

Current pciehp evaluates _OSC/OSHP method after some controller
initialization is done. So if evaluating _OSC/OSHP is failed, we need
to cleanup already initialized data structures or hardware. This
clearly is not robust way. With this patch, _OSC/OSHP evaluation is
done first.

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

pciehp: fix slow probing

2008-05-27T22:43:16+00:00

Fix the "pciehp probing slow" problem reported from Jan C. Nordholz in
http://bugzilla.kernel.org/show_bug.cgi?id=10751.

The command completed bit in Slot Status register applies only to
commands issued to control the attention indicator, power indicator,
power controller, or electromechanical interlock. However, writes to
other parts of the Slot Control register would end up writing to the
control fields. Hence, any write to Slot Control register is
considered as a command. However, if the controller doesn't support
any of attention indicator, power indicator, power controller and
electromechanical interlock, command completed bit would not set in
writing to Slot Control register. In this case, we should not wait for
command completed bit set, otherwise all commands would be considered
not completed in timeout seconds (1 sec.).

The cause of the problem is pciehp driver didn't take this situation
into account. This patch changes pciehp to take it into account. This
patch also add the check for "No Command Completed Support" bit in
Slot Capability register. If it is set, we should not wait for command
completed bit set as well.

This problem seems to be revealed by the commit
c27fb883dffe11aa4cb35ecea1fa1832ba45d4da that fixed the bug that
pciehp did not wait for command completed properly (pciehp just
ignored the command completion event).

Signed-off-by: Kenji Kaneshige 
Signed-off-by: Kristen Carlson Accardi 
Signed-off-by: Jesse Barnes

pciehp: fix NULL dereference in interrupt handler

2008-05-27T22:43:08+00:00

Fix the following NULL dereference problem reported from Pierre Ossman
and Ingo Molnar.

pciehp: HPC vendor_id 8086 device_id 27d0 ss_vid 0 ss_did 0
pciehp: pciehp_find_slot: slot (device=0x0) not found
BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
IP: [] pciehp_handle_presence_change+0x7e/0x113
PGD 0
Oops: 0000 [1]
CPU 0
Modules linked in:
Pid: 1, comm: swapper Tainted: G        W 2.6.26-rc3-sched-devel.git-00001-g2b99b26-dirty #170
RIP: 0010:[]  [] pciehp_handle_presence_change+0x7e/0x113
RSP: 0000:ffff81003f83fbb0  EFLAGS: 00010046
RAX: 0000000000000039 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000046
RBP: ffff81003f83fbd0 R08: 0000000000000001 R09: ffffffff80245103
R10: 0000000000000020 R11: 0000000000000000 R12: ffff81003ea53a30
R13: 0000000000000000 R14: 0000000000000011 R15: ffffffff80495926
FS:  0000000000000000(0000) GS:ffffffff80be7400(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000070 CR3: 0000000000201000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff81003f83e000, task ffff81003f840000)
Stack:  0000000000000008 ffff81003f83fbf6 ffff81003ea53a30 0000000000000008
 ffff81003f83fc10 ffffffff80495ab4 0000000000000011 0000000000000002
 0000000000000202 0000000000000202 00000000fffffff4 ffff81003ea53a30
Call Trace:
 [] pcie_isr+0x18e/0x1bc
 [] request_irq+0x106/0x12f
 [] pcie_init+0x15e/0x6cc
 [] pciehp_probe+0x64/0x541
 [] pcie_port_probe_service+0x4c/0x76
 [] driver_probe_device+0xd4/0x1f0
 [] __driver_attach+0x7c/0x7e
 [] ? __driver_attach+0x0/0x7e
 [] bus_for_each_dev+0x53/0x7d
 [] driver_attach+0x1c/0x1e
 [] bus_add_driver+0xdd/0x25b
 [] ? pcied_init+0x0/0x8b
 [] driver_register+0x5f/0x13e
 [] ? pcied_init+0x0/0x8b
 [] pcie_port_service_register+0x47/0x49
 [] pcied_init+0x15/0x8b
 [] kernel_init+0x75/0x243
 [] ? _spin_unlock_irq+0x2b/0x3a
 [] ? finish_task_switch+0x57/0x9a
 [] child_rip+0xa/0x12
 [] ? restore_args+0x0/0x30
 [] ? kernel_init+0x0/0x243
 [] ? child_rip+0x0/0x12

Code: 83 80 00 00 00 48 39 f0 75 e1 0f b6 c9 48 c7 c2 00 0e 8d 80 48 c7 c6 8a 60 a6 80 48 c7 c7 10 db a8 80 31 c0 e8 3f 8d d9 ff 31 db <48> 8b 43 70 48 8d 75 ef 48 89 df ff 50 30 80 7d ef 00 74 37 48
RIP  [] pciehp_handle_presence_change+0x7e/0x113
 RSP 
CR2: 0000000000000070
Kernel panic - not syncing: Fatal exception

The situation under which it occurs is hw and timing related: it appears
to happen on a system that has PCI hotplug hardware but with no active
hotplug cards, and another interrupt in the same (shared) IRQ line
arrives too early, before the hotplug-slot entry has been set up - as
triggered by CONFIG_DEBUG_SHIRQ=y:

This patch contains the following two fixes.

(1) Clear all events bits in Slot Status register to prevent the pciehp
    driver from detecting the spurious events that would have been occur
    before pciehp loading.

(2) Add check whether slot initialization had been already done.

This is short term fix. We need more structural fixes to install
interrupt handler after slot initialization is done.

Signed-off-by: Ingo Molnar 
Signed-off-by: Kenji Kaneshige 
Signed-off-by: Kristen Carlson Accardi 
Signed-off-by: Jesse Barnes

pciehp: Fix wrong slot capability check

2008-04-25T21:39:06+00:00

Current pciehp saves only 8bits of Slot Capability registers in
ctrl->ctrlcap. But it refers more than 8bit for checking EMI capability.
It is clearly a bug and EMI would never work. To fix this problem,
this patch saves full Slot Capability contens in ctrl->slot_cap. It also
reduce the redundant reads of Slot Capability register. And this pach
also cleans up the macros to check the slot capabilitys (e.g. MRL_SENS(),
and so on).

Signed-off-by: Kenji Kaneshige 
Signed-off-by:  Kristen Carlson Accardi 
Signed-off-by: Jesse Barnes

pciehp: Fix interrupt event handlig

2008-04-25T21:38:57+00:00

Current pciehp implementation disables and re-enables hotplug interrupts
in its interrupt handler. This operation might be intend to guarantee
that interrupts for the events newly occured during previous events are
being handled will be successfully generated. But current implementaion
has the following prolems.

  - Current interrupt service routin clears status changes without
    waiting command completion. Because of this, events might not be
    cleared properly.
  - Current interrupt service routine clears status changes caused by
    disabling or enabling hotplug interrupts itself. This will lose new
    events that occurs during previous interrupts are being handled.
  - Current implementation doesn't have any serialization mechanism
    between the code to wait for command completion and the interrupt
    handler that clears the command completion events caused by itself.
    There is clearly race conditions between them, and it may cause
    the problem that waiting for command completion doesn't work for
    example.

To fix those problems, this patch stops disabling/re-enabling hotplug
interrupts in interrupt service routine. Instead of this, this patch
re-inspects Slot Status register after clearing what is presumed to
be the last bending interrupt in order to guarantee that all interrupt
events are serviced.

Signed-off-by: Kenji Kaneshige 
Signed-off-by:  Kristen Carlson Accardi 
Signed-off-by: Jesse Barnes