1. 13 2月, 2007 1 次提交
  2. 12 2月, 2007 1 次提交
    • 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
  3. 10 12月, 2006 1 次提交
  4. 09 12月, 2006 1 次提交
    • D
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells 提交于
      This facility provides three entry points:
      
      	ilog2()		Log base 2 of unsigned long
      	ilog2_u32()	Log base 2 of u32
      	ilog2_u64()	Log base 2 of u64
      
      These facilities can either be used inside functions on dynamic data:
      
      	int do_something(long q)
      	{
      		...;
      		y = ilog2(x)
      		...;
      	}
      
      Or can be used to statically initialise global variables with constant values:
      
      	unsigned n = ilog2(27);
      
      When performing static initialisation, the compiler will report "error:
      initializer element is not constant" if asked to take a log of zero or of
      something not reducible to a constant.  They treat negative numbers as
      unsigned.
      
      When not dealing with a constant, they fall back to using fls() which permits
      them to use arch-specific log calculation instructions - such as BSR on
      x86/x86_64 or SCAN on FRV - if available.
      
      [akpm@osdl.org: MMC fix]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Wojtek Kaniewski <wojtekka@toxygen.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f0d1b0b3
  5. 02 10月, 2006 1 次提交
    • A
      [PATCH] Kprobes: Make kprobe modules more portable · 3a872d89
      Ananth N Mavinakayanahalli 提交于
      In an effort to make kprobe modules more portable, here is a patch that:
      
      o Introduces the "symbol_name" field to struct kprobe.
        The symbol->address resolution now happens in the kernel in an
        architecture agnostic manner. 64-bit powerpc users no longer have
        to specify the ".symbols"
      o Introduces the "offset" field to struct kprobe to allow a user to
        specify an offset into a symbol.
      o The legacy mechanism of specifying the kprobe.addr is still supported.
        However, if both the kprobe.addr and kprobe.symbol_name are specified,
        probe registration fails with an -EINVAL.
      o The symbol resolution code uses kallsyms_lookup_name(). So
        CONFIG_KPROBES now depends on CONFIG_KALLSYMS
      o Apparantly kprobe modules were the only legitimate out-of-tree user of
        the kallsyms_lookup_name() EXPORT. Now that the symbol resolution
        happens in-kernel, remove the EXPORT as suggested by Christoph Hellwig
      o Modify tcp_probe.c that uses the kprobe interface so as to make it
        work on multiple platforms (in its earlier form, the code wouldn't
        work, say, on powerpc)
      Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3a872d89
  6. 12 9月, 2006 1 次提交
  7. 11 7月, 2006 1 次提交
    • C
      [PATCH] disallow modular binfmt_elf32 · 289fbc21
      Christoph Hellwig 提交于
      Currently most architectures either always build binfmt_elf32 in the kernel
      image or make it a boolean option.  Only sparc64 and s390 allow to build it
      modularly.  This patch turns the option into a boolean aswell because elf
      requires various symbols that shouldn't be available to modules.  The most
      urgent one is tasklist_lock whos export this patch series kills, but there
      are others like force_sgi aswell.
      
      Note that sparc doesn't allow a modular 32bit a.out handler either, and
      that would be the more useful case as only few people want 32bit sunos
      compatibility and 99.9% of all sparc64 users need 32bit linux native elf
      support.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: N"David S. Miller" <davem@davemloft.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      289fbc21
  8. 20 6月, 2006 1 次提交
    • D
      [SPARC64]: Move over to GENERIC_HARDIRQS. · e18e2a00
      David S. Miller 提交于
      This is the long overdue conversion of sparc64 over to
      the generic IRQ layer.
      
      The kernel image is slightly larger, but the BSS is ~60K
      smaller due to the reduced size of struct ino_bucket.
      
      A lot of IRQ implementation details, including ino_bucket,
      were moved out of asm-sparc64/irq.h and are now private to
      arch/sparc64/kernel/irq.c, and most of the code in irq.c
      totally disappeared.
      
      One thing that's different at the moment is IRQ distribution,
      we do it at enable_irq() time.  If the cpu mask is ALL then
      we round-robin using a global rotating cpu counter, else
      we pick the first cpu in the mask to support single cpu
      targetting.  This is similar to what powerpc's XICS IRQ
      support code does.
      
      This works fine on my UP SB1000, and the SMP build goes
      fine and runs on that machine, but lots of testing on
      different setups is needed.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e18e2a00
  9. 19 4月, 2006 1 次提交
  10. 10 4月, 2006 1 次提交
  11. 27 3月, 2006 1 次提交
    • A
      [PATCH] bitops: sparc64: use generic bitops · 2d78d4be
      Akinobu Mita 提交于
      - remove __{,test_and_}{set,clear,change}_bit() and test_bit()
      - remove ffz()
      - remove __ffs()
      - remove generic_fls()
      - remove generic_fls64()
      - remove sched_find_first_bit()
      - remove ffs()
      
      - unless defined(ULTRA_HAS_POPULATION_COUNT)
      
        - remove generic_hweight{64,32,16,8}()
      
      - remove find_{next,first}{,_zero}_bit()
      - remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
      - remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
      Signed-off-by: NAkinobu Mita <mita@miraclelinux.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2d78d4be
  12. 22 3月, 2006 1 次提交
  13. 20 3月, 2006 3 次提交
  14. 27 2月, 2006 1 次提交
  15. 12 1月, 2006 1 次提交
  16. 09 1月, 2006 1 次提交
  17. 23 12月, 2005 1 次提交
  18. 07 11月, 2005 1 次提交
  19. 08 9月, 2005 1 次提交
    • V
      [PATCH] Kconfig fix (BLK_DEV_FD dependencies) · a08b6b79
      viro@ZenIV.linux.org.uk 提交于
      Sanitized and fixed floppy dependencies: split the messy dependencies for
      BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
      BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
      to arch/*/Kconfig.  While we are at it, fixed several obvious cases when
      BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h
      are *not* going to have floppy.c compile, let alone work).
      
      If you can come up with better name for that ("this architecture might
      have working PC-compatible floppy disk controller"), you are more than
      welcome - just s/ARCH_MAY_HAVE_PC_FDC/your_prefered_name/g in the patch
      below...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a08b6b79
  20. 06 9月, 2005 1 次提交
  21. 31 8月, 2005 1 次提交
  22. 12 7月, 2005 2 次提交
  23. 11 7月, 2005 1 次提交
  24. 09 7月, 2005 1 次提交
  25. 05 7月, 2005 1 次提交
    • R
      [SPARC64/COMPAT]: Add some compat ioctl for ppdev · e7270dec
      Raphael Assenat 提交于
      The following patch adds some ioctls to include/linux/compat_ioctl.h
      to allow using ppdev from the 32 bit user space on sparc64.
      
      This patch also adds the PPDEV option in the sparc64 menu, near Parallel
      printer support in the 'General machine setup' submenu.
      
      All those ioctls seem to be compatible, since (correct me if I'm wrong)
      they dont use the 'long' type. See include/linux/ppdev.h.
      
      The application I used to test the new ioctls only used the following:
      PPEXCL
      PPCLAIM
      PPNEGOT
      PPGETMODES
      PPRCONTROL
      PPWCONTROL
      PPDATADIR
      PPWDATA
      PPRDATA
      
      But I beleive that the other ioctls will work fine.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e7270dec
  26. 24 6月, 2005 1 次提交
  27. 25 4月, 2005 1 次提交
    • A
      [PATCH] missing dependency on sparc64 · e3b9ab1a
      Al Viro 提交于
      CONFIG_HW_CONSOLE selects vt.c; without the stuff pulled by CONFIG_VT it
      will not build.  Normally we get both in drivers/char/Kconfig and there
      HW_CONSOLE depends on VT.  sparc64 does not pull drivers/char/Kconfig
      and has that sutff in arch/sparc64/Kconfig instead.  However, it forgets
      to add the same dependency.  As the result, turning VT off [which is
      possible] will end up with broken build.  For no good reason... 
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e3b9ab1a
  28. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4