1. 15 8月, 2013 1 次提交
  2. 07 8月, 2013 1 次提交
  3. 19 6月, 2013 1 次提交
  4. 13 6月, 2013 1 次提交
    • L
      i2c: core: make it possible to match a pure device tree driver · c80f5284
      Linus Walleij 提交于
      This tries to address an issue found when writing an MFD driver
      for the Nomadik STw481x PMICs: as the platform is using device
      tree exclusively I want to specify the driver matching like
      this:
      
      static const struct of_device_id stw481x_match[] = {
      	{ .compatible = "st,stw4810", },
      	{ .compatible = "st,stw4811", },
      	{},
      };
      
      static struct i2c_driver stw481x_driver = {
      	.driver = {
      		.name	= "stw481x",
      		.of_match_table = stw481x_match,
      	},
      	.probe		= stw481x_probe,
      	.remove		= stw481x_remove,
      };
      
      However that turns out not to be possible: the I2C probe code
      is written so that the probe() call is always passed a match
      from i2c_match_id() using non-devicetree matches.
      
      This is probably why most devices using device tree for I2C
      clients currently will pass no .of_match_table *at all* but
      instead just use .id_table from struct i2c_driver to match
      the device. As you realize that means that the whole idea with
      compatible strings is discarded, and that is why we find strange
      device tree I2C device compatible strings like "product" instead
      of "vendor,product" as you could expect.
      
      Let's figure out how to fix this before the mess spreads. This
      patch will allow probeing devices with only an of_match_table
      as per above, and will pass NULL as the second argument to the
      probe() function. If the driver wants to deduce secondary info
      from the struct of_device_id .data field, it has to call
      of_match_device() on its own match table in the probe function
      device tree probe path.
      
      If drivers define both an .of_match_table *AND* a i2c_driver
      .id_table, the .of_match_table will take precedence, just
      as is done in the i2c_device_match() function in i2c-core.c.
      
      I2C devices probed from device tree should subsequently be
      fixed to handle the case where of_match_table() is
      used (I think none of them do that today), and platforms should
      fix their device trees to use compatible strings for I2C devices
      instead of setting the name to Linux device driver names as is
      done in multiple cases today.
      
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      c80f5284
  5. 04 6月, 2013 1 次提交
  6. 18 5月, 2013 1 次提交
    • A
      i2c: suppress lockdep warning on delete_device · e9b526fe
      Alexander Sverdlin 提交于
      i2c: suppress lockdep warning on delete_device
      
      Since commit 846f9974 the following lockdep
      warning is thrown in case i2c device is removed (via delete_device sysfs
      attribute) which contains subdevices (e.g. i2c multiplexer):
      
      =============================================
      [ INFO: possible recursive locking detected ]
      3.8.7-0-sampleversion-fct #8 Tainted: G           O
      ---------------------------------------------
      bash/3743 is trying to acquire lock:
        (s_active#110){++++.+}, at: [<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8
      
      but task is already holding lock:
        (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208
      
      other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(s_active#110);
         lock(s_active#110);
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
      4 locks held by bash/3743:
        #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff802b3c3c>] sysfs_write_file+0x4c/0x208
        #1:  (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208
        #2:  (&adap->userspace_clients_lock/1){+.+.+.}, at: [<ffffffff80454a18>] i2c_sysfs_delete_device+0x90/0x238
        #3:  (&__lockdep_no_validate__){......}, at: [<ffffffff803dcc24>] device_release_driver+0x24/0x48
      
      stack backtrace:
      Call Trace:
      [<ffffffff80575cc8>] dump_stack+0x8/0x34
      [<ffffffff801b50fc>] __lock_acquire+0x161c/0x2110
      [<ffffffff801b5c3c>] lock_acquire+0x4c/0x70
      [<ffffffff802b60cc>] sysfs_addrm_finish+0x19c/0x1e0
      [<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8
      [<ffffffff802b7d8c>] sysfs_remove_group+0x64/0x148
      [<ffffffff803d990c>] device_remove_attrs+0x9c/0x1a8
      [<ffffffff803d9b1c>] device_del+0x104/0x1d8
      [<ffffffff803d9c18>] device_unregister+0x28/0x70
      [<ffffffff8045505c>] i2c_del_adapter+0x1cc/0x328
      [<ffffffff8045802c>] i2c_del_mux_adapter+0x14/0x38
      [<ffffffffc025c108>] pca954x_remove+0x90/0xe0 [pca954x]
      [<ffffffff804542f8>] i2c_device_remove+0x80/0xe8
      [<ffffffff803dca9c>] __device_release_driver+0x74/0xf8
      [<ffffffff803dcc2c>] device_release_driver+0x2c/0x48
      [<ffffffff803dbc14>] bus_remove_device+0x13c/0x1d8
      [<ffffffff803d9b24>] device_del+0x10c/0x1d8
      [<ffffffff803d9c18>] device_unregister+0x28/0x70
      [<ffffffff80454b08>] i2c_sysfs_delete_device+0x180/0x238
      [<ffffffff802b3cd4>] sysfs_write_file+0xe4/0x208
      [<ffffffff8023ddc4>] vfs_write+0xbc/0x160
      [<ffffffff8023df6c>] SyS_write+0x54/0xd8
      [<ffffffff8013d424>] handle_sys64+0x44/0x64
      
      The problem is already known for USB and PCI subsystems. The reason is that
      delete_device attribute is defined statically in i2c-core.c and used for all
      devices in i2c subsystem.
      
      Discussion of original USB problem:
      http://lkml.indiana.edu/hypermail/linux/kernel/1204.3/01160.html
      
      Commit 356c05d5 introduced new macro to suppress
      lockdep warnings for this special case and included workaround for USB code.
      
      LKML discussion of the workaround:
      http://lkml.indiana.edu/hypermail/linux/kernel/1205.1/03634.html
      
      As i2c case is in principle the same, the same workaround could be used here.
      Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@nsn.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      e9b526fe
  7. 09 4月, 2013 1 次提交
  8. 02 4月, 2013 3 次提交
    • L
      i2c: Make return type of i2c_del_adapter() void · 71546300
      Lars-Peter Clausen 提交于
      i2c_del_adapter() is usually called from a drivers remove callback. The Linux
      device driver model does not allow the remove callback to fail and all resources
      allocated in the probe callback need to be freed, as well as all resources which
      have been provided to the rest of the kernel(for example a I2C adapter) need to
      be revoked. So any function revoking such resources isn't allowed to fail
      either. i2c_del_adapter() adheres to this requirement and will never fail. But
      i2c_del_adapter()'s return type is int, which may cause driver authors to think
      that it can fail. This led to code constructs like:
      
      	ret = i2c_del_adapter(...);
      	BUG_ON(ret);
      
      Since i2c_del_adapter() always returns 0 the BUG_ON is never hit and essentially
      becomes dead code, which means it can be removed. Making the return type of
      i2c_del_adapter() void makes it explicit that the function will never fail and
      should prevent constructs like the above from re-appearing in the kernel code.
      
      All callers of i2c_del_adapter() have already been updated in a previous patch
      to ignore the return value, so the conversion of the return type from int to
      void can be done without causing any build failures.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Reviewed-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      71546300
    • L
      i2c: i2c_del_adapter: Don't treat removing a non-registered adapter as error · f5fb0822
      Lars-Peter Clausen 提交于
      Currently i2c_del_adapter() returns -EINVAL when it gets an adapter which is not
      registered. But none of the users of i2c_del_adapter() depend on this behavior,
      so for the sake of being able to sanitize the return type of i2c_del_adapter
      argue, that the purpose of i2c_del_adapter() is to remove an I2C adapter from
      the system. If the adapter is not registered in the first place this becomes a
      no-op. So we can return success without having to do anything.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Reviewed-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      f5fb0822
    • L
      i2c: Remove detach_adapter · 19baba4c
      Lars-Peter Clausen 提交于
      The detach_adapter callback has been deprecated for quite some time and has no
      user left. Keeping it alive blocks other cleanups, so remove it.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Reviewed-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      19baba4c
  9. 24 3月, 2013 2 次提交
    • V
      i2c: Add bus recovery infrastructure · 5f9296ba
      Viresh Kumar 提交于
      Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
      protocol Rev. 03 section 3.1.16 titled "Bus clear".
      
      http://www.nxp.com/documents/user_manual/UM10204.pdf
      
      Sometimes during operation i2c bus hangs and we need to give dummy clocks to
      slave device to start the transfer again. Now we may have capability in the bus
      controller to generate these clocks or platform may have gpio pins which can be
      toggled to generate dummy clocks. This patch supports both.
      
      This patch also adds in generic bus recovery routines gpio or scl line based
      which can be used by bus controller. In addition controller driver may provide
      its own version of the bus recovery routine.
      
      This doesn't support multi-master recovery for now.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      [wsa: changed gpio type to int and minor reformatting]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      5f9296ba
    • D
      i2c: core: Pick i2c bus number from dt alias if present · ee5c2744
      Doug Anderson 提交于
      This allows you to get the equivalent functionality of
      i2c_add_numbered_adapter() with all data in the device tree and no
      special case code in your driver.  This is a common device tree
      technique.
      
      For quick reference, the FDT syntax for using an alias to provide an
      ID looks like:
        aliases {
          i2c0 = &i2c_0;
          i2c1 = &i2c_1;
        };
      Signed-off-by: NDoug Anderson <dianders@chromium.org>
      [wsa: removed one check from static function. We know our callers]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      ee5c2744
  10. 28 2月, 2013 2 次提交
    • T
      idr: remove MAX_IDR_MASK and move left MAX_IDR_* into idr.c · e8c8d1bc
      Tejun Heo 提交于
      MAX_IDR_MASK is another weirdness in the idr interface.  As idr covers
      whole positive integer range, it's defined as 0x7fffffff or INT_MAX.
      
      Its usage in idr_find(), idr_replace() and idr_remove() is bizarre.
      They basically mask off the sign bit and operate on the rest, so if
      the caller, by accident, passes in a negative number, the sign bit
      will be masked off and the remaining part will be used as if that was
      the input, which is worse than crashing.
      
      The constant is visible in idr.h and there are several users in the
      kernel.
      
      * drivers/i2c/i2c-core.c:i2c_add_numbered_adapter()
      
        Basically used to test if adap->nr is a negative number which isn't
        -1 and returns -EINVAL if so.  idr_alloc() already has negative
        @start checking (w/ WARN_ON_ONCE), so this can go away.
      
      * drivers/infiniband/core/cm.c:cm_alloc_id()
        drivers/infiniband/hw/mlx4/cm.c:id_map_alloc()
      
        Used to wrap cyclic @start.  Can be replaced with max(next, 0).
        Note that this type of cyclic allocation using idr is buggy.  These
        are prone to spurious -ENOSPC failure after the first wraparound.
      
      * fs/super.c:get_anon_bdev()
      
        The ID allocated from ida is masked off before being tested whether
        it's inside valid range.  ida allocated ID can never be a negative
        number and the masking is unnecessary.
      
      Update idr_*() functions to fail with -EINVAL when negative @id is
      specified and update other MAX_IDR_MASK users as described above.
      
      This leaves MAX_IDR_MASK without any user, remove it and relocate
      other MAX_IDR_* constants to lib/idr.c.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Cc: "Marciniszyn, Mike" <mike.marciniszyn@intel.com>
      Cc: Jack Morgenstein <jackm@dev.mellanox.co.il>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Acked-by: NWolfram Sang <wolfram@the-dreams.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8c8d1bc
    • T
      i2c: convert to idr_alloc() · 4ae42b0f
      Tejun Heo 提交于
      Convert to the much saner new idr interface.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Wolfram Sang <wolfram@the-dreams.de>
      Tested-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4ae42b0f
  11. 28 1月, 2013 1 次提交
  12. 23 11月, 2012 1 次提交
  13. 06 10月, 2012 2 次提交
  14. 10 9月, 2012 1 次提交
    • J
      i2c-core: Fix for lockdep validator · 390946b1
      Jean Delvare 提交于
      If kernel is compiled with CONFIG_PROVE_LOCKING the
      validator raises an error when a multiplexer is removed
      via sysfs and sub-clients are connected to it. This is a
      false positive.
      Documentation/lockdep-design.txt recommends to handle this
      via calls to mutex_lock_nested().
      
      Based on an earlier fix from Michael Lawnick.
      
      Note that the extra code resolves to nothing unless
      CONFIG_DEBUG_LOCK_ALLOC=y.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Michael Lawnick <ml.lawnick@gmx.de>
      390946b1
  15. 24 7月, 2012 2 次提交
  16. 30 6月, 2012 1 次提交
    • J
      [media] i2c: Export an unlocked flavor of i2c_transfer · b37d2a3a
      Jean Delvare 提交于
      Some drivers (in particular for TV cards) need exclusive access to
      their I2C buses for specific operations. Export an unlocked flavor
      of i2c_transfer to give them full control.
      
      The unlocked flavor has the following limitations:
      * Obviously, caller must hold the i2c adapter lock.
      * No debug messages are logged. We don't want to log messages while
        holding a rt_mutex.
      * No check is done on the existence of adap->algo->master_xfer. It
        is thus the caller's responsibility to ensure that the function is
        OK to call.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      b37d2a3a
  17. 12 5月, 2012 1 次提交
  18. 27 3月, 2012 1 次提交
  19. 16 3月, 2012 1 次提交
  20. 23 11月, 2011 1 次提交
  21. 25 7月, 2011 1 次提交
  22. 17 4月, 2011 1 次提交
  23. 31 3月, 2011 1 次提交
  24. 20 3月, 2011 3 次提交
  25. 22 1月, 2011 1 次提交
  26. 15 1月, 2011 3 次提交
  27. 11 1月, 2011 1 次提交
  28. 16 11月, 2010 1 次提交
  29. 25 10月, 2010 2 次提交