1. 10 4月, 2013 1 次提交
  2. 18 9月, 2012 2 次提交
    • G
      powerpc/eeh: Fix crash on converting OF node to edev · 1e38b714
      Gavin Shan 提交于
      The kernel crash was reported by Alexy. He was testing some feature
      with private kernel, in which Alexy added some code in pci_pm_reset()
      to read the CSR after writting it. The bug could be reproduced on
      Fiber Channel card (Fibre Channel: Emulex Corporation Saturn-X:
      LightPulse Fibre Channel Host Adapter (rev 03)) by the following
      commands.
      
      	# echo 1 > /sys/devices/pci0004:01/0004:01:00.0/reset
      	# rmmod lpfc
      	# modprobe lpfc
      
      The history behind the test case is that those additional config
      space reading operations in pci_pm_reset() would cause EEH error,
      but we didn't detect EEH error until "modprobe lpfc". For the case,
      all the PCI devices on PCI bus (0004:01) were removed and added after
      PE reset. Then the EEH devices would be figured out again based on
      the OF nodes. Unfortunately, there were some child OF nodes under
      PCI device (0004:01:00.0), but they didn't have attached PCI_DN since
      they're invisible from PCI domain. However, we were still trying to
      convert OF node to EEH device without checking on the attached PCI_DN.
      Eventually, it caused the kernel crash as follows:
      
      Unable to handle kernel paging request for data at address 0x00000030
      Faulting instruction address: 0xc00000000004d888
      cpu 0x0: Vector: 300 (Data Access) at [c000000fc797b950]
          pc: c00000000004d888: .eeh_add_device_tree_early+0x78/0x140
          lr: c00000000004d880: .eeh_add_device_tree_early+0x70/0x140
          sp: c000000fc797bbd0
         msr: 8000000000009032
         dar: 30
       dsisr: 40000000
        current = 0xc000000fc78d9f70
        paca    = 0xc00000000edb0000   softe: 0        irq_happened: 0x00
          pid   = 2951, comm = eehd
      enter ? for help
      [c000000fc797bc50] c00000000004d848 .eeh_add_device_tree_early+0x38/0x140
      [c000000fc797bcd0] c00000000004d848 .eeh_add_device_tree_early+0x38/0x140
      [c000000fc797bd50] c000000000051b54 .pcibios_add_pci_devices+0x34/0x190
      [c000000fc797bde0] c00000000004fb10 .eeh_reset_device+0x100/0x160
      [c000000fc797be70] c0000000000502dc .eeh_handle_event+0x19c/0x300
      [c000000fc797bf00] c000000000050570 .eeh_event_handler+0x130/0x1a0
      [c000000fc797bf90] c000000000020138 .kernel_thread+0x54/0x70
      
      The patch changes of_node_to_eeh_dev() and just returns NULL if the
      passed OF node doesn't have attached PCI_DN.
      
      Cc: stable@vger.kernel.org
      Reported-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1e38b714
    • G
      powerpc/eeh: Remove EEH PE for normal PCI hotplug · 20ee6a97
      Gavin Shan 提交于
      Function eeh_rmv_from_parent_pe() could be called by the path of
      either normal PCI hotplug, or EEH recovery. For the former case,
      we need purge the corresponding PE on removal of the associated
      PE bus.
      
      The patch tries to cover that by passing more information to function
      pcibios_remove_pci_devices() so that we know if the corresponding PE
      needs to be purged or be marked as "invalid".
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      20ee6a97
  3. 10 9月, 2012 1 次提交
  4. 14 6月, 2012 1 次提交
  5. 28 3月, 2012 2 次提交
  6. 07 1月, 2012 1 次提交
  7. 25 11月, 2011 1 次提交
    • B
      powerpc/powernv: PCI support for p7IOC under OPAL v2 · 184cd4a3
      Benjamin Herrenschmidt 提交于
      This adds support for p7IOC (and possibly other IODA v1 IO Hubs)
      using OPAL v2 interfaces.
      
      We completely take over resource assignment and assign them using an
      algorithm that hands out device BARs in a way that makes them fit in
      individual segments of the M32 window of the bridge, which enables us
      to assign individual PEs to devices and functions.
      
      The current implementation gives out a PE per functions on PCIe, and a
      PE for the entire bridge for PCIe to PCI-X bridges.
      
      This can be adjusted / fine tuned later.
      
      We also setup DMA resources (32-bit only for now) and MSIs (both 32-bit
      and 64-bit MSI are supported).
      
      The DMA allocation tries to divide the available 256M segments of the
      32-bit DMA address space "fairly" among PEs. This is done using a
      "weight" heuristic which assigns less value to things like OHCI USB
      controllers than, for example SCSI RAID controllers. This algorithm
      will probably want some fine tuning for specific devices or device
      types.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      184cd4a3
  8. 13 7月, 2011 1 次提交
  9. 12 7月, 2011 1 次提交
  10. 08 6月, 2011 3 次提交
  11. 31 3月, 2011 1 次提交
  12. 05 2月, 2011 2 次提交
  13. 06 7月, 2010 1 次提交
  14. 28 8月, 2009 2 次提交
  15. 21 5月, 2009 2 次提交
  16. 19 5月, 2009 1 次提交
  17. 16 12月, 2008 1 次提交
  18. 06 11月, 2008 1 次提交
  19. 05 11月, 2008 1 次提交
    • B
      powerpc/pci: Use common PHB resource hookup · 53280323
      Benjamin Herrenschmidt 提交于
      The 32-bit and 64-bit powerpc PCI code used to set up the resource
      pointers of the root bus of a given PHB in completely different
      places.
      
      This unifies this in large part, by making 32-bit use a routine very
      similar to what 64-bit does when initially scanning the PCI busses.
      
      The actual setup of the PHB resources itself is then moved to a
      common function in pci-common.c.
      
      This should cause no functional change on 64-bit.  On 32-bit, the
      effect is that the PHB resources are going to be setup a bit earlier,
      instead of being setup from pcibios_fixup_bus().
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      53280323
  20. 21 10月, 2008 1 次提交
  21. 04 8月, 2008 1 次提交
  22. 18 6月, 2008 1 次提交
    • J
      powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata · 5ce4b596
      Josh Boyer 提交于
      The 440EPx/GRx chips don't support PCI MRM commands.  Drivers determine this
      by looking for a zero value in the PCI cache line size register.  However,
      some drivers write to this register upon initialization.  This can cause
      MRMs to be used on these chips, which may cause deadlocks on PLB4.
      
      The workaround implemented here introduces a new indirect_type flag, called
      PPC_INDIRECT_TYPE_BROKEN_MRM.  This is set in the pci_controller structure in
      the pci fixup function for 4xx PCI bridges by determining if the bridge is
      compatible with 440EPx/GRx.  The flag is checked in the indirect_write_config
      function, and forces any writes to the PCI_CACHE_LINE_SIZE register to be
      zero, which will disable MRMs for these chips.
      
      A similar workaround has been tested by AMCC on various PCI cards, such as
      the Silicon Image ATA card and Intel E1000 GIGE card.  Hangs were seen with
      the Silicon Image card, and MRMs were seen on the bus with a PCI analyzer.
      With the workaround in place, the card functioned properly and only Memory
      Reads were seen on the bus with the analyzer.
      Acked-by: NStefan Roese <sr@denx.de>
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      5ce4b596
  23. 18 4月, 2008 1 次提交
  24. 24 1月, 2008 1 次提交
  25. 17 1月, 2008 3 次提交
  26. 21 12月, 2007 1 次提交
  27. 20 12月, 2007 3 次提交
  28. 11 12月, 2007 2 次提交