1. 18 5月, 2009 1 次提交
  2. 11 5月, 2009 2 次提交
    • D
      intel-iommu: Clean up handling of "caching mode" vs. IOTLB flushing. · 1f0ef2aa
      David Woodhouse 提交于
      As we just did for context cache flushing, clean up the logic around
      whether we need to flush the iotlb or just the write-buffer, depending
      on caching mode.
      
      Fix the same bug in qi_flush_iotlb() that qi_flush_context() had -- it
      isn't supposed to be returning an error; it's supposed to be returning a
      flag which triggers a write-buffer flush.
      
      Remove some superfluous conditional write-buffer flushes which could
      never have happened because they weren't for non-present-to-present
      mapping changes anyway.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      1f0ef2aa
    • D
      intel-iommu: Clean up handling of "caching mode" vs. context flushing. · 4c25a2c1
      David Woodhouse 提交于
      It really doesn't make a lot of sense to have some of the logic to
      handle caching vs. non-caching mode duplicated in qi_flush_context() and
      __iommu_flush_context(), while the return value indicates whether the
      caller should take other action which depends on the same thing.
      
      Especially since qi_flush_context() thought it was returning something
      entirely different anyway.
      
      This patch makes qi_flush_context() and __iommu_flush_context() both
      return void, removes the 'non_present_entry_flush' argument and makes
      the only call site which _set_ that argument to 1 do the right thing.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      4c25a2c1
  3. 29 4月, 2009 1 次提交
    • F
      Intel IOMMU Pass Through Support · 4ed0d3e6
      Fenghua Yu 提交于
      The patch adds kernel parameter intel_iommu=pt to set up pass through
      mode in context mapping entry. This disables DMAR in linux kernel; but
      KVM still runs on VT-d and interrupt remapping still works.
      
      In this mode, kernel uses swiotlb for DMA API functions but other VT-d
      functionalities are enabled for KVM. KVM always uses multi level
      translation page table in VT-d. By default, pass though mode is disabled
      in kernel.
      
      This is useful when people don't want to enable VT-d DMAR in kernel but
      still want to use KVM and interrupt remapping for reasons like DMAR
      performance concern or debug purpose.
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      Acked-by: NWeidong Han <weidong@intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      4ed0d3e6
  4. 22 4月, 2009 10 次提交
  5. 21 4月, 2009 5 次提交
  6. 20 4月, 2009 2 次提交
    • R
      PM/Suspend: Introduce two new platform callbacks to avoid breakage · 6a7c7eaf
      Rafael J. Wysocki 提交于
      Commit 900af0d9 (PM: Change suspend
      code ordering) changed the ordering of suspend code in such a way
      that the platform .prepare() callback is now executed after the
      device drivers' late suspend callbacks have run.  Unfortunately, this
      turns out to break ARM platforms that need to talk via I2C to power
      control devices during the .prepare() callback.
      
      For this reason introduce two new platform suspend callbacks,
      .prepare_late() and .wake(), that will be called just prior to
      disabling non-boot CPUs and right after bringing them back on line,
      respectively, and use them instead of .prepare() and .finish() for
      ACPI suspend.  Make the PM core execute the .prepare() and .finish()
      platform suspend callbacks where they were executed previously (that
      is, right after calling the regular suspend methods provided by
      device drivers and right before executing their regular resume
      methods, respectively).
      
      It is not necessary to make analogous changes to the hibernation
      code and data structures at the moment, because they are only used
      by ACPI platforms.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NLen Brown <len.brown@intel.com>
      6a7c7eaf
    • R
      <linux/seccomp.h> needs to include <linux/errno.h>. · 42a17ad2
      Ralf Baechle 提交于
      <linux/seccomp.h> uses EINVAL so should include <linux/errno.h>.  This
      fixes a build error on 64-bit MIPS if CONFIG_SECCOMP is disabled.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42a17ad2
  7. 18 4月, 2009 1 次提交
    • D
      USB: add reset endpoint operations · 3444b26a
      David Vrabel 提交于
      Wireless USB endpoint state has a sequence number and a current
      window and not just a single toggle bit.  So allow HCDs to provide a
      endpoint_reset method and call this or clear the software toggles as
      required (after a clear halt, set configuration etc.).
      
      usb_settoggle() and friends are then HCD internal and are moved into
      core/hcd.h and all device drivers call usb_reset_endpoint() instead.
      
      If the device endpoint state has been reset (with a clear halt) but
      the host endpoint state has not then subsequent data transfers will
      not complete. The device will only work again after it is reset or
      disconnected.
      Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3444b26a
  8. 17 4月, 2009 4 次提交
    • J
      Driver core: remove pr_fmt() from dynamic_dev_dbg() printk · 7607b1d6
      Jason Baron 提交于
      When pr_fmt() was added to the pr_debug() code, we added it not only to the
      dynamic_pr_debug() function, but also to the dynamic_dev_dbg() funciton.
      However, dev_dbg() doesn't make use of pr_fmt(), so neither should
      dynamic_dev_dbg().
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7607b1d6
    • M
      dynamic debug: resurrect old pr_debug() semantics as pr_devel() · 4ccb4579
      Michael Ellerman 提交于
      pr_debug() used to produce zero code unless DEBUG was #defined.  This is
      now no longer the case in practice[1].
      
      There are places where it's useful to have debugging printks, but we don't
      want them to generate any code in production kernels.
      
      So add a new macro, pr_devel(), for _devel_opment, to provide the old
      semantics, ie.  if the programmer doesn't explicitly enable debugging, no
      code is produced.
      
      [1]: You can turn CONFIG_DYNAMIC_DEBUG off, but it's enabled in at least
           one distro kernel, so it's not really a solution.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Greg Banks <gnb@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4ccb4579
    • M
      Driver Core: early platform driver · 13977091
      Magnus Damm 提交于
      V3 of the early platform driver implementation.
      
      Platform drivers are great for embedded platforms because we can separate
      driver configuration from the actual driver.  So base addresses,
      interrupts and other configuration can be kept with the processor or board
      code, and the platform driver can be reused by many different platforms.
      
      For early devices we have nothing today.  For instance, to configure early
      timers and early serial ports we cannot use platform devices.  This
      because the setup order during boot.  Timers are needed before the
      platform driver core code is available.  The same goes for early printk
      support.  Early in this case means before initcalls.
      
      These early drivers today have their configuration either hard coded or
      they receive it using some special configuration method.  This is working
      quite well, but if we want to support both regular kernel modules and
      early devices then we need to have two ways of configuring the same
      driver.  A single way would be better.
      
      The early platform driver patch is basically a set of functions that allow
      drivers to register themselves and architecture code to locate them and
      probe.  Registration happens through early_param().  The time for the
      probe is decided by the architecture code.
      
      See Documentation/driver-model/platform.txt for more details.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Tejun Heo <htejun@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      13977091
    • A
      ata: Report 16/32bit PIO as best we can · e3cf95dd
      Alan Cox 提交于
      The legacy old IDE ioctl API for this is a bit primitive so we try
      and map stuff sensibly onto it.
      
      - Set PIO over DMA devices to report 32bit
      - Add ability to change the PIO32 settings if the controller permits it
      - Add that functionality into the sff drivers
      - Add that functionality into the VLB legacy driver
      - Turn on the 32bit PIO on the ninja32 and add support there
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      e3cf95dd
  9. 16 4月, 2009 1 次提交
  10. 15 4月, 2009 6 次提交
  11. 14 4月, 2009 7 次提交
    • L
      tty: Update some of the USB kernel doc · 78c5b82e
      Leandro Dorileo 提交于
      Updates some usb_serial_port members documentation.
      Signed-off-by: NLeandro Dorileo <ldorileo@gmail.com>
      Signed-off-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      78c5b82e
    • P
      rcu: Make hierarchical RCU less IPI-happy · ef631b0c
      Paul E. McKenney 提交于
      This patch fixes a hierarchical-RCU performance bug located by Anton
      Blanchard.  The problem stems from a misguided attempt to provide a
      work-around for jiffies-counter failure.  This work-around uses a per-CPU
      n_rcu_pending counter, which is incremented on each call to rcu_pending(),
      which in turn is called from each scheduling-clock interrupt.  Each CPU
      then treats this counter as a surrogate for the jiffies counter, so
      that if the jiffies counter fails to advance, the per-CPU n_rcu_pending
      counter will cause RCU to invoke force_quiescent_state(), which in turn
      will (among other things) send resched IPIs to CPUs that have thus far
      failed to pass through an RCU quiescent state.
      
      Unfortunately, each CPU resets only its own counter after sending a
      batch of IPIs.  This means that the other CPUs will also (needlessly)
      send -another- round of IPIs, for a full N-squared set of IPIs in the
      worst case every three scheduler-clock ticks until the grace period
      finally ends.  It is not reasonable for a given CPU to reset each and
      every n_rcu_pending for all the other CPUs, so this patch instead simply
      disables the jiffies-counter "training wheels", thus eliminating the
      excessive IPIs.
      
      Note that the jiffies-counter IPIs do not have this problem due to
      the fact that the jiffies counter is global, so that the CPU sending
      the IPIs can easily reset things, thus preventing the other CPUs from
      sending redundant IPIs.
      
      Note also that the n_rcu_pending counter remains, as it will continue to
      be used for tracing.  It may also see use to update the jiffies counter,
      should an appropriate kick-the-jiffies-counter API appear.
      Located-by: NAnton Blanchard <anton@au1.ibm.com>
      Tested-by: NAnton Blanchard <anton@au1.ibm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: anton@samba.org
      Cc: akpm@linux-foundation.org
      Cc: dipankar@in.ibm.com
      Cc: manfred@colorfullife.com
      Cc: cl@linux-foundation.org
      Cc: josht@linux.vnet.ibm.com
      Cc: schamp@sgi.com
      Cc: niv@us.ibm.com
      Cc: dvhltc@us.ibm.com
      Cc: ego@in.ibm.com
      Cc: laijs@cn.fujitsu.com
      Cc: rostedt@goodmis.org
      Cc: peterz@infradead.org
      Cc: penberg@cs.helsinki.fi
      Cc: andi@firstfloor.org
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      LKML-Reference: <12396834793575-git-send-email->
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ef631b0c
    • I
      lockdep: warn about lockdep disabling after kernel taint, fix · 27b19565
      Ingo Molnar 提交于
      Impact: build fix for Sparc and s390
      
      Stephen Rothwell reported that the Sparc build broke:
      
       In file included from kernel/panic.c:12:
       include/linux/debug_locks.h: In function '__debug_locks_off':
       include/linux/debug_locks.h:15: error: implicit declaration of function 'xchg'
      
      due to:
      
       9eeba613: lockdep: warn about lockdep disabling after kernel taint
      
      There is some inconsistency between architectures about where exactly
      xchg() is defined.
      
      The traditional place is in system.h but the more logical point for it
      is in atomic.h - where most architectures (especially new ones) have
      it defined. These architecture also still offer it via system.h.
      
      Some, such as Sparc or s390 only have it in asm/system.h and not available
      via asm/atomic.h at all.
      
      Use the widest set of headers in debug_locks.h and also include asm/system.h.
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20090414144317.026498df.sfr@canb.auug.org.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      27b19565
    • S
      intelfb: support i854 · 347486bb
      Stefan Husemann 提交于
      Support the Intel 854 Chipset in fbdev.
      
      We test and use the patch on a Thomson IP1101 IPTV-Box.  On the VGA-Port
      we get a normal signal.
      
      Here is the link to the Mambux-Project: http://www.mambux.de
      
      Cc: Keith Packard <keithp@keithp.com>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: NStefan Husemann <shusemann@googlemail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      347486bb
    • E
      include/linux/fiemap.h: include types.h now that it's exported · 5dec8bfb
      Eric Sandeen 提交于
      Include <linux/types.h> in fiemap.h.  Sam Ravnborg pointed out that this
      was missing in this newly-exported header which uses the __u32 and __u64
      types.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5dec8bfb
    • A
      aio: remove INIT_KIOCTX · 17a5138d
      Alexey Dobriyan 提交于
      Unused after 20dcae32 aka
      "[PATCH] aio: remove kioctx from mm_struct".
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      17a5138d
    • J
      hwmon: sht15 humidity sensor driver · 251eb40f
      Jonathan Cameron 提交于
      Data sheet at:
      http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf
      
      These sensors communicate over a 2 wire bus running a device specific
      protocol.  The complexity of the driver is mainly due to handling the
      substantial delays between requesting a reading and the device pulling the
      data line low to indicate that the data is available.  This is handled by
      an interrupt that is disabled under all other conditions.
      
      I wasn't terribly clear on the best way to handle this, so comments on
      that aspect would be particularly welcome!
      
      Interpretation of the temperature depends on knowing the supply voltage.
      If configured in a board config as a regulator consumer this is obtained
      from the regulator subsystem.  If not it should be provided in the
      platform data.
      
      I've placed this driver in the hwmon subsystem as it is definitely a
      device that may be used for hardware monitoring and with it's relatively
      slow response times (up to 120 millisecs to get a reading) a caching
      strategy certainly seems to make sense!
      Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      251eb40f