1. 22 1月, 2013 4 次提交
    • S
      tracing: Use this_cpu_ptr per-cpu helper · d8a0349c
      Shan Wei 提交于
      typeof(&buffer) is a pointer to array of 1024 char, or char (*)[1024].
      But, typeof(&buffer[0]) is a pointer to char which match the return type of get_trace_buf().
      As well-known, the value of &buffer is equal to &buffer[0].
      so return this_cpu_ptr(&percpu_buffer->buffer[0]) can avoid type cast.
      
      Link: http://lkml.kernel.org/r/50A1A800.3020102@gmail.comReviewed-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NShan Wei <davidshan@tencent.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      d8a0349c
    • S
      ring-buffer: Remove unnecessary recusive call in rb_advance_iter() · 771e0384
      Steven Rostedt 提交于
      The original ring-buffer code had special checks at the start
      of rb_advance_iter() and instead of repeating them again at the
      end of the function if a certain condition existed, I just did
      a recursive call to rb_advance_iter() because the special condition
      would cause rb_advance_iter() to return early (after the checks).
      
      But as things have changed, the special checks no longer exist
      and the only thing done for the special_condition is to call
      rb_inc_iter() and return. Instead of doing a confusing recursive call,
      just call rb_inc_iter instead.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      771e0384
    • S
      tracing: Fix sparse warning with is_signed_type() macro · 418c59e4
      Steven Rostedt 提交于
      Sparse complains when is_signed_type() is used on a pointer.
      This macro is needed for the format output used for ftrace
      and perf, to know if a binary field is a signed type or not.
      The is_signed_type() macro is used against all fields that are
      recorded by events to automate the operation.
      
      The problem sparse has is with the current way is_signed_type()
      works:
      
        ((type)-1 < 0)
      
      If "type" is a poiner, than sparse does not like it being compared
      to an integer (zero). The simple fix is to just give zero the
      same type. The runtime result stays the same.
      Reported-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      418c59e4
    • S
      ftrace: Be first to run code modification on modules · c1bf08ac
      Steven Rostedt 提交于
      If some other kernel subsystem has a module notifier, and adds a kprobe
      to a ftrace mcount point (now that kprobes work on ftrace points),
      when the ftrace notifier runs it will fail and disable ftrace, as well
      as kprobes that are attached to ftrace points.
      
      Here's the error:
      
       WARNING: at kernel/trace/ftrace.c:1618 ftrace_bug+0x239/0x280()
       Hardware name: Bochs
       Modules linked in: fat(+) stap_56d28a51b3fe546293ca0700b10bcb29__8059(F) nfsv4 auth_rpcgss nfs dns_resolver fscache xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack lockd sunrpc ppdev parport_pc parport microcode virtio_net i2c_piix4 drm_kms_helper ttm drm i2c_core [last unloaded: bid_shared]
       Pid: 8068, comm: modprobe Tainted: GF            3.7.0-0.rc8.git0.1.fc19.x86_64 #1
       Call Trace:
        [<ffffffff8105e70f>] warn_slowpath_common+0x7f/0xc0
        [<ffffffff81134106>] ? __probe_kernel_read+0x46/0x70
        [<ffffffffa0180000>] ? 0xffffffffa017ffff
        [<ffffffffa0180000>] ? 0xffffffffa017ffff
        [<ffffffff8105e76a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff810fd189>] ftrace_bug+0x239/0x280
        [<ffffffff810fd626>] ftrace_process_locs+0x376/0x520
        [<ffffffff810fefb7>] ftrace_module_notify+0x47/0x50
        [<ffffffff8163912d>] notifier_call_chain+0x4d/0x70
        [<ffffffff810882f8>] __blocking_notifier_call_chain+0x58/0x80
        [<ffffffff81088336>] blocking_notifier_call_chain+0x16/0x20
        [<ffffffff810c2a23>] sys_init_module+0x73/0x220
        [<ffffffff8163d719>] system_call_fastpath+0x16/0x1b
       ---[ end trace 9ef46351e53bbf80 ]---
       ftrace failed to modify [<ffffffffa0180000>] init_once+0x0/0x20 [fat]
        actual: cc:bb:d2:4b:e1
      
      A kprobe was added to the init_once() function in the fat module on load.
      But this happened before ftrace could have touched the code. As ftrace
      didn't run yet, the kprobe system had no idea it was a ftrace point and
      simply added a breakpoint to the code (0xcc in the cc:bb:d2:4b:e1).
      
      Then when ftrace went to modify the location from a call to mcount/fentry
      into a nop, it didn't see a call op, but instead it saw the breakpoint op
      and not knowing what to do with it, ftrace shut itself down.
      
      The solution is to simply give the ftrace module notifier the max priority.
      This should have been done regardless, as the core code ftrace modification
      also happens very early on in boot up. This makes the module modification
      closer to core modification.
      
      Link: http://lkml.kernel.org/r/20130107140333.593683061@goodmis.org
      
      Cc: stable@vger.kernel.org
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Reported-by: NFrank Ch. Eigler <fche@redhat.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      c1bf08ac
  2. 18 1月, 2013 2 次提交
  3. 17 1月, 2013 22 次提交
  4. 16 1月, 2013 4 次提交
  5. 15 1月, 2013 8 次提交
    • T
      ALSA: hda/hdmi - Work around "alsactl restore" errors · 6f54c361
      Takashi Iwai 提交于
      When "alsactl restore" is performed on HDMI codecs, it tries to
      restore the channel map value since the channel map controls are
      writable.  But hdmi_chmap_ctl_put() returns -EBADFD when no PCM stream
      is assigned yet, and this results in an error message from alsactl.
      Although the error is harmless, it's certainly ugly and can be
      regarded as a regression.
      
      As a workaround, this patch changes the return code in such a case to
      be zero for making others happy.  (A slight excuse is: when the chmap
      is changed through the proper alsa-lib API, the PCM status is checked
      there anyway, so we don't have to be too strict in the kernel side.)
      
      Cc: <stable@vger.kernel.org> [v3.7+]
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6f54c361
    • D
      cpuidle: remove the power_specified field in the driver · 8aef33a7
      Daniel Lezcano 提交于
      We realized that the power usage field is never filled and when it
      is filled for tegra, the power_specified flag is not set causing all
      of these values to be reset when the driver is initialized with
      set_power_state().
      
      However, the power_specified flag can be simply removed under the
      assumption that the states are always backward sorted, which is the
      case with the current code.
      
      This change allows the menu governor select function and the
      cpuidle_play_dead() to be simplified.  Moreover, the
      set_power_states() function can removed as it does not make sense
      any more.
      
      Drop the power_specified flag from struct cpuidle_driver and make
      the related changes as described above.
      
      As a consequence, this also fixes the bug where on the dynamic
      C-states system, the power fields are not initialized.
      
      [rjw: Changelog]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=42870
      References: https://bugzilla.kernel.org/show_bug.cgi?id=43349
      References: https://lkml.org/lkml/2012/10/16/518Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8aef33a7
    • T
      Merge tag 'asoc-atmel-pinctrl' of... · 2e4c4dbe
      Takashi Iwai 提交于
      Merge tag 'asoc-atmel-pinctrl' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: atmel: Fixes for pinctrl
      
      Due to a series of problems with the handling of Atmel, a combination of
      making changes that make other branches instantly buggy and a general
      failure to deal with the resulting issues effectively, v3.8 Atmel audio
      currently won't work at all for DT boards without adding pinctrl
      definitions and a request for those.
      2e4c4dbe
    • L
      Merge tag 'trace-3.8-rc3-regression-fix' of... · 406089d0
      Linus Torvalds 提交于
      Merge tag 'trace-3.8-rc3-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
      
      Pull tracing regression fixes from Steven Rostedt:
       "The clean up patch commit 0fb9656d "tracing: Make tracing_enabled
        be equal to tracing_on" caused two regressions.
      
         1) The irqs off latency tracer no longer starts if tracing_on is off
            when the tracer is set, and then tracing_on is enabled.  The
            tracing_on file needs the hook that tracing_enabled had to enable
            tracers if they request it (call the tracer's start() method).
      
         2) That commit had a separate change that really should have been a
            separate patch, but it must have been added accidently with the -a
            option of git commit.  But as the change is still related to the
            commit it wasn't noticed in review.  That change, changed the way
            blocking is done by the trace_pipe file with respect to the
            tracing_on settings.  I've been told that this change breaks
            current userspace, and this specific change is being reverted."
      
      * tag 'trace-3.8-rc3-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Fix regression of trace_pipe
        tracing: Fix regression with irqsoff tracer and tracing_on file
      406089d0
    • L
      Merge tag 'regmap-debugfs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap · 7dea1ff3
      Linus Torvalds 提交于
      Pull regmap debugfs optimisation fixes from Mark Brown:
       "The debugfs optimisations merged in v3.8 weren't my finest hour, there
        were a number of cases that the more complex algorithm made worse
        especially around the error handling.  This patch series should
        address those issues."
      
      * tag 'regmap-debugfs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
        regmap: debugfs: Make sure we store the last entry in the offset cache
        regmap: debugfs: Ensure a correct return value for empty caches
        regmap: debugfs: Discard the cache if we fail to allocate an entry
        regmap: debugfs: Fix check for block start in cached seeks
        regmap: debugfs: Fix attempts to read nonexistant register blocks
      7dea1ff3
    • L
      Merge tag 'regulator-3.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator · 2ac1e664
      Linus Torvalds 提交于
      Pull regulator fixes from Mark Brown:
       "A few fixes for the regulator subsystems, a few driver specific things
        plus a fix for the interaction between regultor_can_change_voltage()
        and continuous voltage ranges both of which were added for this
        release."
      
      * tag 'regulator-3.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
        regulator: max8998: Ensure enough delay time for max8998_set_voltage_buck_time_sel
        regulator: max8998: Use uV in voltage_map_desc
        regulator: max8997: Use uV in voltage_map_desc
        regulator: core: Fix comment for regulator_register()
        regulator: core: Fix continuous_voltage_range case in regulator_can_change_voltage
        regulator: s5m8767: Fix probe failure due to stack corruption
      2ac1e664
    • M
      e3d5b2f5
    • M
      3ab91da2