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

staging: vt6656: use ieee80211_tx_info to select packet type.

2015-06-10T17:42:14+00:00

[ Upstream commit b23f14302e86628625ac3982a6d23e35888755f2 ]

Information for packet type is in ieee80211_tx_info

band IEEE80211_BAND_5GHZ for PK_TYPE_11A.

IEEE80211_TX_RC_USE_CTS_PROTECT via tx_rate flags selects PK_TYPE_11GB

This ensures that the packet is always the right type.

Signed-off-by: Malcolm Priestley 
Cc:  # v3.17+
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: gdm724x: Correction of variable usage after applying ALIGN()

2015-06-10T17:42:13+00:00

[ Upstream commit 892c89d5d7ffd1bb794fe54d86c0eef18d215fab ]

Fix regression introduced by commit <29ef8a53542a>. After it writing
AT commands to /dev/GCT-ATM0 is unsuccessful (no echo, no response)
and dmesg show "gdmtty: invalid payload : 1 16 f011".

Before that commit value of dummy_cnt was only a padding size. After using
ALIGN() this value is increased by its first argument. So the following
usage of this variable needs correction.

Signed-off-by: Sławomir Demeszko 
Cc: stable  # 3.14+
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel

2015-05-17T23:12:30+00:00

[ Upstream commit abe46b8932dd9a6dfc3698e3eb121809b7b9ed28 ]

Reading of analog input channels by the `INSN_READ` comedi instruction
is broken for all except channel 0.  `pci171x_ai_insn_read()` calls
`pci171x_ai_read_sample()` with the wrong value for the third parameter.
It is supposed to be the current index in a channel list (which is
always of length 1 in this case, so the index should be 0), but instead
it is passing the actual channel number.  `pci171x_ai_read_sample()`
checks the channel number encoded in the raw sample value read from the
hardware matches the channel number stored in the specified index of the
previously set up channel list and returns `-ENODATA` if it doesn't
match.  Since the index should always be 0 in this case, the match will
fail unless the channel number is also 0.  Fix it by passing 0 as the
channel index.

Note that when the bug first appeared, it was `pci171x_ai_dropout()`
that was called with the wrong parameter value.  `pci171x_ai_dropout()`
got replaced with `pci171x_ai_read_sample()` in commit 7fd2dae2500d
("staging: comedi: adv_pci1710: introduce pci171x_ai_read_sample()").

Fixes: 16c7eb6047bb ("staging: comedi: adv_pci1710: always enable PCI171x_PARANOIDCHECK code")
Signed-off-by: Ian Abbott 
Cc: stable  # 3.16+
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: android: sync: Fix memory corruption in sync_timeline_signal().

2015-05-17T23:11:52+00:00

[ Upstream commit 8e43c9c75faf2902955bd2ecd7a50a8cc41cb00a ]

The android_fence_release() function checks for active sync points
by calling list_empty() on the list head embedded on the sync
point. However, it is only valid to use list_empty() on nodes that
have been initialized with INIT_LIST_HEAD() or list_del_init().

Because the list entry has likely been removed from the active list
by sync_timeline_signal(), there is a good chance that this
WARN_ON_ONCE() will be hit due to dangling pointers pointing at
freed memory (even though the sync drivers did nothing wrong)
and memory corruption will ensue as the list entry is removed for
a second time, corrupting the active list.

This problem can be reproduced quite easily with CONFIG_DEBUG_LIST=y
and fences with more than one sync point.

Signed-off-by: Alistair Strachan 
Cc: Maarten Lankhorst 
Cc: Greg Kroah-Hartman 
Cc: Colin Cross 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: panel: fix lcd type

2015-05-17T23:11:52+00:00

[ Upstream commit 2c20d92dad5db6440cfa88d811b69fd605240ce4 ]

the lcd type as defined in the Kconfig is not matching in the code.
as a result the rs, rw and en pins were getting interchanged.
Kconfig defines the value of PANEL_LCD to be 1 if we select custom
configuration but in the code LCD_TYPE_CUSTOM is defined as 5.

my hardware is LCD_TYPE_CUSTOM, but the pins were assigned to it
as pins of LCD_TYPE_OLD, and it was not working.
Now values are corrected with referenece to the values defined in
Kconfig and it is working.
checked on JHD204A lcd with LCD_TYPE_CUSTOM configuration.

Cc:  # 2.6.32+
Signed-off-by: Sudip Mukherjee 
Acked-by: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

vt6655: RFbSetPower fix missing rate RATE_12M

2015-04-17T00:11:44+00:00

[ Upstream commit 40c8790bcb7ac74f3038153cd09310e220c6a1df ]

When the driver sets this rate a power of zero value is set causing
data flow stoppage until another rate is tried.

Signed-off-by: Malcolm Priestley 
Cc: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: vt6656: vnt_rf_setpower: fix missing rate RATE_12M

2015-04-17T00:11:44+00:00

[ Upstream commit 163fe301b9f78b6de57d0014eafe504fd20c0cd4 ]

When the driver sets this rate a power of zero value is set causing
data flow stoppage until another rate is tried.

Signed-off-by: Malcolm Priestley 
Cc:  # v3.17+
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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

2015-03-24T01:02:48+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-24T01:02:47+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-14T19:37:20+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: Sasha Levin