linux-toradex.git/drivers, branch v2.6.27.54 Linux kernel for Apalis and Colibri modules apm_power: Add missing break statement 2010-09-20T20:03:22+00:00 Anton Vorontsov cbouatmailru@gmail.com 2010-09-07T20:10:26+00:00 7a0e4cc1437156ac650b52653f1cd244ecfe0598 commit 1d220334d6a8a711149234dc5f98d34ae02226b8 upstream. The missing break statement causes wrong capacity calculation for batteries that report energy. Reported-by: d binderman <dcb314@hotmail.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 1d220334d6a8a711149234dc5f98d34ae02226b8 upstream.

The missing break statement causes wrong capacity calculation for
batteries that report energy.

Reported-by: d binderman <dcb314@hotmail.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
hwmon: (f75375s) Do not overwrite values read from registers 2010-09-20T20:03:22+00:00 Guillem Jover guillem@hadrons.org 2010-09-17T15:24:12+00:00 a804b54dcb96b45c38443c8128123a9b7a291346 commit c3b327d60bbba3f5ff8fd87d1efc0e95eb6c121b upstream. All bits in the values read from registers to be used for the next write were getting overwritten, avoid doing so to not mess with the current configuration. Signed-off-by: Guillem Jover <guillem@hadrons.org> Cc: Riku Voipio <riku.voipio@iki.fi> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit c3b327d60bbba3f5ff8fd87d1efc0e95eb6c121b upstream.

All bits in the values read from registers to be used for the next
write were getting overwritten, avoid doing so to not mess with the
current configuration.

Signed-off-by: Guillem Jover <guillem@hadrons.org>
Cc: Riku Voipio <riku.voipio@iki.fi>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
hwmon: (f75375s) Shift control mode to the correct bit position 2010-09-20T20:03:21+00:00 Guillem Jover guillem@hadrons.org 2010-09-17T15:24:11+00:00 14df2c15035622fbc6830509d18b4256c81bbbfa commit 96f3640894012be7dd15a384566bfdc18297bc6c upstream. The spec notes that fan0 and fan1 control mode bits are located in bits 7-6 and 5-4 respectively, but the FAN_CTRL_MODE macro was making the bits shift by 5 instead of by 4. Signed-off-by: Guillem Jover <guillem@hadrons.org> Cc: Riku Voipio <riku.voipio@iki.fi> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 96f3640894012be7dd15a384566bfdc18297bc6c upstream.

The spec notes that fan0 and fan1 control mode bits are located in bits
7-6 and 5-4 respectively, but the FAN_CTRL_MODE macro was making the
bits shift by 5 instead of by 4.

Signed-off-by: Guillem Jover <guillem@hadrons.org>
Cc: Riku Voipio <riku.voipio@iki.fi>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ath9k_hw: fix parsing of HT40 5 GHz CTLs 2010-09-20T20:03:20+00:00 Luis R. Rodriguez lrodriguez@atheros.com 2010-08-30T23:26:33+00:00 d14a2c2005c205bcd6742cac79dacd69436603b6 commit 904879748d7439a6dabdc6be9aad983e216b027d upstream. The 5 GHz CTL indexes were not being read for all hardware devices due to the masking out through the CTL_MODE_M mask being one bit too short. Without this the calibrated regulatory maximum values were not being picked up when devices operate on 5 GHz in HT40 mode. The final output power used for Atheros devices is the minimum between the calibrated CTL values and what CRDA provides. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 904879748d7439a6dabdc6be9aad983e216b027d upstream.

