21 Apr, 2010
1 commit
-
Define a new function to return the waitqueue of a "struct sock".
static inline wait_queue_head_t *sk_sleep(struct sock *sk)
{
return sk->sk_sleep;
}Change all read occurrences of sk_sleep by a call to this function.
Needed for a future RCU conversion. sk_sleep wont be a field directly
available.Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
20 Apr, 2010
11 commits
-
Set version to 1.52.53-1.
Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Author: Yaniv Rosner
Signed-off-by: Yaniv Rosner
Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Move "don't shut down the power" logic into bnx2x_set_power_state() to make the code cleaner.
Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Properly mask the value to be written to the register (according to the register size) during the self-test.
Otherwise immediate parity error would be generated.Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Try to enable less MSI-X vectors if initial request has failed.
Author: Dmitry Kravkov
Signed-off-by: Dmitry Kravkov
Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Added total_mcast/bcast_pkts_transmitted statistics.
Author: Dmitry Kravkov
Signed-off-by: Dmitry Kravkov
Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
White spaces, code readability and prints.
Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Don't run code that can't be run if MCP is not present.
This will prevent NULL pointer dereferencing.Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Increase DMAE max write size for 57711 to the maximum allowed value.
Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Author: Dmitry Kravkov
Signed-off-by: Dmitry Kravkov
Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
This patch introduces the parity errors handling code for 57710 and 57711 chips.
HW is configured to stop all DMA transactions to the host and sending packets to the network
once parity error is detected, which is meant to prevent silent data corruption.
At the same time HW generates the attention interrupt to every function of the device where parity
has been detected so that driver can start the recovery flow.The recovery is actually resetting the chip and restarting the driver on all active functions
of the chip where the parity error has been reported.Signed-off-by: Vladislav Zolotarov
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller
16 Apr, 2010
1 commit
-
…wireless-next-2.6 into for-davem
Conflicts:
Documentation/feature-removal-schedule.txt
drivers/net/wireless/ath/ath5k/phy.c
drivers/net/wireless/wl12xx/wl1271_main.c
15 Apr, 2010
12 commits
-
The ixgbe driver was setting up 82598 hardware correctly, so that
when promiscuous mode was enabled hardware stripping was turned
off. But on 82599 the logic to disable/enable hardware stripping
is different, and the code was not updated correctly when the
hardware vlan stripping was enabled as default.This change comprises the creation of two new helper functions
and calling them from the right locations to disable and enable
hardware stripping of vlan tags at appropriate times.Signed-off-by: Jesse Brandeburg
Signed-off-by: Jeff Kirsher
Signed-off-by: David S. Miller -
replaces (skb->len - skb->data_len) occurrences by skb_headlen(skb)
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller -
A very useful information was provided by Sitecom R&D guys:
Please find the information regarding our latest Ralink adapters below;
WL-302 - VID: 0x0DF6, PID: 0x002D - Ralink RT2771
WL-315 - VID: 0x0DF6, PID: 0x0039 - Ralink RT2770
WL-319 - VID: 0x182D, PID: 0x0037 - Ralink RT2860
WL-321 - VID: 0x0DF6, PID: 0x003B - Ralink RT2770
WL-324 - VID: 0x0DF6, PID: 0x003D - Ralink RT2870
WL-329 - VID: 0x0DF6, PID: 0x0041 - Ralink RT3572
WL-343 - VID: 0x0DF6, PID: 0x003E - Ralink RT3070
WL-344 - VID: 0x0DF6, PID: 0x0040 - Ralink RT3071
WL-345 - VID: 0x0DF6, PID: 0x0042 - Ralink RT3072
WL-608 - VID: 0x0DF6, PID: 0x003F - Ralink RT2070Note:
PID: 0x003C, 0x004A, and 0x004D: --these products do not exist; devices were never produced/shipped--The WL-349v4 USB dongle (0x0df6,0x0050) will be shipped soon (it isn't available yet), and uses a Ralink RT3370 chipset.
Signed-off-by: Xose Vazquez Perez
Acked-by: Gertjan van Wingerde
Signed-off-by: John W. Linville -
This patch adds the following 5 entries to the usbid device table:
* Netgear WNA1000
* Proxim ORiNOCO Dual Band 802.11n USB Adapter
* 3Com Dual Band 802.11n USB Adapter
* H3C Dual Band 802.11n USB Adapter
* WNC Generic 11n USB dongleCC:
Signed-off-by: Christian Lamparter
Signed-off-by: John W. Linville -
If EEPROM is used, NVS data is now loaded but ignored.
Stop loading it to avoid need of dummy NVS file for modules with EEPROM.Signed-off-by: Grazvydas Ignotas
Acked-by: Kalle Valo
Signed-off-by: John W. Linville -
This patch fixes two warnings below after unplugging ar9271 usb device:
-one is a kernel warning[1]
-another is a lockdep warning[2]The root reason is that __skb_queue_purge can't be executed in hardirq
context, so the patch forks ath9k_skb_queue_purge(ath9k version of _skb_queue_purge),
which frees skb with dev_kfree_skb_any which can be run in hardirq
context safely, then prevent the lockdep warning and kernel warning after
unplugging ar9271 usb device.[1] kernel warning
[ 602.894005] ------------[ cut here ]------------
[ 602.894005] WARNING: at net/core/skbuff.c:398 skb_release_head_state+0x71/0x87()
[ 602.894005] Hardware name: 6475EK2
[ 602.894005] Modules linked in: ath9k_htc ath9k ath9k_common ath9k_hw ath bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table kvm_intel kvm arc4 ecb mac80211 snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi snd_pcm snd_timer hwmon iTCO_wdt snd e1000e pcspkr i2c_i801 usbhid iTCO_vendor_support wmi cfg80211 yenta_socket rsrc_nonstatic pata_acpi snd_page_alloc soundcore uhci_hcd ohci_hcd ehci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: ath]
[ 602.894005] Pid: 2506, comm: ping Tainted: G W 2.6.34-rc3-wl #20
[ 602.894005] Call Trace:
[ 602.894005] [] warn_slowpath_common+0x7c/0x94
[ 602.894005] [] ? __skb_queue_purge+0x43/0x4a [ath9k_htc]
[ 602.894005] [] warn_slowpath_null+0x14/0x16
[ 602.894005] [] skb_release_head_state+0x71/0x87
[ 602.894005] [] __kfree_skb+0x16/0x81
[ 602.894005] [] kfree_skb+0x7e/0x86
[ 602.894005] [] __skb_queue_purge+0x43/0x4a [ath9k_htc]
[ 602.894005] [] __hif_usb_tx+0x1c1/0x21b [ath9k_htc]
[ 602.894005] [] hif_usb_tx_cb+0x12f/0x154 [ath9k_htc]
[ 602.894005] [] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
[ 602.894005] [] ehci_urb_done+0x7a/0x8b [ehci_hcd]
[ 602.894005] [] qh_completions+0x2ee/0x376 [ehci_hcd]
[ 602.894005] [] ehci_work+0x95/0x76e [ehci_hcd]
[ 602.894005] [] ? ehci_irq+0x2f/0x1d4 [ehci_hcd]
[ 602.894005] [] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
[ 602.894005] [] ? __rcu_process_callbacks+0x7a/0x2df
[ 602.894005] [] ? handle_fasteoi_irq+0x22/0xd2
[ 602.894005] [] usb_hcd_irq+0x4a/0xa7 [usbcore]
[ 602.894005] [] handle_IRQ_event+0x77/0x14f
[ 602.894005] [] ? skb_release_data+0xc9/0xce
[ 602.894005] [] handle_fasteoi_irq+0x92/0xd2
[ 602.894005] [] handle_irq+0x88/0x91
[ 602.894005] [] do_IRQ+0x63/0xc9
[ 602.894005] [] ? ip_flush_pending_frames+0x4d/0x5c
[ 602.894005] [] ret_from_intr+0x0/0x16
[ 602.894005] [] ? __delete_object+0x5a/0xb1
[ 602.894005] [] ? _raw_write_unlock_irqrestore+0x47/0x7e
[ 602.894005] [] ? _raw_write_unlock_irqrestore+0x4c/0x7e
[ 602.894005] [] __delete_object+0x5a/0xb1
[ 602.894005] [] delete_object_full+0x25/0x31
[ 602.894005] [] kmemleak_free+0x26/0x45
[ 602.894005] [] kfree+0xaa/0x149
[ 602.894005] [] ? sock_def_write_space+0x84/0x89
[ 602.894005] [] ? ip_flush_pending_frames+0x4d/0x5c
[ 602.894005] [] skb_release_data+0xc9/0xce
[ 602.894005] [] __kfree_skb+0x1e/0x81
[ 602.894005] [] kfree_skb+0x7e/0x86
[ 602.894005] [] ip_flush_pending_frames+0x4d/0x5c
[ 602.894005] [] raw_sendmsg+0x653/0x709
[ 602.894005] [] inet_sendmsg+0x54/0x5d
[ 602.894005] [] ? sock_recvmsg+0xc6/0xdf
[ 602.894005] [] sock_sendmsg+0xc0/0xd9
[ 602.894005] [] ? might_fault+0x68/0xb8
[ 602.894005] [] ? might_fault+0xb1/0xb8
[ 602.894005] [] ? copy_from_user+0x2f/0x31
[ 602.894005] [] ? verify_iovec+0x54/0x91
[ 602.894005] [] sys_sendmsg+0x1da/0x241
[ 602.894005] [] ? finish_task_switch+0x0/0xc9
[ 602.894005] [] ? finish_task_switch+0x0/0xc9
[ 602.894005] [] ? trace_hardirqs_on_caller+0x16/0x150
[ 602.894005] [] ? _raw_spin_unlock_irq+0x56/0x63
[ 602.894005] [] ? finish_task_switch+0xa4/0xc9
[ 602.894005] [] ? finish_task_switch+0x0/0xc9
[ 602.894005] [] ? need_resched+0x23/0x2d
[ 602.894005] [] ? trace_hardirqs_on_caller+0x16/0x150
[ 602.894005] [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 602.894005] [] system_call_fastpath+0x16/0x1b
[ 602.894005] ---[ end trace 91ba2d8dc7826839 ]---[2] lockdep warning
[ 169.363215] ======================================================
[ 169.365390] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[ 169.366334] 2.6.34-rc3-wl #20
[ 169.366872] ------------------------------------------------------
[ 169.366872] khubd/78 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 169.366872] (clock-AF_INET){++.?..}, at: [] sock_def_write_space+0x1e/0x89
[ 169.366872]
[ 169.366872] and this task is already holding:
[ 169.366872] (&(&hif_dev->tx.tx_lock)->rlock){-.-...}, at: [] hif_usb_stop+0x24/0x53 [ath9k_htc]
[ 169.366872] which would create a new lock dependency:
[ 169.366872] (&(&hif_dev->tx.tx_lock)->rlock){-.-...} -> (clock-AF_INET){++.?..}
[ 169.366872]
[ 169.366872] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 169.366872] (&(&hif_dev->tx.tx_lock)->rlock){-.-...}
[ 169.366872] ... which became HARDIRQ-irq-safe at:
[ 169.366872] [] __lock_acquire+0x2c6/0xd2b
[ 169.366872] [] lock_acquire+0xec/0x119
[ 169.366872] [] _raw_spin_lock+0x40/0x73
[ 169.366872] [] hif_usb_tx_cb+0x5e/0x154 [ath9k_htc]
[ 169.366872] [] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
[ 169.366872] [] ehci_urb_done+0x7a/0x8b [ehci_hcd]
[ 169.366872] [] qh_completions+0x2ee/0x376 [ehci_hcd]
[ 169.366872] [] ehci_work+0x95/0x76e [ehci_hcd]
[ 169.366872] [] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
[ 169.366872] [] usb_hcd_irq+0x4a/0xa7 [usbcore]
[ 169.366872] [] handle_IRQ_event+0x77/0x14f
[ 169.366872] [] handle_fasteoi_irq+0x92/0xd2
[ 169.366872] [] handle_irq+0x88/0x91
[ 169.366872] [] do_IRQ+0x63/0xc9
[ 169.366872] [] ret_from_intr+0x0/0x16
[ 169.366872] [] cpuidle_idle_call+0xa7/0x115
[ 169.366872] [] cpu_idle+0x68/0xc4
[ 169.366872] [] rest_init+0x104/0x10b
[ 169.366872] [] start_kernel+0x3f1/0x3fc
[ 169.366872] [] x86_64_start_reservations+0xb3/0xb7
[ 169.366872] [] x86_64_start_kernel+0xf8/0x107
[ 169.366872]
[ 169.366872] to a HARDIRQ-irq-unsafe lock:
[ 169.366872] (clock-AF_INET){++.?..}
[ 169.366872] ... which became HARDIRQ-irq-unsafe at:
[ 169.366872] ... [] __lock_acquire+0x33a/0xd2b
[ 169.366872] [] lock_acquire+0xec/0x119
[ 169.366872] [] _raw_write_lock_bh+0x45/0x7a
[ 169.366872] [] tcp_close+0x165/0x34d
[ 169.366872] [] inet_release+0x55/0x5c
[ 169.366872] [] sock_release+0x1f/0x6e
[ 169.366872] [] sock_close+0x27/0x2b
[ 169.366872] [] __fput+0x125/0x1ca
[ 169.366872] [] fput+0x1a/0x1c
[ 169.366872] [] filp_close+0x68/0x72
[ 169.366872] [] sys_close+0xad/0xe7
[ 169.366872] [] system_call_fastpath+0x16/0x1b(Trimmed at the "other info that might help us debug this" line in
the interest of brevity... -- JWL)Signed-off-by: Ming Lei
Acked-by: Sujith
Signed-off-by: John W. Linville -
In ath9k-htc register out path, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).Signed-off-by: Sujith
Signed-off-by: Ming Lei
Signed-off-by: John W. Linville -
In ath9k-htc register in path, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).Signed-off-by: Ming Lei
Signed-off-by: John W. Linville -
In ath9k_hif_usb_alloc_rx_urbs, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skbs allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).Signed-off-by: Ming Lei
Signed-off-by: John W. Linville -
We get RXORN interrupts when all receive buffers are full. This is not
necessarily a fatal situation. It can also happen when the bus is busy or the
CPU is not fast enough to process all frames.Older chipsets apparently need a reset to come out of this situration, but on
newer chips we can treat RXORN like RX, as going thru a full reset does more
harm than good, there.The exact chip revisions which need a reset are unknown - this guess
AR5K_SREV_AR5212 ("venice") is copied from the HAL.Inspired by openwrt 413-rxorn.patch:
"treat rxorn like rx, reset after rxorn seems to do more harm than good"Signed-off-by: Bruno Randolf
Signed-off-by: John W. Linville -
There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
resulted in high bitrates, which i think is what we want anyways. Cleared the
confusion and added some documentation.Signed-off-by: Bruno Randolf
Signed-off-by: John W. Linville
14 Apr, 2010
11 commits
-
Pointed out by Stephen Rothwell.
Signed-off-by: David S. Miller
-
Conflicts:
drivers/net/pcmcia/smc91c92_cs.c
drivers/net/virtio_net.c -
The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed. This happens because
tun/tap devices can hang on to skbs undefinitely.As noted by Herbert, possible solutions include a timeout followed by a
copy/change of ownership of the skb, or always copying/changing
ownership if we're going into a hostile device.This patch implements the second approach.
Note: one issue still remaining is that since skbs
keep reference to tun socket and tun socket has a
reference to tun device, we won't flush backlog,
instead simply waiting for all skbs to get transmitted.
At least this is not user-triggerable, and
this was not reported in practice, my assumption is
other devices besides tap complete an skb
within finite time after it has been queued.A possible solution for the second issue
would not to have socket reference the device,
instead, implement dev->destructor for tun, and
wait for all skbs to complete there, but this
needs some thought, probably too risky for 2.6.34.Signed-off-by: Michael S. Tsirkin
Tested-by: Yan Vugenfirer
Acked-by: Herbert Xu
Signed-off-by: David S. Miller -
Signed-off-by: Giuseppe Cavallaro
Signed-off-by: David S. Miller -
Moved STMMAC_VLAN_TAG_USED from stmmac.h to common.h header
because it is used within the device and descriptor cores.Signed-off-by: Giuseppe Cavallaro
Signed-off-by: David S. Miller -
Output for chip that uses the Enhanced descriptors:
[snip]
STMMAC driver:
platform registration... done!
DWMAC1000 - user ID: 0x10, Synopsys ID: 0x33
Enhanced descriptor structure
no valid MAC address;please, use ifconfig or nwhwconfig!
eth0 - (dev. name: stmmaceth - id: 0, IRQ #134
IO base addr: 0xfd110000)
STMMAC MII Bus: probed
[snip]Signed-off-by: Giuseppe Cavallaro
Signed-off-by: David S. Miller -
Fix the Transmit FIFO flush operation; it was
disabled while reworking the descriptor structures.Signed-off-by: Giuseppe Cavallaro
Signed-off-by: David S. Miller -
Currently the driver assumes that the mac10/100 can only use the
normal descriptor structure and the gmac can only use the
enhanced structures.
This patch removes the descriptor's code from the dma files
and adds two new files just for handling the normal and enhanced
descriptors.Signed-off-by: Giuseppe Cavallaro
Signed-off-by: David S. Miller -
The patch splits core and dma parts for the mac10/100 device.
This was already done for the GMAC device.
It should make more flexible the driver to support other chips.Signed-off-by: Giuseppe Cavallaro
Signed-off-by: David S. Miller -
Signed-off-by: Christoph Hellwig
Signed-off-by: Michael S. Tsirkin -
This is a fix for bug 572201 @ bugs.debian.org
This patch fixes the TX_LIMIT feature flag. The previous logic check
for TX_LIMIT2 also took into account a device that only had TX_LIMIT
set.Reported-by: Stephen Mulcahu
Reported-by: Ben Huchings
Signed-off-by: Ayaz Abdulla
Signed-off-by: David S. Miller
13 Apr, 2010
4 commits
-
The promiscous cmd config code gives an impression that
setting a port to promisc mode will unset the other port.
This is not the case and is clarified with a comment.Signed-off-by: Sathya Perla
Signed-off-by: David S. Miller -
Network drivers do not have to update last_rx, unless they need it for
their private use.Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller -
In the current implementation, CAN drivers need to #include
_before_ they #include , which is both ugly and
unnecessary.Fix this by including in and remove the
#include lines from drivers.Signed-off-by: Hans J. Koch
Signed-off-by: David S. Miller -
bcm_enet_hw_preinit will correctly set values in ENET_CTL_REG for internal
or external MII operations, however, bcm_enet_open will blindly overwrite the
ENET_CTL_REG register value and thus we will loose any changes to it that
were made in bcm_enet_hw_preinit, rendering external MII operations non-working.This would lead to the driver not being able to check for link availability on
external PHY setups, and thus we would never get to sending packets because
link was down from the driver side.This was completely un-noticed because all boards out there but BCM6338-based
ones use internal phy on their enet0 interface.Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
