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

staging: r8192e_pci: fix htons error

2014-06-11T18:54:12+00:00

commit 9326c5ca0982f548cc08c0cffb14dcbd020f3d43 upstream.

A sparse error fixup removed a htons() which is required for the driver
to function. This patch puts the htons() back and fixes the sparse
warning correctly by changing the left side cast.

Signed-off-by: Sean MacLennan 
Signed-off-by: Greg Kroah-Hartman

Staging: speakup: Update __speakup_paste_selection() tty (ab)usage to match vt

2014-06-11T18:54:12+00:00

commit 28a821c306889b9f2c3fff49abedc9b2c743eb73 upstream.

This function is largely a duplicate of paste_selection() in
drivers/tty/vt/selection.c, but with its own selection state.  The
speakup selection mechanism should really be merged with vt.

For now, apply the changes from 'TTY: vt, fix paste_selection ldisc
handling', 'tty: Make ldisc input flow control concurrency-friendly',
and 'tty: Fix unsafe vt paste_selection()'.

References: https://bugs.debian.org/735202
References: https://bugs.debian.org/744015
Reported-by: Paul Gevers 
Reported-and-tested-by: Jarek Czekalski 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: ni_daq_700: add mux settling delay

2014-06-11T18:54:12+00:00

commit ffed54dced86723f352323f15789d9ad6bee25e1 upstream.

I got a patch from the original author, Fred Brooks, to add a small
settling delay after setting the AI channel multiplexor.  The lack of
delay resulted in unstable or scrambled data on faster processors.

Signed-off-by: Ian Abbott 
Reported-by: Fred Brooks 
Signed-off-by: Greg Kroah-Hartman

Staging: speakup: Move pasting into a work item

2014-06-11T18:54:11+00:00

commit d7500135802ca55b3f4e01a16544e8b34082f8c3 upstream.

Input is handled in softirq context, but when pasting we may
need to sleep.  speakup_paste_selection() currently tries to
bodge this by busy-waiting if in_atomic(), but that doesn't
help because the ldisc may also sleep.

For bonus breakage, speakup_paste_selection() changes the
state of current, even though it's not running in process
context.

Move it into a work item and make sure to cancel it on exit.

References: https://bugs.debian.org/735202
References: https://bugs.debian.org/744015
Reported-by: Paul Gevers 
Reported-and-tested-by: Jarek Czekalski 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

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