1. 20 2月, 2016 1 次提交
  2. 16 12月, 2015 1 次提交
  3. 13 12月, 2015 2 次提交
  4. 09 12月, 2015 2 次提交
  5. 06 10月, 2015 2 次提交
  6. 05 10月, 2015 1 次提交
  7. 15 9月, 2015 1 次提交
  8. 31 8月, 2015 2 次提交
  9. 30 8月, 2015 3 次提交
  10. 22 8月, 2015 3 次提交
  11. 21 8月, 2015 1 次提交
  12. 15 8月, 2015 1 次提交
  13. 12 8月, 2015 3 次提交
  14. 07 8月, 2015 1 次提交
    • N
      regmap: Use different lockdep class for each regmap init call · 3cfe7a74
      Nicolas Boichat 提交于
      Lockdep validator complains about recursive locking and deadlock
      when two different regmap instances are called in a nested order.
      That happens anytime a regmap read/write call needs to access
      another regmap.
      
      This is because, for performance reason, lockdep groups all locks
      initialized by the same mutex_init() in the same lock class.
      Therefore all regmap mutexes are in the same lock class, leading
      to lockdep "nested locking" warnings if a regmap accesses another
      regmap.
      
      In general, it is impossible to establish in advance the hierarchy
      of regmaps, so we make sure that each regmap init call initializes
      its own static lock_class_key. This is done by wrapping all
      regmap_init calls into macros.
      
      This also allows us to give meaningful names to the lock_class_key.
      For example, in rt5677 case, we have in /proc/lockdep_chains:
      irq_context: 0
      [ffffffc0018d2198] &dev->mutex
      [ffffffc0018d2198] &dev->mutex
      [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock
      [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock
      [ffffffc001b95448] &(&base->lock)->rlock
      
      The above would have resulted in a lockdep recursive warning
      previously. This is not the case anymore as the lockdep validator
      now clearly identifies the 2 regmaps as separate.
      Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      3cfe7a74
  15. 17 7月, 2015 2 次提交
  16. 14 7月, 2015 1 次提交
  17. 13 7月, 2015 1 次提交
    • L
      regmap: Add better support for devices without readback support · 04dc91ce
      Lars-Peter Clausen 提交于
      Currently regmap requires that a reg_read callback is supplied, otherwise a
      warning is emitted each time regmap_read() is called. This means a device
      or bus without readback support needs to supply dummy reg_read callback.
      Apart from that regmap_read() will still work fine if a cache is used.
      
      Remove the warning and let regmap_readable() return false if not reg_read
      callback is supplied. This means a device no longer has to supply a dummy
      callback if it does not support readback and it also doesn't have to have a
      readable_reg callback that always returns false since this is now implicit.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      04dc91ce
  18. 10 7月, 2015 3 次提交
  19. 16 6月, 2015 1 次提交
  20. 15 6月, 2015 1 次提交
  21. 29 5月, 2015 1 次提交
  22. 22 5月, 2015 2 次提交
  23. 20 3月, 2015 2 次提交
    • S
      regmap: Move tracing header into drivers/base/regmap · f58078da
      Steven Rostedt 提交于
      The tracing events for regmap are confined to the regmap subsystem. It
      also requires accessing an internal header. Instead of including the
      internal header from a generic file location, move the tracing file
      into the regmap directory.
      
      Also rename the regmap tracing header to trace.h, as it is redundant to
      keep the regmap.h name when it is in the regmap directory.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      f58078da
    • P
      regmap: introduce regmap_name to fix syscon regmap trace events · c6b570d9
      Philipp Zabel 提交于
      This patch fixes a NULL pointer dereference when enabling regmap event
      tracing in the presence of a syscon regmap, introduced by commit bdb0066d
      ("mfd: syscon: Decouple syscon interface from platform devices").
      That patch introduced syscon regmaps that have their dev field set to NULL.
      The regmap trace events expect it to point to a valid struct device and feed
      it to dev_name():
      
        $ echo 1 > /sys/kernel/debug/tracing/events/regmap/enable
      
        Unable to handle kernel NULL pointer dereference at virtual address 0000002c
        pgd = 80004000
        [0000002c] *pgd=00000000
        Internal error: Oops: 17 [#1] SMP ARM
        Modules linked in: coda videobuf2_vmalloc
        CPU: 0 PID: 304 Comm: kworker/0:2 Not tainted 4.0.0-rc2+ #9197
        Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
        Workqueue: events_freezable thermal_zone_device_check
        task: 9f25a200 ti: 9f1ee000 task.ti: 9f1ee000
        PC is at ftrace_raw_event_regmap_block+0x3c/0xe4
        LR is at _regmap_raw_read+0x1bc/0x1cc
        pc : [<803636e8>]    lr : [<80365f2c>]    psr: 600f0093
        sp : 9f1efd78  ip : 9f1efdb8  fp : 9f1efdb4
        r10: 00000004  r9 : 00000001  r8 : 00000001
        r7 : 00000180  r6 : 00000000  r5 : 9f00e3c0  r4 : 00000003
        r3 : 00000001  r2 : 00000180  r1 : 00000000  r0 : 9f00e3c0
        Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
        Control: 10c5387d  Table: 2d91004a  DAC: 00000015
        Process kworker/0:2 (pid: 304, stack limit = 0x9f1ee210)
        Stack: (0x9f1efd78 to 0x9f1f0000)
        fd60:                                                       9f1efda4 9f1efd88
        fd80: 800708c0 805f9510 80927140 800f0013 9f1fc800 9eb2f490 00000000 00000180
        fda0: 808e3840 00000001 9f1efdfc 9f1efdb8 80365f2c 803636b8 805f8958 800708e0
        fdc0: a00f0013 803636ac 9f16de00 00000180 80927140 9f1fc800 9f1fc800 9f1efe6c
        fde0: 9f1efe6c 9f732400 00000000 00000000 9f1efe1c 9f1efe00 80365f70 80365d7c
        fe00: 80365f3c 9f1fc800 9f1fc800 00000180 9f1efe44 9f1efe20 803656a4 80365f48
        fe20: 9f1fc800 00000180 9f1efe6c 9f1efe6c 9f732400 00000000 9f1efe64 9f1efe48
        fe40: 803657bc 80365634 00000001 9e95f910 9f1fc800 9f1efeb4 9f1efe8c 9f1efe68
        fe60: 80452ac0 80365778 9f1efe8c 9f1efe78 9e93d400 9e93d5e8 9f1efeb4 9f72ef40
        fe80: 9f1efeac 9f1efe90 8044e11c 80452998 8045298c 9e93d608 9e93d400 808e1978
        fea0: 9f1efecc 9f1efeb0 8044fd14 8044e0d0 ffffffff 9f25a200 9e93d608 9e481380
        fec0: 9f1efedc 9f1efed0 8044fde8 8044fcec 9f1eff1c 9f1efee0 80038d50 8044fdd8
        fee0: 9f1ee020 9f72ef40 9e481398 00000000 00000008 9f72ef54 9f1ee020 9f72ef40
        ff00: 9e481398 9e481380 00000008 9f72ef40 9f1eff5c 9f1eff20 80039754 80038bfc
        ff20: 00000000 9e481380 80894100 808e1662 00000000 9e4f2ec0 00000000 9e481380
        ff40: 800396f8 00000000 00000000 00000000 9f1effac 9f1eff60 8003e020 80039704
        ff60: ffffffff 00000000 ffffffff 9e481380 00000000 00000000 9f1eff78 9f1eff78
        ff80: 00000000 00000000 9f1eff88 9f1eff88 9e4f2ec0 8003df30 00000000 00000000
        ffa0: 00000000 9f1effb0 8000eb60 8003df3c 00000000 00000000 00000000 00000000
        ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
        Backtrace:
        [<803636ac>] (ftrace_raw_event_regmap_block) from [<80365f2c>] (_regmap_raw_read+0x1bc/0x1cc)
         r9:00000001 r8:808e3840 r7:00000180 r6:00000000 r5:9eb2f490 r4:9f1fc800
        [<80365d70>] (_regmap_raw_read) from [<80365f70>] (_regmap_bus_read+0x34/0x6c)
         r10:00000000 r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:9f1fc800
         r4:9f1fc800
        [<80365f3c>] (_regmap_bus_read) from [<803656a4>] (_regmap_read+0x7c/0x144)
         r6:00000180 r5:9f1fc800 r4:9f1fc800 r3:80365f3c
        [<80365628>] (_regmap_read) from [<803657bc>] (regmap_read+0x50/0x70)
         r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:00000180 r4:9f1fc800
        [<8036576c>] (regmap_read) from [<80452ac0>] (imx_get_temp+0x134/0x1a4)
         r6:9f1efeb4 r5:9f1fc800 r4:9e95f910 r3:00000001
        [<8045298c>] (imx_get_temp) from [<8044e11c>] (thermal_zone_get_temp+0x58/0x74)
         r7:9f72ef40 r6:9f1efeb4 r5:9e93d5e8 r4:9e93d400
        [<8044e0c4>] (thermal_zone_get_temp) from [<8044fd14>] (thermal_zone_device_update+0x34/0xec)
         r6:808e1978 r5:9e93d400 r4:9e93d608 r3:8045298c
        [<8044fce0>] (thermal_zone_device_update) from [<8044fde8>] (thermal_zone_device_check+0x1c/0x20)
         r5:9e481380 r4:9e93d608
        [<8044fdcc>] (thermal_zone_device_check) from [<80038d50>] (process_one_work+0x160/0x3d4)
        [<80038bf0>] (process_one_work) from [<80039754>] (worker_thread+0x5c/0x4f4)
         r10:9f72ef40 r9:00000008 r8:9e481380 r7:9e481398 r6:9f72ef40 r5:9f1ee020
         r4:9f72ef54
        [<800396f8>] (worker_thread) from [<8003e020>] (kthread+0xf0/0x108)
         r10:00000000 r9:00000000 r8:00000000 r7:800396f8 r6:9e481380 r5:00000000
         r4:9e4f2ec0
        [<8003df30>] (kthread) from [<8000eb60>] (ret_from_fork+0x14/0x34)
         r7:00000000 r6:00000000 r5:8003df30 r4:9e4f2ec0
        Code: e3140040 1a00001a e3140020 1a000016 (e596002c)
        ---[ end trace 193c15c2494ec960 ]---
      
      Fixes: bdb0066d (mfd: syscon: Decouple syscon interface from platform devices)
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      c6b570d9
  24. 05 2月, 2015 1 次提交
  25. 28 9月, 2014 1 次提交