1. 23 9月, 2008 1 次提交
  2. 22 7月, 2008 1 次提交
  3. 08 7月, 2008 1 次提交
  4. 02 5月, 2008 1 次提交
    • D
      sparc64: Stop creating dummy root PCI host controller devices. · c26d3c01
      David S. Miller 提交于
      It just creates confusion, errors, and bugs.
      
      For one thing, this can cause dup sysfs or procfs nodes to get
      created:
      
      [    1.198015] proc_dir_entry '00.0' already registered
      [    1.198036] Call Trace:
      [    1.198052]  [00000000004f2534] create_proc_entry+0x7c/0x98
      [    1.198092]  [00000000005719e4] pci_proc_attach_device+0xa4/0xd4
      [    1.198126]  [00000000007d991c] pci_proc_init+0x64/0x88
      [    1.198158]  [00000000007c62a4] kernel_init+0x190/0x330
      [    1.198183]  [0000000000426cf8] kernel_thread+0x38/0x48
      [    1.198210]  [00000000006a0d90] rest_init+0x18/0x5c
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c26d3c01
  5. 27 4月, 2008 1 次提交
  6. 24 4月, 2008 1 次提交
  7. 19 2月, 2008 1 次提交
  8. 27 12月, 2007 1 次提交
  9. 23 10月, 2007 1 次提交
  10. 14 10月, 2007 1 次提交
  11. 12 9月, 2007 1 次提交
  12. 31 8月, 2007 1 次提交
    • D
      [SPARC64]: Fix several bugs in MSI handling. · 5f92c329
      David S. Miller 提交于
      1) sun4{u,v}_build_msi() have improper return value handling.
      
         We should always return negative error codes, instead of
         using the magic value "0" which could in fact be a valid
         MSI number.
      
      2) sun4{u,v}_build_msi() should return -ENOMEM instead of
         calling prom_prom() halt with kzalloc() of the interrupt
         data fails.
      
      3) We 'remembered' the MSI number using a singleton in the
         struct device archdata area, this doesn't work for MSI-X
         which can cause multiple MSIs assosciated with one device.
      
         Delete that archdata member, and instead store the MSI
         number in the IRQ chip data area.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f92c329
  13. 30 7月, 2007 2 次提交
    • D
      [SPARC64]: Fix conflicts in SBUS/PCI/EBUS/ISA DMA handling. · ad7ad57c
      David S. Miller 提交于
      Fully unify all of the DMA ops so that subordinate bus types to
      the DMA operation providers (such as ebus, isa, of_device) can
      work transparently.
      
      Basically, we just make sure that for every system device we
      create, the dev->archdata 'iommu' and 'stc' fields are filled
      in.
      
      Then we have two platform variants of the DMA ops, one for SUN4U which
      actually programs the real hardware, and one for SUN4V which makes
      hypervisor calls.
      
      This also fixes the crashes in parport_pc on sparc64, reported by
      Meelis Roos.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad7ad57c
    • D
      [SPARC64]: Fix sun4u PCI config space accesses on sun4u. · a2d6ea01
      David S. Miller 提交于
      Don't provide fake PCI config space for sun4u.
      
      Also, put back the funny host controller space handling that
      at least Sabre needs.  You have to read PCI host controller
      registers at their nature size otherwise you get zeros instead
      of correct values.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2d6ea01
  14. 12 7月, 2007 1 次提交
  15. 08 6月, 2007 1 次提交
    • D
      [SPARC64]: Handle PCI bridges without 'ranges' property. · 8c2786cf
      David S. Miller 提交于
      This fixes the IDE controller not showing up on Netra-T1
      systems.
      
      Just like Simba bridges, some PCI bridges can lack the
      'ranges' OBP property.  So we handle this similarly to
      the existing Simba code:
      
      1) In of_device register address resolving, we push the
         translation to the parent.
      
      2) In PCI device scanning, we interrogate the PCI config
         space registers of the PCI bus device in order to resolve
         the resources, just like the generic Linux PCI probing
         code does.
      
      With much help and testing from Fabio, who also reported
      the initial problem.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NFabio Massimo Di Nitto <fabbione@ubuntu.com>
      8c2786cf
  16. 29 5月, 2007 1 次提交
  17. 12 5月, 2007 1 次提交
  18. 10 5月, 2007 1 次提交
  19. 09 5月, 2007 7 次提交
  20. 07 5月, 2007 2 次提交
    • D
      [SPARC64]: Fix section mismatch warnings in arch/sparc64/kernel/pci.c · a6009dda
      David S. Miller 提交于
      apb_calc_first_last(), apb_fake_ranges(), pci_of_scan_bus(),
      of_scan_pci_bridge(), pci_of_scan_bus(), and pci_scan_one_pbm()
      should all be __devinit.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a6009dda
    • D
      [SPARC64]: SUN4U PCI-E controller support. · 861fe906
      David S. Miller 提交于
      Some minor refactoring in the generic code was necessary for
      this:
      
      1) This controller requires 8-byte access to the interrupt map
         and clear register.  They are 64-bits on all the other
         SBUS and PCI controllers anyways, so this was easy to cure.
      
      2) The IMAP register has a different layout and some bits that we
         need to preserve, so use a read/modify/write when making
         changes to the IMAP register in generic code.
      
      3) Flushing the entire IOMMU TLB is best done with a single write
         to a register on this PCI controller, add a iommu->iommu_flushinv
         for this.
      
      Still lacks MSI support, that will come later.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      861fe906
  21. 03 5月, 2007 1 次提交
    • M
      MSI: arch must connect the irq and the msi_desc · 7fe3730d
      Michael Ellerman 提交于
      set_irq_msi() currently connects an irq_desc to an msi_desc. The archs call
      it at some point in their setup routine, and then the generic code sets up the
      reverse mapping from the msi_desc back to the irq.
      
      set_irq_msi() should do both connections, making it the one and only call
      required to connect an irq with it's MSI desc and vice versa.
      
      The arch code MUST call set_irq_msi(), and it must do so only once it's sure
      it's not going to fail the irq allocation.
      
      Given that there's no need for the arch to return the irq anymore, the return
      value from the arch setup routine just becomes 0 for success and anything else
      for failure.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7fe3730d
  22. 26 4月, 2007 10 次提交
  23. 13 4月, 2007 1 次提交