iio: hid-sensor-magn-3d: Fix build warning

Fix build warning, sizeof() called on dynamically
sized pointer, by removing the call and the dependent
function parameter. It is not needed or used in this
driver, when pushing values to an iio buffer.

Changes from v1
- Fix mistake in varible name

Signed-off-by: Reyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: add support of the max5821

Signed-off-by: Philippe Reynes <tremyfr@yahoo.fr>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
staging: iio: ad5933: fix sparse warnings

Fix the following sparse warnings:

  CHECK   drivers/staging/iio/impedance-analyzer/ad5933.c
drivers/staging/iio/impedance-analyzer/ad5933.c:241:17: warning:
incorrect type in assignment (different base types)
drivers/staging/iio/impedance-analyzer/ad5933.c:241:17:    expected
unsigned int [unsigned] [usertype] d32
drivers/staging/iio/impedance-analyzer/ad5933.c:241:17:    got
restricted __be32 [usertype] <noident>
drivers/staging/iio/impedance-analyzer/ad5933.c:263:13: warning:
incorrect type in assignment (different base types)
drivers/staging/iio/impedance-analyzer/ad5933.c:263:13:    expected
unsigned short [unsigned] dat
drivers/staging/iio/impedance-analyzer/ad5933.c:263:13:    got
restricted __be16 [usertype] <noident>
drivers/staging/iio/impedance-analyzer/ad5933.c:271:13: warning:
incorrect type in assignment (different base types)
drivers/staging/iio/impedance-analyzer/ad5933.c:271:13:    expected
unsigned short [unsigned] [addressable] dat
drivers/staging/iio/impedance-analyzer/ad5933.c:271:13:    got
restricted __be16 [usertype] <noident>
drivers/staging/iio/impedance-analyzer/ad5933.c:310:19: warning: cast to
restricted __be32
drivers/staging/iio/impedance-analyzer/ad5933.c:310:19: warning: cast to
restricted __be32
drivers/staging/iio/impedance-analyzer/ad5933.c:310:19: warning: cast to
restricted __be32
drivers/staging/iio/impedance-analyzer/ad5933.c:310:19: warning: cast to
restricted __be32
drivers/staging/iio/impedance-analyzer/ad5933.c:310:19: warning: cast to
restricted __be32
drivers/staging/iio/impedance-analyzer/ad5933.c:310:19: warning: cast to
restricted __be32
drivers/staging/iio/impedance-analyzer/ad5933.c:446:21: warning:
incorrect type in assignment (different base types)
drivers/staging/iio/impedance-analyzer/ad5933.c:446:21:    expected
unsigned short [unsigned] dat
drivers/staging/iio/impedance-analyzer/ad5933.c:446:21:    got
restricted __be16 [usertype] <noident>
drivers/staging/iio/impedance-analyzer/ad5933.c:454:21: warning:
incorrect type in assignment (different base types)
drivers/staging/iio/impedance-analyzer/ad5933.c:454:21:    expected
unsigned short [unsigned] [addressable] dat
drivers/staging/iio/impedance-analyzer/ad5933.c:454:21:    got
restricted __be16 [usertype] <noident>
drivers/staging/iio/impedance-analyzer/ad5933.c:548:23: warning: cast to
restricted __be16
drivers/staging/iio/impedance-analyzer/ad5933.c:548:23: warning: cast to
restricted __be16
drivers/staging/iio/impedance-analyzer/ad5933.c:548:23: warning: cast to
restricted __be16
drivers/staging/iio/impedance-analyzer/ad5933.c:548:23: warning: cast to
restricted __be16

Signed-off-by: Teodora Baluta <teodora.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: buffer: Use roundup() instead of open-coding it

Makes the code slightly shorter and a bit easier to understand.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: buffer: Coalesce adjacent demux table entries

When copying multiple multiple samples that are adjacent in both the source as
well as the destination buffer, instead of creating a new demux table entry for
each sample just increase the length of the previous entry by the size of the
new sample. This makes the demuxing process slightly more efficient.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
staging: iio: hmc5843_core: fix sparse warnings

Fix the following sparse warnings:

 CHECK   drivers/staging/iio/magnetometer/hmc5843_core.c
drivers/staging/iio/magnetometer/hmc5843_core.c:138:70: warning:
incorrect type in argument 3 (different signedness)
drivers/staging/iio/magnetometer/hmc5843_core.c:138:70:    expected
unsigned int *val
drivers/staging/iio/magnetometer/hmc5843_core.c:138:70:    got int
*<noident>
drivers/staging/iio/magnetometer/hmc5843_core.c:215:64: warning:
incorrect type in argument 3 (different signedness)
drivers/staging/iio/magnetometer/hmc5843_core.c:215:64:    expected
unsigned int *val
drivers/staging/iio/magnetometer/hmc5843_core.c:215:64:    got int
*<noident>
drivers/staging/iio/magnetometer/hmc5843_core.c:354:72: warning:
incorrect type in argument 3 (different signedness)
drivers/staging/iio/magnetometer/hmc5843_core.c:354:72:    expected
unsigned int *val
drivers/staging/iio/magnetometer/hmc5843_core.c:354:72:    got int
*<noident>
drivers/staging/iio/magnetometer/hmc5843_core.c:362:72: warning:
incorrect type in argument 3 (different signedness)
drivers/staging/iio/magnetometer/hmc5843_core.c:362:72:    expected
unsigned int *val
drivers/staging/iio/magnetometer/hmc5843_core.c:362:72:    got int
*<noident>

Signed-off-by: Teodora Baluta <teodora.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
staging: iio: isl29018: fix sparse warning regarding incorrect type (different signedness)

Fix the following sparse warning:

drivers/staging/iio/light/isl29018.c:508:50: warning: incorrect type in
argument 3 (different signedness)
drivers/staging/iio/light/isl29018.c:508:50:    expected unsigned int
*conf_adc_bit
drivers/staging/iio/light/isl29018.c:508:50:    got int *<noident>

Signed-off-by: Teodora Baluta <teodora.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
staging: iio: adis16240: fix sparse warnings regarding incorrect argument type

Silence the following sparse warnings by changing cast from u16 to
__be16:

  CHECK   drivers/staging/iio/accel/adis16240_core.c
drivers/staging/iio/accel/adis16240_core.c:128:51: warning: incorrect
type in argument 3 (different signedness)
drivers/staging/iio/accel/adis16240_core.c:128:51:    expected unsigned
short [usertype] *val
drivers/staging/iio/accel/adis16240_core.c:128:51:    got signed short
*<noident>
drivers/staging/iio/accel/adis16240_core.c:142:51: warning: incorrect
type in argument 3 (different signedness)
drivers/staging/iio/accel/adis16240_core.c:142:51:    expected unsigned
short [usertype] *val
drivers/staging/iio/accel/adis16240_core.c:142:51:    got signed short
*<noident>

Signed-off-by: Teodora Baluta <teodora.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
drm: Don't grab an fb reference for the idr

The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
  gets closed.
- Kernel fbs (for fbdev emulation) get cleaned up by the driver code
  at module unload time.

But now i915 also reconstructs the bios fbs for a smooth transition.
And that fb is purely transitional and should get removed immmediately
once all crtcs stop using it. Of course if the i915 fbdev code decides
to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
in that case the fbdev code will grab it's own reference.

The problem is now that we also want to register that takeover fb in
the idr, so that userspace can do a smooth transition (animated maybe
even!) itself. But currently we have no one who will clean up the idr
reference once that fb isn't useful any more, and so essentially leak
it.

Fix this by no longer holding a full fb reference for the idr, but
instead just have a weak reference using kref_get_unless_zero. But
that requires us to synchronize and clean up with the idr and fb_lock
in drm_framebuffer_free, so add that. It's a bit ugly that we have to
unconditionally grab the fb_lock, but without that someone might creep
through a race.

This leak was caught by the fb leak check in drm_mode_config_cleanup.
Originally the leak was introduced in

commit 46f297fb83d4f9a6f6891964beb184664341a28b
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Mar 7 08:57:48 2014 -0800

    drm/i915: add plane_config fetching infrastructure v2

Cc:  Jesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
video/fbdev: Always built-in video= cmdline parsing

In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.

But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these 2 functions
and always build them in.

Whiel at it fix the checkpatch fail in this code.

v2: Also move fb_mode_option. Spotted by the kbuild.

v3: Review from Geert:
- Keep the old copyright notice from fb_mem.c, although I have no
idea what exactly applies.
- Only compile this when needed.

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

--

I prefer if we can merge this through drm-next since we'll use it
there in follow-up patches.
-Daniel
drm: Perform cmdline mode parsing during connector initialisation

i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line mode
is first parsed by drm_fb_helper_initial_config() which is called after
i915.ko's custom initial_config() as a fallback method. So in order for
us to honour it, we need to move the cmdline parser earlier. If we
perform the connector cmdline parsing as soon as we initialise the
connector, that cmdline mode and forced status is then available even if
the fbdev helper is not compiled in or never called.

We also then expose the cmdline user mode in the connector mode lists.

v2: Rebase after connector->name upheaval.

v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely
simplifies things while at that.

v4: Fix checkpatch.

v5: Select FB_CMDLINE to adapt to the changed fbdev patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Cc: dri-devel@lists.freedesktop.org
Cc: Julia Lemire <jlemire@matrox.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm: Warn when leaking flip events on close

Warn when there are events on the file_priv->event_list just before
file_priv gets freed. This can occur if the driver doesn't clean up
pending page flip events in ->preclose().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm: idiot-proof vblank

After spending slightly more time than I'd care to admit debugging the
various and presumably spectacular way things fail when you pass too low
a value to drm_vblank_init() (thanks console-lock for not letting me see
the carnage!), I decided it might be a good idea to add some sanity
checking.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
staging: iio: accel: sca3000_core.c: Adjust code to fit 80-chars limit

Signed-off-by: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
staging: iio: accel: Add blank lines between declarations and code

This patch adds missing blank lines between declarations and code and
fixes lines starting by spaces, satisfying checkpatch.pl.

Signed-off-by: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: fix error return code

Convert a zero return value on error to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}

// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
staging: iio: adis16060: Fix coding style problem

This patch fixes a warning from checkpatch.pl script :
"WARNING: Missing a blank line after declarations"

Signed-off-by: Oussama Jabbari <oussama.jabbari@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: accel: kxcjk-1013: support runtime pm

In an effort to improve raw read performance and at the same time enter
low power state at every possible chance.
For raw reads, it will keep the system powered on for a default or user
specified time, via autosuspend_delay attribute of device power.
This will help read multiple samples without power on/off sequence.
For triggers it will keep the system on till, requested to be turned
off by trigger state by utilizing run time PM usage counters.

When runtime pm is not enabled, then it keeps the chip in operation
mode always.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: accel: kxcjk-1013: Set adjustable range

This chip can support 3 different ranges. Allowing range specification.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: accel: BMC150 accel support

This change implements BMC150 accelerometer driver. A BMC150 package
consist of a compass and an accelerometer. This driver only implements
accelerometer part.
Spec downloaded from:
http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-03.pdf

This sensor chip supports many advanced features, but this driver
implements minimum feature set which is a must to be useful.
This driver can be enhanced incrementally.
If the sensor vendor wants to update full featured version, they
can substitute or enhance this driver when they get chance.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>