The 5 GHz CTL indexes were not being read for all hardware
devices due to the masking out through the CTL_MODE_M mask
being one bit too short. Without this the calibrated regulatory
maximum values were not being picked up when devices operate
on 5 GHz in HT40 mode. The final output power used for Atheros
devices is the minimum between the calibrated CTL values and
what CRDA provides.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: io_ti: check firmware version before updating 2010-08-26T23:40:14+00:00 Greg Kroah-Hartman gregkh@suse.de 2010-08-17T22:15:37+00:00 7bb7a0dd0031031e1bd5d41cbcd992ab925eaca1 commit 0827a9ff2bbcbb03c33f1a6eb283fe051059482c upstream. If we can't read the firmware for a device from the disk, and yet the device already has a valid firmware image in it, we don't want to replace the firmware with something invalid. So check the version number to be less than the current one to verify this is the correct thing to do. Reported-by: Chris Beauchamp <chris@chillibean.tv> Tested-by: Chris Beauchamp <chris@chillibean.tv> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 0827a9ff2bbcbb03c33f1a6eb283fe051059482c upstream.

If we can't read the firmware for a device from the disk, and yet the
device already has a valid firmware image in it, we don't want to
replace the firmware with something invalid.  So check the version
number to be less than the current one to verify this is the correct
thing to do.


Reported-by: Chris Beauchamp <chris@chillibean.tv>
Tested-by: Chris Beauchamp <chris@chillibean.tv>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: add device IDs for igotu to navman 2010-08-26T23:40:13+00:00 Ross Burton ross@linux.intel.com 2010-08-06T15:36:39+00:00 38cebc0e22ee07f456f99401c559bb621e370e64 commit 0eee6a2b2a52e17066a572d30ad2805d3ebc7508 upstream. I recently bought a i-gotU USB GPS, and whilst hunting around for linux support discovered this post by you back in 2009: http://kerneltrap.org/mailarchive/linux-usb/2009/3/12/5148644 >Try the navman driver instead. You can either add the device id to the > driver and rebuild it, or do this before you plug the device in: > modprobe navman > echo -n "0x0df7 0x0900" > /sys/bus/usb-serial/drivers/navman/new_id > > and then plug your device in and see if that works. I can confirm that the navman driver works with the right device IDs on my i-gotU GT-600, which has the same device IDs. Attached is a patch adding the IDs. From: Ross Burton <ross@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 0eee6a2b2a52e17066a572d30ad2805d3ebc7508 upstream.

I recently bought a i-gotU USB GPS, and whilst hunting around for linux
support discovered this post by you back in 2009:

http://kerneltrap.org/mailarchive/linux-usb/2009/3/12/5148644

>Try the navman driver instead.  You can either add the device id to the
> driver and rebuild it, or do this before you plug the device in:
> 	modprobe navman
> 	echo -n "0x0df7 0x0900" > /sys/bus/usb-serial/drivers/navman/new_id
>
> and then plug your device in and see if that works.

I can confirm that the navman driver works with the right device IDs on
my i-gotU GT-600, which has the same device IDs.  Attached is a patch
adding the IDs.

From: Ross Burton <ross@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drm: stop information leak of old kernel stack. 2010-08-26T23:40:13+00:00 Dave Airlie airlied@redhat.com 2010-08-17T04:46:00+00:00 2afa902362e67ff39a9d0f5d3523ded05a1b7c70 commit b9f0aee83335db1f3915f4e42a5e21b351740afd upstream. non-critical issue, CVE-2010-2803 Userspace controls the amount of memory to be allocate, so it can get the ioctl to allocate more memory than the kernel uses, and get access to kernel stack. This can only be done for processes authenticated to the X server for DRI access, and if the user has DRI access. Fix is to just memset the data to 0 if the user doesn't copy into it in the first place. Reported-by: Kees Cook <kees@ubuntu.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit b9f0aee83335db1f3915f4e42a5e21b351740afd upstream.

non-critical issue, CVE-2010-2803

Userspace controls the amount of memory to be allocate, so it can
get the ioctl to allocate more memory than the kernel uses, and get
access to kernel stack. This can only be done for processes authenticated
to the X server for DRI access, and if the user has DRI access.

Fix is to just memset the data to 0 if the user doesn't copy into
it in the first place.

