1. 22 8月, 2008 2 次提交
    • A
      PCI: shpchp: Rename duplicate slot name N as N-1, N-2, N-M... · d6a9e9b4
      Alex Chiang 提交于
      Commit ef0ff95f (shpchp: fix slot name)
      introduces the shpchp_slot_with_bus module parameter, which was intended
      to help work around broken firmware that assigns the same name to multiple
      slots.
      
      Commit b3bd307c (shpchp: add message about
      shpchp_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: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      d6a9e9b4
    • A
      PCI: pciehp: Rename duplicate slot name N as N-1, N-2, N-M... · 167e782e
      Alex Chiang 提交于
      Commit 3800345f (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 9e4f2e8d (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: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      167e782e
  2. 19 8月, 2008 2 次提交
  3. 29 7月, 2008 1 次提交
  4. 22 7月, 2008 1 次提交
  5. 16 7月, 2008 1 次提交
  6. 03 7月, 2008 1 次提交
    • A
      PCI: acpiphp: cleanup notify handler on all root bridges · a13307ce
      Alex Chiang 提交于
      During the development of the physical PCI slot patch series, Gary Hade
      kept on reporting strange oopses due to interactions between pci_slot
      and acpiphp.
      
      	http://lkml.org/lkml/2007/11/28/319
      
      find_root_bridges() unconditionally installs
      handle_hotplug_event_bridge() as an ACPI_SYSTEM_NOTIFY handler for all
      root bridges.
      
      However, during module cleanup, remove_bridge() will only remove the
      notify handler iff the root bridge had a hot-pluggable slot directly
      underneath. That is:
      
      	root bridge -> hotplug slot
      
      But, if the topology looks like either of the following:
      
      	root bridge -> non-hotplug slot
      	root bridge -> p2p bridge -> hotplug slot
      
      Then we currently do not remove the notify handler from that root
      bridge.
      
      This can cause a kernel oops if we modprobe acpiphp later and it gets
      loaded somewhere else in memory. If the root bridge then receives a
      hotplug event, it will then attempt to call a stale, non-existent notify
      handler and we blow up.
      
      Much thanks goes to Gary Hade for his persistent debugging efforts.
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NGary Hade <garyhade@us.ibm.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a13307ce
  7. 28 6月, 2008 3 次提交
    • K
      pciehp: use get_service_data · b9708940
      Kenji Kaneshige 提交于
      Current pciehp driver saves its private data pointer into pci_dev
      structure using pci_set_drvdata()/pci_get_drvdata(). But because
      pciehp is not a pci device driver but a PCI Express service driver, it
      should save its private data pointer into pcie_device structure using
      set_service_data()/get_service_data().
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b9708940
    • K
      pciehp: remove needless command completed interrupt setting · 3aa50c44
      Kenji Kaneshige 提交于
      Currently, pciehp driver enables command completed interrupt as follows.
      
      (1) Don't enable at initialization.
      (2) Enable command completed interrupt whenever pciehp issues a
          command, if the command doesn't attempt to disable the interrupt.
      (3) Disable command completed interrupt at driver unloading.
      
      Once we enable command completed interrupt, we don't need to re-enable
      it for every command. So we can simplify above steps as follows:
      
      (1) Enable command completed interrupt at initialization.
      (2) No special sequence for command completed interrupt.
      (3) Disable command completed interrupt at driver unloading.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      3aa50c44
    • K
      pciehp: fix interrupt initialization · c4635eb0
      Kenji Kaneshige 提交于
      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: dbd79aed).
      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: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Acked-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      c4635eb0
  8. 26 6月, 2008 6 次提交
  9. 11 6月, 2008 10 次提交
  10. 31 5月, 2008 1 次提交
  11. 28 5月, 2008 7 次提交
    • K
      pciehp: add message about pciehp_slot_with_bus option · 9e4f2e8d
      Kenji Kaneshige 提交于
      Some (broken?) platform assign the same slot name to multiple hotplug
      slots. On such system, slot initialization would fail because of name
      collision. The pciehp driver already have a "slot_with_bus" module
      option which adds the bus number into the slot name. This patch adds
      the message about this module option that will be displayed when slot
      name collision is detected.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      9e4f2e8d
    • K
      pci hotplug core: add check of duplicate slot name · a86161b3
      Kenji Kaneshige 提交于
      Fix the following errors reported by Jan C. Nordholz in
      http://bugzilla.kernel.org/show_bug.cgi?id=10751.
      
      kobject_add_internal failed for 2 with -EEXIST, don't try to register things with the same name in the same directory.
      Pid: 1, comm: swapper Tainted: G        W 2.6.26-rc3 #1
       [<c0266980>] kobject_add_internal+0x140/0x190
       [<c0266afd>] kobject_init_and_add+0x2d/0x40
       [<c027bc91>] pci_hp_register+0x81/0x2f0
       [<c027fd07>] pciehp_probe+0x1a7/0x470
       [<c01b3b84>] sysfs_add_one+0x44/0xa0
       [<c01b3c1f>] sysfs_addrm_start+0x3f/0xb0
       [<c01b497a>] sysfs_create_link+0x8a/0xf0
       [<c0279570>] pcie_port_probe_service+0x50/0x80
       [<c02e0545>] driver_sysfs_add+0x55/0x70
       [<c02e0662>] driver_probe_device+0x82/0x180
       [<c02e07cc>] __driver_attach+0x6c/0x70
       [<c02dfe0a>] bus_for_each_dev+0x3a/0x60
       [<c05db2d0>] pcied_init+0x0/0x80
       [<c02e04e6>] driver_attach+0x16/0x20
       [<c02e0760>] __driver_attach+0x0/0x70
       [<c02e0341>] bus_add_driver+0x1a1/0x220
       [<c05db2d0>] pcied_init+0x0/0x80
       [<c02e09cd>] driver_register+0x4d/0x120
       [<c05db050>] ibm_acpiphp_init+0x0/0x190
       [<c0125aab>] printk+0x1b/0x20
       [<c05db2d0>] pcied_init+0x0/0x80
       [<c05db2de>] pcied_init+0xe/0x80
       [<c05c751a>] kernel_init+0x10a/0x300
       [<c0120138>] schedule_tail+0x18/0x50
       [<c0103b9a>] ret_from_fork+0x6/0x1c
       [<c05c7410>] kernel_init+0x0/0x300
       [<c05c7410>] kernel_init+0x0/0x300
       [<c010485b>] kernel_thread_helper+0x7/0x1c
       =======================
      pci_hotplug: Unable to register kobject '2'<3>pciehp: pci_hp_register failed with error -22
      
      Slot with the same name can be registered multiple times if shpchp or
      pciehp driver is loaded after acpiphp is loaded because ACPI based
      hotplug driver and Native OS hotplug driver trying to handle the same
      physical slot. In this case, current pci_hotplug core will call
      kobject_init_and_add() muliple time with the same name. This is the
      cause of this problem. To fix this problem, this patch adds the check
      into pci_hp_register() to see if the slot with the same name.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a86161b3
    • K
      pciehp: move msleep after power off · 0711c70e
      Kenji Kaneshige 提交于
      According to the PCI Express specification, we must wait for at least
      1 second after turning power off before taking any action that relies
      on power having been removed from the slot/adapter. For this, current
      pciehp wait for 1 second after issuing the power off command in
      hpc_power_off_slot() function. But waiting for 1 second in
      hpc_power_off_slot() can make pciehp probing slow-down because pciehp
      probe code calls hpc_power_off_slot() if the slot is not occupied just
      in case. We don't need to wait for 1 second at the pciehp probe time
      because there is no action on that empty slot. So move 1 second wait
      from hpc_power_off_slot() to the caller of hpc_power_off_slot().
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0711c70e
    • K
      pciehp: poll cmd completion if hotplug interrupt is disabled · 6592e02a
      Kenji Kaneshige 提交于
      Fix improper long wait for command completion in pciehp probing.
      
      As described in PCI Express specification, software notification is
      not generated if the command that occurs as a result of a write to the
      Slot Control register that disables software notification of command
      completed events. Since pciehp driver doesn't take it into account,
      such command is issued in pciehp probing, and it causes improper long
      wait for command completion.
      
      This patch changes the pciehp driver to take such command into
      account.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6592e02a
    • K
      pciehp: fix slow probing · 5808639b
      Kenji Kaneshige 提交于
      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
      c27fb883 that fixed the bug that
      pciehp did not wait for command completed properly (pciehp just
      ignored the command completion event).
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      5808639b
    • K
      pciehp: fix NULL dereference in interrupt handler · dbd79aed
      Kenji Kaneshige 提交于
      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: [<ffffffff80494a8b>] 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:[<ffffffff80494a8b>]  [<ffffffff80494a8b>] 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:
       [<ffffffff80495ab4>] pcie_isr+0x18e/0x1bc
       [<ffffffff80260831>] request_irq+0x106/0x12f
       [<ffffffff80495fb6>] pcie_init+0x15e/0x6cc
       [<ffffffff804933a3>] pciehp_probe+0x64/0x541
       [<ffffffff8048f4e7>] pcie_port_probe_service+0x4c/0x76
       [<ffffffff8054af70>] driver_probe_device+0xd4/0x1f0
       [<ffffffff8054b108>] __driver_attach+0x7c/0x7e
       [<ffffffff8054b08c>] ? __driver_attach+0x0/0x7e
       [<ffffffff8054a4b6>] bus_for_each_dev+0x53/0x7d
       [<ffffffff8054ad3c>] driver_attach+0x1c/0x1e
       [<ffffffff8054a9c2>] bus_add_driver+0xdd/0x25b
       [<ffffffff80c09d3d>] ? pcied_init+0x0/0x8b
       [<ffffffff8054b288>] driver_register+0x5f/0x13e
       [<ffffffff80c09d3d>] ? pcied_init+0x0/0x8b
       [<ffffffff8048f441>] pcie_port_service_register+0x47/0x49
       [<ffffffff80c09d52>] pcied_init+0x15/0x8b
       [<ffffffff80bf3938>] kernel_init+0x75/0x243
       [<ffffffff808639d2>] ? _spin_unlock_irq+0x2b/0x3a
       [<ffffffff80228d1f>] ? finish_task_switch+0x57/0x9a
       [<ffffffff8020c258>] child_rip+0xa/0x12
       [<ffffffff8020bcec>] ? restore_args+0x0/0x30
       [<ffffffff80bf38c3>] ? kernel_init+0x0/0x243
       [<ffffffff8020c24e>] ? 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  [<ffffffff80494a8b>] pciehp_handle_presence_change+0x7e/0x113
       RSP <ffff81003f83fbb0>
      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: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      dbd79aed
    • K
      shpchp: add message about shpchp_slot_with_bus option · b3bd307c
      Kenji Kaneshige 提交于
      Some (broken?) platform assign the same slot name to multiple hotplug
      slots. On such system, slot initialization would fail because of name
      collision. The shpchp driver already have a "slot_with_bus" module
      option which adds the bus number into the slot name. This patch adds
      the message about this module option that will be displayed when slot
      name collision is detected.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b3bd307c
  12. 30 4月, 2008 1 次提交
  13. 26 4月, 2008 4 次提交