1. 14 2月, 2007 1 次提交
  2. 13 2月, 2007 4 次提交
  3. 12 2月, 2007 2 次提交
    • J
      [PATCH] disable init/initramfs.c: architectures · 67d38229
      Jean-Paul Saman 提交于
      Update all arch/*/kernel/vmlinux.lds.S to not include space for initramfs
      when CONFIG_BLK_DEV_INITRAMFS is not selected.  This saves another 4 kbytes
      on most platfoms (some reserve PAGE_SIZE for initramfs).
      Signed-off-by: NJean-Paul Saman <jean-paul.saman@nxp.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      67d38229
    • C
      [PATCH] Set CONFIG_ZONE_DMA for arches with GENERIC_ISA_DMA · 5ac6da66
      Christoph Lameter 提交于
      As Andi pointed out: CONFIG_GENERIC_ISA_DMA only disables the ISA DMA
      channel management.  Other functionality may still expect GFP_DMA to
      provide memory below 16M.  So we need to make sure that CONFIG_ZONE_DMA is
      set independent of CONFIG_GENERIC_ISA_DMA.  Undo the modifications to
      mm/Kconfig where we made ZONE_DMA dependent on GENERIC_ISA_DMA and set
      theses explicitly in each arches Kconfig.
      
      Reviews must occur for each arch in order to determine if ZONE_DMA can be
      switched off.  It can only be switched off if we know that all devices
      supported by a platform are capable of performing DMA transfers to all of
      memory (Some arches already support this: uml, avr32, sh sh64, parisc and
      IA64/Altix).
      
      In order to switch ZONE_DMA off conditionally, one would have to establish
      a scheme by which one can assure that no drivers are enabled that are only
      capable of doing I/O to a part of memory, or one needs to provide an
      alternate means of performing an allocation from a specific range of memory
      (like provided by alloc_pages_range()) and insure that all drivers use that
      call.  In that case the arches alloc_dma_coherent() may need to be modified
      to call alloc_pages_range() instead of relying on GFP_DMA.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ac6da66
  4. 09 2月, 2007 2 次提交
    • R
      [PPC] Fix compile error for e500 core based processors · 862a7284
      Rojhalat Ibrahim 提交于
      We get the following compiler error:
      
        CC      arch/ppc/kernel/ppc_ksyms.o
      arch/ppc/kernel/ppc_ksyms.c:275: error: '__mtdcr' undeclared here (not in a function)
      arch/ppc/kernel/ppc_ksyms.c:275: warning: type defaults to 'int' in declaration of '__mtdcr'
      arch/ppc/kernel/ppc_ksyms.c:276: error: '__mfdcr' undeclared here (not in a function)
      arch/ppc/kernel/ppc_ksyms.c:276: warning: type defaults to 'int' in declaration of '__mfdcr'
      make[1]: *** [arch/ppc/kernel/ppc_ksyms.o] Error 1
      
      This is due to the EXPORT_SYMBOL for __mtdcr/__mfdcr not having the proper CONFIG protection
      Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      862a7284
    • K
      [POWERPC] Fix is_power_of_4(x) compile error · 8dabba5d
      Kumar Gala 提交于
      When building an 85xx kernel we get:
      
        CC      arch/powerpc/mm/pgtable_32.o
      arch/powerpc/mm/pgtable_32.c: In function 'io_block_mapping':
      arch/powerpc/mm/pgtable_32.c:330: error: expected identifier before '(' token
      arch/powerpc/mm/pgtable_32.c:330: error: expected statement before ')' token
      
      The is_power_of_2(x) fixup patch left an extra ')' on the is_power_of_4 macro.
      There is a similiar issue on the arch/ppc side.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      8dabba5d
  5. 08 2月, 2007 3 次提交
  6. 07 2月, 2007 4 次提交
  7. 24 1月, 2007 1 次提交
  8. 14 12月, 2006 1 次提交
    • R
      [PATCH] getting rid of all casts of k[cmz]alloc() calls · 5cbded58
      Robert P. J. Day 提交于
      Run this:
      
      	#!/bin/sh
      	for f in $(grep -Erl "\([^\)]*\) *k[cmz]alloc" *) ; do
      	  echo "De-casting $f..."
      	  perl -pi -e "s/ ?= ?\([^\)]*\) *(k[cmz]alloc) *\(/ = \1\(/" $f
      	done
      
      And then go through and reinstate those cases where code is casting pointers
      to non-pointers.
      
      And then drop a few hunks which conflicted with outstanding work.
      
      Cc: Russell King <rmk@arm.linux.org.uk>, Ian Molton <spyro@f2s.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Paul Fulghum <paulkf@microgate.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Karsten Keil <kkeil@suse.de>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Cc: Jaroslav Kysela <perex@suse.cz>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cbded58
  9. 13 12月, 2006 1 次提交
  10. 09 12月, 2006 3 次提交
  11. 08 12月, 2006 1 次提交
    • B
      [POWERPC] Fix mmap of PCI resource with hack for X · 396a1a58
      Benjamin Herrenschmidt 提交于
      The powerpc version of pci_resource_to_user() and associated hooks
      used by /proc/bus/pci and /sys/bus/pci mmap have been broken for some
      time on machines that don't have a 1:1 mapping of devices (basically
      on non-PowerMacs) and have PCI devices above 32 bits.
      
      This attempts to fix it as well as possible.
      
      The rule is supposed to be that pci_resource_to_user() always converts
      the resources back into a BAR values since that's what the /proc
      interface was supposed to deal with. However, for X to work on
      platforms where PCI MMIO is not mapped 1:1, it became a habit of
      platforms like powerpc to pass "fixed up" values there since X expects
      to be able to use values from /proc/bus/pci/devices as offsets to mmap
      of /dev/mem...
      
      So we keep that contraption here, causing also /sys/*/resource to
      expose fully absolute MMIO addresses instead of BAR values, which is
      ugly, but should still work as long as those are only used to calculate
      alignment within a page.
      
      X is still broken when built 32 bits on machines where PCI MMIO can be
      above 32-bit space unfortunately.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      396a1a58
  12. 07 12月, 2006 1 次提交
  13. 06 12月, 2006 1 次提交
  14. 04 12月, 2006 6 次提交
  15. 30 11月, 2006 1 次提交
  16. 29 11月, 2006 1 次提交
  17. 13 11月, 2006 1 次提交
  18. 01 11月, 2006 1 次提交
  19. 28 10月, 2006 1 次提交
  20. 25 10月, 2006 3 次提交
    • B
      [POWERPC] Support feature fixups in vdso's · 0909c8c2
      Benjamin Herrenschmidt 提交于
      This patch reworks the feature fixup mecanism so vdso's can be fixed up.
      The main issue was that the construct:
      
              .long   label  (or .llong on 64 bits)
      
      will not work in the case of a shared library like the vdso. It will
      generate an empty placeholder in the fixup table along with a reloc,
      which is not something we can deal with in the vdso.
      
      The idea here (thanks Alan Modra !) is to instead use something like:
      
      1:
              .long   label - 1b
      
      That is, the feature fixup tables no longer contain addresses of bits of
      code to patch, but offsets of such code from the fixup table entry
      itself. That is properly resolved by ld when building the .so's. I've
      modified the fixup mecanism generically to use that method for the rest
      of the kernel as well.
      
      Another trick is that the 32 bits vDSO included in the 64 bits kernel
      need to have a table in the 64 bits format. However, gas does not
      support 32 bits code with a statement of the form:
      
              .llong  label - 1b  (Or even just .llong label)
      
      That is, it cannot emit the right fixup/relocation for the linker to use
      to assign a 32 bits address to an .llong field. Thus, in the specific
      case of the 32 bits vdso built as part of the 64 bits kernel, we are
      using a modified macro that generates:
      
              .long   0xffffffff
              .llong  label - 1b
      
      Note that is assumes that the value is negative which is enforced by
      the .lds (those offsets are always negative as the .text is always
      before the fixup table and gas doesn't support emiting the reloc the
      other way around).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0909c8c2
    • B
      [POWERPC] Consolidate feature fixup code · 42c4aaad
      Benjamin Herrenschmidt 提交于
      There are currently two versions of the functions for applying the
      feature fixups, one for CPU features and one for firmware features. In
      addition, they are both in assembly and with separate implementations
      for 32 and 64 bits. identify_cpu() is also implemented in assembly and
      separately for 32 and 64 bits.
      
      This patch replaces them with a pair of C functions. The call sites are
      slightly moved on ppc64 as well to be called from C instead of from
      assembly, though it's a very small change, and thus shouldn't cause any
      problem.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      42c4aaad
    • O
      [POWERPC] Fix hang in start_ldr if _end or _edata is unaligned · fb20f65a
      Olaf Hering 提交于
      Quick fix for lack of memset(__bss_start, 0, _end-__bss_start) in
      load_kernel().  If edata is unaligned, the loop will overwrite all
      memory because r3 and r4 will never be equal.
      Signed-off-by: NOlaf Hering <olaf@aepfle.de>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fb20f65a
  21. 16 10月, 2006 1 次提交