linux-toradex.git/drivers/staging, branch v3.14.4

staging: r8188eu: Calling rtw_get_stainfo() with a NULL sta_addr will return NULL

2014-05-06T14:59:26+00:00

commit 9452bf560273e4de2395ffdd79024debfb0c1290 upstream.

This makes the follow-on check for psta != NULL pointless and makes
the whole exercise rather pointless. This is another case of why
blindly zero-initializing variables when they are declared is bad.

Reported-by: Jes Sorensen 
Signed-off-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: usbdux: bug fix for accessing 'ao_chanlist' in private data

2014-05-06T14:59:26+00:00

commit 2704f807f9498054b8153002bafa3e818079e9a5 upstream.

In usbdux_ao_cmd(), the channels for the command are transfered from the
cmd->chanlist and stored in the private data 'ao_chanlist'. The channel
numbers are bit-shifted when stored so that they become the "command"
that is transfered to the device. The channel to command conversion
results in the 'ao_chanlist' having these values for the channels:

  channel 0 -> ao_chanlist = 0x00
  channel 1 -> ao_chanlist = 0x40
  channel 2 -> ao_chanlist = 0x80
  channel 3 -> ao_chanlist = 0xc0

The problem is, the usbduxsub_ao_isoc_irq() function uses the 'chan' value
from 'ao_chanlist' to access the 'ao_readback' array in the private data.
So instead of accessing the array as 0, 1, 2, 3, it accesses it as 0x00,
0x40, 0x80, 0xc0.

Fix this by storing the raw channel number in 'ao_chanlist' and doing the
bit-shift when creating the command.

Fixes: a998a3db530bff80 "staging: comedi: usbdux: cleanup the private data 'outBuffer'"
Signed-off-by: H Hartley Sweeten 
Reviewed-by: Ian Abbott 
Acked-by: Bernd Porr 
Signed-off-by: Greg Kroah-Hartman

staging: r8712u: Fix case where ethtype was never obtained and always be checked against 0

2014-05-06T14:59:26+00:00

commit f764cd68d9036498f08fe8834deb6a367b5c2542 upstream.

Zero-initializing ether_type masked that the ether type would never be
obtained for 8021x packets and the comparison against eapol_type
would always fail.

Reported-by: Jes Sorensen 
Signed-off-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman

staging:serqt_usb2: Fix sparse warning restricted __le16 degrades to integer

2014-05-06T14:59:26+00:00

commit abe5d64d1a74195a44cd14624f8178b9f48b7cc7 upstream.

This patch fixes the following sparse warning :
drivers/staging/serqt_usb2/serqt_usb2.c:727:40: warning: restricted __le16 degrades to integer

Signed-off-by: Himangi Saraogi 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: fix circular locking dependency in comedi_mmap()

2014-04-27T00:19:03+00:00

commit b34aa86f12e8848ba453215602c8c50fa63c4cb3 upstream.

Mmapping a comedi data buffer with lockdep checking enabled produced the
following kernel debug messages:

======================================================
[ INFO: possible circular locking dependency detected ]
3.5.0-rc3-ija1+ #9 Tainted: G         C
-------------------------------------------------------
comedi_test/4160 is trying to acquire lock:
 (&dev->mutex#2){+.+.+.}, at: [] comedi_mmap+0x57/0x1d9 [comedi]

but task is already holding lock:
 (&mm->mmap_sem){++++++}, at: [] vm_mmap_pgoff+0x41/0x76

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&mm->mmap_sem){++++++}:
       [] lock_acquire+0x97/0x105
       [] might_fault+0x6d/0x90
       [] do_devinfo_ioctl.isra.7+0x11e/0x14c [comedi]
       [] comedi_unlocked_ioctl+0x256/0xe48 [comedi]
       [] vfs_ioctl+0x18/0x34
       [] do_vfs_ioctl+0x382/0x43c
       [] sys_ioctl+0x42/0x65
       [] system_call_fastpath+0x16/0x1b

