Commit Graph

144841 Commits

Author SHA1 Message Date
Linus Torvalds
71019c350a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
  ASoC: Remove BROKEN from mpc5200 kconfig
  ASoC: TWL4030: Fix gain control for earpiece amplifier
  ALSA: pcm core - Avoid jiffies check for devices with BATCH flag
  ALSA: Add missing SNDRV_PCM_INFO_BATCH flag to some drivers
  ALSA: indigo-express: add missing 64KHz flags
  ASoC: Set the MPC5200 i2s driver to BROKEN status.
  ASoC: Fix logic in WM8350 master clocking check
2009-05-05 08:22:55 -07:00
Clemens Ladisch
b452e08e73 sound: via82xx: fix DXS volume range
With 5 bits and 1.5 dB per step, the DXS volume range is only 48 dB.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2009-05-05 16:01:32 +02:00
Clemens Ladisch
bd0185ceac sound: serial-u16550: fix buffer overflow
Remove most of the serial port parameters from the card longname string
because it was way too long and overflowed into the mixername string.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2009-05-05 16:01:18 +02:00
Christoph Paasch
b98b4947cb netfilter: ip6t_ipv6header: fix match on packets ending with NEXTHDR_NONE
As packets ending with NEXTHDR_NONE don't have a last extension header,
the check for the length needs to be after the check for NEXTHDR_NONE.

Signed-off-by: Christoph Paasch <christoph.paasch@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
2009-05-05 15:32:16 +02:00
Patrick McHardy
a7ca7fccac netfilter: add missing linux/types.h include to xt_LED.h
Pointed out by Dave Miller:

  CHECK   include/linux/netfilter (57 files)
/home/davem/src/GIT/net-2.6/usr/include/linux/netfilter/xt_LED.h:6: found __[us]{8,16,32,64} type without #include <linux/types.h>

Signed-off-by: Patrick McHardy <kaber@trash.net>
2009-05-05 14:31:12 +02:00
Jinyoung Park
97a775c49c ASoC: Fix errors in WM8990
The mis-typing exist in dapm controller definitions and dapm route definitions,
so happen mis-matched error when snd_soc_dapm_add_routes().

Cc: stable@kernel.org
Signed-off-by: Jinyoung Park <parkjy@mtekvision.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com
2009-05-05 09:56:49 +01:00
Russell King
0c15702445 Merge branch 'for-rmk' of git://git.pengutronix.de/git/imx/linux-2.6 2009-05-05 09:22:26 +01:00
Russell King
64724ef8bd Merge branch 'for-rmk' of git://git.marvell.com/orion 2009-05-05 09:22:05 +01:00
Magnus Lilja
25971dfe3a i.MX31: Disable CPU_32v6K in mx3_defconfig.
The i.MX31 ARM11 core is not a v6K core. Disable this option as it
is incompatible with non v6K cores.

Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2009-05-05 09:38:04 +02:00
Sascha Hauer
b09de4209d mx3fb: Fix compilation with CONFIG_PM
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2009-05-05 09:37:17 +02:00
Uwe Kleine-König
7b9020badf mx27ads: move PBC mapping out of vmalloc space
Before this patch I got the following line in my dmesg:

	[    0.000000] BUG: mapping for 0xd4000000 at 0xeb000000 overlaps vmalloc space

VMALLOC_END is 0xf4000000 and there are the following other mappings
defined for mx27ads:

	(0xa0500000,+0x00001000) maps to 0xffff0000
	(0x10000000,+0x00100000) maps to 0xf4000000
	(0x80000000,+0x00100000) maps to 0xf4100000
	(0xd8000000,+0x00100000) maps to 0xf4200000

