linux-stable.git/drivers/staging, branch linux-3.19.y Linux kernel stable tree staging: vt6655: use ieee80211_tx_info to select packet type. 2015-05-06T20:01:45+00:00 Malcolm Priestley tvboxspy@gmail.com 2015-04-01T21:32:52+00:00 4b4c40a89685298337f978f6195da45923324c35 commit a6388e68321a1e0a0f408379c2a36396807745b3 upstream. 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 <tvboxspy@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a6388e68321a1e0a0f408379c2a36396807745b3 upstream.

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 <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: android: sync: Fix memory corruption in sync_timeline_signal(). 2015-05-06T20:01:45+00:00 Alistair Strachan alistair.strachan@imgtec.com 2015-03-24T21:51:31+00:00 11ebd79a59cf22f9790dbb102a431b0151437ec5 commit 8e43c9c75faf2902955bd2ecd7a50a8cc41cb00a upstream. 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 <alistair.strachan@imgtec.com> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Colin Cross <ccross@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8e43c9c75faf2902955bd2ecd7a50a8cc41cb00a upstream.

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 <alistair.strachan@imgtec.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Colin Cross <ccross@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: panel: fix lcd type 2015-05-06T20:01:45+00:00 Sudip Mukherjee sudipm.mukherjee@gmail.com 2015-03-24T10:59:32+00:00 433a727c236a599f5adae6dd70d55293013dd641 commit 2c20d92dad5db6440cfa88d811b69fd605240ce4 upstream. 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. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Acked-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2c20d92dad5db6440cfa88d811b69fd605240ce4 upstream.

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.

Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Acked-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel 2015-04-29T08:23:46+00:00 Ian Abbott abbotti@mev.co.uk 2015-02-27T16:04:42+00:00 b52d86967f6a2cab714dc8424cf7a0c1c559a958 commit abe46b8932dd9a6dfc3698e3eb121809b7b9ed28 upstream. 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 <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit abe46b8932dd9a6dfc3698e3eb121809b7b9ed28 upstream.

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 <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vt6655: Fix late setting of byRFType. 2015-04-13T12:03:54+00:00 Malcolm Priestley tvboxspy@gmail.com 2015-03-07T17:04:55+00:00 99aadf9b8e6344eba5e841446fc16370636e0f40 commit 1f51d5801859e0b382dcc8f06875811d63ec8953 upstream. byRFType is not set prior to registration of mac80211 causing unpredictable operation after channel scans. With byRFType unset all channels are enabled this causes tx power to be set to values not present its eeprom. Move setting of this variable to vt6655_probe. byRFType must have a mask set. byRevId not used by driver and is removed. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1f51d5801859e0b382dcc8f06875811d63ec8953 upstream.

byRFType is not set prior to registration of mac80211 causing
unpredictable operation after channel scans.

With byRFType unset all channels are enabled this causes tx power
to be set to values not present its eeprom.

Move setting of this variable to vt6655_probe.

byRFType must have a mask set. byRevId not used by driver and
is removed.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vt6655: RFbSetPower fix missing rate RATE_12M 2015-04-13T12:03:54+00:00 Malcolm Priestley tvboxspy@gmail.com 2015-03-07T17:04:54+00:00 cb5e2a71141b7527472d7727ef4c76c90018ebe7 commit 40c8790bcb7ac74f3038153cd09310e220c6a1df upstream. 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 <tvboxspy@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 40c8790bcb7ac74f3038153cd09310e220c6a1df upstream.

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 <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: vt6656: vnt_rf_setpower: fix missing rate RATE_12M 2015-04-13T12:03:54+00:00 Malcolm Priestley tvboxspy@gmail.com 2015-03-07T16:36:37+00:00 ab4eba1a775b8a1eaf94ffe1abd2d588943460df commit 163fe301b9f78b6de57d0014eafe504fd20c0cd4 upstream. 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 <tvboxspy@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 163fe301b9f78b6de57d0014eafe504fd20c0cd4 upstream.

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 <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: cb_pcidas64: fix incorrect AI range code handling 2015-03-18T13:11:08+00:00 Ian Abbott abbotti@mev.co.uk 2015-01-19T14:47:27+00:00 330a8414f07972938cad16721d85e1f696c8d6b8 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 <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back 2015-03-18T13:11:07+00:00 Ian Abbott abbotti@mev.co.uk 2015-01-27T18:16:51+00:00 6ceed5c2a0a42ae9171338da039ef1b19efd790f 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 <abbotti@mev.co.uk> Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio: mxs-lradc: only update the buffer when its conversions have finished 2015-03-18T13:10:58+00:00 Kristina Martšenko kristina.martsenko@gmail.com 2015-01-25T16:28:22+00:00 5fc76bbea3153b71689ebd61edab3b8868b04c27 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 <kristina.martsenko@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <kristina.martsenko@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>