1. 08 7月, 2011 1 次提交
    • T
      drivers/virt: introduce Freescale hypervisor management driver · 6db71994
      Timur Tabi 提交于
      Add the drivers/virt directory, which houses drivers that support
      virtualization environments, and add the Freescale hypervisor management
      driver.
      
      The Freescale hypervisor management driver provides several services to
      drivers and applications related to the Freescale hypervisor:
      
      1. An ioctl interface for querying and managing partitions
      
      2. A file interface to reading incoming doorbells
      
      3. An interrupt handler for shutting down the partition upon receiving the
         shutdown doorbell from a manager partition
      
      4. A kernel interface for receiving callbacks when a managed partition
         shuts down.
      Signed-off-by: NTimur Tabi <timur@freescale.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      6db71994
  2. 25 5月, 2011 1 次提交
  3. 24 5月, 2011 1 次提交
  4. 19 5月, 2011 1 次提交
  5. 11 5月, 2011 1 次提交
    • R
      bcma: add Broadcom specific AMBA bus driver · 8369ae33
      Rafał Miłecki 提交于
      Broadcom has released cards based on a new AMBA-based bus type. From a
      programming point of view, this new bus type differs from AMBA and does
      not use AMBA common registers. It also differs enough from SSB. We
      decided that a new bus driver is needed to keep the code clean.
      
      In its current form, the driver detects devices present on the bus and
      registers them in the system. It allows registering BCMA drivers for
      specified bus devices and provides them basic operations. The bus driver
      itself includes two important bus managing drivers: ChipCommon core
      driver and PCI(c) core driver. They are early used to allow correct
      initialization.
      
      Currently code is limited to supporting buses on PCI(e) devices, however
      the driver is designed to be used also on other hosts. The host
      abstraction layer is implemented and already used for PCI(e).
      
      Support for PCI(e) hosts is working and seems to be stable (access to
      80211 core was tested successfully on a few devices). We can still
      optimize it by using some fixed windows, but this can be done later
      without affecting any external code. Windows are just ranges in MMIO
      used for accessing cores on the bus.
      
      Cc: Greg KH <greg@kroah.com>
      Cc: Michael Büsch <mb@bu3sch.de>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: George Kashperko <george@znau.edu.ua>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Andy Botting <andy@andybotting.com>
      Cc: linuxdriverproject <devel@linuxdriverproject.org>
      Cc: linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8369ae33
  6. 14 4月, 2011 2 次提交
  7. 18 2月, 2011 1 次提交
    • O
      drivers: hwspinlock: add framework · bd9a4c7d
      Ohad Ben-Cohen 提交于
      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: NOhad 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: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      bd9a4c7d
  8. 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
  9. 14 1月, 2011 2 次提交
  10. 26 11月, 2010 1 次提交
  11. 05 11月, 2010 1 次提交
  12. 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
  13. 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
  14. 27 7月, 2010 1 次提交
  15. 02 7月, 2010 1 次提交
  16. 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
  17. 08 5月, 2010 1 次提交
  18. 08 2月, 2010 1 次提交
  19. 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
  20. 20 9月, 2009 1 次提交
  21. 29 8月, 2009 1 次提交
  22. 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
  23. 17 6月, 2009 1 次提交
  24. 09 6月, 2009 1 次提交
  25. 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
  26. 29 3月, 2009 1 次提交
  27. 09 1月, 2009 1 次提交
  28. 08 1月, 2009 1 次提交
  29. 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
  30. 24 10月, 2008 1 次提交
  31. 22 10月, 2008 1 次提交
  32. 11 10月, 2008 1 次提交
  33. 17 9月, 2008 1 次提交
  34. 14 8月, 2008 1 次提交
  35. 30 7月, 2008 1 次提交
  36. 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
  37. 21 7月, 2008 1 次提交
  38. 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