So map PBC to 0xf4300000.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2009-05-05 09:37:08 +02:00
Sascha Hauer
e2c97e7fdc MXC: remove BUG_ON in interrupt handler
On i.MX31 I sometimes get spurious interrupts. There is no need
to crash the whole system when this happens. Instead, silently
ignore it.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2009-05-05 09:37:01 +02:00
Valentin Longchamp
f1fd4c64af mx31: remove mx31moboard_defconfig
We want to have a mx31_defconfig file that builds a kernel that is able
to boot on all support mx31 systems and thus also can be better tested
by automatic build scripts. For these reasons, this config file is not
needed anymore.

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2009-05-05 09:36:52 +02:00
Guennadi Liakhovetski
9abf137c6d ARM: ARCH_MXC should select HAVE_CLK
All i.MX platforms support <linux/clk.h> calls and should select HAVE_CLK.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2009-05-05 09:36:44 +02:00
Martin Fuzzey
f2292532a5 mxc : BUG in imx_dma_request
On MX2 platforms imx_dma_request() calls request_irq() which may sleep
with interrupts disabled.

Signed-off-by: Martin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2009-05-05 09:36:36 +02:00
Martin Fuzzey
de0096d809 mxc : Clean up properly when imx_dma_free() used without imx_dma_disable()
The sequence
	imx_dma_request()
	imx_dma_enable()
	imx_dma_free()
left the dma channel in_use mode and did not release the timer.

Signed-off-by: Martin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2009-05-05 09:36:22 +02:00
Enrik Berkhan
2196d1cf4a i2c-algo-pca: Let PCA9564 recover from unacked data byte (state 0x30)
Currently, the i2c-algo-pca driver does nothing if the chip enters state
0x30 (Data byte in I2CDAT has been transmitted; NOT ACK has been
received).  Thus, the i2c bus connected to the controller gets stuck
afterwards.

I have seen this kind of error on a custom board in certain load
situations most probably caused by interference or noise.

A possible reaction is to let the controller generate a STOP condition.
This is documented in the PCA9564 data sheet (2006-09-01) and the same
is done for other NACK states as well.

Further, state 0x38 isn't handled completely, either. Try to do another
START in this case like the data sheet says. As this couldn't be tested,
I've added a comment to try to reset the chip if the START doesn't help
as suggested by Wolfram Sang.

Signed-off-by: Enrik Berkhan <Enrik.Berkhan@ge.com>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2009-05-05 08:39:25 +02:00
Dave Airlie
0cdba07bb2 i2c-algo-bit: Fix timeout test
When fetching DDC using i2c algo bit, we were often seeing timeouts
before getting valid EDID on a retry. The VESA spec states 2ms is the
DDC timeout, so when this translates into 1 jiffie and we are close
to the end of the time period, it could return with a timeout less than
2ms.

Change this code to use time_after instead of time_after_eq.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2009-05-05 08:39:24 +02:00
Roel Kluin
4ccc28f725 i2c: Timeouts off by 1
with while (timeout++ < MAX_TIMEOUT); timeout reaches MAX_TIMEOUT + 1
after the loop, so the tests below are off by one.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2009-05-05 08:39:24 +02:00
David S. Miller
bc83871e83 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6 2009-05-04 21:31:29 -07:00
Jesse Brandeburg
e151a60ad1 e1000: fix virtualization bug
a recent fix to e1000 (commit 15b2bee2) caused KVM/QEMU/VMware based
virtualized e1000 interfaces to begin failing when resetting.

This is because the driver in a virtual environment doesn't
get to run instructions *AT ALL* when an interrupt is asserted.
The interrupt code runs immediately and this recent bug fix
allows an interrupt to be possible when the interrupt handler
will reject it (due to the new code), when being called from
any path in the driver that holds the E1000_RESETTING flag.

the driver should use the __E1000_DOWN flag instead of the
__E1000_RESETTING flag to prevent interrupt execution
while reconfiguring the hardware.

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-04 21:28:13 -07:00
Jay Vosburgh
815bcc2719 bonding: fix alb mode locking regression
Fix locking issue in alb MAC address management; removed
incorrect locking and replaced with correct locking.  This bug was
introduced in commit 059fe7a578
("bonding: Convert locks to _bh, rework alb locking for new locking")

	Bug reported by Paul Smith <paul@mad-scientist.net>, who also
