1. 25 Mar, 2014 1 commit
    • Lars-Peter Clausen's avatar
      ASoC: Remove name_prefix unset during DAI link init hack · 6479f15a
      Lars-Peter Clausen authored
      Before we had card level support for DAPM and controls machine drivers would
      register their controls and DAPM elements with the CODEC. This required us to
      temporarily unset the name_prefix of a CODEC during the rtd init callback to
      avoid the machine level controls getting the CODEC's prefix. Now that all
      machine drivers properly register their machine level controls and DAPM elements
      with the card rather than with the CODEC we can drop the hack that sets the
      CODEC's name_prefix to NULL while calling the DAI link or AUX dev init callback.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      6479f15a
  2. 23 Mar, 2014 12 commits
  3. 21 Mar, 2014 3 commits
  4. 20 Mar, 2014 1 commit
  5. 19 Mar, 2014 4 commits
  6. 18 Mar, 2014 6 commits
  7. 17 Mar, 2014 7 commits
  8. 16 Mar, 2014 3 commits
    • Linus Torvalds's avatar
      Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 59bf6c3c
      Linus Torvalds authored
      Pull scheduler fixes from Ingo Molnar:
       "Three small fixes"
      
      * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/clock: Prevent tracing recursion in sched_clock_cpu()
        stop_machine: Fix^2 race between stop_two_cpus() and stop_cpus()
        sched/deadline: Deny unprivileged users to set/change SCHED_DEADLINE policy
      59bf6c3c
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · b44eeb4d
      Linus Torvalds authored
      Pull perf fixes from Ingo Molnar:
       "Misc smaller fixes"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf/x86: Fix leak in uncore_type_init failure paths
        perf machine: Use map as success in ip__resolve_ams
        perf symbols: Fix crash in elf_section_by_name
        perf trace: Decode architecture-specific signal numbers
      b44eeb4d
    • Michael Kerrisk's avatar
      ipc: Fix 2 bugs in msgrcv() MSG_COPY implementation · 4f87dac3
      Michael Kerrisk authored
      While testing and documenting the msgrcv() MSG_COPY flag that Stanislav
      Kinsbursky added in commit 4a674f34 ("ipc: introduce message queue
      copy feature" => kernel 3.8), I discovered a couple of bugs in the
      implementation.  The two bugs concern MSG_COPY interactions with other
      msgrcv() flags, namely:
      
       (A) MSG_COPY + MSG_EXCEPT
       (B) MSG_COPY + !IPC_NOWAIT
      
      The bugs are distinct (and the fix for the first one is obvious),
      however my fix for both is a single-line patch, which is why I'm
      combining them in a single mail, rather than writing two mails+patches.
      
       ===== (A) MSG_COPY + MSG_EXCEPT =====
      
      With the addition of the MSG_COPY flag, there are now two msgrcv()
      flags--MSG_COPY and MSG_EXCEPT--that modify the meaning of the 'msgtyp'
      argument in unrelated ways.  Specifying both in the same call is a
      logical error that is currently permitted, with the effect that MSG_COPY
      has priority and MSG_EXCEPT is ignored.  The call should give an error
      if both flags are specified.  The patch below implements that behavior.
      
       ===== (B) (B) MSG_COPY + !IPC_NOWAIT =====
      
      The test code that was submitted in commit 3a665531 ("selftests: IPC
      message queue copy feature test") shows MSG_COPY being used in
      conjunction with IPC_NOWAIT.  In other words, if there is no message at
      the position 'msgtyp'.  return immediately with the error in ENOMSG.
      
      What was not (fully) tested is the behavior if MSG_COPY is specified
      *without* IPC_NOWAIT, and there is an odd behavior.  If the queue
      contains less than 'msgtyp' messages, then the call blocks until the
      next message is written to the queue.  At that point, the msgrcv() call
      returns a copy of the newly added message, regardless of whether that
      message is at the ordinal position 'msgtyp'.  This is clearly bogus, and
      problematic for applications that might want to make use of the MSG_COPY
      flag.
      
      I considered the following possible solutions to this problem:
      
       (1) Force the call to block until a message *does* appear at the
           position 'msgtyp'.
      
       (2) If the MSG_COPY flag is specified, the kernel should implicitly add
           IPC_NOWAIT, so that the call fails with ENOMSG for this case.
      
       (3) If the MSG_COPY flag is specified, but IPC_NOWAIT is not, generate
           an error (probably, EINVAL is the right one).
      
      I do not know if any application would really want to have the
      functionality of solution (1), especially since an application can
      determine in advance the number of messages in the queue using msgctl()
      IPC_STAT.  Obviously, this solution would be the most work to implement.
      
      Solution (2) would have the effect of silently fixing any applications
      that tried to employ broken behavior.  However, it would mean that if we
      later decided to implement solution (1), then user-space could not
      easily detect what the kernel supports (but, since I'm somewhat doubtful
      that solution (1) is needed, I'm not sure that this is much of a
      problem).
      
      Solution (3) would have the effect of informing broken applications that
      they are doing something broken.  The downside is that this would cause
      a ABI breakage for any applications that are currently employing the
      broken behavior.  However:
      
      a) Those applications are almost certainly not getting the results they
         expect.
      b) Possibly, those applications don't even exist, because MSG_COPY is
         currently hidden behind CONFIG_CHECKPOINT_RESTORE.
      
      The upside of solution (3) is that if we later decided to implement
      solution (1), user-space could determine what the kernel supports, via
      the error return.
      
      In my view, solution (3) is mildly preferable to solution (2), and
      solution (1) could still be done later if anyone really cares.  The
      patch below implements solution (3).
      
      PS.  For anyone out there still listening, it's the usual story:
      documenting an API (and the thinking about, and the testing of the API,
      that documentation entails) is the one of the single best ways of
      finding bugs in the API, as I've learned from a lot of experience.  Best
      to do that documentation before releasing the API.
      Signed-off-by: default avatarMichael Kerrisk <mtk.manpages@gmail.com>
      Acked-by: default avatarStanislav Kinsbursky <skinsbursky@parallels.com>
      Cc: Stanislav Kinsbursky <skinsbursky@parallels.com>
      Cc: stable@vger.kernel.org
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4f87dac3
  9. 15 Mar, 2014 3 commits
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 3b4df68d
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "This is a set of six fixes.  Two are instant crash/null deref types
        (storvsc and isci).  The two qla2xxx are initialisation problems that
        cause MSI-X failures and card misdetection, the isci erroneous macro
        is actually illegal C that's causing a miscompile with certain gcc
        versions and the be2iscsi bad if expression is a static checker fix"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        [SCSI] storvsc: NULL pointer dereference fix
        [SCSI] qla2xxx: Poll during initialization for ISP25xx and ISP83xx
        [SCSI] isci: correct erroneous for_each_isci_host macro
        [SCSI] isci: fix reset timeout handling
        [SCSI] be2iscsi: fix bad if expression
        [SCSI] qla2xxx: Fix multiqueue MSI-X registration.
      3b4df68d
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · a4ecdf82
      Linus Torvalds authored
      Pull x86 fixes from Peter Anvin:
       "Two x86 fixes: Suresh's eager FPU fix, and a fix to the NUMA quirk for
        AMD northbridges.
      
        This only includes Suresh's fix patch, not the "mostly a cleanup"
        patch which had __init issues"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/amd/numa: Fix northbridge quirk to assign correct NUMA node
        x86, fpu: Check tsk_used_math() in kernel_fpu_end() for eager FPU
      a4ecdf82
    • Linus Torvalds's avatar
      Merge tag 'pm+acpi-3.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · cee152ff
      Linus Torvalds authored
      Pull ACPI and power management fixes from Rafael Wysocki:
       "Three of these are regression fixes, for two recent regressions and
        one introduced during the 3.13 cycle, and the fourth one is a working
        version of the fix that had to be reverted last time.
      
        Specifics:
      
         - A recent ACPI resources handling fix overlooked the fact that it
           had to update the ACPI PNP subsystem's resources parsing too and
           caused confusing warning messages to be printed during system
           intialization on some systems (with arguably buggy ACPI tables).
           Fix from Zhang Rui.
      
         - Moving the early ACPI initialization before timekeeping_init()
           earlier in this cycle broke fast TSC calibration on at least one
           system, so it needs to be done later, but still before
           efi_enter_virtual_mode() to allow the EFI initialization to refer
           to ACPI.
      
         - A change related to code duplication reduction in the cpufreq core
           inadvertently caused cpufreq intialization to fail for some CPUs
           handled by intel_pstate by adding checks that may fail for that
           driver, but aren't even necessary when it is used.  The issue is
           addressed by preventing those checks from run in the configurations
           in which they aren't needed.
      
         - If the Hardware Reduced ACPI flag is set in the ACPI tables, system
           suspend, hibernation and ACPI power off will only work when special
           sleep control and sleep status registeres are provided (their
           addresses in the ACPI tables are not zero).  If those registers are
           not available, the features in question have no chances to work, so
           they shouldn't even be regarded as supported.  That helps with
           power off in particular, because alternative power off methods may
           be used then and they may actually work"
      
      * tag 'pm+acpi-3.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states
        ACPI / init: Invoke early ACPI initialization later
        cpufreq: Skip current frequency initialization for ->setpolicy drivers
        PNP / ACPI: proper handling of ACPI IO/Memory resource parsing failures
      cee152ff