commit 5ed540ae change the led behavior
for iwlwifi driver; the side effect cause led blink all the time.

Modify the led blink table to fix this problem
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since

commit a120e912
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Feb 19 15:47:33 2010 -0800

    iwlwifi: sanity check before counting number of tfds can be free

we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.

On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link, making bisection of other problems impossible.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since

commit a120e912
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Feb 19 15:47:33 2010 -0800

    iwlwifi: sanity check before counting number of tfds can be free

we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.

On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link.

Cc: stable@kernel.org # 2.6.32+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The locking with SMPS requests means that the
debugs file should lock the mgd mutex, not the
iflist mutex. Calls to __ieee80211_request_smps()
need to hold that mutex, so add an assertion.

This has always been wrong, but for some reason
never been noticed, probably because the locking
error only happens while unassociated.

Cc: stable@kernel.org [2.6.34+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch 'ath9k_hw: fix stopping rx DMA during resets' added code to detect
a condition where rx DMA was stopped, but the MAC failed to enter the idle
state. This condition requires a hardware reset, however the return value
of ath_stoprecv was 'true' in that case, which allowed it to skip the reset
when issuing a fast channel change.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Reported-by: NPaul Stewart <pstew@google.com>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When retrasmitting one frame, only SAR bits in control field should
be kept.
Signed-off-by: NRuiyi Zhang <Ruiyi.zhang@atheros.com>
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>

shutdown should wait for SCO link to be properly disconnected before
detroying the socket, otherwise an application using the socket may
assume link is properly disconnected before it really happens which
can be a problem when e.g synchronizing profile switch.
Signed-off-by: NLuiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>

In the teardown path the reset command is sent to the controller,
this event causes the command timer to be reactivated.

So the timer is removed in two situations, when the adapter isn't
marked as UP and when we know that some command has been sent.
Reported-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>

hci_io_capa_reply_evt() holds reference for hciconnection. It's useless since
hci_io_capa_request_evt()/hci_simple_pair_complete_evt() already protects the
connection. In addition it leaves connection open after failed SSP pairing.
Signed-off-by: NVille Tervo <ville.tervo@nokia.com>
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>

For some reason, sending QoS configuration causes transmission to stop
after a single frame on HT channels when not associated. Removing the
extra QoS configuration has no effect on station mode, and fixes
injection mode.
Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

priv->tx_power_next is not initialized to max supported power,
but instead default value is used, what cause errors like

[   58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14.
[   58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22).

if maximum tx power read from the eeprom is smaller than default.
In consequence card is unable to initialize properly. Fix the problem
and cleanup tx power initialization.
Reported-and-tested-by: NRobin Dong <hao.bigrat@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Pass the correct module name and device interface so that
ethtool can display the proper values.

The firmware version will be fixed later on when the FW
can actually report a version. :)
Reported-by: NRichard Farina <sidhayn@gmail.com>
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
Tested-by: NRichard Farina <sidhayn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During PHY errors, the MAC can sometimes fail to enter an idle state on older
hardware (before AR9380) after an rx stop has been requested.

This typically shows up in the kernel log with messages like these:

ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
------------[ cut here ]------------
WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
Call Trace:
[<8023f0e8>] dump_stack+0x8/0x34
[<80075050>] warn_slowpath_common+0x78/0xa4
[<80075094>] warn_slowpath_null+0x18/0x24
[<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
[<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
[<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]

When this happens, the state that the MAC enters is easy to identify and
does not result in bogus DMA traffic, however to ensure a working state
after a channel change, the hardware should still be reset.

This patch adds detection for this specific MAC state, after which the above
warnings completely disappear in my tests.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Otherwise, IWLWIFI_LEGACY has to be selected independently before the
drivers are made available.
Reported-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This patch fixes a very serious off-by-one bug in
the driver, which could leave the device in an
unresponsive state.

The problem was that the extra_len variable [used to
reserve extra scratch buffer space for the firmware]
was left uninitialized. Because p54_assign_address
later needs the value to reserve additional space,
the resulting frame could be to big for the small
device's memory window and everything would
immediately come to a grinding halt.

Reference: https://bugs.launchpad.net/bugs/722185

Cc: <stable@kernel.org>
Acked-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJason Conti <jason.conti@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These missing chip wakeups mainly cause crashes on AR5416 cards in MIPS
boards, but have also been reported to cause radio stability issues on
AR9285.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Joe Culler reported a problem with his AR9170 device:

> ath: EEPROM regdomain: 0x5c
> ath: EEPROM indicates we should expect a direct regpair map
> ath: invalid regulatory domain/country code 0x5c
> ath: Invalid EEPROM contents

It turned out that the regdomain 'APL7_FCCA' was not mapped yet.
According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to
FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch
should be correct.

Cc: <stable@kernel.org>
Reported-by: NJoe Culler <joe.culler@gmail.com>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the mwl8k driver attempts and fails to switch from sta to ap
firmware (or vice-versa) in the mwl8k_add_interface routine, the
mwl8k_stop routine will be called. This routine must not attempt
to free the irq if it was not requested.
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

At least EEPROM version 0x11A has the wrong
number of chains programmed into it for some
reason, so we need to override in the driver.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

A number of these devices have appeared "in the wild", and apparently
the Windows driver is perfectly happy to support this EEPROM version.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Cc: stable@kernel.org
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

{rx,tx}done_work's are only initialized for usb devices.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Cc: stable@kernel.org
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some compiler/architecture combinations generate some warnings that are
not seen on my main system. Two of the "warnings" about unitialized variables
are really bugs.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: <stable@kernel.org>
Reported-by: Mark Davis [via p54/devices wiki]
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were allocating the size of the NVS file struct and not checking
whether the length of the buffer passed was correct before copying it
into the allocated memory.  This is a security hole because buffer
overflows can occur if the userspace passes a bigger file than what is
expected.

With this patch, we check if the size of the data passed from
userspace matches the size required.

This bug was introduced in 2.6.36.

Cc: stable@kernel.org
Reported-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

2.6.38 added WARN_ON(in_irq) in del_timer_sync that triggers on zd1211rw when
reseting rx idle timer in urb completion handler.

Move timer reseting to tasklet.
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Patch removes the bogus flag introduced by upstream commit
eefdbec1. Old code had buffer length check
that new code tried to handle with URB_SHORT_NOT_OK flag. With USB debugging
enabled bogus flag caused usb_submit_urb fail.

Remove URB_SHORT_NOT_OK flag and add buffer length check to urb completion
handler.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32092Reported-by: NJonathan Callen <abcd@gentoo.org>
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cleaning the ieee80211_rx_data.flags field here is wrong, instead the
flags should be valid accross processing the frame on different
interfaces. Fix this by removing the incorrect flags=0 assignment.

Introduced in commit 554891e6
(mac80211: move packet flags into packet).
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The description for buf_size was misleading and
just said you couldn't TX larger aggregates, but
of course you can't TX aggregates in a way that
would exceed the window either, which is possible
even if the aggregates are shorter than that.

Expand the description, thanks to Emmanuel for
explaining this to me.

Cc: Emmanuel Grumbach <egrumbach@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The phy information print during driver init time doesn't show
the numeric part of the chip name properly for AR9485. This patch
addresses this issue by adding the string to the respective array.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The MODULE_AUTHOR() macro in the main module (wl12xx) has been updated
to reflect one of the author's new email address, but the wl12xx_spi
and wl12xx_sdio modules haven't been updated.  This patches updates
them.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Otherwise, skb_put inside of dma_rx can fail...

	https://bugzilla.kernel.org/show_bug.cgi?id=32042Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: stable@kernel.org

On error path kfree() should get pointer to memory allocated by
kmalloc() not the address of variable holding it (which is on stack).
Signed-off-by: NMariusz Kozlowski <mk@lab.zgora.pl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

All callers are prepared for alloc failures anyway, so this error
can safely be boomeranged to the callers domain without super
bad consequences. ...At worst the connection might go into a state
where each RTO tries to (unsuccessfully) re-fragment with such
a mis-sized value and eventually dies.
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Sometime the ASCONF_ACK parameters can equal to the fourfold of
ASCONF parameters, this only happend in some special case:

  ASCONF parameter is :
    Unrecognized Parameter (4 bytes)
  ASCONF_ACK parameter should be:
    Error Cause Indication parameter (8 bytes header)
     + Error Cause (4 bytes header)
       + Unrecognized Parameter (4bytes)

Four 4bytes Unrecognized Parameters in ASCONF chunk will cause panic.

Pid: 0, comm: swapper Not tainted 2.6.38-next+ #22 Bochs Bochs
EIP: 0060:[<c0717eae>] EFLAGS: 00010246 CPU: 0
EIP is at skb_put+0x60/0x70
EAX: 00000077 EBX: c09060e2 ECX: dec1dc30 EDX: c09469c0
ESI: 00000000 EDI: de3c8d40 EBP: dec1dc58 ESP: dec1dc2c
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=dec1c000 task=c09aef20 task.ti=c0980000)
Stack:
 c09469c0 e1894fa4 00000044 00000004 de3c8d00 de3c8d00 de3c8d44 de3c8d40
 c09060e2 de25dd80 de3c8d40 dec1dc7c e1894fa4 dec1dcb0 00000040 00000004
 00000000 00000800 00000004 00000004 dec1dce0 e1895a2b dec1dcb4 de25d960
Call Trace:
 [<e1894fa4>] ? sctp_addto_chunk+0x4e/0x89 [sctp]
 [<e1894fa4>] sctp_addto_chunk+0x4e/0x89 [sctp]
 [<e1895a2b>] sctp_process_asconf+0x32f/0x3d1 [sctp]
 [<e188d554>] sctp_sf_do_asconf+0xf8/0x173 [sctp]
 [<e1890b02>] sctp_do_sm+0xb8/0x159 [sctp]
 [<e18a2248>] ? sctp_cname+0x0/0x52 [sctp]
 [<e189392d>] sctp_assoc_bh_rcv+0xac/0xe3 [sctp]
 [<e1897d76>] sctp_inq_push+0x2d/0x30 [sctp]
 [<e18a21b2>] sctp_rcv+0x7a7/0x83d [sctp]
 [<c077a95c>] ? ipv4_confirm+0x118/0x125
 [<c073a970>] ? nf_iterate+0x34/0x62
 [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
 [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
 [<c0747992>] ip_local_deliver_finish+0xf5/0x194
 [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
 [<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44
 [<c0747ab3>] ip_local_deliver+0x3e/0x44
 [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
 [<c074775c>] ip_rcv_finish+0x29f/0x2c7
 [<c07474bd>] ? ip_rcv_finish+0x0/0x2c7
 [<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44
 [<c0747cae>] ip_rcv+0x1f5/0x233
 [<c07474bd>] ? ip_rcv_finish+0x0/0x2c7
 [<c071dce3>] __netif_receive_skb+0x310/0x336
 [<c07221f3>] netif_receive_skb+0x4b/0x51
 [<e0a4ed3d>] cp_rx_poll+0x1e7/0x29c [8139cp]
 [<c072275e>] net_rx_action+0x65/0x13a
 [<c0445a54>] __do_softirq+0xa1/0x149
 [<c04459b3>] ? __do_softirq+0x0/0x149
 <IRQ>
 [<c0445891>] ? irq_exit+0x37/0x72
 [<c040a7e9>] ? do_IRQ+0x81/0x95
 [<c07b3670>] ? common_interrupt+0x30/0x38
 [<c0428058>] ? native_safe_halt+0xa/0xc
 [<c040f5d7>] ? default_idle+0x58/0x92
 [<c0408fb0>] ? cpu_idle+0x96/0xb2
 [<c0797989>] ? rest_init+0x5d/0x5f
 [<c09fd90c>] ? start_kernel+0x34b/0x350
 [<c09fd0cb>] ? i386_start_kernel+0xba/0xc1
Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

auth_hmacs field of struct sctp_cookie is used for store
Requested HMAC Algorithm Parameter, and each HMAC Identifier
is 2 bytes, so the length should be:
  SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2
Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

dev_ethtool_get_rx_csum() won't report rx checksumming when it's not
changeable and driver is converted to hw_features and friends. Fix this.

(dev->hw_features & NETIF_F_RXCSUM) check is dropped - if the
ethtool_ops->get_rx_csum is set, then driver is not coverted, yet.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.

Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().

Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.

The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_POINTTOPOINT setting in
the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
of the two.  The usbnet framework only looks at the MAC address
for device naming if both flags are set, otherwise it trusts the
flag.
Signed-off-by: NArnd Bergmann <arnd.bergmann@linaro.org>
Tested-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now we have CONFIG_ARCH_DMA_ADDR_T_64BIT. We can fix the hacky
dma_addr_t size test cleanly.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>