Skip to content

L
linux
Switch branch/tag
  1. 07 Mar, 2015 4 commits
  3. 04 Mar, 2015 2 commits
  5. 02 Mar, 2015 3 commits
    • Arnd Bergmann's avatar
      Input: sun4i-ts - add thermal driver dependency · 4a6155a4
      Arnd Bergmann authored 
      The sun4i-ts driver has had a dependency on the thermal code
with the addition of the thermal zone sensor support, but this
is not currently enforced in Kconfig, so with TOUCHSCREEN_SUN4I=y,
THERMAL=m and THERMAL_OF=y we get

drivers/built-in.o: In function `sun4i_ts_remove':
:(.text+0x2376f4): undefined reference to `thermal_zone_of_sensor_unregister'
drivers/built-in.o: In function `sun4i_ts_probe':
:(.text+0x237a94): undefined reference to `thermal_zone_of_sensor_register'
:(.text+0x237c00): undefined reference to `thermal_zone_of_sensor_unregister'

We need the dependency on THERMAL in order to ensure that this
driver becomes a loadable module if the thermal support itself
is modular, while the dependency on THERMAL_OF is a runtime
dependency and the driver will still build if it is missing.
It is entirely possible to build sun4i-ts without THERMAL_OF
just to use the hwmon sensors and/or touchscreen.

Fixes: 22369710 ("Input: sun4i-ts - add thermal zone sensor support")
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
[wens@csie.org: Fix description and Kconfig dependencies]
Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      4a6155a4
    • Geert Uytterhoeven's avatar
      Input: cyapa - remove superfluous type check in cyapa_gen5_read_idac_data() · 2523caab
      Geert Uytterhoeven authored 
      drivers/input/mouse/cyapa_gen5.c: In function ‘cyapa_gen5_read_idac_data’:
drivers/input/mouse/cyapa_gen5.c:1876: warning: ‘max_element_cnt’ may be used uninitialized in this function
drivers/input/mouse/cyapa_gen5.c:1873: warning: ‘offset’ may be used uninitialized in this function

If *data_size is non-zero, and idac_data_type contains an unknown type,
max_element_cnt and offset will be uninitialized, and the loop will
process non-existing data.

However, this cannot happen (for now), as there's a test for unknown
types at the top of cyapa_gen5_read_idac_data().

As no "if ... else if ..." is used in other places, remove the
superfluous "if" to silence the compiler warning.
Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: default avatarDudley Du <dudl@cypress.com>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      2523caab
    • Dudley Du's avatar
      Input: cyapa - fix unaligned functions redefinition error · 17a28055
      Dudley Du authored 
      Use asm/unaligned.h instead of linux/unaligned/access_ok.h header file to
fix compiling issues such as following while doing cross platform
compiling:

"include/linux/unaligned/access_ok.h:7:19: error: redefinition of
 'get_unaligned_le16'
...
include/linux/unaligned/le_struct.h:6:19: note: previous definition of
 'get_unaligned_le16' was here".
Reported-by: default avatarkbuild test robot <kbuild-all@01.org>
Signed-off-by: default avatarDudley Du <dudl@cypress.com>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      17a28055
  7. 26 Feb, 2015 1 commit
  9. 20 Feb, 2015 1 commit
  11. 16 Feb, 2015 11 commits
  13. 15 Feb, 2015 6 commits
  15. 12 Feb, 2015 2 commits
  17. 10 Feb, 2015 2 commits
  19. 09 Feb, 2015 5 commits
    • Linus Torvalds's avatar
      Linux 3.19 · bfa76d49
      Linus Torvalds authored
      bfa76d49
    • Linus Torvalds's avatar
      Merge tag 'nios2-fixes-v3.19-final' of git://git.rocketboards.org/linux-socfpga-next · da2d96d3
      Linus Torvalds authored 
      Pull nios2 fix from Ley Foon Tan:
 "This fixes incorrect behavior of some user programs"

* tag 'nios2-fixes-v3.19-final' of git://git.rocketboards.org/linux-socfpga-next:
  nios2: fix unhandled signals
      da2d96d3
    • Linus Torvalds's avatar
      Merge git://git.kvack.org/~bcrl/aio-fixes · cdecbb33
      Linus Torvalds authored 
      Pull aio nested sleep annotation from Ben LaHaise,

* git://git.kvack.org/~bcrl/aio-fixes:
  aio: annotate aio_read_event_ring for sleep patterns
      cdecbb33
    • Linus Torvalds's avatar
      Merge tag 'trace-fixes-v3.19-rc7' of... · 4e02370f
      Linus Torvalds authored 
      Merge tag 'trace-fixes-v3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull ftrace fixes from Steven Rostedt:
 "During testing Sedat Dilek hit a "suspicious RCU usage" splat that
  pointed out a real bug.  During suspend and resume the tlb_flush
  tracepoint is called when the CPU is going offline.  As the CPU has
  been noted as offline, RCU is ignoring that CPU, which means that it
  can not use RCU protected locks.  When tracepoints are activated, they
  require RCU locking, and if RCU is ignoring a CPU that runs a
  tracepoint, there is a chance that the tracepoint could cause
  corruption.

  The solution was to change the tracepoint into a
  TRACE_EVENT_CONDITION() which allows us to check a condition to
  determine if the tracepoint should be called or not.  If the condition
  is not met, the rcu protected code will not be executed.  By adding
  the condition "cpu_online(smp_processor_id())", this will prevent the
  RCU protected code from being executed if the CPU is marked offline.

  After adding this, another bug was discovered.  As RCU checks rcu
  callers, if a rcu call is not done, there is no check (obviously).  We
  found that tracepoints could be added in RCU ignored locations and not
  have lockdep complain until the tracepoint is activated.  This missed
  places where tracepoints were added in places they should not have
  been.  To fix this, code was added in 3.18 that if lockdep is enabled,
  any tracepoint will still call the rcu checks even if the tracepoint
  is not enabled.  The bug here, is that the check does not take the
  CONDITION into account.  As the condition may prevent tracepoints from
  being activated in RCU ignored areas (as the one patch does), we get
  false positives when we enable lockdep and hit a tracepoint that the
  condition prevents it from being called in a RCU ignored location.

  The fix for this is to add the CONDITION to the rcu checks, even if
  the tracepoint is not enabled"

* tag 'trace-fixes-v3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  x86/tlb/trace: Do not trace on CPU that is offline
  tracing: Add condition check to RCU lockdep checks
      4e02370f
    • Chung-Ling Tang's avatar
      nios2: fix unhandled signals · a3248d60
      Chung-Ling Tang authored 
      Follow other architectures for user fault handling.
Signed-off-by: default avatarChung-Ling Tang <cltang@codesourcery.com>
Acked-by: default avatarLey Foon Tan <lftan@altera.com>
      a3248d60
  21. 08 Feb, 2015 2 commits
    • Steven Rostedt (Red Hat)'s avatar
      x86/tlb/trace: Do not trace on CPU that is offline · 6c8465a8
      Steven Rostedt (Red Hat) authored 
      When taking a CPU down for suspend and resume, a tracepoint may be called
when the CPU has been designated offline. As tracepoints require RCU for
protection, they must not be called if the current CPU is offline.

Unfortunately, trace_tlb_flush() is called in this scenario as was noted
by LOCKDEP:

...

 Disabling non-boot CPUs ...
 intel_pstate CPU 1 exiting

 ===============================
 smpboot: CPU 1 didn't die...
 [ INFO: suspicious RCU usage. ]
 3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted
 -------------------------------
 include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 RCU used illegally from offline CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 no locks held by swapper/1/0.

 stack backtrace:
 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc7-next-20150204.1-iniza-small #1
 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
  0000000000000001 ffff88011a44fe18 ffffffff817e370d 0000000000000011
  ffff88011a448290 ffff88011a44fe48 ffffffff810d6847 ffff8800c66b9600
  0000000000000001 ffff88011a44c000 ffffffff81cb3900 ffff88011a44fe78
 Call Trace:
  [<ffffffff817e370d>] dump_stack+0x4c/0x65
  [<ffffffff810d6847>] lockdep_rcu_suspicious+0xe7/0x120
  [<ffffffff810b71a5>] idle_task_exit+0x205/0x2c0
  [<ffffffff81054c4e>] play_dead_common+0xe/0x50
  [<ffffffff81054ca5>] native_play_dead+0x15/0x140
  [<ffffffff8102963f>] arch_cpu_idle_dead+0xf/0x20
  [<ffffffff810cd89e>] cpu_startup_entry+0x37e/0x580
  [<ffffffff81053e20>] start_secondary+0x140/0x150
 intel_pstate CPU 2 exiting

...

By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the
condition is cpu_online(smp_processor_id()), we can avoid calling RCU protected
code when the CPU is offline.

Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com

Cc: stable@vger.kernel.org # 3.17+
Fixes: d17d8f9d "x86/mm: Add tracepoints for TLB flushes"
Reported-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
Suggested-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: default avatarDave Hansen <dave@sr71.net>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      6c8465a8
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Add condition check to RCU lockdep checks · a05d59a5
      Steven Rostedt (Red Hat) authored 
      The trace_tlb_flush() tracepoint can be called when a CPU is going offline.
When a CPU is offline, RCU is no longer watching that CPU and since the
tracepoint is protected by RCU, it must not be called. To prevent the
tlb_flush tracepoint from being called when the CPU is offline, it was
converted to a TRACE_EVENT_CONDITION where the condition checks if the
CPU is online before calling the tracepoint.

Unfortunately, this was not enough to stop lockdep from complaining about
it. Even though the RCU protected code of the tracepoint will never be
called, the condition is hidden within the tracepoint, and even though the
condition prevents RCU code from being called, the lockdep checks are
outside the tracepoint (this is to test tracepoints even when they are not
enabled).

Even though tracepoints should be checked to be RCU safe when they are not
enabled, the condition should still be considered when checking RCU.

Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com

Fixes: 3a630178 "tracing: generate RCU warnings even when tracepoints are disabled"
Cc: stable@vger.kernel.org # 3.18+
Acked-by: default avatarDave Hansen <dave@sr71.net>
Reported-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      a05d59a5
  23. 07 Feb, 2015 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7