05 Jun, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms and conditions of the gnu general public license
    version 2 as published by the free software foundation this program
    is distributed in the hope 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 you should have received a copy of the gnu general
    public license along with this program if not write to the free
    software foundation inc 51 franklin st fifth floor boston ma 02110
    1301 usa

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 111 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Alexios Zavras
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190530000436.567572064@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

29 Apr, 2019

1 commit


16 Nov, 2018

1 commit

  • Before this commit sensor_hub_input_attr_get_raw_value() failed to take
    the signedness of 16 and 8 bit values into account, returning e.g.
    65436 instead of -100 for the z-axis reading of an accelerometer.

    This commit adds a new is_signed parameter to the function and makes all
    callers pass the appropriate value for this.

    While at it, this commit also fixes up some neighboring lines where
    statements were needlessly split over 2 lines to improve readability.

    Signed-off-by: Hans de Goede
    Acked-by: Srinivas Pandruvada
    Acked-by: Benjamin Tissoires
    Cc:
    Signed-off-by: Jonathan Cameron

    Hans de Goede
     

22 Apr, 2017

1 commit


20 Jun, 2015

1 commit


23 Feb, 2015

1 commit

  • Add additional flag to read in async mode. In this mode the caller will get
    reply via registered callback for capture_sample. Callbacks can be registered
    using sensor_hub_register_callback function. The usage id parameter of the
    capture_sample can be matched with the usage id of the requested attribute.

    Signed-off-by: Srinivas Pandruvada
    Acked-by: Jonathan Cameron
    Signed-off-by: Jiri Kosina

    Srinivas Pandruvada
     

20 Oct, 2014

1 commit


15 Nov, 2013

3 commits


02 Oct, 2013

1 commit


12 Sep, 2013

2 commits


04 Jul, 2013

2 commits

  • There is no real reason to not support 16 or 32 bit values too.

    Signed-off-by: Alexander Holler
    Cc: Alessandro Zummo
    Cc: Lars-Peter Clausen
    Cc: Jonathan Cameron
    Cc: Jiri Kosina
    Cc: John Stultz
    Cc: Jingoo Han
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexander Holler
     
  • The draft for HID-sensors (HUTRR39) currently doesn't define the range
    for the attribute year. Asking one of the authors revealed that full
    years (e.g. 2013 instead of just 13) were meant.

    So we now allow both, 8 bit and 16 bit values for the attribute year and
    assuming full years when the value is 16 bits wide.

    We will still support 8 bit values until the specification gets final
    (and maybe defines a way to set the time too).

    Signed-off-by: Alexander Holler
    Cc: Alessandro Zummo
    Cc: Lars-Peter Clausen
    Cc: Jonathan Cameron
    Cc: Jiri Kosina
    Cc: John Stultz
    Cc: Jingoo Han
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexander Holler
     

30 Apr, 2013

1 commit


26 Jan, 2013

1 commit


06 Jan, 2013

2 commits

  • The structure with common attributes for hid-sensors isn't specific
    to the iio-subsystem, so rename it to hid_sensor_common.

    Signed-off-by: Alexander Holler
    Acked-by: Jiri Kosina
    Signed-off-by: Jonathan Cameron

    Alexander Holler
     
  • This driver makes the time from HID sensors (hubs) which are offering
    such available like any other RTC does.

    It is necessary that all values like year, month etc, are send as
    8bit values (1 byte each) and all of them in 1 report. Also the
    spec HUTRR39b doesn't define the range of the year field, we
    tread it as 0 - 99 because that's what most RTCs I know about are
    offering.

    Currently the time can only be read. Setting the time must be done
    through sending a report (or a feature). The spec currently doesn't
    define how and I'm not sure if I just should define something by myself.

    Signed-off-by: Alexander Holler
    Signed-off-by: Jonathan Cameron

    Alexander Holler