Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 02 4月, 2017 1 次提交
  3. 11 1月, 2017 1 次提交
  5. 05 1月, 2017 1 次提交
  7. 13 11月, 2016 1 次提交
    • J
      iio:core: add a callback to allow drivers to provide _available attributes · 51239600
      由 Jonathan Cameron 提交于 
      A large number of attributes can only take a limited range of values.
Currently in IIO this is handled by directly registering additional
*_available attributes thus providing this information to userspace.

It is desirable to provide this information via the core for much the same
reason this was done for the actual channel information attributes in the
first place.  If it isn't there, then it can only really be accessed from
userspace.  Other in kernel IIO consumers have no access to what valid
parameters are.

Two forms are currently supported:
* list of values in one particular IIO_VAL_* format.
	e.g. 1.300000 1.500000 1.730000
* range specification with a step size:
	e.g. [1.000000 0.500000 2.500000]
	equivalent to 1.000000 1.5000000 2.000000 2.500000

An addition set of masks are used to allow different sharing rules for the
*_available attributes generated.

This allows for example:

in_accel_x_offset
in_accel_y_offset
in_accel_offset_available.

We could have gone with having a specification for each and every
info_mask element but that would have meant changing the existing userspace
ABI.  This approach does not.
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
[forward ported, added some docs and fixed buffer overflows /peda]
Acked-by: NDaniel Baluta <daniel.baluta@intel.com>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      51239600
  9. 02 10月, 2016 1 次提交
  11. 06 9月, 2016 1 次提交
  13. 04 9月, 2016 1 次提交
  15. 01 7月, 2016 1 次提交
  17. 30 5月, 2016 1 次提交
  19. 24 4月, 2016 1 次提交
    • G
      iio:core: mounting matrix support · dfc57732
      由 Gregor Boirie 提交于 
      Expose a rotation matrix to indicate userspace the chip placement with
respect to the overall hardware system. This is needed to adjust
coordinates sampled from a sensor chip when its position deviates from the
main hardware system.

Final coordinates computation is delegated to userspace since:
* computation may involve floating point arithmetics ;
* it allows an application to combine adjustments with arbitrary
  transformations.

This 3 dimentional space rotation matrix is expressed as 3x3 array of
strings to support floating point numbers. It may be retrieved from a
"[<dir>_][<type>_]mount_matrix" sysfs attribute file. It is declared into a
device / driver specific DTS property or platform data.
Signed-off-by: NGregor Boirie <gregor.boirie@parrot.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      dfc57732
  21. 03 4月, 2016 2 次提交
  23. 12 3月, 2016 1 次提交
    • A
      iio: core: implement iio_device_{claim|release}_direct_mode() · 08a33805
      由 Alison Schofield 提交于 
      It is often the case that the driver wants to be sure a device stays
in direct mode while it is executing a task or series of tasks.  To
accomplish this today, the driver performs this sequence: 1) take the
device state lock, 2) verify it is not in a buffered mode, 3) execute
some tasks, and 4) release that lock.

This patch introduces a pair of helper functions that simplify these
steps and make it more semantically expressive.

iio_device_claim_direct_mode()
        If the device is not in any buffered mode it is guaranteed
        to stay that way until iio_release_direct_mode() is called.

iio_device_release_direct_mode()
        Release the claim. Device is no longer guaranteed to stay
        in direct mode.
Signed-off-by: NAlison Schofield <amsfield22@gmail.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      08a33805
  25. 31 1月, 2016 1 次提交
  27. 17 1月, 2016 1 次提交
    • M
      include/linux/kernel.h: change abs() macro so it uses consistent return type · 8f57e4d9
      由 Michal Nazarewicz 提交于 
      Rewrite abs() so that its return type does not depend on the
architecture and no unexpected type conversion happen inside of it.  The
only conversion is from unsigned to signed type.  char is left as a
return type but treated as a signed type regradless of it's actual
signedness.

With the old version, int arguments were promoted to long and depending
on architecture a long argument might result in s64 or long return type
(which may or may not be the same).

This came after some back and forth with Nicolas.  The current macro has
different return type (for the same input type) depending on
architecture which might be midly iritating.

An alternative version would promote to int like so:

	#define abs(x)	__abs_choose_expr(x, long long,			\
			__abs_choose_expr(x, long,			\
			__builtin_choose_expr(				\
				sizeof(x) <= sizeof(int),		\
				({ int __x = (x); __x<0?-__x:__x; }),	\
				((void)0))))

I have no preference but imagine Linus might.  :] Nicolas argument against
is that promoting to int causes iconsistent behaviour:

	int main(void) {
		unsigned short a = 0, b = 1, c = a - b;
		unsigned short d = abs(a - b);
		unsigned short e = abs(c);
		printf("%u %u\n", d, e);  // prints: 1 65535
	}

Then again, no sane person expects consistent behaviour from C integer
arithmetic.  ;)

Note:

  __builtin_types_compatible_p(unsigned char, char) is always false, and
  __builtin_types_compatible_p(signed char, char) is also always false.
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Reviewed-by: NNicolas Pitre <nico@linaro.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f57e4d9
  29. 23 12月, 2015 1 次提交
  31. 22 11月, 2015 1 次提交
  33. 15 11月, 2015 1 次提交
  35. 24 9月, 2015 2 次提交
  37. 28 8月, 2015 1 次提交
  39. 16 8月, 2015 1 次提交
  41. 03 8月, 2015 1 次提交
  43. 21 6月, 2015 1 次提交
  45. 23 5月, 2015 1 次提交
  47. 17 5月, 2015 1 次提交
  49. 11 5月, 2015 1 次提交
  51. 09 4月, 2015 1 次提交
  53. 15 3月, 2015 1 次提交
    • M
      iio: core: Fix double free. · c1b03ab5
      由 Martin Fuzzey 提交于 
      When an error occurred during event registration memory was freed twice
resulting in kernel memory corruption and a crash in unrelated code.

The problem was caused by
	iio_device_unregister_eventset()
	iio_device_unregister_sysfs()

being called twice, once on the error path and then
again via iio_dev_release().

Fix this by making these two functions idempotent so they
may be called multiple times.

The problem was observed before applying
	78b33216 iio:core: Handle error when mask type is not separate
Signed-off-by: NMartin Fuzzey <mfuzzey@parkeon.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      c1b03ab5
  55. 30 1月, 2015 1 次提交
  57. 28 1月, 2015 4 次提交
  59. 06 1月, 2015 1 次提交
  61. 26 12月, 2014 1 次提交
  63. 12 12月, 2014 1 次提交
    • L
      iio: Move buffer registration to the core · 3e1b6c95
      由 Lars-Peter Clausen 提交于 
      Originally device and buffer registration were kept as separate operations
in IIO to allow to register two distinct sets of channels for buffered and
non-buffered operations. This has since already been further restricted and
the channel set registered for the buffer needs to be a subset of the
channel set registered for the device. Additionally the possibility to not
have a raw (or processed) attribute for a channel which was registered for
the device was added a while ago. This means it is possible to not register
any device level attributes for a channel even if it is registered for the
device. Also if a channel's scan_index is set to -1 and the channel is
registered for the buffer it is ignored.

So in summary it means it is possible to register the same channel array for
both the device and the buffer yet still end up with distinctive sets of
channels for both of them. This makes the argument for having to have to
manually register the channels for both the device and the buffer invalid.
Considering that the vast majority of all drivers want to register the same
set of channels for both the buffer and the device it makes sense to move
the buffer registration into the core to avoid some boiler-plate code in the
device driver setup path.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      3e1b6c95
  65. 22 11月, 2014 3 次提交