Commit 250cce26d5 uses UTS_RELEASE
as the the in-tree iwlwifi driver version. However the inclusion
of generated/utsrelease.h makes it a unpleasant behaviour to
recompile the driver everytime when utsrelease.h is updated. In
fact, the driver module is already built with the UTS_RELEASE
information via vermagic of modinfo. Mark the in-tree driver
with the version string "in-tree" to distinguish with those old
out-of-tree drivers.
Reported-by: David Miller <davem@davemloft.net>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Current rt2x00 drivers may result in a "ieee80211_tx_status: headroom too
small" error message when a frame needs to be properly aligned before
transmitting it.
This is because the space needed to ensure proper alignment isn't
requested from mac80211.
Fix this by adding sufficient amount of alignment space to the amount
of headroom requested for TX frames.
Reported-by: David Ellingsworth <david@identd.dyndns.org>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2800_blink_set uses an illegal value to set the LED_CFG_G_LED_MODE
field of the LED_CFG register. This field is only 2 bits large, so
should be initialized with value that fits. Use default value from
the vendor driver.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use rt2x00dev->ops->extra_tx_headroom, not rt2x00dev->hw->extra_tx_headroom
in the tx code, as the later may include other headroom not to be used in
the chipset driver.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It turns out that some PCI devices require extra delays when changing
power state from D3 to D0 (and the other way around). Although this
is against the PCI specification, we can handle it quite easily by
allowing drivers to define arbitrary D3 delays for devices known to
require extra time for switching power states.
Introduce additional field d3_delay in struct pci_dev and use it to
store the value of the device's D0->D3 delay, in miliseconds. Make
the PCI PM core code use the per-device d3_delay unless
pci_pm_d3_delay is greater (in which case the latter is used).
[This also allows the driver to specify d3_delay shorter than the
10 ms required by the PCI standard if the device is known to be able
to handle that.]
Make the sky2 driver set d3_delay to 150 for devices handled by it.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14730 which is a
listed regression from 2.6.30.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 enabled EEPROM
checksum checks to avoid bogus bug reports but failed to address
updating the code to consider devices with custom EEPROM sizes.
Devices with custom sized EEPROMs have the upper limit size stuffed
in the EEPROM. Use this as the upper limit instead of the static
default size. In case of a checksum error also provide back the
max size and whether or not this was the default size or a custom
one. If the EEPROM is busted we add a failsafe check to ensure
we don't loop forever or try to read bogus areas of hardware.
This closes bug 14874
http://bugzilla.kernel.org/show_bug.cgi?id=14874
Cc: stable@kernel.org
Cc: David Quan <david.quan@atheros.com>
Cc: Stephen Beahm <stephenbeahm@comcast.net>
Reported-by: Joshua Covington <joshuacov@googlemail.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If multicast parameter (as returned by zd_op_prepare_multicast) has
changed, no bit in changed_flags is set. To handle this situation, we do
not return if changed_flags is 0. If we do so, we will have some issue
with IPv6 which uses multicast for link layer address resolution.
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
tid is used as an array offset.
agg = &priv->stations[sta_id].tid[tid].agg;
iwl4965_tx_status_reply_tx(priv, agg, tx_resp, txq_id, index);
It should be limitted to MAX_TID_COUNT - 1;
struct iwl_tid_data tid[MAX_TID_COUNT];
regards,
dan carpenter
Signed-off-by: Dan Carpenter <error27@gmail.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If there was an error acquiring the firmware lock in
mwl8k_configure_filter(), we would end up leaking the multicast
command packet prepared by mwl8k_prepare_multicast().
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The unit of sizeof() is byte instead of bit, so fix it.
The patch can fix debug output of some dma_addr_t variables.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add missing DEBUG_FS dependency for ATH9K_DEBUGFS in ath9k's Kconfig.
Signed-off-by: Dominik D. Geyer <dominik.geyer@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I noticed a timeout bug in
/drivers/net/wireless/wl12xx/wl1271_spi.c
In the current code you cannot tell why you exited
the "poll for data ready" do-while loop if exiting
was done after the last possible loop.
Then timeout==0 regardless of (val & OCP_READY_MASK) or
!(val & OCP_READY_MASK), leading to possible false timeout...
Simple correction could be decreasing timeout after checking
for !(val & OCP_READY_MASK), not before
(Manually converted from email to an actual patch by me. -- JWL)
Reported-by: "Juha Leppanen" <juha_motorsportcom@luukku.com>
Signed-off-by: "Juha Leppanen" <juha_motorsportcom@luukku.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
o Dump registers such as tx ring and rx ring counter, firmware state,
niu regs, etc. which can be useful for debugging purpose.
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
tx_skbuff is define as:
struct sk_buff *tx_skbuff[TX_RING_ENTRIES];
EVT_RING_ENTRIES is 64 and TX_RING_ENTRIES is 32.
This function is in a error path so that's why it wasn't noticed.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
With `while (--limit > 0)' i reaches 0 after the loop, so upon timeout the
error was not returned.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
With `while (--i > 0)' i reaches 0 after the loop, so upon timeout the
error was not issued.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
lp->rx_skb has type struct sk_buff **, not struct sk_buff *, so the
elements of the array should have pointer type, not structure type.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@disable sizeof_type_expr@
type T;
T **x;
@@
x =
<+...sizeof(
- T
+ *x
)...+>
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
This should address the problems in version 1 (lazy) and version 2 (ugly).
Bump the stats on orig_dev not on the newly assigned NULL dev variable.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
With `while (i++ < MII_TIMEOUT)' i reaches MII_TIMEOUT + 1 after the loop
This is probably unlikely a problem in practice.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Test the just-allocated value for NULL rather than some other value.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x,y;
statement S;
@@
x = \(kmalloc\|kcalloc\|kzalloc\)(...);
(
if ((x) == NULL) S
|
if (
- y
+ x
== NULL)
S
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use kzalloc rather than kcalloc(1,...)
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
@@
- kcalloc(1,
+ kzalloc(
...)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
velocity_open() calls velocity_give_many_rx_descs(), which gives RX
descriptors to the NIC, before installing an interrupt handler or
calling velocity_init_registers(). I think this is very unsafe and it
appears to explain the bug report <http://bugs.debian.org/508527>.
On MTU change, velocity_give_many_rx_descs() is again called before
velocity_init_registers(). I'm not sure whether this is unsafe but
it does look wrong.
Therefore, move the calls to velocity_give_many_rx_descs() after
request_irq() and velocity_init_registers().
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Jan Ceuleers <jan.ceuleers@computer.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This allows a bond device to specify an arp_ip_target as a host that is
not on the same vlan as the base bond device and still use arp
validation. A configuration like this, now works:
BONDING_OPTS="mode=active-backup arp_interval=1000 arp_ip_target=10.0.100.1 arp_validate=3"
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::213:21ff:febe:33e9/64 scope link
valid_lft forever preferred_lft forever
9: bond0.100@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
inet 10.0.100.2/24 brd 10.0.100.255 scope global bond0.100
inet6 fe80::213:21ff:febe:33e9/64 scope link
valid_lft forever preferred_lft forever
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 1000
ARP IP target/s (n.n.n.n form): 10.0.100.1
Slave Interface: eth1
MII Status: up
Link Failure Count: 1
Permanent HW addr: 00:40:05:30:ff:30
Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:13:21:be:33:e9
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We use a rather complicated logic to support eTSEC and eTSEC2.0
registers maps in a single driver. Currently, the code tries to
unmap 'regs', but for non-eTSEC2.0 controllers 'regs' doesn't
point to a mapping start, and this might cause badness on probe
failure or module removal:
Freescale PowerQUICC MII Bus: probed
Trying to vfree() nonexistent vm area (e107f000)
------------[ cut here ]------------
Badness at c00a7754 [verbose debug info unavailable]
NIP: c00a7754 LR: c00a7754 CTR: c02231ec
[...]
NIP [c00a7754] __vunmap+0xec/0xf4
LR [c00a7754] __vunmap+0xec/0xf4
Call Trace:
[df827e50] [c00a7754] __vunmap+0xec/0xf4 (unreliable)
[df827e70] [c001519c] iounmap+0x44/0x54
[df827e80] [c028b924] fsl_pq_mdio_probe+0x1cc/0x2fc
[df827eb0] [c02fb9b4] of_platform_device_probe+0x5c/0x84
[df827ed0] [c0229928] really_probe+0x78/0x1a8
[df827ef0] [c0229b20] __driver_attach+0xa4/0xa8
Fix this by introducing a proper priv structure (finally!), which
now holds 'regs' and 'map' fields separately.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sometimes ucc_geth fails to suspend with the following trace:
ucc_geth e0103000.ucc: suspend
ucc_geth e0102000.ucc: suspend
NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------
Badness at net/sched/sch_generic.c:255
NIP: c021cb5c LR: c021cb5c CTR: c01ab4b4
[...]
NIP [c021cb5c] dev_watchdog+0x298/0x2a8
LR [c021cb5c] dev_watchdog+0x298/0x2a8
Call Trace:
[c0389da0] [c021cb5c] dev_watchdog+0x298/0x2a8 (unreliable)
[c0389e00] [c0031ed8] run_timer_softirq+0x16c/0x1dc
[c0389e50] [c002c638] __do_softirq+0xa4/0x11c
[...]
This patch fixes the issue by properly detaching the device on
suspend, and attaching it back on resume.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since hibernation assumes power loss, we should fully reinitialize
PHYs (including platform fixups), as if PHYs were just attached.
This patch factors phy_init_hw() out of phy_attach_direct(), then
converts mdio_bus to dev_pm_ops and adds an appropriate restore()
callback.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sometimes kernel hangs on resume with the following trace:
ucc_geth e0102000.ucc: resume
INFO: task bash:1764 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash D 0fecf43c 0 1764 1763 0x00000000
Call Trace:
[cf9a7c10] [c0012868] ret_from_except+0x0/0x14 (unreliable)
--- Exception: cf9a7ce0 at __switch_to+0x4c/0x6c
LR = 0xcf9a7cc0
[cf9a7cd0] [c0008c14] __switch_to+0x4c/0x6c (unreliable)
[cf9a7ce0] [c028bcfc] schedule+0x158/0x260
[cf9a7d10] [c028c720] __mutex_lock_slowpath+0x80/0xd8
[cf9a7d40] [c01cf388] phy_stop+0x20/0x70
[cf9a7d50] [c01d514c] ugeth_resume+0x6c/0x13c
[...]
Here is why.
On suspend:
- PM core starts suspending devices, ucc_geth_suspend gets called;
- ucc_geth calls phy_stop() on suspend. Note that phy_stop() is
mostly asynchronous so it doesn't block ucc_geth's suspend routine,
it just sets PHY_HALTED state and disables PHY's interrupts;
- Suddenly the state machine gets scheduled, it grabs the phydev->lock
mutex and tries to process the PHY_HALTED state, so it calls
phydev->adjust_link(phydev->attached_dev). In ucc_geth case
adjust_link() calls msleep(), which reschedules the code flow back to
PM core, which now finishes suspend and so we end up sleeping with
phydev->lock mutex held.
On resume:
- PM core starts resuming devices (notice that nobody rescheduled
the state machine yet, so the mutex is still held), the core calls
ucc_geth's resume routine;
- ucc_geth_resume restarts the PHY with phy_stop()/phy_start()
sequence, and the phy_*() calls are trying to grab the phydev->lock
mutex. Here comes the deadlock.
This patch fixes the issue by stopping the state machine on suspend
and starting it again on resume.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (74 commits)
Revert "b43: Enforce DMA descriptor memory constraints"
iwmc3200wifi: fix array out-of-boundary access
wl1251: timeout one too soon in wl1251_boot_run_firmware()
mac80211: fix propagation of failed hardware reconfigurations
mac80211: fix race with suspend and dynamic_ps_disable_work
ath9k: fix missed error codes in the tx status check
ath9k: wake hardware during AMPDU TX actions
ath9k: wake hardware for interface IBSS/AP/Mesh removal
ath9k: fix suspend by waking device prior to stop
cfg80211: fix error path in cfg80211_wext_siwscan
wl1271_cmd.c: cleanup char => u8
iwlwifi: Storage class should be before const qualifier
ath9k: Storage class should be before const qualifier
cfg80211: fix race between deauth and assoc response
wireless: remove remaining qual code
rt2x00: Add USB ID for Linksys WUSB 600N rev 2.
ath5k: fix SWI calibration interrupt storm
mac80211: fix ibss join with fixed-bssid
libertas: Remove carrier signaling from the scan code
orinoco: fix GFP_KERNEL in orinoco_set_key with interrupts disabled
...
Use the %pM kernel extension to display the MAC address.
The only difference in the output is that the MAC address is
shown in the usual colon-separated hex notation instead of
space-separated.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
All its members (vif, mac_addr, type) are now available
in the vif struct directly, so we can pass that instead
of the conf struct. I generated this patch (except the
mac80211 and header file changes) with this semantic
patch:
@@
identifier conf, fn, hw;
type tp;
@@
tp fn(struct ieee80211_hw *hw,
-struct ieee80211_if_init_conf *conf)
+struct ieee80211_vif *vif)
{
<...
(
-conf->type
+vif->type
|
-conf->mac_addr
+vif->addr
|
-conf->vif
+vif
)
...>
}
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We've long lacked a good confirmation that frames
have really gone out, e.g. before going off-channel
for a scan. Add a flush() operation that drivers
can implement to provide that confirmation, and use
it in a few places:
* before scanning sends the nullfunc frames
* after scanning sends the nullfunc frames, if any
* when going idle, to send any pending frames
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
