1. 29 6月, 2011 3 次提交
  2. 28 6月, 2011 4 次提交
  3. 24 6月, 2011 2 次提交
  4. 22 6月, 2011 5 次提交
  5. 21 6月, 2011 4 次提交
  6. 20 6月, 2011 4 次提交
  7. 19 6月, 2011 1 次提交
  8. 18 6月, 2011 1 次提交
  9. 17 6月, 2011 4 次提交
    • D
      ARM: 6963/1: Thumb-2: Relax relocation requirements for non-function symbols · 9a00318e
      Dave Martin 提交于
      The "Thumb bit" of a symbol is only really meaningful for function
      symbols (STT_FUNC).
      
      However, sometimes a branch is relocated against a non-function
      symbol; for example, PC-relative branches to anonymous assembler
      local symbols are typically fixed up against the start-of-section
      symbol, which is not a function symbol.  Some inline assembler
      generates references of this type, such as fixup code generated by
      macros in <asm/uaccess.h>.
      
      The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24
      interprets this case as an error, because the target symbol appears
      to be an ARM symbol; but this is really not the case, since the
      target symbol is just a base in these cases.  The addend defines
      the precise offset to the target location, but since the addend is
      encoded in a non-interworking Thumb branch instruction, there is no
      explicit Thumb bit in the addend.  Because these instructions never
      interwork, the implied Thumb bit in the addend is 1, and the
      destination is Thumb by definition.
      
      This patch removes the extraneous Thumb bit check for non-function
      symbols, enabling modules containing the affected relocation types
      to be loaded.  No modification to the actual relocation code is
      required, since this code does not take bit[0] of the
      location->destination offset into account in any case.
      
      Function symbols are always checked for interworking conflicts, as
      before.
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9a00318e
    • L
      ARM: 6962/1: mach-h720x: fix build error · 343fda59
      Linus Walleij 提交于
      The h7201/h7202 machines did not build since they define
      ARM_DMA_ZONE_OFFSET but do not select ZONE_DMA. Fix it up by
      selecting ZONE_DMA in their Kconfig.
      
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      343fda59
    • M
      ARM: 6959/1: SMP build fix for entry-macro-multi.S · 2bc58a6f
      Magnus Damm 提交于
      The assembly code in entry-macro-multi.S does not build without
      the include asm/assembler.h in the case of CONFIG_SMP=y.
      
      Fixes the rather theoretical SMP build of mach-shmobile/entry-intc.c:
      
      arch/arm/include/asm/entry-macro-multi.S: Assembler messages:
      arch/arm/include/asm/entry-macro-multi.S:20: Error: bad instruction `alt_smp(test_for_ipi r0,r6,r5,lr)'
      arch/arm/include/asm/entry-macro-multi.S:20: Error: bad instruction `alt_up_b(9997f)'
      make[1]: *** [arch/arm/mach-shmobile/entry-intc.o] Error 1
      make: *** [arch/arm/mach-shmobile] Error 2
      make: *** Waiting for unfinished jobs....
      Signed-off-by: NMagnus Damm <damm@opensource.se>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2bc58a6f
    • K
      xen/setup: Fix for incorrect xen_extra_mem_start. · acd049c6
      Konrad Rzeszutek Wilk 提交于
      The earlier attempts (24bdb0b6)
      at fixing this problem caused other problems to surface (PV guests
      with no PCI passthrough would have SWIOTLB turned on - which meant
      64MB of precious contingous DMA32 memory being eaten up per guest).
      The problem was: "on xen we add an extra memory region at the end of
      the e820, and on this particular machine this extra memory region
      would start below 4g and cross over the 4g boundary:
      
      [0xfee01000-0x192655000)
      
      Unfortunately e820_end_of_low_ram_pfn does not expect an
      e820 layout like that so it returns 4g, therefore initial_memory_mapping
      will map [0 - 0x100000000), that is a memory range that includes some
      reserved memory regions."
      
      The memory range was the IOAPIC regions, and with the 1-1 mapping
      turned on, it would map them as RAM, not as MMIO regions. This caused
      the hypervisor to complain. Fortunately this is experienced only under
      the initial domain so we guard for it.
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      acd049c6
  10. 16 6月, 2011 7 次提交
  11. 15 6月, 2011 2 次提交
  12. 14 6月, 2011 3 次提交