1. 05 5月, 2012 1 次提交
  2. 16 4月, 2012 1 次提交
  3. 13 4月, 2012 2 次提交
  4. 10 4月, 2012 1 次提交
  5. 29 3月, 2012 2 次提交
  6. 24 3月, 2012 3 次提交
  7. 20 3月, 2012 2 次提交
  8. 12 3月, 2012 1 次提交
    • R
      ARM: fix ioremap/iounmap for !CONFIG_MMU · 8a2b6255
      Rob Herring 提交于
      With commit 4fe7ef3a (ARM: provide runtime hook for ioremap/iounmap),
      compiles with !CONFIG_MMU were broken. Rename nommu __iounmap to
      __arm_iounmap and add arch_ioremap_caller and arch_iounmap. Its
      not expected that these need to be overriden for !CONFIG_MMU, so setting
      the function ptrs has no effect in this case.
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      8a2b6255
  9. 07 3月, 2012 1 次提交
  10. 27 2月, 2012 1 次提交
  11. 24 2月, 2012 1 次提交
    • B
      arm/PCI: remove arch pci_flags definition · 6696cbc3
      Bjorn Helgaas 提交于
      The PCI core provides a pci_flags definition (currently __weak), so drop
      the arm definition in favor of that.
      
      We EXPORT_SYMBOL(pci_flags) as arm did previously.  I'm dubious about
      this: no other architecture exports it, and I didn't see any modules in
      the tree that reference it.
      
      CC: Rob Herring <rob.herring@calxeda.com>
      CC: Russell King <linux@arm.linux.org.uk>
      CC: linux-arm-kernel@lists.infradead.org
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      6696cbc3
  12. 16 2月, 2012 1 次提交
  13. 15 2月, 2012 1 次提交
  14. 10 2月, 2012 2 次提交
  15. 03 2月, 2012 1 次提交
    • R
      Revert "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping" · 97f10409
      Russell King 提交于
      This reverts commit 3c424f35.
      
      Joachim Eastwood reports:
      | "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
      | Commit: 3c424f35 in Linus master
      |
      | Breaks booting on my custom AT91RM9200 board.
      | There isn't any error messages or anything that indicates what goes
      | wrong it just stops after; Uncompressing Linux... done, booting the
      | kernel.
      |
      | Reverting it makes my board boot again.
      
      and further debugging reveals:
      
      ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
      ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
      ioremap: found: addr fef74000 => fed73000 => fed73400
      
      Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
      0xfffff.  This happens because the changed if statement becomes:
      
                      if (0x00200 > 0xfffff ||
                          0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
      and therefore:
                      if (0x00200 > 0xfffff ||
                          0x000003ff > 0x00203fff)
      
      The if condition fails, and so we _believe_ that the SRAM mapping fits
      our request.  Clearly that's totally bogus.
      
      Moreover, the original premise of the 'fix' patch was wrong:
      |    The condition checking boundaries of the requested and existing
      |    mappings didn't take in-page offset into consideration though,
      |    which lead to obscure and hard to debug problems when requested
      |    mapping crossed end of the static one.
      
      as the code immediately above this loop does:
      
              size = PAGE_ALIGN(offset + size);
      
      so 'size' already contains the requested offset into the page.
      
      So, revert the broken 'fix'.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      97f10409
  16. 28 1月, 2012 1 次提交
  17. 27 1月, 2012 5 次提交
  18. 23 1月, 2012 5 次提交
  19. 20 1月, 2012 2 次提交
  20. 13 1月, 2012 1 次提交
    • R
      ARM: Add arm_memblock_steal() to allocate memory away from the kernel · 716a3dc2
      Russell King 提交于
      Several platforms are now using the memblock_alloc+memblock_free+
      memblock_remove trick to obtain memory which won't be mapped in the
      kernel's page tables.  Most platforms do this (correctly) in the
      ->reserve callback.  However, OMAP has started to call these functions
      outside of this callback, and this is extremely unsafe - memory will
      not be unmapped, and could well be given out after memblock is no
      longer responsible for its management.
      
      So, provide arm_memblock_steal() to perform this function, and ensure
      that it panic()s if it is used inappropriately.  Convert everyone
      over, including OMAP.
      
      As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot
      with this change.  Mark this option as BROKEN and make it depend on
      BROKEN.  OMAP needs to be fixed, or 137d105d (ARM: OMAP4: Fix
      errata i688 with MPU interconnect barriers.) reverted until such
      time it can be fixed correctly.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      716a3dc2
  21. 24 12月, 2011 1 次提交
    • D
      ARM: 7197/1: errata: Remove SMP dependency for erratum 751472 · ba90c516
      Dave Martin 提交于
      Activation conditions for a workaround should not be encoded in the
      workaround's direct dependencies if this makes otherwise reasonable
      configuration choices impossible.
      
      This patches uses the SMP/UP patching facilities instead to compile
      out the workaround if the configuration means that it is definitely
      not needed.
      
      This means that configs for buggy silicon can simply select
      ARM_ERRATA_751472, without preventing a UP kernel from being built
      or duplicatiing knowledge about when to activate the workaround.
      This seems the correct way to do things, because the erratum is a
      property of the silicon, irrespective of what the kernel config
      happens to be.
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ba90c516
  22. 19 12月, 2011 1 次提交
  23. 11 12月, 2011 1 次提交
  24. 09 12月, 2011 2 次提交
    • T
      memblock: s/memblock_analyze()/memblock_allow_resize()/ and update users · 1aadc056
      Tejun Heo 提交于
      The only function of memblock_analyze() is now allowing resize of
      memblock region arrays.  Rename it to memblock_allow_resize() and
      update its users.
      
      * The following users remain the same other than renaming.
      
        arm/mm/init.c::arm_memblock_init()
        microblaze/kernel/prom.c::early_init_devtree()
        powerpc/kernel/prom.c::early_init_devtree()
        openrisc/kernel/prom.c::early_init_devtree()
        sh/mm/init.c::paging_init()
        sparc/mm/init_64.c::paging_init()
        unicore32/mm/init.c::uc32_memblock_init()
      
      * In the following users, analyze was used to update total size which
        is no longer necessary.
      
        powerpc/kernel/machine_kexec.c::reserve_crashkernel()
        powerpc/kernel/prom.c::early_init_devtree()
        powerpc/mm/init_32.c::MMU_init()
        powerpc/mm/tlb_nohash.c::__early_init_mmu()  
        powerpc/platforms/ps3/mm.c::ps3_mm_add_memory()
        powerpc/platforms/embedded6xx/wii.c::wii_memory_fixups()
        sh/kernel/machine_kexec.c::reserve_crashkernel()
      
      * x86/kernel/e820.c::memblock_x86_fill() was directly setting
        memblock_can_resize before populating memblock and calling analyze
        afterwards.  Call memblock_allow_resize() before start populating.
      
      memblock_can_resize is now static inside memblock.c.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      1aadc056
    • T
      memblock: Kill memblock_init() · fe091c20
      Tejun Heo 提交于
      memblock_init() initializes arrays for regions and memblock itself;
      however, all these can be done with struct initializers and
      memblock_init() can be removed.  This patch kills memblock_init() and
      initializes memblock with struct initializer.
      
      The only difference is that the first dummy entries don't have .nid
      set to MAX_NUMNODES initially.  This doesn't cause any behavior
      difference.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      fe091c20