Commit graph

256322 commits

Author SHA1 Message Date
Hans Verkuil
d118e294e2 [media] cx18/ivtv: fix g_tuner support
The driver shouldn't override vt->type, and the tuner name should be
based on vt->type as well.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:07:43 -03:00
Hans Verkuil
d16625e788 [media] tuner-core: power up tuner when called with s_power(1)
Drivers must be able to rely on s_power to power up subdevices.

Note that at this moment no driver attempts to power up tuners. This probably
isn't surprising since s_power(1) was never implemented in tuner-core.c until
now.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:07:01 -03:00
Hans Verkuil
a6cf90a915 [media] v4l2-ioctl.c: check for valid tuner type in S_HW_FREQ_SEEK
Prohibit attempts to change the tuner to a type that is different
from the device node the ioctl is called from. I.e. the type must
be RADIO for a radio node and ANALOG_TV for a video/vbi node.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:06:12 -03:00
Hans Verkuil
487833018e [media] tuner-core: simplify the standard fixup
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:04:41 -03:00
Hans Verkuil
338e9e1ad5 [media] tuner-core/v4l2-subdev: document that the type field has to be filled in
The tuner ops g_frequency, g_tuner and s_tuner require that the tuner type
field is filled in. Document this.

The tuner-core doc is based on a patch from Mauro Carvalho Chehab <mchehab@redhat.com>.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:04:23 -03:00
Hans Verkuil
e206fc5e3d [media] v4l2-subdev.h: remove unused s_mode tuner op
s_mode is no longer used, so remove it.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:03:59 -03:00
Hans Verkuil
6293698277 [media] feature-removal-schedule: change in how radio device nodes are handled
Radio devices have weird side-effects when used with combined TV/radio
tuners and the V4L2 spec is ambiguous on how it should work. This results
in inconsistent driver behavior which makes life hard for everyone.

Be more strict in when and how the switch between radio and tv mode
takes place and make sure all drivers behave the same.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:03:47 -03:00
Hans Verkuil
a024c1a6b2 [media] bttv: fix s_tuner for radio
Fix typo: g_tuner should have been s_tuner.

Tested with a bttv card.

Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:03:00 -03:00
Hans Verkuil
50e9efd60b [media] pvrusb2: fix g/s_tuner support
The tuner-core subdev requires that the type field of v4l2_tuner is
filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
use that yet, so we have to do it manually based on whether the current
input is radio or not.

Tested with my pvrusb2.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Mike Isely <isely@pobox.com>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:02:40 -03:00
Hans Verkuil
227690df75 [media] v4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tuner
The subdevs are supposed to receive a valid tuner type for the g_frequency
and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill
this in v4l2-ioctl.c based on whether the device node from which this is
called is a radio node or not.

The spec does not require applications to fill in the type, and if they
leave it at 0 then the 'check_mode' call in tuner-core.c will return
an error and the ioctl does nothing.

Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:02:07 -03:00
Hans Verkuil
9bf0ef060e [media] tuner-core: fix tuner_resume: use t->mode instead of t->type
set_mode is called with t->type, which is the tuner type. Instead, use
t->mode which is the actual tuner mode (i.e. radio vs tv).

Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:00:57 -03:00
Hans Verkuil
4e4a31fb95 [media] tuner-core: fix s_std and s_tuner
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.

This patch splits set_mode_freq in a set_mode and a set_freq and in s_std/s_tuner
first calls set_mode, and if that returns 0 (i.e. the mode is supported)
then they set t->std/t->audmode and call set_freq.

This fixes a bug where changing std or audmode would actually change it to
the previous value.

Discovered while testing analog TV standards for cx18 with a tda18271 tuner.

Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-07 15:00:10 -03:00
Andre Guedes
8c156c322f Bluetooth: Fix potential deadlock in mgmt
All threads running in process context should disable local bottom
halve before locking hdev->lock.

This patch fix the following message generated when Bluetooh module
is loaded with enable_mgmt=y (CONFIG_PROVE_LOCKING enabled).

