1. 24 7月, 2010 2 次提交
  2. 29 6月, 2010 1 次提交
    • G
      sparc/of: Move of_device fields into struct pdev_archdata · 1636f8ac
      Grant Likely 提交于
      This patch moves SPARC architecture specific data members out of
      struct of_device and into the pdev_archdata structure.  The reason
      for this change is to unify the struct of_device definition amongst
      all the architectures.  It also remvoes the .sysdata, .slot, .portid
      and .clock_freq properties because they aren't actually used by
      anything.
      
      A subsequent patch will replace struct of_device entirely with struct
      platform_device and the of_platform support code will share common
      routines with the platform bus (but the bus instances themselves can
      remain separate).
      
      This patch also adds 'struct resources *resource' and num_resources
      to match the fields defined in struct platform_device.  After this
      change, 'struct platform_device' can be used as a drop-in replacement
      for 'struct of_platform'.
      
      This change is in preparation for merging the of_platform_bus_type
      with the platform_bus_type.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      1636f8ac
  3. 19 5月, 2010 2 次提交
  4. 29 4月, 2010 1 次提交
    • G
      driver-core: Add device node pointer to struct device · d706c1b0
      Grant Likely 提交于
      Currently, platforms using CONFIG_OF add a 'struct device_node *of_node'
      to dev->archdata.  However, with CONFIG_OF becoming generic for all
      architectures, it makes sense for commonality to move it out of archdata
      and into struct device proper.
      
      This patch adds a struct device_node *of_node member to struct device
      and updates all locations which currently write the device_node pointer
      into archdata to also update dev->of_node.  Subsequent patches will
      modify callers to use the archdata location and ultimately remove
      the archdata member entirely.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      CC: Michal Simek <monstr@monstr.eu>
      CC: Greg Kroah-Hartman <gregkh@suse.de>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Stephen Rothwell <sfr@canb.auug.org.au>
      CC: Jeremy Kerr <jeremy.kerr@canonical.com>
      CC: microblaze-uclinux@itee.uq.edu.au
      CC: linux-kernel@vger.kernel.org
      CC: linuxppc-dev@ozlabs.org
      CC: sparclinux@vger.kernel.org
      d706c1b0
  5. 29 1月, 2010 1 次提交
  6. 09 12月, 2009 1 次提交
  7. 16 6月, 2009 1 次提交
  8. 22 4月, 2009 1 次提交
    • D
      sparc: Fix bus type probing for ESP and LE devices. · 956d039a
      David S. Miller 提交于
      If there is a dummy "espdma" or "ledma" parent device above ESP scsi
      or LE ethernet device nodes, we have to match the bus as SBUS.
      
      Otherwise the address and size cell counts are wrong and we don't
      calculate the final physical device resource values correctly at all.
      
      Commit 5280267c ("sparc: Fix handling
      of LANCE and ESP parent nodes in of_device.c") was meant to fix this
      problem, but that only influences the inner loop of
      build_device_resources().  We need this logic to also kick in at the
      beginning of build_device_resources() as well, when we make the first
      attempt to determine the device's immediate parent bus type for 'reg'
      property element extraction.
      
      Based almost entirely upon a patch by Friedrich Oslage.
      Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      956d039a
  9. 08 4月, 2009 1 次提交
  10. 07 1月, 2009 1 次提交
    • S
      sparc64: Use unsigned long long for u64. · 90181136
      Sam Ravnborg 提交于
      Andrew Morton wrote:
      
          People keep on doing
      
                  printk("%llu", some_u64);
      
          testing it only on x86_64 and this generates a warning storm on
          powerpc, sparc64, etc.  Because they use `long', not `long long'.
      
          Quite a few 64-bit architectures are using `long' for their
          s64/u64 types.  We should convert them all to `long long'.
      
      Update types.h so we use unsigned long long for u64 and
      fix all warnings in sparc64 code.
      Tested with an allnoconfig, defconfig and allmodconfig builds.
      
      This patch introduces additional warnings in several drivers.
      These will be dealt with in separate patches.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90181136
  11. 27 12月, 2008 1 次提交
  12. 05 12月, 2008 1 次提交
    • S
      sparc,sparc64: unify kernel/ · a88b5ba8
      Sam Ravnborg 提交于
      o Move all files from sparc64/kernel/ to sparc/kernel
        - rename as appropriate
      o Update sparc/Makefile to the changes
      o Update sparc/kernel/Makefile to include the sparc64 files
      
      NOTE: This commit changes link order on sparc64!
      
      Link order had to change for either of sparc32 and sparc64.
      And assuming sparc64 see more testing than sparc32 change link
      order on sparc64 where issues will be caught faster.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a88b5ba8
  13. 21 9月, 2008 1 次提交
    • D
      sparc64: Fix disappearing PCI devices on e3500. · 7ee766d8
      David S. Miller 提交于
      Based upon a bug report by Meelis Roos.
      
      The OF device layer builds properties by matching bus types and
      applying 'range' properties as appropriate, up to the root.
      
      The match for "PCI" busses is looking at the 'device_type' property,
      and this does work %99 of the time.
      
      But on an E3500 system with a PCI QFE card, the DEC 21153 bridge
      sitting above the QFE network interface devices has a 'name' of "pci",
      but it completely lacks a 'device_type' property.  So we don't match
      it as a PCI bus, and subsequently we end up with no resource values at
      all for the devices sitting under that DEC bridge.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ee766d8
  14. 12 9月, 2008 1 次提交
  15. 03 9月, 2008 1 次提交
  16. 30 8月, 2008 1 次提交
  17. 29 8月, 2008 3 次提交
  18. 26 8月, 2008 1 次提交
  19. 25 8月, 2008 1 次提交
  20. 30 7月, 2008 1 次提交
  21. 22 7月, 2008 1 次提交
  22. 27 4月, 2008 1 次提交
  23. 24 4月, 2008 1 次提交
  24. 09 2月, 2008 1 次提交
  25. 18 10月, 2007 1 次提交
  26. 14 10月, 2007 1 次提交
  27. 21 7月, 2007 1 次提交
  28. 20 7月, 2007 3 次提交
  29. 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
  30. 14 5月, 2007 1 次提交
  31. 12 5月, 2007 1 次提交
  32. 26 4月, 2007 3 次提交
    • D
    • D
      [SPARC64]: Kill pbm->pci_first_slot. · 0bba2dd8
      David S. Miller 提交于
      Set but never used.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bba2dd8
    • D
      [SPARC64]: Fix sabre pci controllers with new probing scheme. · 01f94c4a
      David S. Miller 提交于
      The SIMBA APB bridge is strange, it is a PCI bridge but it lacks
      some standard OF properties, in particular it lacks a 'ranges'
      property.
      
      What you have to do is read the IO and MEM range registers in
      the APB bridge to determine the ranges handled by each bridge.
      So fill in the bus resources by doing that.
      
      Since we now handle this quirk in the generic PCI and OF device
      probing layers, we can flat out eliminate all of that code from
      the sabre pci controller driver.
      
      In fact we can thus eliminate completely another quirk of the sabre
      driver.  It tried to make the two APB bridges look like PBMs but that
      makes zero sense now (and it's questionable whether it ever made sense).
      So now just use pbm_A and probe the whole PCI hierarchy using that as
      the root.
      
      This simplification allows many future cleanups to occur.
      
      Also, I've found yet another quirk that needs to be worked around
      while testing this.  You can't use the 'class-code' OF firmware
      property, especially for IDE controllers.  We have to read the value
      out of PCI config space or else we'll see the value the device was
      showing before it was programmed into native mode.
      
      I'm starting to think it might be wise to just read all of the values
      out of PCI config space instead of using the OF properties. :-/
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      01f94c4a