-> #0 (&dev->mutex#2){+.+.+.}:
       [] __lock_acquire+0x101d/0x1591
       [] lock_acquire+0x97/0x105
       [] mutex_lock_nested+0x46/0x2a4
       [] comedi_mmap+0x57/0x1d9 [comedi]
       [] mmap_region+0x281/0x492
       [] do_mmap_pgoff+0x26b/0x2a7
       [] vm_mmap_pgoff+0x5d/0x76
       [] sys_mmap_pgoff+0xc7/0x10d
       [] sys_mmap+0x16/0x20
       [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&mm->mmap_sem);
                               lock(&dev->mutex#2);
                               lock(&mm->mmap_sem);
  lock(&dev->mutex#2);

 *** DEADLOCK ***

To avoid the circular dependency, just try to get the lock in
`comedi_mmap()` instead of blocking.  Since the comedi device's main mutex
is heavily used, do a down-read of its `attach_lock` rwsemaphore
instead.  Trying to down-read `attach_lock` should only fail if
some task has down-write locked it, and that is only done while the
comedi device is being attached to or detached from a low-level hardware
device.

Unfortunately, acquiring the `attach_lock` doesn't prevent another
task replacing the comedi data buffer we are trying to mmap.  The
details of the buffer are held in a `struct comedi_buf_map` and pointed
to by `s->async->buf_map` where `s` is the comedi subdevice whose buffer
we are trying to map.  The `struct comedi_buf_map` is already reference
counted with a `struct kref`, so we can stop it being freed prematurely.

Modify `comedi_mmap()` to call new function
`comedi_buf_map_from_subdev_get()` to read the subdevice's current
buffer map pointer and increment its reference instead of accessing
`async->buf_map` directly.  Call `comedi_buf_map_put()` to decrement the
reference once the buffer map structure has been dealt with.  (Note that
`comedi_buf_map_put()` does nothing if passed a NULL pointer.)

`comedi_buf_map_from_subdev_get()` checks the subdevice's buffer map
pointer has been set and the buffer map has been initialized enough for
`comedi_mmap()` to deal with it (specifically, check the `n_pages`
member has been set to a non-zero value).  If all is well, the buffer
map's reference is incremented and a pointer to it is returned.  The
comedi subdevice's spin-lock is used to protect the checks.  Also use
the spin-lock in `__comedi_buf_alloc()` and `__comedi_buf_free()` to
protect changes to the subdevice's buffer map structure pointer and the
buffer map structure's `n_pages` member.  (This checking of `n_pages` is
a bit clunky and I [Ian Abbott] plan to deal with it in the future.)

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

staging: comedi: 8255_pci: initialize MITE data window

2014-04-27T00:19:03+00:00

commit 268d1e799663b795cba15c64f5d29407786a9dd4 upstream.

According to National Instruments' PCI-DIO-96/PXI-6508/PCI-6503 User
Manual, the physical address in PCI BAR1 needs to be OR'ed with 0x80 and
written to register offset 0xC0 in the "MITE" registers (BAR0).  Do so
during initialization of the National Instruments boards handled by the
"8255_pci" driver.  The boards were previously handled by the
"ni_pcidio" driver, where the initialization was done by `mite_setup()`
in the "mite" module.  The "mite" module comes with too much extra
baggage for the "8255_pci" driver to deal with so use a local, simpler
initialization function.

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

staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()

2014-03-05T00:20:01+00:00

The function c4_ioctl() writes data from user in ifr->ifr_data
to the kernel struct data arg, without any iolen bounds checking.
This can lead to a arbitrary write outside of the struct data arg.
Corrected by adding bounds-checking of iolen before the copy_from_user().

Signed-off-by: Salva Peiró 
Signed-off-by: Greg Kroah-Hartman

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

2014-03-01T01:08:03+00:00

Jonathan writes:

Fourth set of IIO fixes for the 3.14 kernel.

A single line patch fixing a regression that was introduced in 3.13 in the
reworking of the mxs touch screen and ADC drivers to be interrupt rather
than polling driven.  It resulted in a stray double reporting of the release
coordinate in the touch screen driver.  The bug lay in the adc side
of the driver which left the statemachine in the wrong state.

staging: r8188eu: Add new device ID

2014-02-25T01:02:31+00:00

The D-Link DWA-123 REV D1 with USB ID 2001:3310 uses this driver.

Signed-off-by: Manu Gupta 
Signed-off-by: Larry Finger 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

staging:iio:adc:MXS:LRADC: fix touchscreen statemachine

2014-02-24T21:55:50+00:00

Releasing the touchscreen lets the internal statemachine left in a wrong state.
Due to this the release coordinate will be reported again by accident when the next
touchscreen event happens. This change sets up the correct state when waiting
for the next touchscreen event.

This has led to reported issues with calibrating the touchscreen.
Bug was introduced somewhere in the series that began with
18da755de59b406ce2371a55fb15ed676eb08ed2
Staging/iio/adc/touchscreen/MXS: add proper clock handling
in which the way this driver worked was substantially changed
to be interrupt driven rather than relying on a busy loop.
This was a regression in the 3.13 kernel.

Signed-off-by: Juergen Beisert 
Tested-by: Alexandre Belloni 
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron