linux-stable.git/drivers/staging, branch v4.7.3

staging: comedi: ni_mio_common: fix wrong insn_write handler

2016-09-07T06:34:55+00:00

commit 5ca05345c56cb979e1a25ab6146437002f95cac8 upstream.

For counter subdevices, the `s->insn_write` handler is being set to the
wrong function, `ni_tio_insn_read()`.  It should be
`ni_tio_insn_write()`.

Signed-off-by: Ian Abbott 
Reported-by: Éric Piel 
Fixes: 10f74377eec3 ("staging: comedi: ni_tio: make ni_tio_winsn() a
  proper comedi (*insn_write)"
Signed-off-by: Greg Kroah-Hartman

staging: comedi: ni_mio_common: fix AO inttrig backwards compatibility

2016-09-07T06:34:55+00:00

commit f0f4b0cc3a8cffd983f5940d46cd0227f3f5710a upstream.

Commit ebb657babfa9 ("staging: comedi: ni_mio_common: clarify the
cmd->start_arg validation and use") introduced a backwards compatibility
issue in the use of asynchronous commands on the AO subdevice when
`start_src` is `TRIG_EXT`. Valid values for `start_src` are `TRIG_INT`
(for internal, software trigger), and `TRIG_EXT` (for external trigger).
When set to `TRIG_EXT`. In both cases, the driver relies on an
internal, software trigger to set things up (allowing the user
application to write sufficient samples to the data buffer before the
trigger), so it acts as a software "pre-trigger" in the `TRIG_EXT` case.
The software trigger is handled by `ni_ao_inttrig()`.

Prior to the above change, when `start_src` was `TRIG_INT`, `start_arg`
was required to be 0, and `ni_ao_inttrig()` checked that the software
trigger number was also 0. After the above change, when `start_src` was
`TRIG_INT`, any value was allowed for `start_arg`, and `ni_ao_inttrig()`
checked that the software trigger number matched this `start_arg` value.
The backwards compatibility issue is that the internal trigger number
now has to match `start_arg` when `start_src` is `TRIG_EXT` when it
previously had to be 0.

Fix the backwards compatibility issue in `ni_ao_inttrig()` by always
allowing software trigger number 0 when `start_src` is something other
than `TRIG_INT`.

Thanks to Spencer Olson for reporting the issue.

Signed-off-by: Ian Abbott
Reported-by: Spencer Olson
Fixes: ebb657babfa9 ("staging: comedi: ni_mio_common: clarify the cmd->start_arg validation and use")
Reviewed-by: H Hartley Sweeten
Signed-off-by: Greg Kroah-Hartman

staging: comedi: comedi_test: fix timer race conditions

2016-09-07T06:34:55+00:00

commit 403fe7f34e3327ddac2e06a15e76a293d613381e upstream.

Commit 73e0e4dfed4c ("staging: comedi: comedi_test: fix timer lock-up")
fixed a lock-up in the timer routine `waveform_ai_timer()` (which was
called `waveform_ai_interrupt()` at the time) caused by
commit 240512474424 ("staging: comedi: comedi_test: use
comedi_handle_events()").  However, it introduced a race condition that
can result in the timer routine misbehaving, such as accessing freed
memory or dereferencing a NULL pointer.

73e0... changed the timer routine to do nothing unless a
`WAVEFORM_AI_RUNNING` flag was set, and changed `waveform_ai_cancel()`
to clear the flag and replace a call to `del_timer_sync()` with a call
to `del_timer()`.  `waveform_ai_cancel()` may be called from the timer
routine itself (via `comedi_handle_events()`), or from `do_cancel()`.
(`do_cancel()` is called as a result of a file operation (usually a
`COMEDI_CANCEL` ioctl command, or a release), or during device removal.)
When called from `do_cancel()`, the call to `waveform_ai_cancel()` is
followed by a call to `do_become_nonbusy()`, which frees up stuff for
the current asynchronous command under the assumption that it is now
safe to do so.  The race condition occurs when the timer routine
`waveform_ai_timer()` checks the `WAVEFORM_AI_RUNNING` flag just before
it is cleared by `waveform_ai_cancel()`, and is still running during the
call to `do_become_nonbusy()`.  In particular, it can lead to a NULL
pointer dereference:

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] waveform_ai_timer+0x17d/0x290 [comedi_test]

That corresponds to this line in `waveform_ai_timer()`:

		unsigned int chanspec = cmd->chanlist[async->cur_chan];

but `do_become_nonbusy()` frees `cmd->chanlist` and sets it to `NULL`.

Fix the race by calling `del_timer_sync()` instead of `del_timer()` in
`waveform_ai_cancel()` when not in an interrupt context.  The only time
`waveform_ai_cancel()` is called in an interrupt context is when it is
called from the timer routine itself, via `comedi_handle_events()`.

There is no longer any need for the `WAVEFORM_AI_RUNNING` flag, so get
rid of it.

The bug was copied from the AI subdevice to the AO when support for
commands on the AO subdevice was added by commit 0cf55bbef2f9 ("staging:
comedi: comedi_test: implement commands on AO subdevice").  That
involves the timer routine `waveform_ao_timer()`, the comedi "cancel"
routine `waveform_ao_cancel()`, and the flag `WAVEFORM_AO_RUNNING`.  Fix
it in the same way as for the AI subdevice.

Fixes: 73e0e4dfed4c ("staging: comedi: comedi_test: fix timer lock-up")
Fixes: 0cf55bbef2f9 ("staging: comedi: comedi_test: implement commands
 on AO subdevice")
Reported-by: Éric Piel 
Signed-off-by: Ian Abbott 
Cc: Éric Piel 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: daqboard2000: bug fix board type matching code

2016-09-07T06:34:55+00:00

commit 80e162ee9b31d77d851b10f8c5299132be1e120f upstream.

`daqboard2000_find_boardinfo()` is supposed to check if the
DaqBoard/2000 series model is supported, based on the PCI subvendor and
subdevice ID.  The current code is wrong as it is comparing the PCI
device's subdevice ID to an expected, fixed value for the subvendor ID.
It should be comparing the PCI device's subvendor ID to this fixed
value.  Correct it.

Fixes: 7e8401b23e7f ("staging: comedi: daqboard2000: add back subsystem_device check")
Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

staging/lustre/llite: Close atomic_open race with several openers

2016-09-07T06:34:55+00:00

commit 99f1c013194e64d4b67d5d318148303b0e1585e1 upstream.

Right now, if it's an open of a negative dentry, a race is possible
with several openers who all try to instantiate/rehash the same
dentry and would hit a BUG_ON in d_add.
But in fact if we got a negative dentry in atomic_open, that means
we just revalidated it so no point in talking to MDS at all,
just return ENOENT and make the race go away completely.

Signed-off-by: Oleg Drokin 
Signed-off-by: Greg Kroah-Hartman

staging: iio: accel: fix error check

2016-06-26T14:57:02+00:00

sca3000_read_ctrl_reg() returns a negative number on failure, check for
this instead of zero.

Signed-off-by: Luis de Bethencourt 
Cc: 
Signed-off-by: Jonathan Cameron

Merge tag 'iio-fixes-for-4.7b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus

2016-06-22T16:57:28+00:00

Jonathan writes:

Second set of IIO fixes for the 4.7 cycle.

This includes one tracked regression (Arnd's patch for the ad7606).
The other two have I think always been broken.

* inv_mpu6050
  - Fix a use after free in the ACPI code.
* ad5933
  - The code for setting the cycles had a bug that meant it was simply wrong.
* ad7606_spi
  - Fix a regression that got introduced in a buggy cleanup of a sparse
    warning.

Revert "Staging: rtl8188eu: rtw_efuse: Use sizeof type *pointer instead of sizeof type."

2016-06-17T18:21:45+00:00

This reverts commit b5e12ec38331 ("Staging: rtl8188eu: rtw_efuse: Use
sizeof type *pointer instead of sizeof type.").

This commit is wrong, the rtw_malloc2d helper function takes the size of
the array elements as its 3th argument, whereas sizeof(*eFuseWord)
gives the size of a pointer instead of the size of a u16.

Since sizeof(void *) > sizeof(u16) this has no adverse effects, but it
is still wrong.

Cc: Sandhya Bankar 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

Revert "Staging: drivers: rtl8188eu: use sizeof(*ptr) instead of sizeof(struct)"

2016-06-17T18:21:45+00:00

This reverts commit 99aded71b52c ("Staging: drivers: rtl8188eu: use
sizeof(*ptr) instead of sizeof(struct)").

This commit is wrong, as adapt->HalData has a type of "void *", so
now we are allocating a much to small struct, which causes the driver
to overwrite random memory which leads to a non working driver and
various system crashes.

Cc: Jacky Boen 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

staging: iio: ad5933: fix order of cycle conditions

2016-06-11T17:37:13+00:00

Correctly handle the settling time cycles value. The else branch is an
impossible condition, > 1022 in the else branch of > 511. Flipping the order.

Based on the Table 13 at the bottom of Page 25 of the Data Sheet:
http://www.analog.com/media/en/technical-documentation/data-sheets/AD5933.pdf

Signed-off-by: Luis de Bethencourt 
Reviewed-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron