1. 06 5月, 2012 5 次提交
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha · 03cb00b3
      Linus Torvalds 提交于
      Pull alpha fixes from Matt Turner:
       "My alpha tree is back up (after taking quite some time to get my GPG
        key signed).  It contains just some simple fixes."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha:
        alpha: silence 'const' warning in sys_marvel.c
        alpha: include module.h to fix modpost on Tsunami
        alpha: properly define get/set_rtc_time on Marvel/SMP
        alpha: VGA_HOSE depends on VGA_CONSOLE
      03cb00b3
    • J
      TTY: pdc_cons, fix regression in close · 49a5f3cf
      Jiri Slaby 提交于
      The test in pdc_console_tty_close '!tty->count' was always wrong
      because tty->count is decremented after tty->ops->close is called and
      thus can never be zero. Hence the 'then' branch was never executed and
      the timer never deleted.
      
      This did not matter until commit 5dd5bc40 ("TTY: pdc_cons, use
      tty_port").  There we needed to set TTY in tty_port to NULL, but this
      never happened due to the bug above.
      
      So change the test to really trigger at the last close by changing the
      condition to 'tty->count == 1'.
      
      Well, the driver should not touch tty->count at all.  It should use
      tty_port->count and count open count there itself.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Reported-and-tested-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      49a5f3cf
    • L
      Merge tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 1c2f9548
      Linus Torvalds 提交于
      Pull sound sound fixes from Takashi Iwai:
       "As good as nothing exciting here; just a few trivial fixes for various
        ASoC stuff."
      
      * tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ASoC: omap-pcm: Free dma buffers in case of error.
        ASoC: s3c2412-i2s: Fix dai registration
        ASoC: wm8350: Don't use locally allocated codec struct
        ASoC: tlv312aic23: unbreak resume
        ASoC: bf5xx-ssm2602: Set DAI format
        ASoC: core: check of_property_count_strings failure
        ASoC: dt: sgtl5000.txt: Add description for 'reg' field
        ASoC: wm_hubs: Make sure we don't disable differential line outputs
      1c2f9548
    • L
      Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux · 59068e36
      Linus Torvalds 提交于
      Pull an ACPI patch from Len Brown:
       "It fixes a D3 issue new in 3.4-rc1."
      
      By Lin Ming via Len Brown:
      * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
        ACPI: Fix D3hot v D3cold confusion
      59068e36
    • S
      init: don't try mounting device as nfs root unless type fully matches · 377485f6
      Sasha Levin 提交于
      Currently, we'll try mounting any device who's major device number is
      UNNAMED_MAJOR as NFS root.  This would happen for non-NFS devices as
      well (such as 9p devices) but it wouldn't cause any issues since
      mounting the device as NFS would fail quickly and the code proceeded to
      doing the proper mount:
      
             [  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
             [  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.
      
      Commit 6829a048102a ("NFS: Retry mounting NFSROOT") introduced retries
      when mounting NFS root, which means that now we don't immediately fail
      and instead it takes an additional 90+ seconds until we stop retrying,
      which has revealed the issue this patch fixes.
      
      This meant that it would take an additional 90 seconds to boot when
      we're not using a device type which gets detected in order before NFS.
      
      This patch modifies the NFS type check to require device type to be
      'Root_NFS' instead of requiring the device to have an UNNAMED_MAJOR
      major.  This makes boot process cleaner since we now won't go through
      the NFS mounting code at all when the device isn't an NFS root
      ("/dev/nfs").
      Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      377485f6
  2. 05 5月, 2012 10 次提交
    • T
      Merge branch 'fix/asoc' into for-linus · e9e7183f
      Takashi Iwai 提交于
      e9e7183f
    • T
    • T
      Merge tag 'asoc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus · 20c76945
      Takashi Iwai 提交于
      ASoC: Updates for 3.4
      
      Nothing terribly exciting here, a bunch of small and simple fixes
      scattered around the place.
      20c76945
    • L
      ACPI: Fix D3hot v D3cold confusion · 1cc0c998
      Lin Ming 提交于
      Before this patch, ACPI_STATE_D3 incorrectly referenced D3hot
      in some places, but D3cold in other places.
      
      After this patch, ACPI_STATE_D3 always means ACPI_STATE_D3_COLD;
      and all references to D3hot use ACPI_STATE_D3_HOT.
      
      ACPI's _PR3 method is used to enter both D3hot and D3cold states.
      What distinguishes D3hot from D3cold is the presence _PR3
      (Power Resources for D3hot)  If these resources are all ON,
      then the state is D3hot.  If _PR3 is not present,
      or all _PR0 resources for the devices are OFF,
      then the state is D3cold.
      
      This patch applies after Linux-3.4-rc1.
      A future syntax cleanup may remove ACPI_STATE_D3
      to emphasize that it always means ACPI_STATE_D3_COLD.
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: NAaron Lu <aaron.lu@amd.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1cc0c998
    • G
      hfsplus: Fix potential buffer overflows · 6f24f892
      Greg Kroah-Hartman 提交于
      Commit ec81aecb ("hfs: fix a potential buffer overflow") fixed a few
      potential buffer overflows in the hfs filesystem.  But as Timo Warns
      pointed out, these changes also need to be made on the hfsplus
      filesystem as well.
      Reported-by: NTimo Warns <warns@pre-sense.de>
      Acked-by: NWANG Cong <amwang@redhat.com>
      Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
      Cc: Miklos Szeredi <mszeredi@suse.cz>
      Cc: Sage Weil <sage@newdream.net>
      Cc: Eugene Teo <eteo@redhat.com>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Dave Anderson <anderson@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6f24f892
    • L
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f756beba
      Linus Torvalds 提交于
      Pull timer fix from Thomas Gleixner.
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        rtc: Fix possible null pointer dereference in rtc-mpc5121.c
      f756beba
    • L
      Merge git://git.samba.org/sfrench/cifs-2.6 · c6de1687
      Linus Torvalds 提交于
      Pull CIFS fixes from Steve French.
      
      * git://git.samba.org/sfrench/cifs-2.6:
        fs/cifs: fix parsing of dfs referrals
        cifs: make sure we ignore the credentials= and cred= options
        [CIFS] Update cifs version to 1.78
        cifs - check S_AUTOMOUNT in revalidate
        cifs: add missing initialization of server->req_lock
        cifs: don't cap ra_pages at the same level as default_backing_dev_info
        CIFS: Fix indentation in cifs_show_options
      c6de1687
    • D
      CPU frequency drivers MAINTAINERS update · a03a09b2
      Dave Jones 提交于
      Remove myself as cpufreq maintainer.
      x86 driver changes can go through the regular x86/ACPI trees.
      ARM driver changes through the ARM trees.
      cpufreq core changes are rare these days, and can just go to lkml/direct.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a03a09b2
    • L
      seqlock: add 'raw_seqcount_begin()' function · 4f988f15
      Linus Torvalds 提交于
      The normal read_seqcount_begin() function will wait for any current
      writers to exit their critical region by looping until the sequence
      count is even.
      
      That "wait for sequence count to stabilize" is the right thing to do if
      the read-locker will just retry the whole operation on contention: no
      point in doing a potentially expensive reader sequence if we know at the
      beginning that we'll just end up re-doing it all.
      
      HOWEVER.  Some users don't actually retry the operation, but instead
      will abort and do the operation with proper locking.  So the sequence
      count case may be the optimistic quick case, but in the presense of
      writers you may want to do full locking in order to guarantee forward
      progress.  The prime example of this would be the RCU name lookup.
      
      And in that case, you may well be better off without the "retry early",
      and are in a rush to instead get to the failure handling.  Thus this
      "raw" interface that just returns the sequence number without testing it
      - it just forces the low bit to zero so that read_seqcount_retry() will
      always fail such a "active concurrent writer" scenario.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4f988f15
    • L
      Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value read · 2f624278
      Linus Torvalds 提交于
      We really need to use a ACCESS_ONCE() on the sequence value read in
      __read_seqcount_begin(), because otherwise the compiler might end up
      reloading the value in between the test and the return of it.  As a
      result, it might end up returning an odd value (which means that a write
      is in progress).
      
      If the reader is then fast enough that that odd value is still the
      current one when the read_seqcount_retry() is done, we might end up with
      a "successful" read sequence, even despite the concurrent write being
      active.
      
      In practice this probably never really happens - there just isn't
      anything else going on around the read of the sequence count, and the
      common case is that we end up having a read barrier immediately
      afterwards.
      
      So the code sequence in which gcc might decide to reaload from memory is
      small, and there's no reason to believe it would ever actually do the
      reload.  But if the compiler ever were to decide to do so, it would be
      incredibly annoying to debug.  Let's just make sure.
      
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f624278
  3. 04 5月, 2012 25 次提交