tested the fix.

Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-04 21:28:10 -07:00
Nicolas Pitre
3a5df4bf2a [ARM] mv78xx0: update defconfig
Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-05-04 21:09:19 -04:00
Nicolas Pitre
7e14acb440 [ARM] orion5x: update defconfig
Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-05-04 21:09:19 -04:00
Nicolas Pitre
f2d41ecb0f [ARM] Kirkwood: update defconfig
Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-05-04 21:09:19 -04:00
Stephen Smalley
65c90bca0d selinux: Fix send_sigiotask hook
The CRED patch incorrectly converted the SELinux send_sigiotask hook to
use the current task SID rather than the target task SID in its
permission check, yielding the wrong permission check.  This fixes the
hook function.  Detected by the ltp selinux testsuite and confirmed to
correct the test failure.

Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
2009-05-05 08:31:03 +10:00
Jake Edge
f83ce3e6b0 proc: avoid information leaks to non-privileged processes
By using the same test as is used for /proc/pid/maps and /proc/pid/smaps,
only allow processes that can ptrace() a given process to see information
that might be used to bypass address space layout randomization (ASLR).
These include eip, esp, wchan, and start_stack in /proc/pid/stat as well
as the non-symbolic output from /proc/pid/wchan.

ASLR can be bypassed by sampling eip as shown by the proof-of-concept
code at http://code.google.com/p/fuzzyaslr/ As part of a presentation
(http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) esp and wchan were
also noted as possibly usable information leaks as well.  The
start_stack address also leaks potentially useful information.

Cc: Stable Team <stable@kernel.org>
Signed-off-by: Jake Edge <jake@lwn.net>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-04 15:14:23 -07:00
Marcel Holtmann
a67e899cf3 Bluetooth: Fix issue with sysfs handling for connections
Due to a semantic changes in flush_workqueue() the current approach of
synchronizing the sysfs handling for connections doesn't work anymore. The
whole approach is actually fully broken and based on assumptions that are
no longer valid.

With the introduction of Simple Pairing support, the creation of low-level
ACL links got changed. This change invalidates the reason why in the past
two independent work queues have been used for adding/removing sysfs
devices. The adding of the actual sysfs device is now postponed until the
host controller successfully assigns an unique handle to that link. So
the real synchronization happens inside the controller and not the host.

The only left-over problem is that some internals of the sysfs device
handling are not initialized ahead of time. This leaves potential access
to invalid data and can cause various NULL pointer dereferences. To fix
this a new function makes sure that all sysfs details are initialized
when an connection attempt is made. The actual sysfs device is only
registered when the connection has been successfully established. To
avoid a race condition with the registration, the check if a device is
registered has been moved into the removal work.

As an extra protection two flush_work() calls are left in place to
make sure a previous add/del work has been completed first.

Based on a report by Marc Pignat <marc.pignat@hevs.ch>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Justin P. Mattock <justinmattock@gmail.com>
Tested-by: Roger Quadros <ext-roger.quadros@nokia.com>
Tested-by: Marc Pignat <marc.pignat@hevs.ch>
2009-05-04 14:29:02 -07:00
Jiri Slaby
6909268dc9 mac80211: pid, fix memory corruption
pid doesn't count with some band having more bitrates than the one
associated the first time.
Fix that by counting the maximal available bitrate count and allocate
big enough space.

Secondly, fix touching uninitialized memory which causes panics.
Index sucked from this random memory points to the hell.
The fix is to sort the rates on each band change.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-04 16:22:16 -04:00
Jiri Slaby
8e53217527 mac80211: minstrel, fix memory corruption
minstrel doesn't count max rate count in fact, since it doesn't use
a loop variable `i' and hence allocs space only for bitrates found in
the first band.

Fix it by involving the `i' as an index so that it traverses all the
bands now and finds the real max bitrate count.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-04 16:22:15 -04:00
Luis R. Rodriguez
30a548c727 cfg80211: fix comment on regulatory hint processing
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-04 16:22:14 -04:00
Luis R. Rodriguez
b1ed8ddd21 cfg80211: fix bug while trying to process beacon hints on init
During initialization we would not have received any beacons
so skip processing reg beacon hints, also adds a check to
reg_is_world_roaming() for last_request before accessing its
fields.