[  107.880781] =================================
[  107.881631] [ INFO: inconsistent lock state ]
[  107.881631] 2.6.39+ #1
[  107.881631] ---------------------------------
[  107.881631] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[  107.881631] rcuc0/7 [HC0[0]:SC1[3]:HE1:SE0] takes:
[  107.881631]  (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631] {SOFTIRQ-ON-W} state was registered at:
[  107.881631]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[  107.881631]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  107.881631]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[  107.881631]   [<ffffffffa0011cc2>] mgmt_control+0xd4d/0x175b [bluetooth]
[  107.881631]   [<ffffffffa0013275>] hci_sock_sendmsg+0x97/0x293 [bluetooth]
[  107.881631]   [<ffffffff8121940c>] sock_aio_write+0x126/0x13a
[  107.881631]   [<ffffffff810a35fa>] do_sync_write+0xba/0xfa
[  107.881631]   [<ffffffff810a3beb>] vfs_write+0xaa/0xca
[  107.881631]   [<ffffffff810a3d80>] sys_write+0x45/0x69
[  107.881631]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[  107.881631] irq event stamp: 2100876
[  107.881631] hardirqs last  enabled at (2100876): [<ffffffff812b40d4>] restore_args+0x0/0x30
[  107.881631] hardirqs last disabled at (2100875): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[  107.881631] softirqs last  enabled at (2100862): [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[  107.881631] softirqs last disabled at (2100863): [<ffffffff812b56bc>] call_softirq+0x1c/0x26
[  107.881631]
[  107.881631] other info that might help us debug this:
[  107.881631]  Possible unsafe locking scenario:
[  107.881631]
[  107.881631]        CPU0
[  107.881631]        ----
[  107.881631]   lock(&(&hdev->lock)->rlock);
[  107.881631]   <Interrupt>
[  107.881631]     lock(&(&hdev->lock)->rlock);
[  107.881631]
[  107.881631]  *** DEADLOCK ***
[  107.881631]
[  107.881631] 1 lock held by rcuc0/7:
[  107.881631]  #0:  (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
[  107.881631]
[  107.881631] stack backtrace:
[  107.881631] Pid: 7, comm: rcuc0 Not tainted 2.6.39+ #1
[  107.881631] Call Trace:
[  107.881631]  <IRQ>  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[  107.881631]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[  107.881631]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[  107.881631]  [<ffffffff810504bb>] mark_lock+0x106/0x258
[  107.881631]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[  107.881631]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[  107.881631]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  107.881631]  [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
[  107.881631]  [<ffffffff812b3952>] _raw_spin_lock_bh+0x31/0x40
[  107.881631]  [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631]  [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631]  [<ffffffffa000d3fe>] hci_event_packet+0x122b/0x3e12 [bluetooth]
[  107.881631]  [<ffffffff81050658>] ? mark_held_locks+0x4b/0x6d
[  107.881631]  [<ffffffff812b3cff>] ? _raw_spin_unlock_irqrestore+0x40/0x4d
[  107.881631]  [<ffffffff810507b9>] ? trace_hardirqs_on_caller+0x13f/0x172
[  107.881631]  [<ffffffff812b3d07>] ? _raw_spin_unlock_irqrestore+0x48/0x4d
[  107.881631]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[  107.881631]  [<ffffffff8102f836>] ? __local_bh_enable+0x90/0xa4
[  107.881631]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[  107.881631]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[  107.881631]  [<ffffffff812b56bc>] call_softirq+0x1c/0x26
[  107.881631]  <EOI>  [<ffffffff810033b8>] ? do_softirq+0x46/0x9a
[  107.881631]  [<ffffffff8106a805>] ? rcu_cpu_kthread+0x2b5/0x2e2
[  107.881631]  [<ffffffff8102f906>] _local_bh_enable_ip+0xac/0xc9
[  107.881631]  [<ffffffff8102f93b>] local_bh_enable+0xd/0xf
[  107.881631]  [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[  107.881631]  [<ffffffff81041586>] ? __init_waitqueue_head+0x46/0x46
[  107.881631]  [<ffffffff8106a550>] ? rcu_yield.constprop.42+0x98/0x98
[  107.881631]  [<ffffffff81040f0a>] kthread+0x7f/0x87
[  107.881631]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[  107.881631]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[  107.881631]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[  107.881631]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07 14:28:29 -03:00
Andre Guedes
8aded7110a Bluetooth: Fix potential deadlock in hci_core
Since hdev->lock may be acquired by threads runnning in interrupt
context, all threads running in process context should disable
local bottom halve before locking hdev->lock. This can be done by
using hci_dev_lock_bh macro.

This way, we avoid potencial deadlocks like this one reported by
CONFIG_PROVE_LOCKING=y.

[  304.788780] =================================
[  304.789686] [ INFO: inconsistent lock state ]
[  304.789686] 2.6.39+ #1
[  304.789686] ---------------------------------
[  304.789686] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[  304.789686] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
[  304.789686]  (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686] {SOFTIRQ-ON-W} state was registered at:
[  304.789686]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[  304.789686]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  304.789686]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[  304.789686]   [<ffffffffa0009cf0>] hci_blacklist_del+0x1f/0x8a [bluetooth]
[  304.789686]   [<ffffffffa00139fd>] hci_sock_ioctl+0x2d9/0x314 [bluetooth]
[  304.789686]   [<ffffffff812197d8>] sock_ioctl+0x1f2/0x214
[  304.789686]   [<ffffffff810b0fd6>] do_vfs_ioctl+0x46c/0x4ad
[  304.789686]   [<ffffffff810b1059>] sys_ioctl+0x42/0x65
[  304.789686]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[  304.789686] irq event stamp: 9768
[  304.789686] hardirqs last  enabled at (9768): [<ffffffff812b40d4>] restore_args+0x0/0x30
[  304.789686] hardirqs last disabled at (9767): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[  304.789686] softirqs last  enabled at (9726): [<ffffffff8102fa9b>] __do_softirq+0x129/0x13f
[  304.789686] softirqs last disabled at (9739): [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
[  304.789686]
[  304.789686] other info that might help us debug this:
[  304.789686]  Possible unsafe locking scenario:
[  304.789686]
[  304.789686]        CPU0
[  304.789686]        ----
[  304.789686]   lock(&(&hdev->lock)->rlock);
[  304.789686]   <Interrupt>
[  304.789686]     lock(&(&hdev->lock)->rlock);
[  304.789686]
[  304.789686]  *** DEADLOCK ***
[  304.789686]
[  304.789686] 1 lock held by ksoftirqd/0/3:
[  304.789686]  #0:  (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
[  304.789686]
[  304.789686] stack backtrace:
[  304.789686] Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.39+ #1
[  304.789686] Call Trace:
[  304.789686]  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[  304.789686]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[  304.789686]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[  304.789686]  [<ffffffff810504bb>] mark_lock+0x106/0x258
[  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[  304.789686]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[  304.789686]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[  304.789686]  [<ffffffff812ae126>] ? printk+0x3c/0x3e
[  304.789686]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686]  [<ffffffff811601c6>] ? __dynamic_pr_debug+0x10c/0x11a
[  304.789686]  [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686]  [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686]  [<ffffffffa000c561>] hci_event_packet+0x38e/0x3e12 [bluetooth]
[  304.789686]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
[  304.789686]  [<ffffffff812b3b41>] ? _raw_read_unlock+0x23/0x27
[  304.789686]  [<ffffffffa0013e7f>] ? hci_send_to_sock+0x179/0x188 [bluetooth]
[  304.789686]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[  304.789686]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[  304.789686]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[  304.789686]  [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
[  304.789686]  [<ffffffff8102fab1>] ? __do_softirq+0x13f/0x13f
[  304.789686]  [<ffffffff81040f0a>] kthread+0x7f/0x87
[  304.789686]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[  304.789686]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[  304.789686]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07 14:28:12 -03:00
Gertjan van Wingerde
5f0dd296a0 rt2x00: Implement tx_frames_pending mac80211 callback function.
Implementing this callback function will cause mac80211 refrain from
going to powersave state when there are still untransmitted TX frames
in the queues.
This would exactly mimic the behaviour of the legacy vendor driver which
also doesn't go in powersave mode if there are still TX frames that are not
transmitted.
This should make powersaving and rt2x00 a better couple.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:21:00 -04:00
Gertjan van Wingerde
acb56120d2 rt2x00: Properly identify rt2800usb devices.
Sitecom WLA4000 (USB ID 0x0df6:0x0060) is an RT3072 chipset.
Sitecom WLA5000 (USB ID 0x0df6:0x0062) is an RT3572 chipset.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:21:00 -04:00
Gertjan van Wingerde
71e0b38c29 rt2x00: Add device ID for RT539F device.
Reported-by: Wim Vander Schelden <wim@fixnum.org>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:20:59 -04:00
Gertjan van Wingerde
128f8f773d rt2x00: Reduce window of a queue's tx lock.
Currently a lot of actions that can be done without the queue's tx lock
being held are done inside the locked area.
Move them out to have a leaner and meaner code that operates while the
tx lock is being held.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:20:58 -04:00
Gertjan van Wingerde
77b5621bac rt2x00: Don't use queue entry as parameter when creating TX descriptor.
The functions that create the tx descriptor structure do not operate on
a queue entry at all. Signal this fact in the code by not providing a
queue entry as a parameter, but the rt2x00 device structure and the skb
directly.

This patch is a preparation for reducing the time a queue is locked for
a tx operation.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:20:58 -04:00
Gertjan van Wingerde
77a861c405 rt2x00: Serialize TX operations on a queue.
The rt2x00 driver gets frequent occurrences of the following error message
when operating under load:
phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the
non-full queue 2.

This is caused by simultaneous attempts from mac80211 to send a frame via
rt2x00, which are not properly serialized inside rt2x00queue_write_tx_frame,
causing the second frame to fail sending with the above mentioned error
message.

Fix this by introducing a per-queue spinlock to serialize the TX operations
on that queue.

Reported-by: Andreas Hartmann <andihartmann@01019freenet.de>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:20:57 -04:00
Rafał Miłecki
9352f69c91 bcma: detect PCI core working in hostmode
We must not init it like clientmode one, it would break device (tested
by Hauke on BCM4718). Add stub hostmode driver for now.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:13:34 -04:00
Johannes Berg
34459512ff mac80211: fix TKIP replay vulnerability
Unlike CCMP, the presence or absence of the QoS
field doesn't change the encryption, only the
TID is used. When no QoS field is present, zero
is used as the TID value. This means that it is
possible for an attacker to take a QoS packet
with TID 0 and replay it as a non-QoS packet.

Unfortunately, mac80211 uses different IVs for
checking the validity of the packet's TKIP IV
when it checks TID 0 and when it checks non-QoS
packets. This means it is vulnerable to this
replay attack.

To fix this, use the same replay counter for
TID 0 and non-QoS packets by overriding the
rx->queue value to 0 if it is 16 (non-QoS).

This is a minimal fix for now. I caused this
issue in

commit 1411f9b531
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Thu Jul 10 10:11:02 2008 +0200

    mac80211: fix RX sequence number check

while fixing a sequence number issue (there,
a separate counter needs to be used).

Cc: stable@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:06:09 -04:00
Luciano Coelho
1186980daf mac80211: fix ie memory allocation for scheduled scans
We were not allocating memory for the IEs passed in the scheduled_scan
request and this was causing memory corruption (buffer overflow).

Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:06:08 -04:00
Rafał Miłecki
6ae8ec2786 ssb: fix init regression of hostmode PCI core
Our workarounds seem to be clientmode PCI specific. Using SPROM
workaround on SoC resulted in Oops:

Data bus error, epc == 8017ed58, ra == 80225838
 Oops[#1]:
 Cpu 0
 $ 0   : 00000000 10008000 b8000000 00000001
 $ 4   : 80293b5c 00000caa ffffffff 00000000
 $ 8   : 0000000a 00000003 00000001 696d6d20
 $12   : ffffffff 00000000 00000000 ffffffff
 $16   : 802d0140 b8004800 802c0000 00000000
 $20   : 00000000 802c0000 00000000 802d04d4
 $24   : 00000018 80151a00
 $28   : 81816000 81817df8 8029bda0 80225838
 Hi    : 00000000
 Lo    : 00000000
 epc   : 8017ed58 ssb_ssb_read16+0x48/0x60
   Not tainted
 ra    : 80225838 ssb_pcicore_init+0x54/0x3b4

Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:06:08 -04:00
Antonio Quartulli
a7f9becb7d batman-adv: request the full table if tt_crc doesn't match
In case of tt_crc mismatching for a certain orig_node after applying the
changes, the node must request the full table immediately.

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
2011-07-07 18:49:26 +02:00
Antonio Quartulli
980d55b20a batman-adv: keep global table consistency in case of roaming
To keep consistency of other originator tables, new clients detected as
roamed, are kept in the global table but are marked as TT_CLIENT_PENDING
They are purged only when the new ttvn is received by the corresponding
originator. Moreover they need to be considered as removed in case of global
transtable lookup.

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
2011-07-07 18:49:26 +02:00
Antonio Quartulli
058d0e2698 batman-adv: keep local table consistency for further TT_RESPONSE
To keep transtable consistency among all the nodes, an originator must
not send not yet announced clients within a full table TT_RESPONSE.
Instead, deleted client have to be kept in the table in order to be sent
within an immediate TT_RESPONSE. In this way all the nodes in the
network will always provide the same response for the same request.

All the modification are committed at the next ttvn increment event.

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
2011-07-07 18:49:26 +02:00
Antonio Quartulli
c8c991bf20 batman-adv: initialise last_ttvn and tt_crc for the orig_node structure
The last_ttvn and tt_crc fields of the orig_node structure were not
initialised causing an immediate TT_REQ/RES dialogue even if not needed.

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
2011-07-07 18:49:26 +02:00
Kuninori Morimoto
bd7fdbcaa2 ASoC: ak4642: fixup snd_soc_update_bits mask for PW_MGMT2
mask didn't cover update-data

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
2011-07-07 09:46:06 -07:00
Konrad Rzeszutek Wilk
ee339fe63a xen/pci: Move check for acpi_sci_override_gsi to xen_setup_acpi_sci.
Previously we would check for acpi_sci_override_gsi == gsi every time
a PCI device was enabled. That works during early bootup, but later
on it could lead to triggering unnecessarily the acpi_gsi_to_irq(..) lookup.
The reason is that acpi_sci_override_gsi was declared in __initdata and
after early bootup could contain bogus values.

This patch moves the check for acpi_sci_override_gsi to the
site where the ACPI SCI is preset.

CC: stable@kernel.org
Reported-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
Tested-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
[http://lists.xensource.com/archives/html/xen-devel/2011-07/msg00154.html]
Suggested-by:  Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2011-07-07 12:19:08 -04:00
Simon Guinot
659fb32d1b genirq: replace irq_gc_ack() with {set,clr}_bit variants (fwd)
This fixes a regression introduced by e59347a "arm: orion:
Use generic irq chip".

Depending on the device, interrupts acknowledgement is done by setting
or by clearing a dedicated register. Replace irq_gc_ack() with some
{set,clr}_bit variants allows to handle both cases.

Note that this patch affects the following SoCs: Davinci, Samsung and
Orion. Except for this last, the change is minor: irq_gc_ack() is just
renamed into irq_gc_ack_set_bit().

For the Orion SoCs, the edge GPIO interrupts support is currently
broken. irq_gc_ack() try to acknowledge a such interrupt by setting
the corresponding cause register bit. The Orion GPIO device expect the
opposite. To fix this issue, the irq_gc_ack_clr_bit() variant is used.

Tested on Network Space v2.

Reported-by: Joey Oravec <joravec@drewtech.com>
Signed-off-by: Simon Guinot <sguinot@lacie.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2011-07-07 16:02:26 +00:00
Axel Lin
60cfa098dc platform-drivers-x86: set backlight type to BACKLIGHT_PLATFORM
Some newly added drivers do not set backlight type, as a result
/sys/class/backlight/<backlight>/type shows incorrect backlight type.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Yin Kangkai <kangkai.yin@intel.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-07-07 11:27:17 -04:00
David S. Miller
31817df025 packet: Fix build with INET disabled.
af_packet.c:(.text+0x3d130): undefined reference to `ip_defrag'
or
ERROR: "ip_defrag" [net/packet/af_packet.ko] undefined!

Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 08:18:04 -07:00
Henrique de Moraes Holschuh
a50245af78 thinkpad-acpi: handle HKEY 0x4010, 0x4011 events
Handle events 0x4010 and 0x4011 so that we do not pester users about them.

These events report when the thinkpad is docked/undocked to a native
hotplug dock (i.e. one that does not need ACPI handling, nor is represented
in the ACPI device tree).  Such docks are based on USB 2.0/3.0, and also
work as port replicators.

We really want a proper dock class to report these, or at least new input
EV_SW events.  Since it is not clear which one to use yet, keep reporting
them as vendor-specific ThinkPad events.

WARNING: As defined by the thinkpad-acpi sysfs ABI rules of engagement, the
vendor-specific events will be REMOVED as soon as generic events are made
available (duplicate events are a big problem), with an appropriate update
to the thinkpad-acpi sysfs/event ABI versioning.  Userspace is already
prepared to provide easy backwards compatibility for such changes when
convenient to the distro (see acpi-fakekey).

* Event 0x4010: docking to hotplug dock/port replicator
* Event 0x4011: undocking from hotplug dock/port replicator

Typical usecase would be to trigger display reconfiguration.

Reports mention T410, T510, and series 3 docks/port replicators.  Special
thanks to Robert de Rooy for his extensive report and analysis of the
situation.

http://www.thinkwiki.org/wiki/ThinkPad_Port_Replicator_Series_3
http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Series_3
http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Plus_Series_3
http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Plus_Series_3_for_Mobile_Workstations
http://lenovoblogs.com/insidethebox/?p=290

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Reported-by: Claudius Hubig <claudiushubig@chubig.net>
Reported-by: Doctor Bill <docbill@gmail.com>
Reported-by: Korte Noack <gbk.noack@gmx.de>
Reported-by: Robert de Rooy <robert.de.rooy@gmail.com>
Reported-by: Sebastian Will <swill@csail.mit.edu>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-07-07 10:39:05 -04:00
Andre Bartke
96b269c1b0 drivers/platform/x86: Fix memory leak
data is not freed in the error case of
compal_probe().

Signed-off-by: Andre Bartke <andre.bartke@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-07-07 10:39:03 -04:00
Henrique de Moraes Holschuh
2d43f671c8 thinkpad-acpi: handle some new HKEY 0x60xx events
Handle some user interface events from the newer Lenovo models.  We are likely
to do something smart with these events in the future, for now, hide the ones
we are already certain about from the user and userspace both.

* Events 0x6000 and 0x6005 are key-related.  0x6005 is not properly identified
  yet.  Ignore these events, and do not report them.

* Event 0x6040 has not been properly identified yet, and we don't know if it
  is important (looks like it isn't, but still...).  Keep reporting it.

* Change the message the driver outputs on unknown 0x6xxx events, as all
  recent events are not related to thermal alarms.  Degrade log level from
  ALERT to WARNING.

Thanks to all users who reported these events or asked about them in a number
of mailing lists.  Your help is highly appreciated, even if I did took a lot of
time to act on them.  For that I apologise.

I will list those that identified the reasons for the events as "reported-by",
and I apologise in advance if I leave anyone out: it was not done on purpose, I
made the mistake of not properly tagging all event report emails separately,
and might have missed some.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: Markus Malkusch <markus@malkusch.de>
Reported-by: Peter Giles <g1l3sp@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-07-07 10:39:00 -04:00
Lee, Chun-Yi
ae821c1b2f acer-wmi: fix bitwise bug when set device state
Fix a bitwise bug that was found by Joern Heissler, it must be OR
but not AND when we query current device state.

Acked-by: Joern Heissler <linux-acpi@joern.heissler.de>
Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-07-07 10:38:58 -04:00
Seth Forshee
92530664bb acer-wmi: Only update rfkill status for associated hotkey events
acer-wmi is indiscriminately using the device state from hotkey
events to update the various rfkill states. On the Aspire 1830 this
can result in a soft block on the wlan when the touchpad hotkey is
pressed, as it is reporting a non-zero device state that does not
reflect the wireless status. To fix this, only update rfkill states
when a wlan or bluetooth hotkey is pressed.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2011-07-07 10:38:56 -04:00
Wolfram Sang
d30e1521b2 arm: mach-vt8500: add forgotten irq_data conversion
This platform has not been converted to 'struct irq_data' when the big
pile was done. It fails to compile nowadays, because the compatibility
code has gone.

  CC      arch/arm/mach-vt8500/irq.o
arch/arm/mach-vt8500/irq.c:118:2: error: unknown field 'ack' specified in initializer
arch/arm/mach-vt8500/irq.c:118:2: warning: initialization from incompatible pointer type
arch/arm/mach-vt8500/irq.c:119:2: error: unknown field 'mask' specified in initializer
arch/arm/mach-vt8500/irq.c:119:2: warning: initialization from incompatible pointer type
arch/arm/mach-vt8500/irq.c:120:2: error: unknown field 'unmask' specified in initializer
arch/arm/mach-vt8500/irq.c:120:2: warning: initialization from incompatible pointer type
arch/arm/mach-vt8500/irq.c:121:2: error: unknown field 'set_type' specified in initializer
arch/arm/mach-vt8500/irq.c:121:2: warning: initialization from incompatible pointer type
make[1]: *** [arch/arm/mach-vt8500/irq.o] Error 1

Add the missing conversion. Tested on a JayPC-Tablet.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Alexey Charkov <alchark@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2011-07-07 14:35:25 +00:00
Vitaly Kuzmichev
90c5ffe592 ARM: 6994/1: smp_twd: Fix typo in 'twd_timer_rate' printing
To get hundredths of MHz the rate needs to be divided by 10'000.
Here is an example:
 twd_timer_rate = 123456789
 Before the patch:
    twd_timer_rate / 1000000 = 123
    (twd_timer_rate / 1000000) % 100 = 23
    Result: 123.23MHz.
 After being fixed:
    twd_timer_rate / 1000000 = 123
    (twd_timer_rate / 10000) % 100 = 45
    Result: 123.45MHz.

Signed-off-by: Vitaly Kuzmichev <vkuzmichev@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-07 15:00:12 +01:00
Eric Dumazet
afe62c68cd af_packet: lock imbalance
fanout_add() might return with fanout_mutex held.

Reduce indentation level while we are at it

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 06:41:29 -07:00
Eric Dumazet
68ac31918e sky2: use GFP_KERNEL allocations at device setup
In process and sleep allowed context, favor GFP_KERNEL allocations over
GFP_ATOMIC ones.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 06:13:32 -07:00
Shmulik Ravid
3c878d4746 bnx2x: Add dcbnl notification
This patch adds a dcbnl notification to the bnx2x. The notification is
sent to user mode clients following a change in the dcb negotiated
parameters as resolved by the embedded DCBX stack. 

Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 05:11:30 -07:00
Ian Abbott
be0e1e788b lib/checksum.c: optimize do_csum a bit
Reduce the number of variables modified by the loop in do_csum() by 1,
which seems like a good idea.  On Nios II (a RISC CPU with 3-operand
instruction set) it reduces the loop from 7 to 6 instructions, including
the conditional branch.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 04:52:24 -07:00
Shirley Ma
97bc3633be macvtap: macvtapTX zero-copy support
Only 128 bytes is copied, the rest of data is DMA mapped directly from
userspace.

Signed-off-by: Shirley Ma <xma@...ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 04:41:24 -07:00
Shirley Ma
a6686f2f38 skbuff: skb supports zero-copy buffers
This patch adds userspace buffers support in skb shared info. A new
struct skb_ubuf_info is needed to maintain the userspace buffers
argument and index, a callback is used to notify userspace to release
the buffers once lower device has done DMA (Last reference to that skb
has gone).

If there is any userspace apps to reference these userspace buffers,
then these userspaces buffers will be copied into kernel. This way we
can prevent userspace apps from holding these userspace buffers too long.

Use destructor_arg to point to the userspace buffer info; a new tx flags
SKBTX_DEV_ZEROCOPY is added for zero-copy buffer check.

Signed-off-by: Shirley Ma <xma@...ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 04:41:13 -07:00
Shirley Ma
1cdebb4232 sock.h: Add a new sock zero-copy flag
Signed-off-by: Shirley Ma <xma@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 04:40:21 -07:00
Sebastian Poehn
380b153cf5 gianfar v2: code cleanups
This patch:
# improves readability of some gianfar nfc code

Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 04:30:29 -07:00
Bjørn Mork
2bda8a0c8a Disable router anycast address for /127 prefixes
RFC 6164 requires that routers MUST disable Subnet-Router anycast
for the prefix when /127 prefixes are used.

No need for matching code in addrconf_leave_anycast() as it
will silently ignore any attempt to leave an unknown anycast
address.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 04:15:10 -07:00
Wei Yongjun
949123016a sctp: fix missing send up SCTP_SENDER_DRY_EVENT when subscribe it
We forgot to send up SCTP_SENDER_DRY_EVENT notification when
user app subscribes to this event, and there is no data to be
sent or retransmit.

This is required by the Socket API and used by the DTLS/SCTP
implementation.

Reported-by: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Tested-by: Robin Seggelmann <seggelmann@fh-muenster.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-07 04:10:26 -07:00