1. 18 5月, 2012 1 次提交
  2. 14 5月, 2012 1 次提交
  3. 11 5月, 2012 2 次提交
  4. 08 5月, 2012 1 次提交
  5. 05 5月, 2012 3 次提交
    • 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
    • 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
  6. 02 5月, 2012 1 次提交
  7. 01 5月, 2012 5 次提交
    • E
      net: fix two typos in skbuff.h · d9619496
      Eric Dumazet 提交于
      fix kernel doc typos in function names
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9619496
    • B
      ASoC: Add support for CS42L52 Codec · dfe0f98b
      Brian Austin 提交于
      This patch adds support for Cirrus Logic CS42L52 Low Power Stereo Codec
      Signed-off-by: NBrian Austin <brian.austin@cirrus.com>
      Signed-off-by: NGeorgi Vlaev <joe@nucleusys.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      dfe0f98b
    • M
      efi: Add new variable attributes · 41b3254c
      Matthew Garrett 提交于
      More recent versions of the UEFI spec have added new attributes for
      variables. Add them.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      41b3254c
    • H
      asm-generic: Use __BITS_PER_LONG in statfs.h · f5c2347e
      H. Peter Anvin 提交于
      <asm-generic/statfs.h> is exported to userspace, so using
      BITS_PER_LONG is invalid.  We need to use __BITS_PER_LONG instead.
      
      This is kernel bugzilla 43165.
      Reported-by: NH.J. Lu <hjl.tools@gmail.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Link: http://lkml.kernel.org/r/1335465916-16965-1-git-send-email-hpa@linux.intel.comAcked-by: NArnd Bergmann <arnd@arndb.de>
      Cc: <stable@vger.kernel.org>
      f5c2347e
    • E
      net: fix sk_sockets_allocated_read_positive · 518fbf9c
      Eric Dumazet 提交于
      Denys Fedoryshchenko reported frequent crashes on a proxy server and kindly
      provided a lockdep report that explains it all :
      
        [  762.903868]
        [  762.903880] =================================
        [  762.903890] [ INFO: inconsistent lock state ]
        [  762.903903] 3.3.4-build-0061 #8 Not tainted
        [  762.904133] ---------------------------------
        [  762.904344] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
        [  762.904542] squid/1603 [HC0[0]:SC0[0]:HE1:SE1] takes:
        [  762.904542]  (key#3){+.?...}, at: [<c0232cc4>]
      __percpu_counter_sum+0xd/0x58
        [  762.904542] {IN-SOFTIRQ-W} state was registered at:
        [  762.904542]   [<c0158b84>] __lock_acquire+0x284/0xc26
        [  762.904542]   [<c01598e8>] lock_acquire+0x71/0x85
        [  762.904542]   [<c0349765>] _raw_spin_lock+0x33/0x40
        [  762.904542]   [<c0232c93>] __percpu_counter_add+0x58/0x7c
        [  762.904542]   [<c02cfde1>] sk_clone_lock+0x1e5/0x200
        [  762.904542]   [<c0303ee4>] inet_csk_clone_lock+0xe/0x78
        [  762.904542]   [<c0315778>] tcp_create_openreq_child+0x1b/0x404
        [  762.904542]   [<c031339c>] tcp_v4_syn_recv_sock+0x32/0x1c1
        [  762.904542]   [<c031615a>] tcp_check_req+0x1fd/0x2d7
        [  762.904542]   [<c0313f77>] tcp_v4_do_rcv+0xab/0x194
        [  762.904542]   [<c03153bb>] tcp_v4_rcv+0x3b3/0x5cc
        [  762.904542]   [<c02fc0c4>] ip_local_deliver_finish+0x13a/0x1e9
        [  762.904542]   [<c02fc539>] NF_HOOK.clone.11+0x46/0x4d
        [  762.904542]   [<c02fc652>] ip_local_deliver+0x41/0x45
        [  762.904542]   [<c02fc4d1>] ip_rcv_finish+0x31a/0x33c
        [  762.904542]   [<c02fc539>] NF_HOOK.clone.11+0x46/0x4d
        [  762.904542]   [<c02fc857>] ip_rcv+0x201/0x23e
        [  762.904542]   [<c02daa3a>] __netif_receive_skb+0x319/0x368
        [  762.904542]   [<c02dac07>] netif_receive_skb+0x4e/0x7d
        [  762.904542]   [<c02dacf6>] napi_skb_finish+0x1e/0x34
        [  762.904542]   [<c02db122>] napi_gro_receive+0x20/0x24
        [  762.904542]   [<f85d1743>] e1000_receive_skb+0x3f/0x45 [e1000e]
        [  762.904542]   [<f85d3464>] e1000_clean_rx_irq+0x1f9/0x284 [e1000e]
        [  762.904542]   [<f85d3926>] e1000_clean+0x62/0x1f4 [e1000e]
        [  762.904542]   [<c02db228>] net_rx_action+0x90/0x160
        [  762.904542]   [<c012a445>] __do_softirq+0x7b/0x118
        [  762.904542] irq event stamp: 156915469
        [  762.904542] hardirqs last  enabled at (156915469): [<c019b4f4>]
      __slab_alloc.clone.58.clone.63+0xc4/0x2de
        [  762.904542] hardirqs last disabled at (156915468): [<c019b452>]
      __slab_alloc.clone.58.clone.63+0x22/0x2de
        [  762.904542] softirqs last  enabled at (156915466): [<c02ce677>]
      lock_sock_nested+0x64/0x6c
        [  762.904542] softirqs last disabled at (156915464): [<c0349914>]
      _raw_spin_lock_bh+0xe/0x45
        [  762.904542]
        [  762.904542] other info that might help us debug this:
        [  762.904542]  Possible unsafe locking scenario:
        [  762.904542]
        [  762.904542]        CPU0
        [  762.904542]        ----
        [  762.904542]   lock(key#3);
        [  762.904542]   <Interrupt>
        [  762.904542]     lock(key#3);
        [  762.904542]
        [  762.904542]  *** DEADLOCK ***
        [  762.904542]
        [  762.904542] 1 lock held by squid/1603:
        [  762.904542]  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<c03055c0>]
      lock_sock+0xa/0xc
        [  762.904542]
        [  762.904542] stack backtrace:
        [  762.904542] Pid: 1603, comm: squid Not tainted 3.3.4-build-0061 #8
        [  762.904542] Call Trace:
        [  762.904542]  [<c0347b73>] ? printk+0x18/0x1d
        [  762.904542]  [<c015873a>] valid_state+0x1f6/0x201
        [  762.904542]  [<c0158816>] mark_lock+0xd1/0x1bb
        [  762.904542]  [<c015876b>] ? mark_lock+0x26/0x1bb
        [  762.904542]  [<c015805d>] ? check_usage_forwards+0x77/0x77
        [  762.904542]  [<c0158bf8>] __lock_acquire+0x2f8/0xc26
        [  762.904542]  [<c0159b8e>] ? mark_held_locks+0x5d/0x7b
        [  762.904542]  [<c0159cf6>] ? trace_hardirqs_on+0xb/0xd
        [  762.904542]  [<c0158dd4>] ? __lock_acquire+0x4d4/0xc26
        [  762.904542]  [<c01598e8>] lock_acquire+0x71/0x85
        [  762.904542]  [<c0232cc4>] ? __percpu_counter_sum+0xd/0x58
        [  762.904542]  [<c0349765>] _raw_spin_lock+0x33/0x40
        [  762.904542]  [<c0232cc4>] ? __percpu_counter_sum+0xd/0x58
        [  762.904542]  [<c0232cc4>] __percpu_counter_sum+0xd/0x58
        [  762.904542]  [<c02cebc4>] __sk_mem_schedule+0xdd/0x1c7
        [  762.904542]  [<c02d178d>] ? __alloc_skb+0x76/0x100
        [  762.904542]  [<c0305e8e>] sk_wmem_schedule+0x21/0x2d
        [  762.904542]  [<c0306370>] sk_stream_alloc_skb+0x42/0xaa
        [  762.904542]  [<c0306567>] tcp_sendmsg+0x18f/0x68b
        [  762.904542]  [<c031f3dc>] ? ip_fast_csum+0x30/0x30
        [  762.904542]  [<c0320193>] inet_sendmsg+0x53/0x5a
        [  762.904542]  [<c02cb633>] sock_aio_write+0xd2/0xda
        [  762.904542]  [<c015876b>] ? mark_lock+0x26/0x1bb
        [  762.904542]  [<c01a1017>] do_sync_write+0x9f/0xd9
        [  762.904542]  [<c01a2111>] ? file_free_rcu+0x2f/0x2f
        [  762.904542]  [<c01a17a1>] vfs_write+0x8f/0xab
        [  762.904542]  [<c01a284d>] ? fget_light+0x75/0x7c
        [  762.904542]  [<c01a1900>] sys_write+0x3d/0x5e
        [  762.904542]  [<c0349ec9>] syscall_call+0x7/0xb
        [  762.904542]  [<c0340000>] ? rp_sidt+0x41/0x83
      
      Bug is that sk_sockets_allocated_read_positive() calls
      percpu_counter_sum_positive() without BH being disabled.
      
      This bug was added in commit 180d8cd9
      (foundations of per-cgroup memory pressure controlling.), since previous
      code was using percpu_counter_read_positive() which is IRQ safe.
      
      In __sk_mem_schedule() we dont need the precise count of allocated
      sockets and can revert to previous behavior.
      Reported-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Sined-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Glauber Costa <glommer@parallels.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      518fbf9c
  8. 30 4月, 2012 3 次提交
    • H
      ipvs: kernel oops - do_ip_vs_get_ctl · 8537de8a
      Hans Schillstrom 提交于
      Change order of init so netns init is ready
      when register ioctl and netlink.
      
      Ver2
      	Whitespace fixes and __init added.
      Reported-by: N"Ryan O'Hara" <rohara@redhat.com>
      Signed-off-by: NHans Schillstrom <hans.schillstrom@ericsson.com>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      8537de8a
    • H
      ipvs: take care of return value from protocol init_netns · 582b8e3e
      Hans Schillstrom 提交于
      ip_vs_create_timeout_table() can return NULL
      All functions protocol init_netns is affected of this patch.
      Signed-off-by: NHans Schillstrom <hans.schillstrom@ericsson.com>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      582b8e3e
    • L
      pipes: add a "packetized pipe" mode for writing · 9883035a
      Linus Torvalds 提交于
      The actual internal pipe implementation is already really about
      individual packets (called "pipe buffers"), and this simply exposes that
      as a special packetized mode.
      
      When we are in the packetized mode (marked by O_DIRECT as suggested by
      Alan Cox), a write() on a pipe will not merge the new data with previous
      writes, so each write will get a pipe buffer of its own.  The pipe
      buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
      will tell the reader side to break the read at that boundary (and throw
      away any partial packet contents that do not fit in the read buffer).
      
      End result: as long as you do writes less than PIPE_BUF in size (so that
      the pipe doesn't have to split them up), you can now treat the pipe as a
      packet interface, where each read() system call will read one packet at
      a time.  You can just use a sufficiently big read buffer (PIPE_BUF is
      sufficient, since bigger than that doesn't guarantee atomicity anyway),
      and the return value of the read() will naturally give you the size of
      the packet.
      
      NOTE! We do not support zero-sized packets, and zero-sized reads and
      writes to a pipe continue to be no-ops.  Also note that big packets will
      currently be split at write time, but that the size at which that
      happens is not really specified (except that it's bigger than PIPE_BUF).
      Currently that limit is the system page size, but we might want to
      explicitly support bigger packets some day.
      
      The main user for this is going to be the autofs packet interface,
      allowing us to stop having to care so deeply about exact packet sizes
      (which have had bugs with 32/64-bit compatibility modes).  But user
      space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
      fail with an EINVAL on kernels that do not support this interface.
      Tested-by: NMichael Tokarev <mjt@tls.msk.ru>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: David Miller <davem@davemloft.net>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Thomas Meyer <thomas@m3y3r.de>
      Cc: stable@kernel.org  # needed for systemd/autofs interaction fix
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9883035a
  9. 28 4月, 2012 1 次提交
  10. 27 4月, 2012 6 次提交
    • R
      ARM: pxa: fix gpio wakeup setting · b95ace54
      Robert Jarzmik 提交于
      In 3.3, gpio wakeup setting was broken. The call
      enable_irq_wake() didn't set up the PXA gpio registers
      (PWER, ...) anymore.
      
      Fix it at least for pxa27x. The driver doesn't seem to be
      used in pxa25x (weird ...), and the fix doesn't extend to
      pxa3xx and pxa95x (which don't have a gpio_set_wake()
      available).
      Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      b95ace54
    • L
      ASoC: dpcm: Add bespoke trigger() · 07bf84aa
      Liam Girdwood 提交于
      Some on SoC DSP HW is very tightly coupled with DMA and DAI drivers. It's
      necessary to allow some flexability wrt to PCM operations here so that we
      can define a bespoke DPCM trigger() PCM operation for such HW.
      
      A bespoke DPCM trigger() allows exact ordering and timing of component
      triggering by allowing a component driver to manage the final enable
      and disable configurations without adding extra complexity to other
      component drivers. e.g. The McPDM DAI and ABE are tightly coupled on
      OMAP4 so we have a bespoke trigger to manage the trigger to improve
      performance and reduce complexity when triggering new McPDM BEs.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      07bf84aa
    • L
      ASoC: dpcm: Add API for DAI link substream and runtime lookup · 47c88fff
      Liam Girdwood 提交于
      Some component drivers will need to be able to look up their
      DAI link substream and RTD data. Provide a mechanism for this.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      47c88fff
    • L
      ASoC: dpcm: Add runtime dynamic route update · 618dae11
      Liam Girdwood 提交于
      This patch allows DPCM to dynamically alter the FE to BE PCM links
      at runtime based on mixer setting updates. DAPM is looked up after
      every mixer update and we perform a DPCM runtime update if the
      mixer has a change of value.
      
      This patchs adds/changes the following :-
      
       o Adds DPCM runtime update core.
       o Changes soc_dapm_mixer_update_power() and soc_dapm_mux_update_power()
         to return if a change has occured rather than 0. No other users check
         atm.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      618dae11
    • L
      ASoC: dpcm: Add debugFS support for DPCM · f86dcef8
      Liam Girdwood 提交于
      Add debugFS files for DPCM link management information.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      f86dcef8
    • L
      ASoC: dpcm: Add Dynamic PCM core operations. · 01d7584c
      Liam Girdwood 提交于
      The Dynamic PCM core allows digital audio data to be dynamically
      routed between different ALSA PCMs and DAI links on SoC CPUs with
      on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
      routed to any (or all) SoC DAI links.
      
      Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
      End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
      they can dynamically route digital audio data to any supported BE
      PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
      substream and audio HW parameters.
      
      e.g. pcm:0,0 routing digital data to 2 external codecs.
      
      FE pcm:0,0  ----> BE (McBSP.0) ----> CODEC 0
                   +--> BE (McPDM.0) ----> CODEC 1
      
      e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
      
      FE pcm:0,0 ---
                   +--> BE (McBSP.0) ----> CODEC
      FE pcm:0,1 ---
      
      The digital audio routing is controlled by the usual ALSA method
      of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
      routing based upon the mixer settings and configures the BE PCMs
      based on routing and the FE HW params.
      
      DPCM is designed so that most ASoC component drivers will need no
      modification at all. It's intended that existing CODEC, DAI and
      platform drivers can be used in DPCM based audio devices without
      any changes. However, there will be some cases where minor changes
      are required (e.g. for very tightly coupled HW) and there are
      helpers to support this too.
      
      Somethimes the HW params of a FE and BE do not match or are
      incompatible, so in these cases the machine driver can reconfigure
      any hw_params and make any DSP perform sample rate / format conversion.
      
      This patch adds the core DPCM code and contains :-
      
       o The FE and BE PCM operations.
       o FE and BE DAI link support.
       o FE and BE PCM creation.
       o BE support API.
       o BE and FE link management.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      01d7584c
  11. 26 4月, 2012 1 次提交
  12. 25 4月, 2012 1 次提交
    • A
      USB: EHCI: fix crash during suspend on ASUS computers · 151b6128
      Alan Stern 提交于
      This patch (as1545) fixes a problem affecting several ASUS computers:
      The machine crashes or corrupts memory when going into suspend if the
      ehci-hcd driver is bound to any controllers.  Users have been forced
      to unbind or unload ehci-hcd before putting their systems to sleep.
      
      After extensive testing, it was determined that the machines don't
      like going into suspend when any EHCI controllers are in the PCI D3
      power state.  Presumably this is a firmware bug, but there's nothing
      we can do about it except to avoid putting the controllers in D3
      during system sleep.
      
      The patch adds a new flag to indicate whether the problem is present,
      and avoids changing the controller's power state if the flag is set.
      Runtime suspend is unaffected; this matters only for system suspend.
      However as a side effect, the controller will not respond to remote
      wakeup requests while the system is asleep.  Hence USB wakeup is not
      functional -- but of course, this is already true in the current state
      of affairs.
      
      This fixes Bugzilla #42728.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
      Tested-by: NOleksij Rempel (fishor) <bug-track@fisher-privat.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      151b6128
  13. 24 4月, 2012 4 次提交
  14. 23 4月, 2012 6 次提交
  15. 21 4月, 2012 4 次提交