- 26 4月, 2012 2 次提交
-
-
由 Matt Carlson 提交于
When RSS is enabled, interrupt vector 0 does not receive any rx traffic. The rx producer index fields for vector 0's status block should be considered reserved in this case. This patch changes the code to respect these reserved fields, which avoids a kernel panic when these fields take on non-zero values. Signed-off-by: NMatt Carlson <mcarlson@broadcom.com> Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Benjamin Poirier 提交于
Changes this beauty into a statement that actually has an effect on amd64. Tested-by: NPer Jessen <per@opensuse.org> Signed-off-by: NBenjamin Poirier <bpoirier@suse.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 25 4月, 2012 2 次提交
-
-
由 Meenakshi Venkataraman 提交于
Report correctly the latest released version of the iwlwifi firmware for all iwlwifi-supported devices. Cc: stable@vger.kernel.org #3.3+ Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Newer devices have 20 (5000 series) or 30 (6000 series) hardware queues, rather than the 16 that 4965 had. This was added to the driver a long time ago, but improperly: the queue registers for the higher queues aren't just continuations of the registers for the first 16 queues, they are in other places. Therefore, the hardware would lock up when trying to activate queue 16 or above and the device would have to be restarted. Thanks goes to Emmanuel who identified this and told me how the queue programming should be done. Note that we don't use queues 20 and higher today and doing so needs more work than this. Cc: stable@vger.kernel.org Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 24 4月, 2012 10 次提交
-
-
由 Ingo van Lil 提交于
The asix.c USB Ethernet driver avoids ending a tx transfer with a zero- length packet by appending a four-byte padding to transfers whose length is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket length is valid for high-speed USB only; full-speed USB uses 64 byte packets. Signed-off-by: NIngo van Lil <inguin@gmx.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Anatolij Gustschin 提交于
PHY connect attempts fail if no PHY id is specified in the emac platform data and another mdio bus has been registered before 'davinci_mdio' bus. In this case when configuring the interface, there will be an attempt to connect to already attached PHY on the previously registered mdio bus: net eth1: PHY already attached net eth1: could not connect to phy smsc911x-0:01 IP-Config: Failed to open eth1 IP-Config: Device `eth1' not found Fix this by modifying match_first_device() to match first PHY device on 'davinci_mdio' bus. Signed-off-by: NAnatolij Gustschin <agust@denx.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
If we receive an interrupt too early before we set up ports in the probe function, there won't be any port ready to handle it. Only registering the irq after the ports are setup fixes the problem, and works fine without losing any interrupts. This causes crashes in some situations: [c000000f7ff7fd60] d000000008e223f0 .ehea_neq_tasklet+0x78/0x148 [ehea] [c000000f7ff7fe00] c0000000000b6cac .tasklet_hi_action+0xdc/0x210 [c000000f7ff7fea0] c0000000000b7cc8 .__do_softirq+0x178/0x300 [c000000f7ff7ff90] c000000000022694 .call_do_softirq+0x14/0x24 [c000000f68ee7900] c000000000010e04 .do_softirq+0xec/0x110 [c000000f68ee79a0] c0000000000b789c .irq_exit+0xac/0xe0 [c000000f68ee7a20] c0000000000110bc .do_IRQ+0x114/0x2a8 [c000000f68ee7ae0] c00000000000553c hardware_interrupt_entry+0x18/0x1c Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stephane Fillod 提交于
Make smsc95xx recalculate the hard_mtu after adjusting the hard_header_len. Without this, usbnet adjusts the MTU down to 1488 bytes, and the host is unable to receive standard 1500-byte frames from the device. Inspired by same fix on cdc_eem 78fb72f7. Tested on ARM/Beagle. Signed-off-by: NStephane Fillod <fillods@users.sf.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eldad Zack 提交于
I keep getting the following messages on the log buffer: [ 2167.097507] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2281.331305] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2281.332539] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2329.876605] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2329.877354] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2462.280756] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2615.651689] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU From the code comment I understand that this something that can - and does, quite frequently - happen. Signed-off-by: NEldad Zack <eldad@fogrefinery.com> Acked-by: Franky Lin<frankyl@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
Under some circumstances, a PCI-based driver reports the following OOPs: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP: 0010:[<ffffffffa0418d39>] [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid: 19627, threadinfo ffff880050262000, task ffff8801156d5cc0) Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000002 ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000282 0000000180150014 ffff880050263fd8 ffff8801176c2810 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] ffff880050263bc8 ffffffff810550e2 00000000000002c0 ffff8801176c0d40 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] [<ffffffffa03348e7>] _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1 e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RSP <ffff880050263b58> Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0 Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace 8636c766dcfbe0e6 ]--- This oops is due to interrupts not being disabled in this particular path. Reported-by: NDave Airlie <airlied@gmail.com> Tested-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislav Yakovlev 提交于
Driver incorrectly validates command completion: instead of waiting for a command to be acknowledged it continues execution. Most of the time driver gets acknowledge of the command completion in a tasklet before it executes the next one. But sometimes it sends the next command before it gets acknowledge for the previous one. In such a case one of the following error messages appear in the log: Failed to send SYSTEM_CONFIG: Already sending a command. Failed to send ASSOCIATE: Already sending a command. Failed to send TX_POWER: Already sending a command. After that you need to reload the driver to get it working again. This bug occurs during roaming (reported by Sam Varshavchik) https://bugzilla.redhat.com/show_bug.cgi?id=738508 and machine booting (reported by Tom Gundersen and Mads Kiilerich) https://bugs.archlinux.org/task/28097 https://bugzilla.redhat.com/show_bug.cgi?id=802106 This patch doesn't fix the delay issue during firmware load. But at least device now works as usual after boot. Cc: stable@kernel.org Signed-off-by: NStanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
ctx->vif is dereferenced in different part of iwlwifi code, so do not nullify it. This should address at least one of the possible reasons of WARNING at iwlagn_mac_remove_interface, and perhaps some random crashes when firmware reset is performed. Cc: stable@vger.kernel.org Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
The 'ath9k_hw_update_regulatory_maxpower' helper function has been introduced by commit a55f8588 (ath9k_hw: Cleanup TX power calculation for AR9287). Updating of the max_power_level value has been moved into the helper function in that change, however the removed code from 'ath9k_hw_ar9287_set_txpower' has not been replaced with a call of the new helper function. Due to that missing call, retrieving tx power for 2x2 and 3x3 chainmask is not handled properly. During the calculation of the tx power for 2x2 and 3x3 chainmasks the values are reduced. Those reductions must be compensated during retrieving. Fix this by adding the missing call of the helper function. Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Acked-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
In order to unifying regulatory limit handling commit ca2c68cc (ath9k_hw: clean up tx power handling) introduced a new helper function 'ath9k_hw_apply_txpower', and the direct calls of 'ah->eep_ops->set_txpower' has been replaced by a call of the helper function. This caused a change in the behaviour of the 'ath9k_hw_set_txpowerlimit' function. The purpose of that function is to calculate and store the rate txpower table and the regulatory limit without touching the hardware registers. Before the commit, the 'test' parameter of the function was passed to the 'ah->eep_ops->set_txpower'. Now the calling of the 'set_txpower' function happens indirectly through 'ath9k_hw_apply_txpower', so the 'test' argument of the 'set_txpower' is always 'false'. This patch restores the original behaviour of 'ath9k_hw_set_txpowerlimit' by adding a new argument to 'ath9k_hw_apply_txpower.' Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 4月, 2012 4 次提交
-
-
由 Lee Jones 提交于
Refrain from attempting to free an interrupt line if the request fails and hence, there is no IRQ to free. CC: netdev@vger.kernel.org Signed-off-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Matt Renzelmann 提交于
The dev_id parameter passed to free_irq needs to match the one passed to the corresponding request_irq. Signed-off-by: NMatt Renzelmann <mjr@cs.wisc.edu> Acked-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Wenqi Ma 提交于
Although the network interface is down, the RX packets number which could be observed by ifconfig may keep on increasing. This is because the WORK scheduled in netvsc_set_multicast_list() may be executed after netvsc_close(). That means the rndis filter may be re-enabled by do_set_multicast() even if it was closed by netvsc_close(). By canceling possible WORK before close the rndis filter, the issue could be never happened. Signed-off-by: NWenqi Ma <wenqi_ma@trendmicro.com.cn> Reviewed-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stephen Boyd 提交于
There is a potential deadlock scenario when the ks8851 driver is removed. The interrupt handler schedules a workqueue which acquires a mutex that ks8851_net_stop() also acquires before flushing the workqueue. Previously lockdep wouldn't be able to find this problem but now that it has the support we can trigger this lockdep warning by rmmoding the driver after an ifconfig up. Fix the possible deadlock by disabling the interrupts in the chip and then release the lock across the workqueue flushing. The mutex is only there to proect the registers anyway so this should be ok. ======================================================= [ INFO: possible circular locking dependency detected ] 3.0.21-00021-g8b33780-dirty #2911 ------------------------------------------------------- rmmod/125 is trying to acquire lock: ((&ks->irq_work)){+.+...}, at: [<c019e0b8>] flush_work+0x0/0xac but task is already holding lock: (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&ks->lock){+.+...}: [<c01b89c8>] __lock_acquire+0x940/0x9f8 [<c01b9058>] lock_acquire+0x10c/0x130 [<c083dbec>] mutex_lock_nested+0x68/0x3dc [<bf00bd48>] ks8851_irq_work+0x24/0x46c [ks8851] [<c019c580>] process_one_work+0x2d8/0x518 [<c019cb98>] worker_thread+0x220/0x3a0 [<c01a2ad4>] kthread+0x88/0x94 [<c0107008>] kernel_thread_exit+0x0/0x8 -> #0 ((&ks->irq_work)){+.+...}: [<c01b7984>] validate_chain+0x914/0x1018 [<c01b89c8>] __lock_acquire+0x940/0x9f8 [<c01b9058>] lock_acquire+0x10c/0x130 [<c019e104>] flush_work+0x4c/0xac [<bf00b858>] ks8851_net_stop+0x6c/0x138 [ks8851] [<c06b209c>] __dev_close_many+0x98/0xcc [<c06b2174>] dev_close_many+0x68/0xd0 [<c06b22ec>] rollback_registered_many+0xcc/0x2b8 [<c06b2554>] rollback_registered+0x28/0x34 [<c06b25b8>] unregister_netdevice_queue+0x58/0x7c [<c06b25f4>] unregister_netdev+0x18/0x20 [<bf00c1f4>] ks8851_remove+0x64/0xb4 [ks8851] [<c049ddf0>] spi_drv_remove+0x18/0x1c [<c0468e98>] __device_release_driver+0x7c/0xbc [<c0468f64>] driver_detach+0x8c/0xb4 [<c0467f00>] bus_remove_driver+0xb8/0xe8 [<c01c1d20>] sys_delete_module+0x1e8/0x27c [<c0105ec0>] ret_fast_syscall+0x0/0x3c other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ks->lock); lock((&ks->irq_work)); lock(&ks->lock); lock((&ks->irq_work)); *** DEADLOCK *** 4 locks held by rmmod/125: #0: (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f44>] driver_detach+0x6c/0xb4 #1: (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f50>] driver_detach+0x78/0xb4 #2: (rtnl_mutex){+.+.+.}, at: [<c06b25e8>] unregister_netdev+0xc/0x20 #3: (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851] Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 20 4月, 2012 4 次提交
-
-
由 Giuseppe CAVALLARO 提交于
This patch fixes and adds the irq handler for the IC+ 101A/G where we need to read the reg17 to clean the irq. Also remove the flag for the 1001LF where no interrupt can be used for this device. Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Bjørn Mork 提交于
The MC77xx devices can operate in two modes: "Direct IP" or "QMI", switchable using a password protected AT command. Both product ID and USB interface configuration will change when switched. The "sierra_net" driver supports the "Direct IP" mode. This driver supports the "QMI" mode. There are also multiple possible USB interface configurations in each mode, some providing more than one wwan interface. Like many other devices made for Windows, different interface types are identified using a static interface number. We define a Sierra specific interface whitelist to support this. Signed-off-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
The sp_pri_to_cos[] array size depends on the config but lets say it is BX_E3B0_MAX_NUM_COS_PORT0 and max_num_of_cos is also DCBX_E3B0_MAX_NUM_COS_PORT0. In the original code "pri == max_num_of_cos" was accepted but it is one past the end of the array. Also we used "pri" before capping it. It's a harmless read past the end of the array, but it would affect which error message gets printed. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NEilon Greenstein <eilong@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
MAX_ADDR_LEN is 32. ETH_ALEN is 6. mac->sa_data is a 14 byte array, so the memcpy() is doing a read past the end of the array. I asked about this on netdev and Ben Hutchings told me it's supposed to be copying ETH_ALEN bytes (thanks Ben). Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 18 4月, 2012 6 次提交
-
-
由 Julia Lawall 提交于
Free card->mem in the error-handling code since it was successfully allocated just above. Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Christian Riesch 提交于
Under heavy load (flood ping) it is possible for the MDIO timeout to expire before the loop checks the GO bit again. This patch adds an additional check whether the operation was done before actually returning -ETIMEDOUT. To reproduce this bug, flood ping the device, e.g., ping -f -l 1000 After some time, a "timed out waiting for user access" warning may appear. And even worse, link may go down since the PHY reported a timeout. Signed-off-by: NChristian Riesch <christian.riesch@omicron.at> Cc: <stable@vger.kernel.org> Cc: Cyril Chemparathy <cyril@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jiri Kosina 提交于
arcrimi_probe() calls BUGMSG() before register_netdev() happens. BUGMSG() itself prints dev->name, but as the format string hasn't been expanded by register_netdev() yet, the output contains bogus device name such as arc%d: Given: node 00h, shmem 0h, irq 0 As we don't know the device name yet, just drop the prefix completely from the debugging messages. Reported-by: NSteven Young <sdyoung@vt220.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alexander Duyck 提交于
This patch makes it so that we identify FCoE rings earlier than ixgbe_set_rx_buffer_len. Instead we identify the Rx FCoE rings at allocation time in ixgbe_alloc_q_vector. The motivation behind this change is to avoid memory corruption when FCoE is enabled. Without this change we were initializing the rings at 0, and 2K on systems with 4K pages, then when we bumped the buffer size to 4K with order 1 pages we were accessing offsets 2K and 6K instead of 0 and 4K. This was resulting in memory corruptions. Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Acked-by: NYi Zou <yi.zou@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Benjamin Poirier 提交于
Upon resume from standby, ixgbe may trigger the ASSERT_RTNL() in netif_set_real_num_tx_queues(). The call stack is: netif_set_real_num_tx_queues ixgbe_set_num_queues ixgbe_init_interrupt_scheme ixgbe_resume Signed-off-by: NBenjamin Poirier <bpoirier@suse.de> Tested-by: NStephen Ko <stephen.s.ko@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Sujith Manoharan 提交于
Assigning sequence number for frames without taking care of the fragment field breaks transmission of fragmented frames. Fix this by assigning the fragment number properly. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 17 4月, 2012 3 次提交
-
-
由 Hiroaki SHIMODA 提交于
In register_netdevice(), when ndo_init() is successful and later some error occurred, ndo_uninit() will be called. So dummy deivce is desirable to implement ndo_uninit() method to free percpu stats for this case. And, ndo_uninit() is also called along with dev->destructor() when device is unregistered, so in order to prevent dev->dstats from being freed twice, dev->destructor is modified to free_netdev(). Signed-off-by: NHiroaki SHIMODA <shimoda.hiroaki@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stephane Fillod 提交于
Make smsc75xx recalculate the hard_mtu after adjusting the hard_header_len. Without this, usbnet adjusts the MTU down to 1492 bytes, and the host is unable to receive standard 1500-byte frames from the device. Inspired by same fix on cdc_eem 78fb72f7. Tested on ARM/Omap3 with EVB-LAN7500-LC. Signed-off-by: NStephane Fillod <fillods@users.sf.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jesper Juhl 提交于
If either call to pcan_usb_pro_send_req() in drivers/net/can/usb/peak_usb/pcan_usb_pro.c::pcan_usb_pro_init() fails, we'll leak the memory we allocated to 'usb_if' with kzalloc() when the 'usb_if' variable goes out of scope without having been assigned to anything as we 'return err;'. Fix this by adding appropriate kfree(usb_if) calls to the error paths. Signed-off-by: NJesper Juhl <jj@chaosbits.net> Acked-by: NStephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
- 15 4月, 2012 1 次提交
-
-
由 Davide Ciminaghi 提交于
At the beginning of ks_rcv(), a for loop retrieves the header information relevant to all the frames stored in the mac's internal buffers. The number of pending frames is stored as an 8 bits field in KS_RXFCTR. If interrupts are disabled long enough to allow for more than 32 frames to accumulate in the MAC's internal buffers, a buffer overflow occurs. This patch fixes the problem by making the driver's frame_head_info buffer big enough. Well actually, since the chip appears to have 12K of internal rx buffers and the shortest ethernet frame should be 64 bytes long, maybe the limit could be set to 12*1024/64 = 192 frames, but 255 should be safer. Signed-off-by: NDavide Ciminaghi <ciminaghi@gnudd.com> Signed-off-by: NRaffaele Recalcati <raffaele.recalcati@bticino.it> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 4月, 2012 8 次提交
-
-
由 Don Skidmore 提交于
There are times we turn of the laser before shutdown. This is a bad thing if we want to wake on lan to work so now we make sure the laser is on before shutdown if we support WoL. Signed-off-by: NDon Skidmore <donald.c.skidmore@intel.com> Tested-by: NStephen Ko <stephen.s.ko@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Bruce Allan 提交于
A workaround was previously put in the driver to reset the device when transitioning to Sx in order to activate the changed settings of the PHY OEM bits (Low Power Link Up, or LPLU, and GbE disable configuration) for 82577/8/9 devices. After further review, it was found such a reset can cause the 82579 to confuse which version of 82579 it actually is and broke LPLU on all 82577/8/9 devices. The workaround during an S0->Sx transition on 82579 (instead of resetting the PHY) is to restart auto-negotiation after the OEM bits are configured; the restart of auto-negotiation activates the new OEM bits as does the reset. With 82577/8, the reset is changed to a generic reset which fixes the LPLU bits getting set wrong. Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Will Deacon 提交于
The SMSC911x driver resets the ->head, ->data and ->tail pointers in the skb on the reset path in order to avoid buffer overflow due to packet padding performed by the hardware. This patch fixes the receive path so that the skb pointers are fixed up after the data has been read from the device, The error path is also fixed to use number of words consistently and prevent erroneous FIFO fastforwarding when skipping over bad data. Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Bing Zhao 提交于
The scratch register addresses have been changed for newer chips. Since the old chip was never shipped and it will not be supported any more, just update register addresses to support the new chips. Cc: <stable@vger.kernel.org> # 3.2.y, 3.3.y Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
The hardware needs a reset to recover from full sleep. Issue this reset directly in the ath9k_config call that turns off idle, otherwise tx remains dead until the first channel change after the idle state change Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jonathan Bither 提交于
Signed-off-by: NJonathan Bither <jonbither@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jonathan Bither 提交于
When cross compiling ath5k for a Mips machine with kernel 3.2.14 the compilation fails with "/ath5k/ahb.c:231:12: error: 'THIS_MODULE' undeclared here (not in a function)" Fix the build by including <linux/export.h> Signed-off-by: NJonathan Bither <jonbither@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Arend van Spriel 提交于
There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211. This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3. Cc: stable@vger.kernel.org Tested-by: NFrancesco Saverio Schiavarelli <fschiava@libero.it> Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: NBrett Rudley <brudley@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-