This should fix this:

BUG: unable to handle kernel NULL pointer dereference at

IP: [<e0171332>] wiphy_update_regulatory+0x20f/0x295

*pdpt = 0000000008bf1001 *pde = 0000000000000000
Oops: 0000 [#1]
last sysfs file: /sys/class/backlight/eeepc/brightness
Modules linked in: ath5k(+) mac80211 led_class cfg80211
go_bit cfbcopyarea cfbimgblt cfbfillrect ipv6
ydev usual_tables(P) snd_hda_codec_realtek snd_hda_intel
nd_hwdep uhci_hcd snd_pcm_oss snd_mixer_oss i2c_i801
e serio_raw i2c_core pcspkr atl2 snd_pcm intel_agp
re agpgart eeepc_laptop snd_page_alloc ac video backlight
rfkill button processor evdev thermal fan ata_generic

Pid: 2909, comm: modprobe Tainted: Pc #112) 701
EIP: 0060:[<e0171332>] EFLAGS: 00010246 CPU: 0
EIP is at wiphy_update_regulatory+0x20f/0x295 [cfg80211]
EAX: 00000000 EBX: c5da0000 ECX: 00000000 EDX: c5da0060
ESI: 0000001a EDI: c5da0060 EBP: df3bdd70 ESP: df3bdd40
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process modprobe (pid: 2909, ti=df3bc000 task=c5d030000)
Stack:
 df3bdd90 c5da0060 c04277e0 00000001 00000044 c04277e402
 00000002 c5da0000 0000001a c5da0060 df3bdda8 e01706a2 02
 00000282 000080d0 00000068 c5d53500 00000080 0000028240
Call Trace:
 [<e01706a2>] ? wiphy_register+0x122/0x1b7 [cfg80211]
 [<e0328e02>] ? ieee80211_register_hw+0xd8/0x346
 [<e06a7c9f>] ? ath5k_hw_set_bssid_mask+0x71/0x78 [ath5k]
 [<e06b0c52>] ? ath5k_pci_probe+0xa5c/0xd0a [ath5k]
 [<c01a6037>] ? sysfs_find_dirent+0x16/0x27
 [<c01fec95>] ? local_pci_probe+0xe/0x10
 [<c01ff526>] ? pci_device_probe+0x48/0x66
 [<c024c9fd>] ? driver_probe_device+0x7f/0xf2
 [<c024cab3>] ? __driver_attach+0x43/0x5f
 [<c024c0af>] ? bus_for_each_dev+0x39/0x5a
 [<c024c8d0>] ? driver_attach+0x14/0x16
 [<c024ca70>] ? __driver_attach+0x0/0x5f
 [<c024c5b3>] ? bus_add_driver+0xd7/0x1e7
 [<c024ccb9>] ? driver_register+0x7b/0xd7
 [<c01ff827>] ? __pci_register_driver+0x32/0x85
 [<e00a8018>] ? init_ath5k_pci+0x18/0x30 [ath5k]
 [<c0101131>] ? _stext+0x49/0x10b
 [<e00a8000>] ? init_ath5k_pci+0x0/0x30 [ath5k]
 [<c012f452>] ? __blocking_notifier_call_chain+0x40/0x4c
 [<c013a714>] ? sys_init_module+0x87/0x18b
 [<c0102804>] ? sysenter_do_call+0x12/0x22
Code: b8 da 17 e0 83 c0 04 e8 92 f9 ff ff 84 c0 75 2a 8b
85 c0 74 0c 83 c0 04 e8 7c f9 ff ff 84 c0 75 14 a1 bc da
4 03 74 66 8b 4d d4 80 79 08 00 74 5d a1 e0 d2 17 e0 48
EIP: [<e0171332>] wiphy_update_regulatory+0x20f/0x295
SP 0068:df3bdd40
CR2: 0000000000000004
---[ end trace 830f2dd2a95fd1a8 ]---

This issue is hard to reproduce, but it was noticed and discussed on
this thread:

http://marc.info/?t=123938022700005&r=1&w=2

Cc: stable@kernel.org
Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-04 16:22:13 -04:00
Luis R. Rodriguez
ac46d48e00 cfg80211: fix race condition with wiphy_apply_custom_regulatory()
We forgot to lock using the cfg80211_mutex in
wiphy_apply_custom_regulatory(). Without the lock
there is possible race between processing a reply from CRDA
and a driver calling wiphy_apply_custom_regulatory(). During
the processing of the reply from CRDA we free last_request and
wiphy_apply_custom_regulatory() eventually accesses an
element from last_request in the through freq_reg_info_regd().

This is very difficult to reproduce (I haven't), it takes us
3 hours and you need to be banging hard, but the race is obvious
by looking at the code.

This should only affect those who use this caller, which currently
is ath5k, ath9k, and ar9170.

EIP: 0060:[<f8ebec50>] EFLAGS: 00210282 CPU: 1
EIP is at freq_reg_info_regd+0x24/0x121 [cfg80211]
EAX: 00000000 EBX: f7ca0060 ECX: f5183d94 EDX: 0024cde0
ESI: f8f56edc EDI: 00000000 EBP: 00000000 ESP: f5183d44
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 14617, ti=f5182000 task=f3934d10 task.ti=f5182000)
Stack: c0505300 f7ca0ab4 f5183d94 0024cde0 f8f403a6 f8f63160 f7ca0060 00000000
00000000 f8ebedf8 f5183d90 f8f56edc 00000000 00000004 00000f40 f8f56edc
f7ca0060 f7ca1234 00000000 00000000 00000000 f7ca14f0 f7ca0ab4 f7ca1289
Call Trace:
[<f8ebedf8>] wiphy_apply_custom_regulatory+0x8f/0x122 [cfg80211]
[<f8f3f798>] ath_attach+0x707/0x9e6 [ath9k]
[<f8f45e46>] ath_pci_probe+0x18d/0x29a [ath9k]
[<c023c7ba>] pci_device_probe+0xa3/0xe4
[<c02a860b>] really_probe+0xd7/0x1de
[<c02a87e7>] __driver_attach+0x37/0x55
[<c02a7eed>] bus_for_each_dev+0x31/0x57
[<c02a83bd>] driver_attach+0x16/0x18
[<c02a78e6>] bus_add_driver+0xec/0x21b
[<c02a8959>] driver_register+0x85/0xe2
[<c023c9bb>] __pci_register_driver+0x3c/0x69
[<f8e93043>] ath9k_init+0x43/0x68 [ath9k]
[<c010112b>] _stext+0x3b/0x116
[<c014a872>] sys_init_module+0x8a/0x19e
[<c01049ad>] sysenter_do_call+0x12/0x21
[<ffffe430>] 0xffffe430
=======================
Code: 0f 94 c0 c3 31 c0 c3 55 57 56 53 89 c3 83 ec 14 8b 74 24 2c 89 54 24 0c 89 4c 24 08 85 f6 75
06 8b 35 c8 bb ec f8 a1 cc bb ec f8 <8b> 40 04 83 f8 03 74 3a 48 74 37 8b 43 28 85 c0 74 30 89 c6
8b
EIP: [<f8ebec50>] freq_reg_info_regd+0x24/0x121 [cfg80211] SS:ESP 0068:f5183d44

Cc: stable@kernel.org
Reported-by: Nataraj Sadasivam <Nataraj.Sadasivam@Atheros.com>
Reported-by: Vivek Natarajan <Vivek.Natarajan@Atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-04 16:22:12 -04:00
Reinette Chatre
299f546208 iwlwifi: update key flags at time key is set
We need to be symmetrical in what is done when key is set and cleared.
This is important wrt the key flags as they are used during key
clearing and if they are not set when the key is set the key cannot be
cleared completely.

This addresses the many occurences of the WARN found in
iwl_set_tkip_dynamic_key_info() and tracked in
http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key

If calling iwl_set_tkip_dynamic_key_info()/iwl_remove_dynamic_key()
pair a few times in a row will cause that we run out of key space.
This is because the index stored in the key flags is used by
iwl_remove_dynamic_key() to decide if it should remove the key.
Unfortunately the key flags, and hence the key index is currently only
set at the time the key is written to the device (in
iwl_update_tkip_key()) and _not_ in iwl_set_tkip_dynamic_key_info().
Fix this by setting flags in iwl_set_tkip_dynamic_key_info().

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-04 16:22:10 -04:00
Johannes Berg
c0f0aac05f cfg80211: fix truncated IEs
Another bug in the "cfg80211: do not replace BSS structs" patch,
a forgotten length update leads to bogus data being stored and
passed to userspace, often truncated.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-04 16:22:10 -04:00
Johannes Berg
8ccd8f2112 mac80211: correct fragmentation threshold check
The fragmentation threshold is defined to be including the
FCS, and the code that sets the TX_FRAGMENTED flag correctly
accounts for those four bytes. The code that verifies this
doesn't though, which could lead to spurious warnings and
frames being dropped although everything is ok. Correct the
code by accounting for the FCS.

(JWL -- The problem is described here:
 http://article.gmane.org/gmane.linux.kernel.wireless.general/32205 )

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-04 16:22:08 -04:00
Andreas Schwab
3ee59f8d0d iwlwifi: remove EXPORT_SYMBOL for static symbol
It does not make sense to apply EXPORT_SYMBOL to a static symbol.  Fixes
this build error:

drivers/net/wireless/iwlwifi/iwl3945-base.c:1697: error: __ksymtab_iwl3945_rx_queue_reset causes a section type conflict

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-04 16:22:08 -04:00
Omar Laazimani
9f722c0978 usbnet: CDC EEM support (v5)
This introduces a CDC Ethernet Emulation Model (EEM) host side
driver to support USB EEM devices.

EEM is different from the Ethernet Control Model (ECM) currently
supported by the "CDC Ethernet" driver.  One key difference is
that it doesn't require of USB interface alternate settings to
manage interface state; some maldesigned hardware can't handle
that part of USB.  It also avoids a separate USB interface for
control and status updates.

[ dbrownell@users.sourceforge.net: fix skb leaks, add rx packet
checks, improve fault handling, EEM conformance updates, cleanup ]

Signed-off-by: Omar Laazimani <omar.oberthur@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-04 12:01:43 -07:00
Andreas Herrmann
35d11680a9 x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo
Commit 7ad728f981
(cpumask: x86: convert cpu_sibling_map/cpu_core_map to cpumask_var_t)
changed the output of /proc/cpuinfo for siblings:

Example on an AMD Phenom:

  physical id   : 0
  siblings : 1
  core id	   : 3
  cpu cores  : 4

Before that commit it was:

  physical id	: 0
  siblings : 4
  core id	   : 3
  cpu cores  : 4

Instead of cpu_core_mask it now uses cpu_sibling_mask to count siblings.
This is due to the following hunk of above commit:

|  --- a/arch/x86/kernel/cpu/proc.c
|  +++ b/arch/x86/kernel/cpu/proc.c
|  @@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinf
|          if (c->x86_max_cores * smp_num_siblings > 1) {
|                  seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
|                  seq_printf(m, "siblings\t: %d\n",
|  -                          cpus_weight(per_cpu(cpu_core_map, cpu)));
|  +                          cpumask_weight(cpu_sibling_mask(cpu)));
|                  seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
|                  seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
|                  seq_printf(m, "apicid\t\t: %d\n", c->apicid);

This was a mistake, because the impact line shows that this side-effect
was not anticipated:

   Impact: reduce per-cpu size for CONFIG_CPUMASK_OFFSTACK=y

So revert the respective hunk to restore the old behavior.

[ Impact: fix sibling-info regression in /proc/cpuinfo ]

Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
LKML-Reference: <20090504182859.GA29045@alberich.amd.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-05-04 20:36:49 +02:00
Satoru SATOH
0c266898b4 tcp: Fix tcp_prequeue() to get correct rto_min value
tcp_prequeue() refers to the constant value (TCP_RTO_MIN) regardless of
the actual value might be tuned. The following patches fix this and make
tcp_prequeue get the actual value returns from tcp_rto_min().

Signed-off-by: Satoru SATOH <satoru.satoh@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-04 11:11:01 -07:00
Hannes Hering
0b2febf38a ehea: fix invalid pointer access
This patch fixes an invalid pointer access in case the receive queue
holds no pointer to the next skb when the queue is empty.

Signed-off-by: Hannes Hering <hering2@de.ibm.com>
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-04 11:06:37 -07:00
Takashi Iwai
5d7ee52f1c Merge branch 'fix/misc' into for-linus
* fix/misc:
  ALSA: indigo-express: add missing 64KHz flags
2009-05-04 16:06:58 +02:00
Takashi Iwai
dea6a9d306 Merge branch 'fix/asoc' into for-linus
* fix/asoc:
  ASoC: Remove BROKEN from mpc5200 kconfig
  ASoC: TWL4030: Fix gain control for earpiece amplifier
  ASoC: Set the MPC5200 i2s driver to BROKEN status.
  ASoC: Fix logic in WM8350 master clocking check
2009-05-04 16:06:43 +02:00
Takashi Iwai
56dc16f75d Merge branch 'fix/pcm-jiffies-check' into for-linus
* fix/pcm-jiffies-check:
  ALSA: pcm core - Avoid jiffies check for devices with BATCH flag
  ALSA: Add missing SNDRV_PCM_INFO_BATCH flag to some drivers
2009-05-04 16:06:37 +02:00
Takashi Iwai
6574612fbb ASoC: Remove BROKEN from mpc5200 kconfig
The regression was fixed by commit
3e5b50165f, so no need to mark this
driver as BROKEN.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2009-05-04 16:03:21 +02:00
Takashi Iwai
3a20ac2c52 Merge branch 'fix/pcm-jiffies-check' into fix/asoc 2009-05-04 16:00:16 +02:00
Joerg Roedel
6da7342ff1 amd-iommu: fix iommu flag masks
The feature bits should be set via bitmasks, not via feature IDs.

[ Impact: fix feature enabling in newer IOMMU versions ]

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
LKML-Reference: <20090504102028.GA30307@amd.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-05-04 15:05:24 +02:00
Sam Ravnborg
4391ed6aa9 kbuild, modpost: fix unexpected non-allocatable warning with mips
mips emit the following debug sections:
.mdebug* and .pdr

They were included in the check for non-allocatable section
and caused modpost to warn.

Manuel Lauss suggested to fix this by adding the relevant
sections to the list of sections we do not check.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reported-by: Manuel Lauss <mano@roarinelk.homelinux.net>
2009-05-04 13:05:26 +02:00
Sam Ravnborg
028ecebdd8 kbuild, modpost: fix "unexpected non-allocatable" warning with SUSE gcc
Jean reported that he saw one warning for each module like the one below:
WARNING: arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.o (.comment.SUSE.OPTs): unexpected non-allocatable section.

The warning appeared with the improved version of the
check of the flags in the sections.

That check already ignored sections named ".comment" - but SUSE store
additional info in the comment section and has named it in a SUSE
specific way. Therefore modpost failed to ignore the section.

The fix is to extend the pattern so we ignore all sections
that start with the name ".comment.".

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reported-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Jean Delvare <khali@linux-fr.org>
2009-05-04 13:05:06 +02:00
Anders Kaseorg
7d875a0286 kbuild, modpost: fix unexpected non-allocatable section when cross compiling
The missing TO_NATIVE(sechdrs[i].sh_flags) was causing many
unexpected non-allocatable section warnings when cross-compiling
for an architecture with a different endianness.

Fix endianness of all the fields in the ELF header and
section headers, not just some of them so we are not
hit by this anohter time.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Reported-by: Sean MacLennan <smaclennan@pikatech.com>
Tested-by: Sean MacLennan <smaclennan@pikatech.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2009-05-04 13:05:03 +02:00