summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2010-04-16Merge branch 'master' of ↵John W. Linville138-5391/+7885
git://git.kernel.org/pub/scm/linux/kernel/git/linville/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
2010-04-15Merge branch 'vhost' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostDavid S. Miller2-7/+8
2010-04-15ixgbe: fix bug with vlan strip in promsic modeJesse Brandeburg1-43/+72
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 <jesse.brandeburg@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-15drivers: net: use skb_headlen()Eric Dumazet17-33/+33
replaces (skb->len - skb->data_len) occurrences by skb_headlen(skb) Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14wireless: rt2x00: rt2800usb: identify Sitecom devicesXose Vazquez Perez1-7/+4
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 RT2070 Note: 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 <xose.vazquez@gmail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-04-14ar9170usb: add a couple more USB IDsChristian Lamparter1-0/+10
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 dongle CC: <stable@kernel.org> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-04-14wl1251: don't require NVS data when EEPROM is usedGrazvydas Ignotas1-2/+2
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 <notasas@gmail.com> Acked-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-04-14ath9k-htc: fix lockdep warning and kernel warning after unplugging ar9271 ↵Ming Lei1-2/+9
usb device 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] <IRQ> [<ffffffff8104a41c>] warn_slowpath_common+0x7c/0x94 [ 602.894005] [<ffffffffa022f398>] ? __skb_queue_purge+0x43/0x4a [ath9k_htc] [ 602.894005] [<ffffffff8104a448>] warn_slowpath_null+0x14/0x16 [ 602.894005] [<ffffffff813269c1>] skb_release_head_state+0x71/0x87 [ 602.894005] [<ffffffff8132829a>] __kfree_skb+0x16/0x81 [ 602.894005] [<ffffffff813283b2>] kfree_skb+0x7e/0x86 [ 602.894005] [<ffffffffa022f398>] __skb_queue_purge+0x43/0x4a [ath9k_htc] [ 602.894005] [<ffffffffa022f560>] __hif_usb_tx+0x1c1/0x21b [ath9k_htc] [ 602.894005] [<ffffffffa022f73c>] hif_usb_tx_cb+0x12f/0x154 [ath9k_htc] [ 602.894005] [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore] [ 602.894005] [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd] [ 602.894005] [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd] [ 602.894005] [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd] [ 602.894005] [<ffffffffa00fa5ae>] ? ehci_irq+0x2f/0x1d4 [ehci_hcd] [ 602.894005] [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd] [ 602.894005] [<ffffffff810a6d18>] ? __rcu_process_callbacks+0x7a/0x2df [ 602.894005] [<ffffffff810a47a4>] ? handle_fasteoi_irq+0x22/0xd2 [ 602.894005] [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore] [ 602.894005] [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f [ 602.894005] [<ffffffff813285ce>] ? skb_release_data+0xc9/0xce [ 602.894005] [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2 [ 602.894005] [<ffffffff8100c4fb>] handle_irq+0x88/0x91 [ 602.894005] [<ffffffff8100baed>] do_IRQ+0x63/0xc9 [ 602.894005] [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c [ 602.894005] [<ffffffff813ba993>] ret_from_intr+0x0/0x16 [ 602.894005] <EOI> [<ffffffff811095fe>] ? __delete_object+0x5a/0xb1 [ 602.894005] [<ffffffff813ba5f5>] ? _raw_write_unlock_irqrestore+0x47/0x7e [ 602.894005] [<ffffffff813ba5fa>] ? _raw_write_unlock_irqrestore+0x4c/0x7e [ 602.894005] [<ffffffff811095fe>] __delete_object+0x5a/0xb1 [ 602.894005] [<ffffffff81109814>] delete_object_full+0x25/0x31 [ 602.894005] [<ffffffff813a60c0>] kmemleak_free+0x26/0x45 [ 602.894005] [<ffffffff810ff517>] kfree+0xaa/0x149 [ 602.894005] [<ffffffff81323fb7>] ? sock_def_write_space+0x84/0x89 [ 602.894005] [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c [ 602.894005] [<ffffffff813285ce>] skb_release_data+0xc9/0xce [ 602.894005] [<ffffffff813282a2>] __kfree_skb+0x1e/0x81 [ 602.894005] [<ffffffff813283b2>] kfree_skb+0x7e/0x86 [ 602.894005] [<ffffffff81354245>] ip_flush_pending_frames+0x4d/0x5c [ 602.894005] [<ffffffff81370c1f>] raw_sendmsg+0x653/0x709 [ 602.894005] [<ffffffff81379e31>] inet_sendmsg+0x54/0x5d [ 602.894005] [<ffffffff813207a2>] ? sock_recvmsg+0xc6/0xdf [ 602.894005] [<ffffffff813208c1>] sock_sendmsg+0xc0/0xd9 [ 602.894005] [<ffffffff810e13b4>] ? might_fault+0x68/0xb8 [ 602.894005] [<ffffffff810e13fd>] ? might_fault+0xb1/0xb8 [ 602.894005] [<ffffffff8132a1c3>] ? copy_from_user+0x2f/0x31 [ 602.894005] [<ffffffff8132a5b3>] ? verify_iovec+0x54/0x91 [ 602.894005] [<ffffffff81320d41>] sys_sendmsg+0x1da/0x241 [ 602.894005] [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9 [ 602.894005] [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9 [ 602.894005] [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150 [ 602.894005] [<ffffffff813ba27d>] ? _raw_spin_unlock_irq+0x56/0x63 [ 602.894005] [<ffffffff8103d3cb>] ? finish_task_switch+0xa4/0xc9 [ 602.894005] [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9 [ 602.894005] [<ffffffff810357fe>] ? need_resched+0x23/0x2d [ 602.894005] [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150 [ 602.894005] [<ffffffff813b9750>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 602.894005] [<ffffffff81009c02>] 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: [<ffffffff81323f51>] 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: [<ffffffffa03715b0>] 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] [<ffffffff810772d5>] __lock_acquire+0x2c6/0xd2b [ 169.366872] [<ffffffff8107866d>] lock_acquire+0xec/0x119 [ 169.366872] [<ffffffff813b99bb>] _raw_spin_lock+0x40/0x73 [ 169.366872] [<ffffffffa037163d>] hif_usb_tx_cb+0x5e/0x154 [ath9k_htc] [ 169.366872] [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore] [ 169.366872] [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd] [ 169.366872] [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd] [ 169.366872] [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd] [ 169.366872] [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd] [ 169.366872] [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore] [ 169.366872] [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f [ 169.366872] [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2 [ 169.366872] [<ffffffff8100c4fb>] handle_irq+0x88/0x91 [ 169.366872] [<ffffffff8100baed>] do_IRQ+0x63/0xc9 [ 169.366872] [<ffffffff813ba993>] ret_from_intr+0x0/0x16 [ 169.366872] [<ffffffff8130f6ee>] cpuidle_idle_call+0xa7/0x115 [ 169.366872] [<ffffffff81008c4f>] cpu_idle+0x68/0xc4 [ 169.366872] [<ffffffff813a41e0>] rest_init+0x104/0x10b [ 169.366872] [<ffffffff81899db3>] start_kernel+0x3f1/0x3fc [ 169.366872] [<ffffffff818992c8>] x86_64_start_reservations+0xb3/0xb7 [ 169.366872] [<ffffffff818993c4>] 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] ... [<ffffffff81077349>] __lock_acquire+0x33a/0xd2b [ 169.366872] [<ffffffff8107866d>] lock_acquire+0xec/0x119 [ 169.366872] [<ffffffff813b9d07>] _raw_write_lock_bh+0x45/0x7a [ 169.366872] [<ffffffff8135cf14>] tcp_close+0x165/0x34d [ 169.366872] [<ffffffff8137aced>] inet_release+0x55/0x5c [ 169.366872] [<ffffffff81321350>] sock_release+0x1f/0x6e [ 169.366872] [<ffffffff813213c6>] sock_close+0x27/0x2b [ 169.366872] [<ffffffff8110dd45>] __fput+0x125/0x1ca [ 169.366872] [<ffffffff8110de04>] fput+0x1a/0x1c [ 169.366872] [<ffffffff8110adc9>] filp_close+0x68/0x72 [ 169.366872] [<ffffffff8110ae80>] sys_close+0xad/0xe7 [ 169.366872] [<ffffffff81009c02>] 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 <tom.leiming@gmail.com> Acked-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-04-14ath9k-htc:respect usb buffer cacheline alignment in reg out pathMing Lei3-13/+16
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 <Sujith.Manoharan@atheros.com> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-04-14ath9k-htc:respect usb buffer cacheline alignment in reg in pathMing Lei3-9/+12
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 <tom.leiming@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-04-14ath9k-htc:respect usb buffer cacheline alignment in ath9k_hif_usb_alloc_rx_urbsMing Lei1-3/+3
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 <tom.leiming@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-04-14ath5k: treat RXORN as non-fatalBruno Randolf2-1/+15
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 <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-04-14ath5k: Use high bitrates for ACK/CTSBruno Randolf3-6/+5
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 <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-04-14virtio_net: Fix mis-merge.David S. Miller1-1/+0
Pointed out by Stephen Rothwell. Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14Merge branch 'master' of ↵David S. Miller7-8/+16
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/pcmcia/smc91c92_cs.c drivers/net/virtio_net.c
2010-04-14tun: orphan an skb on txMichael S. Tsirkin1-0/+4
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 <mst@redhat.com> Tested-by: Yan Vugenfirer <yvugenfi@redhat.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14stmmac: updated the drv module versionGiuseppe CAVALLARO1-1/+1
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14stmmac: fix vlan support setupGiuseppe CAVALLARO2-5/+5
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 <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14stmmac: get the descriptor structure from platformGiuseppe CAVALLARO2-4/+9
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 <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14stmmac: fix Transmit FIFO flush operationGiuseppe CAVALLARO6-13/+12
Fix the Transmit FIFO flush operation; it was disabled while reworking the descriptor structures. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14stmmac: rework normal and enhanced descriptorsGiuseppe CAVALLARO12-584/+627
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 <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14stmmac: split core and dma for the mac10/100Giuseppe CAVALLARO4-200/+234
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 <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-14vhost: fix sparse warningsChristoph Hellwig2-7/+8
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2010-04-14forcedeth: fix tx limit2 flag checkAyaz Abdulla1-1/+1
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 <stephen.mulcahy@deri.org> Reported-by: Ben Huchings <ben@decadent.org.uk> Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13be2net: clarify promiscuous cmd with a commentSathya Perla1-0/+4
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 <sathyap@serverengines.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13drivers: net: last_rx eliminationEric Dumazet7-9/+0
Network drivers do not have to update last_rx, unless they need it for their private use. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13Fix some #includes in CAN drivers (rebased for net-next-2.6)Hans J. Koch13-13/+0
In the current implementation, CAN drivers need to #include <linux/can.h> _before_ they #include <linux/can/dev.h>, which is both ugly and unnecessary. Fix this by including <linux/can.h> in <linux/can/dev.h> and remove the #include <linux/can.h> lines from drivers. Signed-off-by: Hans J. Koch <hjk@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13bcm63xx_enet: do not overwrite ENET_CTL_REG valueFlorian Fainelli1-1/+3
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 <ffainelli@freebox.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13PHY: fix typo in bcm63xx PHY driver tableFlorian Fainelli1-1/+1
Signed-off-by: Florian Fainelli <ffainelli@freebox.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13chelsio: Fix build warning.David S. Miller1-1/+1
GCC warns that: drivers/net/chelsio/sge.c:463:11: warning: operation on 's->port' may be undefined Better to eliminate the side effects in the calculation and express what was intended here. Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13smc91c92_cs: define multicast_table as unsigned charKen Kawasaki1-7/+6
smc91c92_cs: * define multicast_table as unsigned char * remove unnecessary "#ifndef final_version" Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13e1000e: stop cleaning when we reach tx_ring->next_to_useTerry Loftin1-0/+2
Tx ring buffers after tx_ring->next_to_use are volatile and could change, possibly causing a crash. Stop cleaning when we hit tx_ring->next_to_use. Signed-off-by: Terry Loftin <terry.loftin@hp.com> Acked-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13igb: restrict WoL for 82576 ET2 Quad Port Server AdapterStefan Assmann2-0/+2
Restrict Wake-on-LAN to first port on 82576 ET2 quad port NICs, as it is only supported there. Signed-off-by: Stefan Assmann <sassmann@redhat.com> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13e1000e: use static params to save stack spaceJesse Brandeburg1-8/+8
used a modified checkstack to get the 56 number (normally checkstack wouldn't show this low a value) checkstack before: 0x0000012f e1000e_check_options [e1000e]: 272 after: 0x0000012f e1000e_check_options [e1000e]: 56 Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13igb: modify register test for i350 to reflect read only bits in RDLEN/TDLENAlexander Duyck1-4/+4
The registers for RDLEN/TDLEN on i350 have the first 7 bits as read only. This is a change from previous hardware in which it was only the first 4 bits that were read only. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13myri10ge: use the DMA state API instead of the pci equivalentsFUJITA Tomonori1-22/+22
This replace the PCI DMA state API (include/linux/pci-dma.h) with the DMA equivalents since the PCI DMA state API will be obsolete. No functional change. For further information about the background: http://marc.info/?l=linux-netdev&m=127037540020276&w=2 Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Andrew Gallatin <gallatin@myri.com> Cc: Brice Goglin <brice@myri.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13qlge: use the DMA state API instead of the pci equivalentsFUJITA Tomonori2-33/+33
This replace the PCI DMA state API (include/linux/pci-dma.h) with the DMA equivalents since the PCI DMA state API will be obsolete. No functional change. For further information about the background: http://marc.info/?l=linux-netdev&m=127037540020276&w=2 Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Ron Mercer <ron.mercer@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13cxgb3: use the DMA state API instead of the pci equivalentsFUJITA Tomonori1-10/+10
This replace the PCI DMA state API (include/linux/pci-dma.h) with the DMA equivalents since the PCI DMA state API will be obsolete. No functional change. For further information about the background: http://marc.info/?l=linux-netdev&m=127037540020276&w=2 Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Divy Le Ray <divy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13chelsio: use the DMA state API instead of the pci equivalentsFUJITA Tomonori1-25/+25
This replace the PCI DMA state API (include/linux/pci-dma.h) with the DMA equivalents since the PCI DMA state API will be obsolete. No functional change. For further information about the background: http://marc.info/?l=linux-netdev&m=127037540020276&w=2 Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Divy Le Ray <divy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13qla3xxx: use the DMA state API instead of the pci equivalentsFUJITA Tomonori2-36/+36
This replace the PCI DMA state API (include/linux/pci-dma.h) with the DMA equivalents since the PCI DMA state API will be obsolete. No functional change. For further information about the background: http://marc.info/?l=linux-netdev&m=127037540020276&w=2 Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Ron Mercer <ron.mercer@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13tg3: use the DMA state API instead of the pci equivalentsFUJITA Tomonori2-22/+22
This replace the PCI DMA state API (include/linux/pci-dma.h) with the DMA equivalents since the PCI DMA state API will be obsolete. No functional change. For further information about the background: http://marc.info/?l=linux-netdev&m=127037540020276&w=2 Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Matt Carlson <mcarlson@broadcom.com> Cc: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13tg3: Update version to 3.110Matt Carlson1-2/+2
This patch updates the tg3 version to 3.110. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Reviewed-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13tg3: Remove function errors flagged by checkpatchMatt Carlson1-9/+9
This patch removes the following checkpatch errors: * return is not a function, parentheses are not required * space prohibited between function name and open parenthesis '(' Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Reviewed-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13tg3: Unify max pkt size preprocessor constantsMatt Carlson2-3/+2
The maximum packet size that gets programmed into the standard producer ring control block is directly related to the packet size used to allocate packet buffers. This patch removes the redundant preprocessor constant. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Reviewed-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13tg3: Re-inline VLAN tags when appropriateMatt Carlson1-11/+33
The tg3 driver is written so that VLAN tagged packets can be accepted, even if CONFIG_VLAN_8021Q or CONFIG_VLAN_8021Q_MODULE is not defined. (Think raw interfaces.) If the device has ASF support enabled, the firmware requires the driver to enable VLAN tag stripping. If VLAN tagging is not explicitly supported by the kernel and ASF is enabled, the driver will have to reinject the VLAN tag back into the packet stream. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Reviewed-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13tg3: Optimize rx double copy testMatt Carlson2-10/+27
On a PCIX bus, the 5701 has a bug which requires the driver to double copy all rx packets. The rx code uses the rx_offset device member as a flag to determine if this workaround should take effect. The following patch will modify the rx_offset member such that this test will become less clear. The patch starts by integrating the workaround check into the packet length check. It rounds out the implementation by relaxing the workaround restrictions if the platform has efficient unaligned accesses. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Reviewed-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13tg3: Reduce 57765 core clock when link at 10MbpsMatt Carlson1-0/+5
This patch reduces the core clock to 6.25MHz when operating at 10Mbps link speed. This is needed to prevent a bug that will ultimately cause transmits to cease. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Reviewed-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13tg3: Set card 57765 card reader MRRS to 1024BMatt Carlson2-0/+3
This patch sets the Maximum Read Request Size for the card reader function to 1024 bytes to prevent an SD controller lockup. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Reviewed-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13tg3: Disable CLKREQ in L2Matt Carlson2-0/+16
This patch disables CLKREQ in L2 to workaround a chipset bug. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Reviewed-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-13gianfar: Add hardware TX timestamping supportManfred Rudigier2-20/+101
If a packet has the skb_shared_tx->hardware flag set the device is instructed to generate a TX timestamp and write it back to memory after the frame is transmitted. During the clean_tx_ring operation the timestamp will be extracted and copied into the skb_shared_hwtstamps struct of the skb. TX timestamping is enabled by setting the tx_type to something else than HWTSTAMP_TX_OFF with the SIOCSHWTSTAMP ioctl command. It is only supported by eTSEC devices. Signed-off-by: Manfred Rudigier <manfred.rudigier@omicron.at> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-28 11:58:41 +0300