Reported-by: Kees Cook <kees@ubuntu.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
md/raid10: fix deadlock with unaligned read during resync 2010-08-13T20:50:36+00:00 NeilBrown neilb@suse.de 2010-08-07T11:17:00+00:00 ea77f594f059adbc1f5b92650890a86b8464151b commit 51e9ac77035a3dfcb6fc0a88a0d80b6f99b5edb1 upstream. If the 'bio_split' path in raid10-read is used while resync/recovery is happening it is possible to deadlock. Fix this be elevating ->nr_waiting for the duration of both parts of the split request. This fixes a bug that has been present since 2.6.22 but has only started manifesting recently for unknown reasons. It is suitable for and -stable since then. Reported-by: Justin Bronder <jsbronder@gentoo.org> Tested-by: Justin Bronder <jsbronder@gentoo.org> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 51e9ac77035a3dfcb6fc0a88a0d80b6f99b5edb1 upstream.

If the 'bio_split' path in raid10-read is used while
resync/recovery is happening it is possible to deadlock.
Fix this be elevating ->nr_waiting for the duration of both
parts of the split request.

This fixes a bug that has been present since 2.6.22
but has only started manifesting recently for unknown reasons.
It is suitable for and -stable since then.

Reported-by:  Justin Bronder <jsbronder@gentoo.org>
Tested-by:  Justin Bronder <jsbronder@gentoo.org>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
PCI: disable MSI on VIA K8M800 2010-08-13T20:50:35+00:00 Tejun Heo tj@kernel.org 2010-05-23T08:22:55+00:00 0945d6a3e9242b63be63c31f4759098f94accf9e commit 549e15611b4ac1de51ef0e0a79c2704f50a638a2 upstream. MSI delivery from on-board ahci controller doesn't work on K8M800. At this point, it's unclear whether the culprit is with the ahci controller or the host bridge. Given the track record and considering the rather minimal impact of MSI, disabling it seems reasonable. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Rainer Hurtado Navarro <publio.escipion.el.africano@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 549e15611b4ac1de51ef0e0a79c2704f50a638a2 upstream.

MSI delivery from on-board ahci controller doesn't work on K8M800.  At
this point, it's unclear whether the culprit is with the ahci
controller or the host bridge.  Given the track record and considering
the rather minimal impact of MSI, disabling it seems reasonable.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Rainer Hurtado Navarro <publio.escipion.el.africano@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
nvram: Fix write beyond end condition; prove to gcc copy is safe 2010-08-13T20:50:34+00:00 H. Peter Anvin hpa@zytor.com 2009-12-11T23:48:23+00:00 8f0b4f678e7f82e415413643a22604925929a157 commit a01c7800420d2c294ca403988488a635d4087a6d upstream. In nvram_write, first of all, correctly handle the case where the file pointer is already beyond the end; we should return EOF in that case. Second, make the logic a bit more explicit so that gcc can statically prove that the copy_from_user() is safe. Once the condition of the beyond-end filepointer is eliminated, the copy is safe but gcc can't prove it, causing build failures for i386 allyesconfig. Third, eliminate the entirely superfluous variable "len", and just use the passed-in variable "count" instead. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Wim Van Sebroeck <wim@iguana.be> Cc: Frederic Weisbecker <fweisbec@gmail.com> LKML-Reference: <tip-*@git.kernel.org> Cc: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit a01c7800420d2c294ca403988488a635d4087a6d upstream.

In nvram_write, first of all, correctly handle the case where the file
pointer is already beyond the end; we should return EOF in that case.

Second, make the logic a bit more explicit so that gcc can statically
prove that the copy_from_user() is safe.  Once the condition of the
beyond-end filepointer is eliminated, the copy is safe but gcc can't
prove it, causing build failures for i386 allyesconfig.

Third, eliminate the entirely superfluous variable "len", and just use
the passed-in variable "count" instead.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <tip-*@git.kernel.org>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>