We were clearing out the multicast filter whenever the interface was
upped, and not setting the mode bits correctly. This can cause
problems if there are any multicast addresses already set at this
point, or if ALLMULTI was set.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Without this the compiler can (and does) optimize register reads away
from within loops, and other such optimizations.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Each eTSEC device should own localized filer table.
Signed-off-by: Jiajun Wu <b06378@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().
To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.
Cc: stable@kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During channge channel, tx power will not send to uCode, the tx power command
should send after scan complete. but should also can send after RXON command.
Stable fix identified by Stanislaw Gruszka <sgruszka@redhat.com>.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: stable@kernel.org [2.6.38+]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When SR-IOV is enabled, i350 devices fail to pass traffic. This is due to
the driver attempting to enable RSS on the PF device, which is not
supported by the i350.
When max_vfs is specified on an i350 adapter, set the number of RSS queues
to 1.
This issue affects 2.6.39 as well.
CC: stable@kernel.org
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the case we fail to allocate a new skb, the old skb should
be resubmitted unmodified.
Fixes bug introduced in a9e12869758430424804.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Should pass along packet if there's no CRC and no hardware error.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Setting tx power can be deferred during scan or changing channel.
If after that correct tx power settings will not be sent to device,
we can observe transmission problems and timeouts. Force to send
tx power settings also after partial rxon change, to assure device
always be configured with up-to-date settings.
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=36492
Cc: stable@kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Avoid queue and run autowakeup_work when device is not present anymore.
That prevent rmmod and device remove crash introduced by:
commit 1c0bcf89d85cc97a0d9ce4cd909351a81fa4fdde
Author: Ivo van Doorn <ivdoorn@gmail.com>
Date: Sat Apr 30 17:18:18 2011 +0200
rt2x00: Add autowake support for USB hardware
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes 802.11n stability and performance regression we have
since 2.6.35. It boost performance on my 5GHz N-only network from about
5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz.
These are test results of 5x downloading of approximately 700MB iso
image:
vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110
patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946
This was achieved with NetworkManager configured to do not perform
periodical scans, by configuring constant BSSID. With periodical scans,
after some time, performance downgrade to unpatched driver level, like
in example below:
patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683
However patch still make better here, since similar test on unpatched
driver make link disconnects with below messages after some time:
wlan1: authenticate with 00:23:69:35:d1:3f (try 1)
wlan1: authenticate with 00:23:69:35:d1:3f (try 2)
wlan1: authenticate with 00:23:69:35:d1:3f (try 3)
wlan1: authentication with 00:23:69:35:d1:3f timed out
On 2.6.35 kernel patch helps against connection hangs with messages:
iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload.
iwlagn 0000:20:00.0: On demand firmware reload
iwlagn 0000:20:00.0: Stopping AGG while state not ON or starting
Cc: stable@kernel.org # 2.6.35+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix missing semicolon at end of smc91x.c match tabledevice driver.
Also remove unnecessary #ifdef around of_match_table pointer.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
The bonding driver is multiqueue enabled, in which each queue represents a slave
to enable optional steering of output frames to given slaves against the default
output policy. However, it needs to reset the skb->queue_mapping prior to
queuing to the physical device or the physical slave (if it is multiqueue) could
wind up transmitting on an unintended tx queue
Change Notes:
v2) Based on first pass review, updated the patch to restore the origional queue
mapping that was found in bond_select_queue, rather than simply resetting to
zero. This preserves the value of queue_mapping when it was set on receive in
the forwarding case which is desireable.
v3) Fixed spelling an casting error in skb->cb
v4) fixed to store raw queue_mapping to avoid double decrement
v5) Eric D requested that ->cb access be wrapped in a macro.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
buffer->skb should be marked NULL to avoid double free of the skb.
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Due to a change in FW template, a bug was introduced in dump queue entries. This is
fixed by reinitializing queue address before looping for each que dump operation.
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (40 commits)
tg3: Fix tg3_skb_error_unmap()
net: tracepoint of net_dev_xmit sees freed skb and causes panic
drivers/net/can/flexcan.c: add missing clk_put
net: dm9000: Get the chip in a known good state before enabling interrupts
drivers/net/davinci_emac.c: add missing clk_put
af-packet: Add flag to distinguish VID 0 from no-vlan.
caif: Fix race when conditionally taking rtnl lock
usbnet/cdc_ncm: add missing .reset_resume hook
vlan: fix typo in vlan_dev_hard_start_xmit()
net/ipv4: Check for mistakenly passed in non-IPv4 address
iwl4965: correctly validate temperature value
bluetooth l2cap: fix locking in l2cap_global_chan_by_psm
ath9k: fix two more bugs in tx power
cfg80211: don't drop p2p probe responses
Revert "net: fix section mismatches"
drivers/net/usb/catc.c: Fix potential deadlock in catc_ctrl_run()
sctp: stop pending timers and purge queues when peer restart asoc
drivers/net: ks8842 Fix crash on received packet when in PIO mode.
ip_options_compile: properly handle unaligned pointer
iwlagn: fix incorrect PCI subsystem id for 6150 devices
...
This reverts commit b1c43f82c5aa265442f82dba31ce985ebb7aa71c.
It was broken in so many ways, and results in random odd pty issues.
It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
cause endless work-loops (see commit a5660b41af6a: "tty: fix endless
work loop when the buffer fills up").
It also used an "unsigned int" return value fo the ->receive_buf()
function, but then made multiple functions return a negative error code,
and didn't actually check for the error in the caller.
And it didn't actually work at all. BenH bisected down odd tty behavior
to it:
"It looks like the patch is causing some major malfunctions of the X
server for me, possibly related to PTYs. For example, cat'ing a
large file in a gnome terminal hangs the kernel for -minutes- in a
loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
data in the quoted bits further down).
...
Some more data: It -looks- like what happens is that the
flush_to_ldisc work queue entry constantly re-queues itself (because
the PTY is full ?) and the workqueue thread will basically loop
forver calling it without ever scheduling, thus starving the consumer
process that could have emptied the PTY."
which is pretty much exactly the problem we fixed in a5660b41af6a.
Milton Miller pointed out the 'unsigned int' issue.
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: Milton Miller <miltonm@bga.com>
Cc: Stefan Bigler <stefan.bigler@keymile.com>
Cc: Toby Gray <toby.gray@realvnc.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 06e8935febe687e2a561707d4c7ca4245d261dbe adds an IRQ handling
optimization for single-function SDIO cards like this one, but at the
same time exposes a small hardware bug.
During hardware init, an interrupt is generated with (apparently) no
source. Previously, mmc threw this interrupt away, but now (due to the
optimization), the mmc layer passes this onto libertas, before it is ready
(and before it has enabled interrupts), causing a crash.
Work around this hardware bug by registering the IRQ handler later and
making it capable of handling interrupts with no cause. The change that
makes the IRQ handler registration happen later actually eliminates
the spurious interrupt as well.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We use priv->mutex to avoid race conditions between iwl_chswitch_done()
and iwlagn_mac_channel_switch(), when marking channel switch in
progress. But iwl_chswitch_done() can be called in atomic context
from iwl_rx_csa() or with mutex already taken from iwlagn_commit_rxon().
These bugs were introduced by:
commit 79d07325502e73508f917475bc1617b60979dd94
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Thu May 6 08:54:11 2010 -0700
iwlwifi: support channel switch offload in driver
To fix remove mutex from iwl_chswitch_done() and use atomic bitops for
marking channel switch pending.
Also remove iwl2030_hw_channel_switch() since 2000 series adapters are
2.4GHz only devices.
Cc: stable@kernel.org # 2.6.36+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Disable fast channel change by default on AR2413/AR5413 due to
some bug reports (it still works for me but it's better to be safe).
Add a module parameter "fastchanswitch" in case anyone wants to enable
it and play with it.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This function attempts to free one fragment beyond the number of
fragments that were actually mapped. This patch brings back the limit
to the correct spot.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Tested-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The failed_get label is used after the call to clk_get has succeeded, so it
should be moved up above the call to clk_put.
The failed_req labels doesn't do anything different than failed_get, so
delete it.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
expression e1,e2;
statement S;
@@
e1 = clk_get@p1(...);
... when != e1 = e2
when != clk_put(e1)
when any
if (...) { ... when != clk_put(e1)
when != if (...) { ... clk_put(e1) ... }
* return@p3 ...;
} else S
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently the DM9000 driver requests the primary interrupt before it
resets the chip and puts it into a known good state. This means that if
the chip is asserting interrupt for some reason we can end up with a
screaming IRQ that the interrupt handler is unable to deal with. Avoid
this by only requesting the interrupt after we've reset the chip so we
know what state it's in.
This started manifesting itself on one of my boards in the past month or
so, I suspect as a result of some core infrastructure changes removing
some form of mitigation against bad behaviour here, even when things boot
it seems that the new code brings the interface up more quickly.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Go to existing error handling code at the end of the function that calls
clk_put.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
expression e1,e2;
statement S;
@@
e1 = clk_get@p1(...);
... when != e1 = e2
when != clk_put(e1)
when any
if (...) { ... when != clk_put(e1)
when != if (...) { ... clk_put(e1) ... }
* return@p3 ...;
} else S
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This avoids messages like this after suspend:
cdc_ncm 2-1.4:1.6: no reset_resume for driver cdc_ncm?
cdc_ncm 2-1.4:1.7: no reset_resume for driver cdc_ncm?
cdc_ncm 2-1.4:1.6: usb0: unregister 'cdc_ncm' usb-0000:00:1d.0-1.4, CDC NCM
This is important for the Ericsson F5521gw GSM/UMTS modem.
Otherwise modemmanager looses the fact that the cdc_ncm and cdc_acm devices
belong together.
The cdc_ether module does the same.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
In some cases we can read wrong temperature value. If after that
temperature value will not be updated to good one, we badly configure
tx power parameters and device is unable to send a data.
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=35932
Cc: stable@kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is the same fix as
commit 841051602e3fa18ea468fe5a177aa92b6eb44b56
Author: Matteo Croce <technoboy85@gmail.com>
Date: Fri Dec 3 02:25:08 2010 +0100
The ath9k driver subtracts 3 dBm to the txpower as with two radios the
signal power is doubled.
The resulting value is assigned in an u16 which overflows and makes
the card work at full power.
in two more places. I grepped the ath tree and didn't find any others.
Cc: stable@kernel.org
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4.
It causes new build regressions with gcc-4.2 which is
pretty common on non-x86 platforms.
Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
catc_ctrl_run() calls usb_submit_urb() with GFP_KERNEL, while it is called from
catc_ctrl_async() and catc_ctrl_done() with catc->ctrl_lock spinlock held.
The patch replaces GFP_KERNEL with GFP_ATOMIC.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes a driver crash during packet reception due to not enough
bytes allocated in the skb. Since the loop reads out 4 bytes at a time, we
need to allow for up to 3 bytes of slack space.
Signed-off-by: Dennis Aberilla <denzzzhome@yahoo.com>
Signed-off-by: David S. Miller <davem@zippy.davemloft.net>
For 6150 devices, modify the supported PCI subsystem ID.
Cc: stable@kernel.org
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
zd1211 devices register 'EP 4 OUT' endpoint as Interrupt type on USB 2.0:
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
However on USB 1.1 endpoint becomes Bulk:
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Commit 37939810b937aba830dd751291fcdc51cae1a6cb assumed that endpoint is
always interrupt type and changed usb_bulk_msg() calls to usb_interrupt_msg().
Problem here is that usb_bulk_msg() on interrupt endpoint selfcorrects the
call and changes requested pipe to interrupt type (see usb_bulk_msg).
However with usb_interrupt_msg() on bulk endpoint does not correct the
pipe type to bulk, but instead URB is submitted with interrupt type pipe.
So pre-2.6.39 used usb_bulk_msg() and therefore worked with both endpoint
types, however in 2.6.39 usb_interrupt_msg() with bulk endpoint causes
ohci_hcd to fail submitted URB instantly with -ENOSPC and preventing zd1211rw
from working with OHCI.
Fix this by detecting endpoint type and using correct endpoint/pipe types
for URB. Also fix asynchronous zd_usb_iowrite16v_async() to use right
URB type on 'EP 4 OUT'.
Cc: stable@kernel.org
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix kernel oops when trying to use passive scheduled scans. The
reason was that in passive scans there are no SSIDs, so there was a
NULL pointer dereference.
To solve the problem, we now check the number of SSIDs provided in the
sched_scan request and only access the list if there's one or more
(ie. passive scan is not forced). We also force all the channels to
be passive by adding the IEEE80211_CHAN_PASSIVE_SCAN flag locally
before the checks in the wl1271_scan_get_sched_scan_channels()
function.
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use a different value for DFS dwell time when performing a scheduled
scan. Previously we were using the same value as for normal passive
scans. This adds some flexibility between these two different types
of passive scan.
For now we use 150 TUs for DFS channel dwell time. This may need to
be fine-tuned in the future.
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
DFS channels were never getting included in the scheduled scans,
because they always contain the passive flag as well and the call was
asking for DFS and active channels.
Fix this by ignoring the passive flag when collecting DFS channels.
Also, move the DFS channels in the channel list before the 5GHz active
channels (this was implemented in the FW differently than specified).
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We were comparing bitwise AND results with a boolean, so when the
boolean was set to true, it was not matching as it should.
Fix this by booleanizing the bitwise AND results with !!.
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Before this patch, the command sequence number is being set before
lbs_queue_cmd() adds the command to the queue. However, lbs_queue_cmd()
sometimes forces commands to queue-jump (e.g. CMD_802_11_WAKEUP_CONFIRM).
It currently does this without considering that sequence numbers might need
adjusting to keep things running in order.
Fix this by setting the sequence number at a later stage, just before
we're actually submitting the command to the hardware. Also fixes a
possible race where seqnum was being modified outside of the driver
lock.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ask for delayed callbacks on TX ring full, to give the
other side more of a chance to make progress.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* git://git.infradead.org/mtd-2.6: (97 commits)
mtd: kill CONFIG_MTD_PARTITIONS
mtd: remove add_mtd_partitions, add_mtd_device and friends
mtd: convert remaining users to mtd_device_register()
mtd: samsung onenand: convert to mtd_device_register()
mtd: omap2 onenand: convert to mtd_device_register()
mtd: txx9ndfmc: convert to mtd_device_register()
mtd: tmio_nand: convert to mtd_device_register()
mtd: socrates_nand: convert to mtd_device_register()
mtd: sharpsl: convert to mtd_device_register()
mtd: s3c2410 nand: convert to mtd_device_register()
mtd: ppchameleonevb: convert to mtd_device_register()
mtd: orion_nand: convert to mtd_device_register()
mtd: omap2: convert to mtd_device_register()
mtd: nomadik_nand: convert to mtd_device_register()
mtd: ndfc: convert to mtd_device_register()
mtd: mxc_nand: convert to mtd_device_register()
mtd: mpc5121_nfc: convert to mtd_device_register()
mtd: jz4740_nand: convert to mtd_device_register()
mtd: h1910: convert to mtd_device_register()
mtd: fsmc_nand: convert to mtd_device_register()
...
Fixed up trivial conflicts in
- drivers/mtd/maps/integrator-flash.c: removed in ARM tree
- drivers/mtd/maps/physmap.c: addition of afs partition probe type
clashing with removal of CONFIG_MTD_PARTITIONS
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
net: Kill ratelimit.h dependency in linux/net.h
net: Add linux/sysctl.h includes where needed.
net: Kill ether_table[] declaration.
inetpeer: fix race in unused_list manipulations
atm: expose ATM device index in sysfs
IPVS: bug in ip_vs_ftp, same list heaad used in all netns.
bug.h: Move ratelimit warn interfaces to ratelimit.h
bonding: cleanup module option descriptions
net:8021q:vlan.c Fix pr_info to just give the vlan fullname and version.
net: davinci_emac: fix dev_err use at probe
can: convert to %pK for kptr_restrict support
net: fix ETHTOOL_SFEATURES compatibility with old ethtool_ops.set_flags
netfilter: Fix several warnings in compat_mtw_from_user().
netfilter: ipset: fix ip_set_flush return code
netfilter: ipset: remove unused variable from type_pf_tdel()
netfilter: ipset: Use proper timeout value to jiffies conversion
The AR9287 calibration code was not being called because of an
incorrect MAC revision check.
This forced the AR9287 to use the AR9285 initial calibration code and
bypass the AR9287 code entirely.
Signed-off-by: Adrian Chadd <adrian@freebsd.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We make oldconfig every time when a new kernel arrives, but
if we don't have such a device(I guess this is the most common
case for a new device), the default value should be 'n' so
that the kernel size we build doesn't grow up too much quickly.
For anyone who has the device, it is OK for them to turn it on
by themselves.
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rx_status.band is used uninitialized, what disallow to work on 5GHz .
Cc: stable@kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6:
gfs2: Drop __TIME__ usage
isdn/diva: Drop __TIME__ usage
atm: Drop __TIME__ usage
dlm: Drop __TIME__ usage
wan/pc300: Drop __TIME__ usage
parport: Drop __TIME__ usage
hdlcdrv: Drop __TIME__ usage
baycom: Drop __TIME__ usage
pmcraid: Drop __DATE__ usage
edac: Drop __DATE__ usage
rio: Drop __DATE__ usage
scsi/wd33c93: Drop __TIME__ usage
scsi/in2000: Drop __TIME__ usage
aacraid: Drop __TIME__ usage
media/cx231xx: Drop __TIME__ usage
media/radio-maxiradio: Drop __TIME__ usage
nozomi: Drop __TIME__ usage
cyclades: Drop __TIME__ usage
Whenever there is a channel width change from 40 Mhz to 20 Mhz,
the hardware is reconfigured to ht20. Meantime before doing
the rate control updation, the packets are being transmitted are
selected rate with IEEE80211_TX_RC_40_MHZ_WIDTH.
While transmitting ht40 rate packets in ht20 mode is causing
baseband panic with AR9003 based chips.
==== BB update: BB status=0x02001109 ====
ath: ** BB state: wd=1 det=1 rdar=0 rOFDM=1 rCCK=1 tOFDM=0 tCCK=0 agc=2
src=0 **
ath: ** BB WD cntl: cntl1=0xffff0085 cntl2=0x00000004 **
ath: ** BB mode: BB_gen_controls=0x000033c0 **
ath: ** BB busy times: rx_clear=99%, rx_frame=0%, tx_frame=0% **
ath: ==== BB update: done ====
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While receiving unsupported rate frame rx state machine
gets into a state 0xb and if phy_restart happens in that
state, BB would go hang. If RXSM is in 0xb state after
first bb panic, ensure to disable the phy_restart.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
