1. 28 7月, 2010 1 次提交
  2. 17 6月, 2010 1 次提交
  3. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  4. 05 12月, 2009 1 次提交
  5. 07 4月, 2009 2 次提交
  6. 03 1月, 2009 1 次提交
  7. 27 7月, 2008 1 次提交
  8. 10 7月, 2008 1 次提交
  9. 03 5月, 2008 1 次提交
    • S
      [SCSI] aic94xx: fix section mismatch · 7ad4a485
      Sam Ravnborg 提交于
      Fix following warnings:
      WARNING: vmlinux.o(.data+0x17aa88): Section mismatch in reference from the variable asd_pcidev_data to the function .devinit.text:asd_aic9410_setup()
      WARNING: vmlinux.o(.data+0x17aa98): Section mismatch in reference from the variable asd_pcidev_data to the function .devinit.text:asd_aic9410_setup()
      WARNING: vmlinux.o(.data+0x17aaa8): Section mismatch in reference from the variable asd_pcidev_data to the function .devinit.text:asd_aic9405_setup()
      
      asd_pcidev_data is only used by __devinit asd_pci_probe.  So mark is const and
      annotate it __devinitconst to fix the warnings.
      
      [akpm@linux-foundation.org: fix warning]
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      7ad4a485
  10. 08 4月, 2008 2 次提交
  11. 24 2月, 2008 2 次提交
    • J
      [SCSI] aic94xx: fix TMF ascb handling to prevent sequencer panic · e2396f1e
      James Bottomley 提交于
      This is a particularly nasty bug.  The problem is that if any internal
      ascb times out, currently we free it even though it's pending at the
      sequencer.  This results in the sequencer getting terminally confused
      and the error message:
      
      BUG:sequencer:dl:no ascb
      
      Being returned when it comes back.  The way to fix this is to manage
      freeing the ascb from the tasklet completion routine, so that we only
      free it when the sequencer actually returns it.  The code is also
      altered to use on stack completions and transfer variables.
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      e2396f1e
    • J
      [SCSI] aic94xx: plumb in I_T_nexus_reset task management function · 63edf49e
      James Bottomley 提交于
      Currently aic94xx has no exported I_T_nexus_reset function.  This is a
      bit of a huge problem, since sas_ata relies on this function to
      perform an ATA phy reset and also it means that if abort fails, we
      really have no bigger hammer to hit everything with.
      
      Plumb in the I_T_nexus_reset by quiescing the sequencer, sending the
      correct phy reset (link for ATA and hard for SAS) and then carefully
      resuming the sequencer again.
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      63edf49e
  12. 23 2月, 2008 1 次提交
    • J
      [SCSI] aic94xx: fix sequencer hang on error recovery · 91b55060
      James Bottomley 提交于
      The clear nexus I_T and clear nexus I_T_L functions in the aic94xx
      specify the SUSPEND_TX flag which causes the sequencer to be suspended
      until it receives a RESUME_TX.  Unfortunately, nothing ever sends the
      resume, so the sequencer on the link is stopped forever, leading to
      eventual timeouts and I/O errors.
      
      Since clear nexus commands are only executed as part of error recovery,
      it's perfectly fine to keep the sequencer running on the link ... as
      soon as the recovery function is completed, we'll send it the commands
      to retry.
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      91b55060
  13. 18 2月, 2008 1 次提交
    • J
      [SCSI] aic94xx: fix REQ_TASK_ABORT and REQ_DEVICE_RESET · cb84e2d2
      James Bottomley 提交于
      This driver has been failing under heavy load with
      
      aic94xx: escb_tasklet_complete: REQ_TASK_ABORT, reason=0x6
      aic94xx: escb_tasklet_complete: Can't find task (tc=4) to abort!
      
      The second message is because the driver fails to identify the task
      it's being asked to abort.  On closer inpection, there's a thinko in
      the for each task loop over pending tasks in both the REQ_TASK_ABORT
      and REQ_DEVICE_RESET cases where it doesn't look at the task on the
      pending list but at the one on the ESCB (which is always NULL).
      
      Fix by looking at the right task.  Also add a print for the case where
      the pending SCB doesn't have a task attached.
      
      Not sure if this will fix all the problems, but it's a definite first
      step.
      
      Cc: Stable Tree <stable@kernel.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      cb84e2d2
  14. 12 2月, 2008 1 次提交
  15. 26 1月, 2008 1 次提交
  16. 12 1月, 2008 3 次提交
  17. 15 11月, 2007 1 次提交
    • A
      aic94xx_sds: rename FLASH_SIZE · d297a5d5
      Andrew Morton 提交于
      arm:
      
      drivers/scsi/aic94xx/aic94xx_sds.c:381:1: warning: "FLASH_SIZE" redefined
      In file included from include/asm/arch/irqs.h:22,
                       from include/asm/irq.h:4,
                       from include/asm/hardirq.h:6,
                       from include/linux/hardirq.h:7,
                       from include/asm-generic/local.h:5,
                       from include/asm/local.h:1,
                       from include/linux/module.h:19,
                       from include/linux/device.h:21,
                       from include/linux/pci.h:52,
                       from drivers/scsi/aic94xx/aic94xx_sds.c:28:
      include/asm/arch/platform.h:444:1: warning: this is the location of the previous definition
      
      Cc: Gilbert Wu <gilbert_wu@adaptec.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d297a5d5
  18. 16 10月, 2007 1 次提交
  19. 13 10月, 2007 3 次提交
  20. 03 10月, 2007 1 次提交
  21. 26 7月, 2007 1 次提交
  22. 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
  23. 19 7月, 2007 5 次提交
  24. 12 7月, 2007 1 次提交
    • A
      PCI: Change all drivers to use pci_device->revision · 44c10138
      Auke Kok 提交于
      Instead of all drivers reading pci config space to get the revision
      ID, they can now use the pci_device->revision member.
      
      This exposes some issues where drivers where reading a word or a dword
      for the revision number, and adding useless error-handling around the
      read. Some drivers even just read it for no purpose of all.
      
      In devices where the revision ID is being copied over and used in what
      appears to be the equivalent of hotpath, I have left the copy code
      and the cached copy as not to influence the driver's performance.
      
      Compile tested with make all{yes,mod}config on x86_64 and i386.
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Acked-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      44c10138
  25. 23 5月, 2007 1 次提交
    • D
      [SCSI] aic94xx: asd_clear_nexus should fail if the cleared task does not complete · 8fdcf86a
      Darrick J. Wong 提交于
      Every so often, the driver will call asd_clear_nexus to clean out a task.
      It is supposed to be the case that the CLEAR NEXUS does not go on the done
      list until after the task itself has been put on the done list, but for
      some reason this doesn't always happen.  Thus, the
      wait_for_completion_timeout call times out, and we return success.  This
      makes libsas free the task even though the task hasn't completed, leading
      to a BUG_ON message from aic94xx_hwi.c around line 341.  We should return
      failure from asd_clear_nexus so that libsas tries again; at a bare minimum
      it shouldn't be freeing active tasks.  I _think_ this will fix one of
      the SCB timeout crash problems (though I've not been able to reproduce
      it lately...)
      Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      8fdcf86a
  26. 09 5月, 2007 1 次提交
  27. 03 5月, 2007 1 次提交
    • J
      PCI: Cleanup the includes of <linux/pci.h> · 6473d160
      Jean Delvare 提交于
      I noticed that many source files include <linux/pci.h> while they do
      not appear to need it. Here is an attempt to clean it all up.
      
      In order to find all possibly affected files, I searched for all
      files including <linux/pci.h> but without any other occurence of "pci"
      or "PCI". I removed the include statement from all of these, then I
      compiled an allmodconfig kernel on both i386 and x86_64 and fixed the
      false positives manually.
      
      My tests covered 66% of the affected files, so there could be false
      positives remaining. Untested files are:
      
      arch/alpha/kernel/err_common.c
      arch/alpha/kernel/err_ev6.c
      arch/alpha/kernel/err_ev7.c
      arch/ia64/sn/kernel/huberror.c
      arch/ia64/sn/kernel/xpnet.c
      arch/m68knommu/kernel/dma.c
      arch/mips/lib/iomap.c
      arch/powerpc/platforms/pseries/ras.c
      arch/ppc/8260_io/enet.c
      arch/ppc/8260_io/fcc_enet.c
      arch/ppc/8xx_io/enet.c
      arch/ppc/syslib/ppc4xx_sgdma.c
      arch/sh64/mach-cayman/iomap.c
      arch/xtensa/kernel/xtensa_ksyms.c
      arch/xtensa/platform-iss/setup.c
      drivers/i2c/busses/i2c-at91.c
      drivers/i2c/busses/i2c-mpc.c
      drivers/media/video/saa711x.c
      drivers/misc/hdpuftrs/hdpu_cpustate.c
      drivers/misc/hdpuftrs/hdpu_nexus.c
      drivers/net/au1000_eth.c
      drivers/net/fec_8xx/fec_main.c
      drivers/net/fec_8xx/fec_mii.c
      drivers/net/fs_enet/fs_enet-main.c
      drivers/net/fs_enet/mac-fcc.c
      drivers/net/fs_enet/mac-fec.c
      drivers/net/fs_enet/mac-scc.c
      drivers/net/fs_enet/mii-bitbang.c
      drivers/net/fs_enet/mii-fec.c
      drivers/net/ibm_emac/ibm_emac_core.c
      drivers/net/lasi_82596.c
      drivers/parisc/hppb.c
      drivers/sbus/sbus.c
      drivers/video/g364fb.c
      drivers/video/platinumfb.c
      drivers/video/stifb.c
      drivers/video/valkyriefb.c
      include/asm-arm/arch-ixp4xx/dma.h
      sound/oss/au1550_ac97.c
      
      I would welcome test reports for these files. I am fine with removing
      the untested files from the patch if the general opinion is that these
      changes aren't safe. The tested part would still be nice to have.
      
      Note that this patch depends on another header fixup patch I submitted
      to LKML yesterday:
        [PATCH] scatterlist.h needs types.h
        http://lkml.org/lkml/2007/3/01/141Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6473d160
  28. 16 2月, 2007 1 次提交
    • J
      [SCSI] aic94xx: tie driver to the major number of the sequencer firmware · a29fdd3c
      James Bottomley 提交于
      The sequencer firmware file has both a string (currently showing
      V17/10c6) and a number (currently set to 1.1).  It has become apparent
      that Adaptec may issue sequencer firmware in the future which could be
      incompatible with the current driver.  Therefore, the driver will be
      tied to the particular major number of the firmware (i.e. the current
      driver will load any 1.x firmware).  Additionally, the driver will print
      out both the ascii string and the major number, so with this pach the
      current firmware will print out
      
      aic94xx: Found sequencer firmware version 1.1 (V17/10c6)
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      a29fdd3c
  29. 15 2月, 2007 1 次提交