1. 24 5月, 2007 1 次提交
  2. 22 5月, 2007 1 次提交
    • A
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan 提交于
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      
      Cross-compile tested on
      
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	arm
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	m68k
      	mips
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	um-x86_64
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      
      as well as my two usual configs.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8edc6e0
  3. 21 5月, 2007 2 次提交
  4. 19 5月, 2007 9 次提交
  5. 15 5月, 2007 10 次提交
  6. 10 5月, 2007 1 次提交
    • R
      Add suspend-related notifications for CPU hotplug · 8bb78442
      Rafael J. Wysocki 提交于
      Since nonboot CPUs are now disabled after tasks and devices have been
      frozen and the CPU hotplug infrastructure is used for this purpose, we need
      special CPU hotplug notifications that will help the CPU-hotplug-aware
      subsystems distinguish normal CPU hotplug events from CPU hotplug events
      related to a system-wide suspend or resume operation in progress.  This
      patch introduces such notifications and causes them to be used during
      suspend and resume transitions.  It also changes all of the
      CPU-hotplug-aware subsystems to take these notifications into consideration
      (for now they are handled in the same way as the corresponding "normal"
      ones).
      
      [oleg@tv-sign.ru: cleanups]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bb78442
  7. 09 5月, 2007 3 次提交
    • R
      IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters · 225c7b1f
      Roland Dreier 提交于
      Add an InfiniBand driver for Mellanox ConnectX adapters.  Because
      these adapters can also be used as ethernet NICs and Fibre Channel 
      HBAs, the driver is split into two modules: 
       
        mlx4_core: Handles low-level things like device initialization and 
          processing firmware commands.  Also controls resource allocation 
          so that the InfiniBand, ethernet and FC functions can share a 
          device without stepping on each other. 
       
        mlx4_ib: Handles InfiniBand-specific things; plugs into the 
          InfiniBand midlayer. 
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      225c7b1f
    • R
      IB/uverbs: Export ib_umem_get()/ib_umem_release() to modules · f7c6a7b5
      Roland Dreier 提交于
      Export ib_umem_get()/ib_umem_release() and put low-level drivers in
      control of when to call ib_umem_get() to pin and DMA map userspace,
      rather than always calling it in ib_uverbs_reg_mr() before calling the
      low-level driver's reg_user_mr method.
      
      Also move these functions to be in the ib_core module instead of
      ib_uverbs, so that driver modules using them do not depend on
      ib_uverbs.
      
      This has a number of advantages:
       - It is better design from the standpoint of making generic code a
         library that can be used or overridden by device-specific code as
         the details of specific devices dictate.
       - Drivers that do not need to pin userspace memory regions do not
         need to take the performance hit of calling ib_mem_get().  For
         example, although I have not tried to implement it in this patch,
         the ipath driver should be able to avoid pinning memory and just
         use copy_{to,from}_user() to access userspace memory regions.
       - Buffers that need special mapping treatment can be identified by
         the low-level driver.  For example, it may be possible to solve
         some Altix-specific memory ordering issues with mthca CQs in
         userspace by mapping CQ buffers with extra flags.
       - Drivers that need to pin and DMA map userspace memory for things
         other than memory regions can use ib_umem_get() directly, instead
         of hacks using extra parameters to their reg_phys_mr method.  For
         example, the mlx4 driver that is pending being merged needs to pin
         and DMA map QP and CQ buffers, but it does not need to create a
         memory key for these buffers.  So the cleanest solution is for mlx4
         to call ib_umem_get() in the create_qp and create_cq methods.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      f7c6a7b5
    • J
      inode numbering: change libfs sb creation routines to avoid collisions with their root inodes · 1a1c9bb4
      Jeff Layton 提交于
      This patch makes it so that simple_fill_super and get_sb_pseudo assign their
      root inodes to be number 1.  It also fixes up a couple of callers of
      simple_fill_super that were passing in files arrays that had an index at
      number 1, and adds a warning for any caller that sends in such an array.
      
      It would have been nice to have made it so that it wasn't possible to make
      such a collision, but some callers need to be able to control what inode
      number their entries get, so I think this is the best that can be done.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1a1c9bb4
  8. 07 5月, 2007 5 次提交
    • R
      IB: Return "maybe missed event" hint from ib_req_notify_cq() · ed23a727
      Roland Dreier 提交于
      The semantics defined by the InfiniBand specification say that
      completion events are only generated when a completions is added to a
      completion queue (CQ) after completion notification is requested.  In
      other words, this means that the following race is possible:
      
      	while (CQ is not empty)
      		ib_poll_cq(CQ);
      	// new completion is added after while loop is exited
      	ib_req_notify_cq(CQ);
      	// no event is generated for the existing completion
      
      To close this race, the IB spec recommends doing another poll of the
      CQ after requesting notification.
      
      However, it is not always possible to arrange code this way (for
      example, we have found that NAPI for IPoIB cannot poll after
      requesting notification).  Also, some hardware (eg Mellanox HCAs)
      actually will generate an event for completions added before the call
      to ib_req_notify_cq() -- which is allowed by the spec, since there's
      no way for any upper-layer consumer to know exactly when a completion
      was really added -- so the extra poll of the CQ is just a waste.
      
      Motivated by this, we add a new flag "IB_CQ_REPORT_MISSED_EVENTS" for
      ib_req_notify_cq() so that it can return a hint about whether the a
      completion may have been added before the request for notification.
      The return value of ib_req_notify_cq() is extended so:
      
      	 < 0	means an error occurred while requesting notification
      	== 0	means notification was requested successfully, and if
      		IB_CQ_REPORT_MISSED_EVENTS was passed in, then no
      		events were missed and it is safe to wait for another
      		event.
      	 > 0	is only returned if IB_CQ_REPORT_MISSED_EVENTS was
      		passed in.  It means that the consumer must poll the
      		CQ again to make sure it is empty to avoid the race
      		described above.
      
      We add a flag to enable this behavior rather than turning it on
      unconditionally, because checking for missed events may incur
      significant overhead for some low-level drivers, and consumers that
      don't care about the results of this test shouldn't be forced to pay
      for the test.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      ed23a727
    • M
      IB: Add CQ comp_vector support · f4fd0b22
      Michael S. Tsirkin 提交于
      Add a num_comp_vectors member to struct ib_device and extend
      ib_create_cq() to pass in a comp_vector parameter -- this parallels
      the userspace libibverbs API.  Update all hardware drivers to set
      num_comp_vectors to 1 and have all ULPs pass 0 for the comp_vector
      value.  Pass the value of num_comp_vectors to userspace rather than
      hard-coding a value of 1.
      
      We want multiple CQ event vector support (via MSI-X or similar for
      adapters that can generate multiple interrupts), but it's not clear
      how many vectors we want, or how we want to deal with policy issues
      such as how to decide which vector to use or how to set up interrupt
      affinity.  This patch is useful for experimenting, since no core
      changes will be necessary when updating a driver to support multiple
      vectors, and we know that we want to make at least these changes
      anyway.
      Signed-off-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      f4fd0b22
    • R
      IB/ipath: Fix a race condition when generating ACKs · 154257f3
      Ralph Campbell 提交于
      Fix a problem where simple ACKs can be sent ahead of RDMA read
      responses thus implicitly NAKing the RDMA read.
      Signed-off-by: NRalph Campbell <ralph.cambpell@qlogic.com>
      Signed-off-by: NRobert Walsh <robert.walsh@qlogic.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      154257f3
    • R
      IB/ipath: Fix two more spin lock problems · 6ed89b95
      Ralph Campbell 提交于
      Fix a missing unlock in ipath_rc_rcv_resp() and remove an extra unlock
      from ipath_rc_rcv_error().
      Signed-off-by: NRalph Campbell <ralph.campbell@qlogic.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      6ed89b95
    • S
      RDMA/cxgb3: Support for new abort logic · aff9e39d
      Steve Wise 提交于
      The HW now posts 2 ABORT_RPL and/or PEER_ABORT_REQ messages.  We need
      to handle them by silenty dropping the 1st but mark that we're ready
      for the final message.  This plugs some close races between the uP and
      HW.  Also update the minimum required firmware version.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      aff9e39d
  9. 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
  10. 02 5月, 2007 1 次提交
  11. 01 5月, 2007 6 次提交