Commits · 256b152b005e319f985f50f2a910a75ba0def74f · nexedi / linux

29 Jul, 2008 18 commits

ath5k: don't enable MSI, we cannot handle it yet · 256b152b

Pavel Roskin authored Jul 18, 2008

MSI is a nice thing, but we cannot enable it without changing the
interrupt handler.  If we do it, we break MSI capable hardware,
specifically AR5006 chipset.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

256b152b

ath5k: fix recursive locking in ath5k_beacon_update · bc05116a

Bob Copeland authored Jul 18, 2008

ath5k_beacon_update takes sc->lock upon entry.  However, it is only
called from within ath5k_config_interface, which already holds the lock.
Remove the unnecessary locking from ath5k_beacon_update.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

bc05116a

iwlwifi: small compile warnings without CONFIG_IWLWIFI_DEBUG · cb9289cb

Denis V. Lunev authored Jul 18, 2008

CC [M]  drivers/net/wireless/iwlwifi/iwl-scan.o
drivers/net/wireless/iwlwifi/iwl-scan.c: In function 'iwl_rx_scan_complete_notif':
drivers/net/wireless/iwlwifi/iwl-scan.c:274: warning: unused variable 'scan_notif'
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Tomas Winkler <tomasw@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cb9289cb

iwlwifi: compilation error when CONFIG_IWLWIFI_DEBUG is not set · c0b6a1c9

Denis V. Lunev authored Jul 17, 2008

CC [M] drivers/net/wireless/iwlwifi/iwl-rfkill.o
drivers/net/wireless/iwlwifi/iwl-led.c: In function 'iwl_led_brightness_set':
drivers/net/wireless/iwlwifi/iwl-led.c:198: error: 'led_type_str' undeclared (first use in this function)
drivers/net/wireless/iwlwifi/iwl-led.c:198: error: (Each undeclared identifier is reported only once
drivers/net/wireless/iwlwifi/iwl-led.c:198: error: for each function it appears in.)

The problem is that led_type_str is defined under CONFIG_IWLWIFI_DEBUG
while IWL_DEBUG is a static inline function in this case. Replace it
with macro.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

c0b6a1c9

libertas: check bounds and only use decimal for sysfs persistent features. · fb904907

Brian Cavagnolo authored Jul 16, 2008

Some persistent settings were using hex and others decimal.  In some cases,
values were set in hex but reported in decimal.  Confusing.
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

fb904907

iwl-3945: add #ifdef CONFIG_IWL3945_LEDS to avoid compile warning. · 699669f3

Rami Rosen authored Jul 16, 2008

When building the wireless-next-2.6 tree with CONFIG_IWL3945 (for building
iwl-3945 driver) and where CONFIG_IWL3945_LEDS is not set,
we get this warning:
drivers/net/wireless/iwlwifi/iwl-3945.c: In function
'iwl3945_pass_packet_to_mac80211':
drivers/net/wireless/iwlwifi/iwl-3945.c:633: warning: unused variable 'hdr'

This patch adds #ifdef to iwl3945_pass_packet_to_mac80211() to avoid this
warning. (The variable 'hdr' is used only if CONFIG_IWL3945_LEDS is set)
Signed-off-by: Rami Rosen <ramirose@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

699669f3

rfkill: yet more minor kernel-doc fixes · 435307a3

Henrique de Moraes Holschuh authored Jul 21, 2008

For some stupid reason, I sent and old version of the patch minor kernel
doc-fix patch, and it got merged before I noticed the problem. This is an
incremental fix on top.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

435307a3

rfkill: mutex fixes · 064af111

Henrique de Moraes Holschuh authored Jul 21, 2008

There are two mutexes in rfkill:

rfkill->mutex, which protects some of the fields of a rfkill struct, and is
also used for callback serialization.

rfkill_mutex, which protects the global state, the list of registered
rfkill structs and rfkill->claim.

Make sure to use the correct mutex, and to not miss locking rfkill->mutex
even when we already took rfkill_mutex.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

064af111

rfkill: document the rfkill struct locking (v2) · f1b23361

Henrique de Moraes Holschuh authored Jul 21, 2008

Reorder fields in struct rfkill and add comments to make it clear
which fields are protected by rfkill->mutex.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

f1b23361

rfkill: fix led-trigger unregister order in error unwind · 37f55e9d

Henrique de Moraes Holschuh authored Jul 21, 2008

rfkill needs to unregister the led trigger AFTER a call to
rfkill_remove_switch(), otherwise it will not update the LED state,
possibly leaving it ON when it should be OFF.

To make led-trigger unregistering safer, guard against unregistering a
trigger twice, and also against issuing trigger events to a led trigger
that was unregistered.  This makes the error unwind paths more resilient.

Refer to "rfkill: Register LED triggers before registering switch".
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Michael Buesch <mb@bu3sch.de>
Cc: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

37f55e9d

rfkill: document rfkill_force_state as required (v2) · 2fd9b221

Henrique de Moraes Holschuh authored Jul 21, 2008

While the rfkill class does work with just get_state(), it doesn't work
well on devices that are subject to external events that cause rfkill state
changes.

Document that rfkill_force_state() is required in those cases.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

2fd9b221

ath5k: use positive logic for HP laptop LEDs · 734b5aa9

Bob Copeland authored Jul 15, 2008

Helge Deller reports that HP laptops (NC4010 and NC6000) use active-
high signals to turn on the LEDs.  Previous code used active-low for
all devices.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

734b5aa9