1. 01 5月, 2010 1 次提交
  2. 30 4月, 2010 1 次提交
  3. 29 4月, 2010 4 次提交
  4. 28 4月, 2010 15 次提交
  5. 27 4月, 2010 12 次提交
  6. 25 4月, 2010 7 次提交
    • A
      e100: Fix the TX workqueue race · 401da6ae
      Alan Cox 提交于
      Nothing stops the workqueue being left to run in parallel with close or a
      few other operations. This causes double unmaps and the like.
      
      See kerneloops.org #1041230 for an example
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      401da6ae
    • D
      VMware Balloon driver · 453dc659
      Dmitry Torokhov 提交于
      This is a standalone version of VMware Balloon driver.  Ballooning is a
      technique that allows hypervisor dynamically limit the amount of memory
      available to the guest (with guest cooperation).  In the overcommit
      scenario, when hypervisor set detects that it needs to shuffle some
      memory, it instructs the driver to allocate certain number of pages, and
      the underlying memory gets returned to the hypervisor.  Later hypervisor
      may return memory to the guest by reattaching memory to the pageframes and
      instructing the driver to "deflate" balloon.
      
      We are submitting a standalone driver because KVM maintainer (Avi Kivity)
      expressed opinion (rightly) that our transport does not fit well into
      virtqueue paradigm and thus it does not make much sense to integrate with
      virtio.
      
      There were also some concerns whether current ballooning technique is the
      right thing.  If there appears a better framework to achieve this we are
      prepared to evaluate and switch to using it, but in the meantime we'd like
      to get this driver upstream.
      
      We want to get the driver accepted in distributions so that users do not
      have to deal with an out-of-tree module and many distributions have
      "upstream first" requirement.
      
      The driver has been shipping for a number of years and users running on
      VMware platform will have it installed as part of VMware Tools even if it
      will not come from a distribution, thus there should not be additional
      risk in pulling the driver into mainline.  The driver will only activate
      if host is VMware so everyone else should not be affected at all.
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      453dc659
    • A
      w1: fix omap 1-wire driver compilation · 81fa08f2
      Amit Kucheria 提交于
      Fixes the following error:
      
        drivers/w1/masters/omap_hdq.c: In function 'hdq_wait_for_flag':
        drivers/w1/masters/omap_hdq.c:137: error: implicit declaration of function 'schedule_timeout_uninterruptible'
        drivers/w1/masters/omap_hdq.c: In function 'hdq_write_byte':
        drivers/w1/masters/omap_hdq.c:177: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function)
        drivers/w1/masters/omap_hdq.c:177: error: (Each undeclared identifier is reported only once
        drivers/w1/masters/omap_hdq.c:177: error: for each function it appears in.)
        drivers/w1/masters/omap_hdq.c:177: error: implicit declaration of function 'schedule_timeout'
        drivers/w1/masters/omap_hdq.c: In function 'hdq_isr':
        drivers/w1/masters/omap_hdq.c:221: error: 'TASK_NORMAL' undeclared (first use in this function)
        drivers/w1/masters/omap_hdq.c: In function 'omap_hdq_break':
        drivers/w1/masters/omap_hdq.c:316: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function)
      Signed-off-by: NAmit Kucheria <amit.kucheria@canonical.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      81fa08f2
    • I
      w1: w1 temp: fix negative termperature calculation · 9a6a1ecd
      Ian Dall 提交于
      Fix regression caused by commit 507e2fba
      ("w1: w1 temp calculation overflow fix") whereby negative temperatures for
      the DS18B20 are not converted properly.
      
      When the temperature exceeds 32767 milli-degrees the temperature overflows
      to -32768 millidegrees.  These are both well within the -55 - +125 degree
      range for the sensor.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=12646Signed-of-by: NIan Dall <ian@beware.dropbear.id.au>
      Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
      Tested-by: NKarsten Elfenbein <kelfe@gmx.de>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9a6a1ecd
    • T
      drivers/video/efifb.c: support framebuffer for NVIDIA 9400M in MacBook Pro 5,1 · 8a3bdfe6
      Thomas Gerlach 提交于
      Description of patch:
      ---------------------
      
      This is a patch for the EFI framebuffer driver to enable the framebuffer
      of the NVIDIA 9400M as found in MacBook Pro (MBP) 5,1 and up.  The
      framebuffer of the NVIDIA graphic cards are located at the following
      addresses in memory:
      
      9400M:    0xC0010000
      9600M GT: 0xB0030000
      
      The patch delivered right here only provides the memory location of the
      framebuffer of the 9400M device.  The 9600M GT is not covered.  It is
      assumed that the 9400M is used when powered up the MBP.
      
      The information which device is currently powered and in use is stored in
      the 64 bytes large EFI variable "gpu-power-prefs".  More specifically,
      byte 0x3B indicates whether 9600M GT (0x00) or 9400M (0x01) is online.
      
      The PCI bus IDs are the following:
      9400M:    PCI 03:00:00
      9600M GT: PCI 02:00:00
      
      The EFI variables can be easily read-out and manipulated with "rEFIt", an
      MBP specific bootloader tool.  For more information on how handle rEFIt
      and EFI variables please consult "http://refit.sourceforge.net" and
      "http://ubuntuforums.org/archive/index.php/t-1076879.html".
      
      IMPORTANT NOTE: The information on how to activate the 9400M device given
      at "ubuntuforums.org" is not correct, since it states
      
      gpu-power-prefs[0x3B] = 0x00 -> 9400M (PCI 02:00:00)
      gpu-power-prefs[0x3B] = 0x01 -> 9600M GT (PCI 03:00:00)
      
      Actually, the assignment of the values and the PCI bus IDs are swapped.
      
      Suggestions:
      ------------
      
      To cover framebuffers of both 9400M and 9600M GT, I would suggest to
      implement a conditional on "gpu-power-prefs".  Depending on the value of
      byte 0x3B, the according framebuffer is selected.  However, this requires
      kernel access to the EFI variables.
      
      [akpm@linux-foundation.org: rename optname, per Peter Jones]
      Signed-off-by: NThomas Gerlach <t.m.gerlach@freenet.de>
      Acked-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8a3bdfe6
    • T
      lis3: add support for HP ProBook 432x/442x/452x/522x · 9bd14a83
      Takashi Iwai 提交于
      Correct axis-mappings for new HP ProBook laptops.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Acked-by: NEric Piel <eric.piel@tremplin-utc.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9bd14a83
    • P
      mtd: fix Orion NAND driver compilation with ARM OABI · a88a2b88
      Paulius Zaleckas 提交于
      We must tell GCC to use even register for variable passed to ldrd
      instruction.  Without this patch GCC 4.2.1 puts this variable to r2/r3 on
      EABI and r3/r4 on OABI, so force it to r2/r3.  This does not change
      anything when EABI and OABI compilation works OK.
      
      Without this patch and with OABI I get:
      
          CC      drivers/mtd/nand/orion_nand.o
        /tmp/ccMkwOCs.s: Assembler messages:
        /tmp/ccMkwOCs.s:63: Error: first destination register must be even -- `ldrd r3,[ip]'
        make[5]: *** [drivers/mtd/nand/orion_nand.o] Error 1
      Signed-off-by: NPaulius Zaleckas <paulius.zaleckas@gmail.com>
      Acked-by: NNicolas Pitre <nico@fluxnic.net>
      Acked-by: NArtem Bityutskiy <dedekind1@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Jamie Lokier <jamie@shareable.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a88a2b88