1. 18 9月, 2009 4 次提交
  2. 10 9月, 2009 1 次提交
    • E
      PCI: Simplify hotplug mch quirk. · 0ba379ec
      Eric W. Biederman 提交于
      There is a very old quirk for the intel E7502 E7320 and E7525 memory
      controller hubs that disables usage of msi interrupts on pcie hotplug
      bridges of those devices, and disables changing the affinity of irqs.
      
      Today all we have to do to disable msi on a specific device is to set
      dev->no_msi, which is much more straightforward than the previous
      logic.
      
      The re-running of this fixup after pci hotplug happens below these
      devices is totally bogus.  All of the state we change is pure software
      state and we don't change the hardware at all.  Which means hotplug on
      the lower devices doesn't have a chance to change this state.  So we
      can safely remove the special case from the pciehp driver and the pcie
      portdriver.
      
      I suspect the special case was someone's expermental debug code that
      slipped in. Certainly it isn't mentioned in commit
      6fb8880a61510295aece04a542767161f624dffe aka BKrev:
      41966101LJ_ogfOU0m2aE6teZfQnuQ where the code first appears.
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0ba379ec
  3. 13 7月, 2009 1 次提交
  4. 08 1月, 2009 1 次提交
  5. 24 10月, 2008 1 次提交
  6. 23 10月, 2008 2 次提交
  7. 21 10月, 2008 1 次提交
  8. 28 5月, 2008 2 次提交
    • 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: 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
  9. 26 4月, 2008 1 次提交
  10. 21 4月, 2008 1 次提交
  11. 02 2月, 2008 4 次提交
  12. 29 11月, 2007 1 次提交
    • R
      pci hotplug: kernel-doc fixes · 26e6c66e
      Randy Dunlap 提交于
      acpiphp.h: not using kernel-doc, so change /** to /*
      acpiphp_core.c: lots of kernel-doc cleanups
      acpiphp_glue.c: lots of kernel-doc cleanups
      acpiphp_ibm.c: lots of kernel-doc cleanups
      cpqphp_core.c: lots of kernel-doc cleanups
      cpqphp_ctrl.c: lots of kernel-doc cleanups
      fakephp.c:  correct kernel-doc notation
      pciehp_ctrl.c: correct kernel-doc notation
      rpadlpar_core.c: correct function names & kernel-doc notation
      rpaphp_core.c: correct kernel-doc notation
      shpchp_ctrl.c: correct kernel-doc notation
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Kristen Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      26e6c66e
  13. 13 10月, 2007 1 次提交
  14. 12 7月, 2007 1 次提交
  15. 03 5月, 2007 2 次提交
  16. 08 2月, 2007 3 次提交
  17. 19 10月, 2006 3 次提交
  18. 27 9月, 2006 1 次提交
  19. 24 3月, 2006 1 次提交
  20. 24 11月, 2005 1 次提交
  21. 11 11月, 2005 5 次提交
  22. 18 9月, 2005 1 次提交
  23. 17 8月, 2005 1 次提交