1. 13 Apr, 2011 2 commits
  2. 17 Feb, 2011 1 commit
    • Ohad Ben-Cohen's avatar
      drivers: hwspinlock: add framework · bd9a4c7d
      Ohad Ben-Cohen authored
      
      Add a platform-independent hwspinlock framework.
      
      Hardware spinlock devices are needed, e.g., in order to access data
      that is shared between remote processors, that otherwise have no
      alternative mechanism to accomplish synchronization and mutual exclusion
      operations.
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      Cc: Hari Kanigeri <h-kanigeri2@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      bd9a4c7d
  3. 14 Jan, 2011 1 commit
    • Nicholas Bellinger's avatar
      [SCSI] target: Add LIO target core v4.0.0-rc6 · c66ac9db
      Nicholas Bellinger authored
      
      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: default avatarNicholas A. Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      c66ac9db
  4. 13 Jan, 2011 2 commits
  5. 26 Nov, 2010 1 commit
  6. 05 Nov, 2010 1 commit
  7. 11 Oct, 2010 1 commit
    • Stefan Richter's avatar
      ieee1394: remove the old IEEE 1394 driver stack · 66fa12c5
      Stefan Richter authored
      
      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: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      66fa12c5
  8. 16 Sep, 2010 1 commit
    • Stefan Richter's avatar
      firewire: nosy: fix build when CONFIG_FIREWIRE=N · 8702d33a
      Stefan Richter authored
      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: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      8702d33a
  9. 27 Jul, 2010 1 commit
  10. 02 Jul, 2010 1 commit
  11. 28 May, 2010 1 commit
    • Len Brown's avatar
      intel_idle: native hardware cpuidle driver for latest Intel processors · 26717172
      Len Brown authored
      
      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: default avatarLen Brown <len.brown@intel.com>
      26717172
  12. 07 May, 2010 1 commit
  13. 08 Feb, 2010 1 commit
  14. 15 Jan, 2010 1 commit
    • Michael S. Tsirkin's avatar
      vhost_net: a kernel-level virtio server · 3a4d5c94
      Michael S. Tsirkin authored
      
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a4d5c94
  15. 19 Sep, 2009 1 commit
  16. 28 Aug, 2009 1 commit
  17. 18 Jun, 2009 1 commit
    • Rodolfo Giometti's avatar
      LinuxPPS: core support · eae9d2ba
      Rodolfo Giometti authored
      
      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: default avatarRodolfo 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: default avatarAlan 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eae9d2ba
  18. 17 Jun, 2009 1 commit
  19. 09 Jun, 2009 1 commit
  20. 29 Apr, 2009 1 commit
    • Guennadi Liakhovetski's avatar
      V4L/DVB (11561a): move media after i2c · a357482a
      Guennadi Liakhovetski authored
      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.html
      
      Signed-off-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Acked-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      a357482a
  21. 28 Mar, 2009 1 commit
  22. 08 Jan, 2009 1 commit
  23. 07 Jan, 2009 1 commit
  24. 19 Dec, 2008 1 commit
    • Len Brown's avatar
      create drivers/platform/x86/ from drivers/misc/ · 41b16dce
      Len Brown authored
      
      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: default avatarLen Brown <len.brown@intel.com>
      41b16dce
  25. 24 Oct, 2008 1 commit
  26. 22 Oct, 2008 1 commit
  27. 10 Oct, 2008 1 commit
  28. 17 Sep, 2008 1 commit
  29. 14 Aug, 2008 1 commit
  30. 30 Jul, 2008 1 commit
  31. 25 Jul, 2008 1 commit
    • Michael Buesch's avatar
      gpiolib: allow user-selection · 7444a72e
      Michael Buesch authored
      
      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: default avatarMichael 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7444a72e
  32. 20 Jul, 2008 1 commit
  33. 14 Jul, 2008 1 commit
    • Dave Airlie's avatar
      drm: reorganise drm tree to be more future proof. · c0e09200
      Dave Airlie authored
      
      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: default avatarDave Airlie <airlied@redhat.com>
      c0e09200
  34. 30 Apr, 2008 1 commit
  35. 09 Feb, 2008 1 commit
  36. 05 Feb, 2008 1 commit
    • David Brownell's avatar
      gpiolib: add drivers/gpio directory · a9c5fff5
      David Brownell authored
      
      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: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: default avatarJean 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a9c5fff5
  37. 02 Feb, 2008 1 commit
  38. 30 Jan, 2008 1 commit