1. 28 1月, 2008 1 次提交
  2. 25 1月, 2008 1 次提交
  3. 17 10月, 2007 1 次提交
  4. 13 10月, 2007 1 次提交
  5. 20 7月, 2007 1 次提交
    • P
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt 提交于
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      20c2df83
  6. 21 5月, 2007 1 次提交
  7. 22 4月, 2007 1 次提交
    • B
      [ARM] 4326/1: S3C24XX: fix sparse errors in DMA code · a7717435
      Ben Dooks 提交于
      Fix the following sparse errors in arch/arm/plat-s3c24xx/dma.c:
      
      dma.c:47:30: warning: symbol 'dma_sel' was not declared. Should it be static?
      dma.c:883:6: warning: symbol 's3c2410_dma_waitforstop' was not declared. Should it be static?
      dma.c:961:1: warning: symbol 's3c2410_dma_started' was not declared. Should it be static?
      dma.c:1283:12: warning: symbol 's3c24xx_dma_sysclass_init' was not declared. Should it be static?
      dma.c:1295:12: warning: symbol 's3c24xx_dma_sysdev_register' was not declared. Should it be static?
      dma.c:1399:25: warning: symbol 's3c2410_dma_map_channel' was not declared. Should it be static?
      
      The patch makes all the relevant functions static.
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a7717435
  8. 17 2月, 2007 2 次提交
  9. 14 2月, 2007 1 次提交
  10. 12 2月, 2007 1 次提交
  11. 31 12月, 2006 1 次提交
  12. 18 12月, 2006 1 次提交
  13. 08 12月, 2006 1 次提交
  14. 07 10月, 2006 1 次提交
  15. 25 9月, 2006 1 次提交
  16. 31 8月, 2006 1 次提交
  17. 18 8月, 2006 1 次提交
    • B
      [ARM] 3753/1: S3C24XX: DMA fixes · f57e1abd
      Ben Dooks 提交于
      Patch from Ben Dooks
      
      A number of small issues with the S3C24XX DMA have
      cropped up, which this patch fixes. These are:
      
        - check wether we can load another buff in start
        - update state handling in s3c2410_dma_lastxfer
        - only reload in irq if channel is not idle
        - more informative timeout errors (add source)
        - do not call request_irq() with irqs locked
        - added waitforstop function
      
      The patch also adds a S3C2410_DMAOP_STARTED for
      the occasions when the driver wants to ensure that
      the DMA system load state is resynced after loading.
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f57e1abd
  18. 03 7月, 2006 1 次提交
  19. 01 7月, 2006 1 次提交
  20. 26 1月, 2006 1 次提交
  21. 24 7月, 2005 1 次提交
  22. 04 6月, 2005 1 次提交
    • A
      [PATCH] ARM: 2694/1: [s3c2410/dma] release irq properly to fix kernel oops · 105bb269
      Albrecht Dreß 提交于
      Patch from Albrecht Dre
      
      Problem:
      When a module requests a DMA channel via the function s3c2410_dma_request(), this function requests the appropriate irq under the name of the client module. When the client module is unloaded, it calls s3c2410_dma_free() which does not free the irq. Consequently, when e.g. running "cat /proc/interrupts", the irq owner points to freed memory, leading to a kernel oops.
      File:
      linux/arch/arm/mach-s3c2410/dma.c
      Fix:
      trivial, below
      
      Signed-off-by: Albrecht Dre
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      105bb269
  23. 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