linux-stable.git/drivers/staging, branch v3.19.2

staging: comedi: cb_pcidas64: fix incorrect AI range code handling

2015-03-18T13:11:08+00:00

commit be8e89087ec2d2c8a1ad1e3db64bf4efdfc3c298 upstream.

The hardware range code values and list of valid ranges for the AI
subdevice is incorrect for several supported boards.  The hardware range
code values for all boards except PCI-DAS4020/12 is determined by
calling `ai_range_bits_6xxx()` based on the maximum voltage of the range
and whether it is bipolar or unipolar, however it only returns the
correct hardware range code for the PCI-DAS60xx boards.  For
PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar
ranges.  For PCI-DAS64/Mx/16 it returns the wrong code for all the
ranges and the comedi range table is incorrect.

Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new
member `ai_range_codes` of `struct pcidas64_board` to map the comedi
range table indices to the hardware range codes.  Use a new comedi range
table for the PCI-DAS64/Mx/16 boards (and the commented out variants).

Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back

2015-03-18T13:11:07+00:00

commit 42b8ce6f55facfa101462e694d33fc6bca471138 upstream.

`do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl.
This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd`
back to user-space.  (This occurs when the low-level Comedi driver's
`do_cmdtest()` handler returns non-zero to indicate a problem with the
contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has
the `CMDF_BOGUS` flag set.)

`compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible
version of the `COMEDI_CMD` ioctl.  Currently, it never copies a 32-bit
compatible version of `struct comedi_cmd` back to user-space, which is
at odds with the way the regular `COMEDI_CMD` ioctl is handled.  To fix
it, change `compat_cmd()` to copy a 32-bit compatible version of the
`struct comedi_cmd` back to user-space when the main ioctl handler
returns `-EAGAIN`.

Signed-off-by: Ian Abbott 
Reviewed-by: H Hartley Sweeten 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: only update the buffer when its conversions have finished

2015-03-18T13:10:58+00:00

commit 89bb35e200bee745c539a96666e0792301ca40f1 upstream.

Using the touchscreen while running buffered capture results in the
buffer reporting lots of wrong values, often just zeros. This is because
we push readings to the buffer every time a touchscreen interrupt
arrives, including when the buffer's own conversions have not yet
finished. So let's only push to the buffer when its conversions are
ready.

Signed-off-by: Kristina Martšenko 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions

2015-03-18T13:10:58+00:00

commit 6abe0300a1d5242f4ff89257197f284679af1a06 upstream.

Reading a channel through sysfs, or starting a buffered capture, can
occasionally turn off the touchscreen.

This is because the read_raw() and buffer preenable()/postdisable()
callbacks unschedule current conversions on all channels. If a delay
channel happens to schedule a touchscreen conversion at the same time,
the conversion gets cancelled and the touchscreen sequence stops.

This is probably related to this note from the reference manual:

	"If a delay group schedules channels to be sampled and a manual
	write to the schedule field in CTRL0 occurs while the block is
	discarding samples, the LRADC will switch to the new schedule
	and will not sample the channels that were previously scheduled.
	The time window for this to happen is very small and lasts only
	while the LRADC is discarding samples."

So make the callbacks only unschedule conversions for the channels they
use. This means channel 0 for read_raw() and channels 0-5 for the buffer
(if the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.

This is tested and fixes the issue on i.MX28, but hasn't been tested on
i.MX23.

Signed-off-by: Kristina Martšenko 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: make ADC reads not disable touchscreen interrupts

2015-03-18T13:10:58+00:00

commit 86bf7f3ef7e961e91e16dceb31ae0f583483b204 upstream.

Reading a channel through sysfs, or starting a buffered capture, will
currently turn off the touchscreen. This is because the read_raw() and
buffer preenable()/postdisable() callbacks disable interrupts for all
LRADC channels, including those the touchscreen uses.

So make the callbacks only disable interrupts for the channels they use.
This means channel 0 for read_raw() and channels 0-5 for the buffer (if
the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.

Note that only i.MX28 is affected by this issue, i.MX23 should be fine.

Signed-off-by: Kristina Martšenko 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: separate touchscreen and buffer virtual channels

2015-03-18T13:10:58+00:00

commit f81197b8a31b8fb287ae57f597b5b6841e1ece92 upstream.

The touchscreen was initially designed [1] to map all of its physical
channels to one virtual channel, leaving buffered capture to use the
remaining 7 virtual channels. When the touchscreen was reimplemented
[2], it was made to use four virtual channels, which overlap and
conflict with the channels the buffer uses.

As a result, when the buffer is enabled, the touchscreen's virtual
channels are remapped to whichever physical channels the buffer was
configured with, causing the touchscreen to read those instead of the
touch measurement channels. Effectively the touchscreen stops working.

So here we separate the channels again, giving the touchscreen 2 virtual
channels and the buffer 6. We can't give the touchscreen just 1 channel
as before, as the current pressure calculation requires 2 channels to be
read at the same time.

This makes the touchscreen continue to work during buffered capture. It
has been tested on i.MX28, but not on i.MX23.

[1] 06ddd353f5c8 ("iio: mxs: Implement support for touchscreen")
[2] dee05308f602 ("Staging/iio/adc/touchscreen/MXS: add interrupt driven
touch detection")

Signed-off-by: Kristina Martšenko 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: mxs-lradc: fix iio channel map regression

2015-03-18T13:10:58+00:00

commit 03305e535cd5cdc1079b32909bf4b2dd67d46f7f upstream.

Since commit c8231a9af8147f8a ("iio: mxs-lradc: compute temperature
from channel 8 and 9") with the removal of adc channel 9 there is
no 1-1 mapping in the channel spec.

All hwmon channel values above 9 are accessible via there index minus
one. So add a hidden iio channel 9 to fix this issue.

Signed-off-by: Stefan Wahren 
Acked-by: Alexandre Belloni 
Reviewed-by: Marek Vasut 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'staging-3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

2015-01-31T03:44:56+00:00

Pull staging tree fixes from Greg KH:
 "Here are two tiny staging tree fixes.  One for the nvec driver to
  resolve a reported problem, and one to add a MAINTAINERS entry for the
  Android drivers"

* tag 'staging-3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  MAINTAINERS: add Android driver entries
  staging: nvec: specify a platform-device base id

vm: add VM_FAULT_SIGSEGV handling support

2015-01-29T18:51:32+00:00

The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
"you should SIGSEGV" error, because the SIGSEGV case was generally
handled by the caller - usually the architecture fault handler.

That results in lots of duplication - all the architecture fault
handlers end up doing very similar "look up vma, check permissions, do
retries etc" - but it generally works.  However, there are cases where
the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.

In particular, when accessing the stack guard page, libsigsegv expects a
SIGSEGV.  And it usually got one, because the stack growth is handled by
that duplicated architecture fault handler.

However, when the generic VM layer started propagating the error return
from the stack expansion in commit fee7e49d4514 ("mm: propagate error
from stack expansion even for guard page"), that now exposed the
existing VM_FAULT_SIGBUS result to user space.  And user space really
expected SIGSEGV, not SIGBUS.

To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
duplicate architecture fault handlers about it.  They all already have
the code to handle SIGSEGV, so it's about just tying that new return
value to the existing code, but it's all a bit annoying.

This is the mindless minimal patch to do this.  A more extensive patch
would be to try to gather up the mostly shared fault handling logic into
one generic helper routine, and long-term we really should do that
cleanup.

Just from this patch, you can generally see that most architectures just
copied (directly or indirectly) the old x86 way of doing things, but in
the meantime that original x86 model has been improved to hold the VM
semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
"newer" things, so it would be a good idea to bring all those
improvements to the generic case and teach other architectures about
them too.

Reported-and-tested-by: Takashi Iwai 
Tested-by: Jan Engelhardt 
Acked-by: Heiko Carstens  # "s390 still compiles and boots"
Cc: linux-arch@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds

staging: nvec: specify a platform-device base id

2015-01-25T11:04:31+00:00

commit 6e3f62f079 (mfd: core: Fix platform-device id generation) modified
the computation of the mfd cell id. Negative numbers forbit the specification
of cell ids as we do. Fix this for now by specifying a base of 0 instead. In
the long run, this may be changed to automatic cell ids (base -2).

Fixes: 6e3f62f079
Reported-by: Misha Komarovskiy 
Signed-off-by: Marc Dietrich 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman