1. 15 1月, 2011 1 次提交
    • N
      [SCSI] target: Add LIO target core v4.0.0-rc6 · c66ac9db
      Nicholas Bellinger 提交于
      LIO target is a full featured in-kernel target framework with the
      following feature set:
      
      High-performance, non-blocking, multithreaded architecture with SIMD
      support.
      
      Advanced SCSI feature set:
      
          * Persistent Reservations (PRs)
          * Asymmetric Logical Unit Assignment (ALUA)
          * Protocol and intra-nexus multiplexing, load-balancing and failover (MC/S)
          * Full Error Recovery (ERL=0,1,2)
          * Active/active task migration and session continuation (ERL=2)
          * Thin LUN provisioning (UNMAP and WRITE_SAMExx)
      
      Multiprotocol target plugins
      
      Storage media independence:
      
          * Virtualization of all storage media; transparent mapping of IO to LUNs
          * No hard limits on number of LUNs per Target; maximum LUN size ~750 TB
          * Backstores: SATA, SAS, SCSI, BluRay, DVD, FLASH, USB, ramdisk, etc.
      
      Standards compliance:
      
          * Full compliance with IETF (RFC 3720)
          * Full implementation of SPC-4 PRs and ALUA
      
      Significant code cleanups done by Christoph Hellwig.
      
      [jejb: fix up for new block bdev exclusive interface. Minor fixes from
       Randy Dunlap and Dan Carpenter.]
      Signed-off-by: NNicholas A. Bellinger <nab@linux-iscsi.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      c66ac9db
  2. 14 1月, 2011 1 次提交
  3. 26 11月, 2010 1 次提交
  4. 05 11月, 2010 1 次提交
  5. 11 10月, 2010 1 次提交
    • S
      ieee1394: remove the old IEEE 1394 driver stack · 66fa12c5
      Stefan Richter 提交于
      The drivers
        - ohci1394 (controller driver)
        - ieee1394 (core)
        - dv1394, raw1394, video1394 (userspace ABI)
        - eth1394, sbp2 (protocol drivers)
      are replaced by
        - firewire-ohci (controller driver)
        - firewire-core (core and userspace ABI)
        - firewire-net, firewire-sbp2 (protocol drivers)
      which are more featureful, better performing, and more secure than the older
      drivers; all with a smaller and more modern code base.
      
      The driver firedtv in drivers/media/dvb/firewire/ contains backends to both
      ieee1394 and firewire-core.  Its ieee1394 backend code can be removed in an
      independent commit; firedtv as-is builds and works fine without ieee1394.
      
      The driver pcilynx (an incomplete controller driver) is deleted without
      replacement since PCILynx cards are extremely rare.  Owners of these cards
      use them with the stand-alone bus sniffer driver nosy instead.
      
      The drivers nosy and init_ohci1394_dma which do not interact with either of
      the two IEEE 1394 stacks are not affected by the ieee1394 subsystem removal.
      
      There are still some issues with the newer firewire subsystem compared to
      the older one:
        - The rare and quirky controllers ALi M52xx, Apple UniNorth v1, NVIDIA
          NForce2 are even less well supported by firewire-ohci than by ohci1394.
          I am looking into the M52xx issue.
        - The experimental firewire-net is reportedly less stable than its
          experimental cousin eth1394.
        - Audio playback of a certain group of audio devices (ones based on DICE
          chipset with EAP; supported by prerelease FFADO code) does not work yet.
          This issue is still under investigation.
        - There were some ieee1394 based out-of-the-mainline drivers.  Of them,
          only lisight, an audio driver for iSight webcams, seems still useful.
          Work is underway to reimplement it on top of firewire-core.
      
      All these remainig issues are minor; they should not stand in the way of
      overall better user experience of IEEE 1394 on Linux, together with a
      reduction in support efforts and maintenance burden.  The coexistence of two
      IEEE 1394 kernel driver stacks in the mainline since 2.6.22 shall end now,
      as announced earlier this year.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      66fa12c5
  6. 17 9月, 2010 1 次提交
    • S
      firewire: nosy: fix build when CONFIG_FIREWIRE=N · 8702d33a
      Stefan Richter 提交于
      drivers/firewire/nosy* is a stand-alone driver that does not depend on
      CONFIG_FIREWIRE.  Hence let make descend into drivers/firewire/ also
      if that option is off.
      
      The stand-alone driver drivers/ieee1394/init_ohci1394_dma*  will soon be
      moved into drivers/firewire/ too and will require the same makefile fix.
      
      Side effect:
      As mentioned in https://bugzilla.novell.com/show_bug.cgi?id=586172#c24
      this influences the order in which either firewire-ohci or ohci1394 is
      going to be bound to an OHCI-1394 controller in case of a modular build
      of both drivers if no modprobe blacklist entries are configured.
      However, a user of such a setup cannot expect deterministic behavior
      anyway.  The Kconfig help and the migration guide at
      ieee1394.wiki.kernel.org recommend blacklist entries when a dual
      IEEE 1394 stack build is being used.  (The coexistence period of the two
      stacks is planned to end soon.)
      
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      8702d33a
  7. 27 7月, 2010 1 次提交
  8. 02 7月, 2010 1 次提交
  9. 29 5月, 2010 1 次提交
    • L
      intel_idle: native hardware cpuidle driver for latest Intel processors · 26717172
      Len Brown 提交于
      This EXPERIMENTAL driver supersedes acpi_idle on
      Intel Atom Processors, Intel Core i3/i5/i7 Processors
      and associated Intel Xeon processors.
      
      It does not support the Intel Core2 processor or earlier.
      
      For kernels configured with ACPI, CONFIG_INTEL_IDLE=y
      allows intel_idle to probe before the ACPI processor driver.
      Booting with "intel_idle.max_cstate=0" disables intel_idle
      and the system will fall back on ACPI's "acpi_idle".
      
      Typical Linux distributions load ACPI processor module early,
      making CONFIG_INTEL_IDLE=m not easily useful on ACPI platforms.
      
      intel_idle probes all processors at module_init time.
      Processors that are hot-added later will be limited
      to using C1 in idle.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      26717172
  10. 08 5月, 2010 1 次提交
  11. 08 2月, 2010 1 次提交
  12. 15 1月, 2010 1 次提交
    • M
      vhost_net: a kernel-level virtio server · 3a4d5c94
      Michael S. Tsirkin 提交于
      What it is: vhost net is a character device that can be used to reduce
      the number of system calls involved in virtio networking.
      Existing virtio net code is used in the guest without modification.
      
      There's similarity with vringfd, with some differences and reduced scope
      - uses eventfd for signalling
      - structures can be moved around in memory at any time (good for
        migration, bug work-arounds in userspace)
      - write logging is supported (good for migration)
      - support memory table and not just an offset (needed for kvm)
      
      common virtio related code has been put in a separate file vhost.c and
      can be made into a separate module if/when more backends appear.  I used
      Rusty's lguest.c as the source for developing this part : this supplied
      me with witty comments I wouldn't be able to write myself.
      
      What it is not: vhost net is not a bus, and not a generic new system
      call. No assumptions are made on how guest performs hypercalls.
      Userspace hypervisors are supported as well as kvm.
      
      How it works: Basically, we connect virtio frontend (configured by
      userspace) to a backend. The backend could be a network device, or a tap
      device.  Backend is also configured by userspace, including vlan/mac
      etc.
      
      Status: This works for me, and I haven't see any crashes.
      Compared to userspace, people reported improved latency (as I save up to
      4 system calls per packet), as well as better bandwidth and CPU
      utilization.
      
      Features that I plan to look at in the future:
      - mergeable buffers
      - zero copy
      - scalability tuning: figure out the best threading model to use
      
      Note on RCU usage (this is also documented in vhost.h, near
      private_pointer which is the value protected by this variant of RCU):
      what is happening is that the rcu_dereference() is being used in a
      workqueue item.  The role of rcu_read_lock() is taken on by the start of
      execution of the workqueue item, of rcu_read_unlock() by the end of
      execution of the workqueue item, and of synchronize_rcu() by
      flush_workqueue()/flush_work(). In the future we might need to apply
      some gcc attribute or sparse annotation to the function passed to
      INIT_WORK(). Paul's ack below is for this RCU usage.
      
      (Includes fixes by Alan Cox <alan@linux.intel.com>,
      David L Stevens <dlstevens@us.ibm.com>,
      Chris Wright <chrisw@redhat.com>)
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: N"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a4d5c94
  13. 20 9月, 2009 1 次提交
  14. 29 8月, 2009 1 次提交
  15. 19 6月, 2009 1 次提交
    • R
      LinuxPPS: core support · eae9d2ba
      Rodolfo Giometti 提交于
      This patch adds the kernel side of the PPS support currently named
      "LinuxPPS".
      
      PPS means "pulse per second" and a PPS source is just a device which
      provides a high precision signal each second so that an application can
      use it to adjust system clock time.
      
      Common use is the combination of the NTPD as userland program with a GPS
      receiver as PPS source to obtain a wallclock-time with sub-millisecond
      synchronisation to UTC.
      
      To obtain this goal the userland programs shoud use the PPS API
      specification (RFC 2783 - Pulse-Per-Second API for UNIX-like Operating
      Systems, Version 1.0) which in part is implemented by this patch.  It
      provides a set of chars devices, one per PPS source, which can be used to
      get the time signal.  The RFC's functions can be implemented by accessing
      to these char devices.
      Signed-off-by: NRodolfo Giometti <giometti@linux.it>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eae9d2ba
  16. 17 6月, 2009 1 次提交
  17. 09 6月, 2009 1 次提交
  18. 30 4月, 2009 1 次提交
    • G
      V4L/DVB (11561a): move media after i2c · a357482a
      Guennadi Liakhovetski 提交于
      Currently drivers/media drivers are linked very early - directly after
      base, block, misc, and mfd and before ata, scsi, ide, input, firewire,
      usb, and i2c. This breaks static build of video4linux drivers, that use
      generic CPU i2c adapter drivers and the v4l2-subdev subsystem, because
      during video4linux probing the v4l2-subdev core requires a struct
      i2c_adapter context, which cannot be satisfied before the i2c subsystem is
      initialised. Moving drivers/media after drivers/i2c fixes this problem.
      
      The best way to trigger action is by submitting a patch:-) So, let's see
      what comes out of it - on the one hand I don't see any reason why media
      has to be linked this early, and nobody was able to give me one yesterday
      as this problem has been discussed on linux-media, OTOH, maybe indeed it
      would be better to move i2c the whole way up above media, but that'd be
      much bigger of a change, I think.
      --
      To unsubscribe from this list: send the line "unsubscribe linux-media" in
      the body of a message to majordomo@vger.kernel.org
      More majordomo info at  http://vger.kernel.org/majordomo-info.htmlSigned-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Acked-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a357482a
  19. 29 3月, 2009 1 次提交
  20. 09 1月, 2009 1 次提交
  21. 08 1月, 2009 1 次提交
  22. 19 12月, 2008 1 次提交
    • L
      create drivers/platform/x86/ from drivers/misc/ · 41b16dce
      Len Brown 提交于
      Move x86 platform specific drivers from drivers/misc/
      to a new home under drivers/platform/x86/.
      
      The community has been maintaining x86 vendor-specific
      platform specific drivers under /drivers/misc/ for a few years.
      The oldest ones started life under drivers/acpi.
      They moved out of drivers/acpi/ because they don't actually
      implement the ACPI specification, but either simply
      use ACPI, or implement vendor-specific ACPI extensions.
      
      In the future we anticipate...
      drivers/misc/ will go away.
      other architectures will create drivers/platform/<arch>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      41b16dce
  23. 24 10月, 2008 1 次提交
  24. 22 10月, 2008 1 次提交
  25. 11 10月, 2008 1 次提交
  26. 17 9月, 2008 1 次提交
  27. 14 8月, 2008 1 次提交
  28. 30 7月, 2008 1 次提交
  29. 26 7月, 2008 1 次提交
    • M
      gpiolib: allow user-selection · 7444a72e
      Michael Buesch 提交于
      This patch adds functionality to the gpio-lib subsystem to make it
      possible to enable the gpio-lib code even if the architecture code didn't
      request to get it built in.
      
      The archtitecture code does still need to implement the gpiolib accessor
      functions in its asm/gpio.h file.  This patch adds the implementations for
      x86 and PPC.
      
      With these changes it is possible to run generic GPIO expansion cards on
      every architecture that implements the trivial wrapper functions.  Support
      for more architectures can easily be added.
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Samuel Ortiz <sameo@openedhand.com>
      Cc: Kumar Gala <galak@gate.crashing.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Adrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7444a72e
  30. 21 7月, 2008 1 次提交
  31. 14 7月, 2008 1 次提交
    • D
      drm: reorganise drm tree to be more future proof. · c0e09200
      Dave Airlie 提交于
      With the coming of kernel based modesetting and the memory manager stuff,
      the everything in one directory approach was getting very ugly and
      starting to be unmanageable.
      
      This restructures the drm along the lines of other kernel components.
      
      It creates a drivers/gpu/drm directory and moves the hw drivers into
      subdirectores. It moves the includes into an include/drm, and
      sets up the unifdef for the userspace headers we should be exporting.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      c0e09200
  32. 30 4月, 2008 1 次提交
  33. 10 2月, 2008 1 次提交
  34. 06 2月, 2008 1 次提交
    • D
      gpiolib: add drivers/gpio directory · a9c5fff5
      David Brownell 提交于
      Add an empty drivers/gpio directory for gpiolib infrastructure and GPIO
      expanders.  It will be populated by later patches.
      
      This won't be the only place to hold such gpio_chip code.  Many external chips
      add a few GPIOs as secondary functionality (such as MFD drivers) and platform
      code frequently needs to closely integrate GPIO and IRQ support.
      
      This is placed *early* in the build/link sequence since it's common for other
      drivers to depend on GPIOs to do their work, so they must be initialized early
      in the device_initcall() sequence.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: NJean Delvare <khali@linux-fr.org>
      Cc: Eric Miao <eric.miao@marvell.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Philipp Zabel <philipp.zabel@gmail.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ben Gardner <bgardner@wabtec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9c5fff5
  35. 02 2月, 2008 1 次提交
  36. 31 1月, 2008 1 次提交
  37. 30 1月, 2008 2 次提交
    • B
      x86: early boot debugging via FireWire (ohci1394_dma=early) · f212ec4b
      Bernhard Kaindl 提交于
      This patch adds a new configuration option, which adds support for a new
      early_param which gets checked in arch/x86/kernel/setup_{32,64}.c:setup_arch()
      to decide wether OHCI-1394 FireWire controllers should be initialized and
      enabled for physical DMA access to allow remote debugging of early problems
      like issues ACPI or other subsystems which are executed very early.
      
      If the config option is not enabled, no code is changed, and if the boot
      paramenter is not given, no new code is executed, and independent of that,
      all new code is freed after boot, so the config option can be even enabled
      in standard, non-debug kernels.
      
      With specialized tools, it is then possible to get debugging information
      from machines which have no serial ports (notebooks) such as the printk
      buffer contents, or any data which can be referenced from global pointers,
      if it is stored below the 4GB limit and even memory dumps of of the physical
      RAM region below the 4GB limit can be taken without any cooperation from the
      CPU of the host, so the machine can be crashed early, it does not matter.
      
      In the extreme, even kernel debuggers can be accessed in this way. I wrote
      a small kgdb module and an accompanying gdb stub for FireWire which allows
      to gdb to talk to kgdb using remote remory reads and writes over FireWire.
      
      An version of the gdb stub fore FireWire is able to read all global data
      from a system which is running a a normal kernel without any kernel debugger,
      without any interruption or support of the system's CPU. That way, e.g. the
      task struct and so on can be read and even manipulated when the physical DMA
      access is granted.
      
      A HOWTO is included in this patch, in Documentation/debugging-via-ohci1394.txt
      and I've put a copy online at
      ftp://ftp.suse.de/private/bk/firewire/docs/debugging-via-ohci1394.txt
      
      It also has links to all the tools which are available to make use of it
      another copy of it is online at:
      ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diffSigned-Off-By: NBernhard Kaindl <bk@suse.de>
      Tested-By: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f212ec4b
    • G
      lguest: fix drivers/lguest Makefile entry · 7ea08093
      Glauber de Oliveira Costa 提交于
      Parts depend on CONFIG_LGUEST, not just CONFIG_LGUEST_GUEST
      Signed-off-by: NGlauber de Oliveira Costa <gcosta@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      7ea08093
  38. 23 10月, 2007 1 次提交
    • R
      Virtio interface · ec3d41c4
      Rusty Russell 提交于
      This attempts to implement a "virtual I/O" layer which should allow
      common drivers to be efficiently used across most virtual I/O
      mechanisms.  It will no-doubt need further enhancement.
      
      The virtio drivers add buffers to virtio queues; as the buffers are consumed
      the driver "interrupt" callbacks are invoked.
      
      There is also a generic implementation of config space which drivers can query
      to get setup information from the host.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Dor Laor <dor.laor@qumranet.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      ec3d41c4
  39. 18 10月, 2007 1 次提交