1. 15 Jan, 2020 1 commit
  2. 09 Jan, 2020 1 commit
    • Russell King's avatar
      i2c: fix bus recovery stop mode timing · cf8ce8b8
      Russell King authored
      
      
      The I2C specification states that tsu:sto for standard mode timing must
      be at minimum 4us. Pictographically, this is:
      
      SCL: ____/~~~~~~~~~
      SDA: _________/~~~~
             ->|    |<- 4us minimum
      
      We are currently waiting 2.5us between asserting SCL and SDA, which is
      in violation of the standard. Adjust the timings to ensure that we meet
      what is stipulated as the minimum timings to ensure that all devices
      correctly interpret the STOP bus transition.
      
      This is more important than trying to generate a square wave with even
      duty cycle.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      cf8ce8b8
  3. 17 Dec, 2019 1 commit
  4. 10 Dec, 2019 1 commit
  5. 28 Nov, 2019 1 commit
  6. 15 Nov, 2019 1 commit
  7. 24 Oct, 2019 1 commit
  8. 29 Aug, 2019 1 commit
  9. 14 Aug, 2019 1 commit
    • Wolfram Sang's avatar
      i2c: replace i2c_new_secondary_device with an ERR_PTR variant · af80559b
      Wolfram Sang authored
      
      
      In the general move to have i2c_new_*_device functions which return
      ERR_PTR instead of NULL, this patch converts i2c_new_secondary_device().
      
      There are only few users, so this patch converts the I2C core and all
      users in one go. The function gets renamed to i2c_new_ancillary_device()
      so out-of-tree users will get a build failure to understand they need to
      adapt their error checking code.
      Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> # adv748x
      Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> # adv7511 + adv7604
      Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # adv7604
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      af80559b
  10. 06 Aug, 2019 1 commit
  11. 31 Jul, 2019 1 commit
  12. 29 Jun, 2019 4 commits
  13. 26 Jun, 2019 1 commit
  14. 14 Jun, 2019 1 commit
  15. 30 May, 2019 1 commit
    • Thomas Gleixner's avatar
      treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 · c942fddf
      Thomas Gleixner authored
      Based on 3 normalized pattern(s):
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version this program is distributed in the
        hope that it will be useful but without any warranty without even
        the implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version [author] [kishon] [vijay] [abraham]
        [i] [kishon]@[ti] [com] this program is distributed in the hope that
        it will be useful but without any warranty without even the implied
        warranty of merchan...
      c942fddf
  16. 17 May, 2019 2 commits
  17. 03 May, 2019 2 commits
  18. 02 May, 2019 1 commit
  19. 01 May, 2019 1 commit
  20. 16 Apr, 2019 3 commits
    • Wolfram Sang's avatar
      i2c: core: introduce callbacks for atomic transfers · 63b96983
      Wolfram Sang authored
      
      
      We had the request to access devices very late when interrupts are not
      available anymore multiple times now. Mostly to prepare shutdown or
      reboot. Allow adapters to specify a specific callback for this case.
      Note that we fall back to the generic {master|smbus}_xfer callback if
      this new atomic one is not present. This is intentional to preserve the
      previous behaviour and avoid regressions. Because there are drivers not
      using interrupts or because it might have worked "accidently" before.
      Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Tested-by: default avatarStefan Lengfeld <contact@stefanchrist.eu>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      63b96983
    • Wolfram Sang's avatar
      i2c: core: use I2C locking behaviour also for SMBUS · 83c42212
      Wolfram Sang authored
      
      
      If I2C transfers are executed in atomic contexts, trylock is used
      instead of lock. This behaviour was missing for SMBUS, although a lot of
      transfers are of SMBUS type, either emulated or direct. So, factor out
      the locking routine into a helper and use it for I2C and SMBUS.
      Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      83c42212
    • Wolfram Sang's avatar
      i2c: core: remove use of in_atomic() · bae1d3a0
      Wolfram Sang authored
      Commit cea443a8 ("i2c: Support i2c_transfer in atomic contexts")
      added in_atomic() to the I2C core. However, the use of in_atomic()
      outside of core kernel code is discouraged and was already[1] when this
      code was added in early 2008. The above commit was a preparation for
      commit b7a36701 ("i2c-pxa: Add polling transfer"). Its commit
      message says explicitly it was added "for cases where I2C transactions
      have to occur at times interrup[t]s are disabled". So, the intention was
      'disabled interrupts'. This matches the use cases for atomic I2C
      transfers I have seen so far: very late communication (mostly to a PMIC)
      to powerdown or reboot the system. For those cases, interrupts are
      disabled then. It doesn't seem that in_atomic() adds value.
      
      After a discussion with Peter Zijlstra[2], we came up with a better set
      of conditionals to match the use case.
      
      The I2C core will soon gain an extra callback into bus drivers
      especially for atomic transfers to make them more generic. The code
      deciding which transfer to use (atomic/non-atomic) should mimic the
      behaviour which locking to use (trylock/lock). This is why we add a
      helper for it.
      
      [1] https://lwn.net/Articles/274695/
      [2] http://patchwork.ozlabs.org/patch/1067437/
      
      Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Tested-by: default avatarStefan Lengfeld <contact@stefanchrist.eu>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      bae1d3a0
  21. 13 Mar, 2019 1 commit
  22. 24 Feb, 2019 1 commit
  23. 08 Jan, 2019 1 commit
  24. 31 Oct, 2018 2 commits
  25. 11 Oct, 2018 1 commit
  26. 05 Oct, 2018 2 commits
  27. 30 Aug, 2018 1 commit
  28. 24 Aug, 2018 1 commit
  29. 08 Aug, 2018 1 commit
  30. 04 Aug, 2018 1 commit
  31. 25 Jul, 2018 1 commit
    • Peter Rosin's avatar
      i2c/mux, locking/core: Annotate the nested rt_mutex usage · 7b94ea50
      Peter Rosin authored
      
      
      If an i2c topology has instances of nested muxes, then a lockdep splat
      is produced when when i2c_parent_lock_bus() is called.  Here is an
      example:
      
        ============================================
        WARNING: possible recursive locking detected
        --------------------------------------------
        insmod/68159 is trying to acquire lock:
          (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]
      
        but task is already holding lock:
          (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]
      
        other info that might help us debug this:
          Possible unsafe locking scenario:
      
                CPU0
                ----
           lock(i2c_register_adapter#2);
           lock(i2c_register_adapter#2);
      
          *** DEADLOCK ***
      
          May be due to missing lock nesting notation
      
        1 lock held by insmod/68159:
          #0:  (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]
      
        stack backtrace:
        CPU: 13 PID: 68159 Comm: insmod Tainted: G           O
        Call Trace:
          dump_stack+0x67/0x98
          __lock_acquire+0x162e/0x1780
          lock_acquire+0xba/0x200
          rt_mutex_lock+0x44/0x60
          i2c_parent_lock_bus+0x32/0x50 [i2c_mux]
          i2c_parent_lock_bus+0x3e/0x50 [i2c_mux]
          i2c_smbus_xfer+0xf0/0x700
          i2c_smbus_read_byte+0x42/0x70
          my2c_init+0xa2/0x1000 [my2c]
          do_one_initcall+0x51/0x192
          do_init_module+0x62/0x216
          load_module+0x20f9/0x2b50
          SYSC_init_module+0x19a/0x1c0
          SyS_init_module+0xe/0x10
          do_syscall_64+0x6c/0x1a0
          entry_SYSCALL_64_after_hwframe+0x42/0xb7
      Reported-by: default avatarJohn Sperbeck <jsperbeck@google.com>
      Tested-by: default avatarJohn Sperbeck <jsperbeck@google.com>
      Signed-off-by: default avatarPeter Rosin <peda@axentia.se>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Deepa Dinamani <deepadinamani@google.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Chang <dpf@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Link: http://lkml.kernel.org/r/20180720083914.1950-3-peda@axentia.se
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7b94ea50