- 24 12月, 2009 8 次提交
-
-
由 Ben Hutchings 提交于
This hardware watchdog can misfire, so it does more harm than good. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Hutchings 提交于
Some cables have EEPROMs that conflict with the PHY's on-board EEPROM so it cannot load firmware. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Matthew Slattery 提交于
The PHY's firmware very occasionally appears to lock up very early, but with the heartbeat update still running. Rebooting the microcontroller core seems to be sufficient to recover. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Matthew Slattery 提交于
The PHY boots in a mode which is not necessarily optimal. This change switches it to self-configure mode (except when in loopback, which won't work in that mode if an SFP+ module is not present) by rebooting the PHY's microcontroller, and replicating the sequence of configuration writes from the boot EEPROM with the appropriate changes. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Matthew Slattery 提交于
If we see the PHY remaining stuck in a link-down state due to PCS being down while PMA/PMD is up, we briefly switch to PMA/PMD loopback and back, which usually unsticks it. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Neil Turton 提交于
We need buffer->len to remain valid to work out the correct address to be unmapped. We therefore need to clear buffer->len after the unmap operation. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Hutchings 提交于
The XGXS block may not get a link immediately in XGXS or XAUI loopback modes, so we still need to check it. Split falcon_xaui_link_ok() into falcon_xgxs_link_ok(), which checks only the Falcon XGXS block, and falcon_xmac_link_ok(), which checks one or both sides of the link as appropriate. Also rename falcon_check_xaui_link() to falcon_xmac_link_ok_retry(). Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Steve Hodgson 提交于
This prevents efx->link_advertising from being blatted during a reset. The phy_short_reach sysfs node is now destroyed later in the port shutdown process, so check for STATE_RUNNING after acquiring the rtnl_lock (just like in set_phy_flash_cfg). Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 22 12月, 2009 23 次提交
-
-
由 Benjamin Herrenschmidt 提交于
The option to support the old style PSK interface in the PS3 GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
My commit 77fdaa12 Author: Johannes Berg <johannes@sipsolutions.net> Date: Tue Jul 7 03:45:17 2009 +0200 mac80211: rework MLME for multiple authentications inadvertedly broke WMM because it removed, along with a bunch of other now useless initialisations, the line initialising sdata->u.mgd.wmm_last_param_set to -1 which would make it adopt any WMM parameter set. If, as is usually the case, the AP uses WMM parameter set sequence number zero, we'd never update it until the AP changes the sequence number. Add the missing initialisation back to get the WMM settings from the AP applied locally. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Cc: stable@kernel.org [2.6.31+] Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
I noticed yesterday, because Jeff had noticed a speed regression, cf. bug http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2138 that the SM PS settings for peers were wrong. Instead of overwriting the SM PS settings with the local bits, we need to keep the remote bits. The bug was part of the original HT code from over two years ago, but unfortunately nobody noticed that it makes no sense -- we shouldn't be overwriting the peer's setting with our own but rather keep it intact when masking the peer capabilities with our own. While fixing that, I noticed that the masking of capabilities is completely useless for most of the bits, so also fix those other bits. Finally, I also noticed that PSMP_SUPPORT no longer exists in the final 802.11n version, so also remove that. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Roel Kluin 提交于
`queue' was unsigned so the test did not work. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Reviewed-by: NPavel Roskin <proski@gnu.org> Acked-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Mack 提交于
The libertas driver copies the SSID buffer back to the wireless core and appends a trailing NULL character for termination. This is a) unnecessary because the buffer is allocated with kzalloc and is hence already NULLed when this function is called, and b) for priv->curbssparams.ssid_len == 32, it writes back one byte too much which causes memory corruptions. Fix this by removing the extra write. Signed-off-by: NDaniel Mack <daniel@caiaq.de> Cc: Stephen Hemminger <shemminger@vyatta.com> Cc: Maithili Hinge <maithili@marvell.com> Cc: Kiran Divekar <dkiran@marvell.com> Cc: Michael Hirsch <m.hirsch@raumfeld.com> Cc: netdev@vger.kernel.org Cc: libertas-dev@lists.infradead.org Cc: linux-wireless@lists.infradead.org Cc: stable@kernel.org Acked-by: NHolger Schurig <holgerschurig@gmail.com> Acked-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
drivers/net/wireless/iwlwifi/iwl-tx.c: In function `iwl_hw_txq_ctx_free': drivers/net/wireless/iwlwifi/iwl-tx.c:410: warning: suggest explicit braces to avoid ambiguous `else' Cc: Zhu Yi <yi.zhu@intel.com> Cc: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
The MIB counters are disabled when doing a chip reset. Since ANI depends on the MIB registers for its operation, relying on the contents of said registers during HW reset results in sub-optimal performance. Cc: stable@kernel.org Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
When TX DMA termination has failed, the HW has to be reset completely. Doing a fast channel change in this case is insufficient. Also, change the debug level of a couple of messages to FATAL. Cc: stable@kernel.org Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
The internal, driver-specific maintenance of sequence numbers is applicable only for HT frames. Also, remove comments that are not relevant anymore. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gertjan van Wingerde 提交于
Fix typo. The index should be multiplied by the entry size, not 'and'-ed. Found via code-inspection. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
Some devices have 40MHz operation disabled entirely. Ensure that driver do not enable 40MHz operation if a channel does not allow this. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2135Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> CC: stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Zhu Yi 提交于
3945 updated write_ptr without regard to read_ptr on the Tx path. This messes up our TFD on high load and result in the following: <1>[ 7290.414172] IP: [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <4>[ 7290.414205] PGD 0 <1>[ 7290.414214] Thread overran stack, or stack corrupted <0>[ 7290.414229] Oops: 0002 [#1] PREEMPT SMP <0>[ 7290.414246] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input <4>[ 7290.414265] CPU 0 <4>[ 7290.414274] Modules linked in: af_packet nfsd usb_storage usb_libusual cpufreq_powersave exportfs cpufreq_conservative iwl3945 nfs cpufreq_userspace snd_hda_codec_realtek acpi_cpufreq uvcvideo lockd iwlcore snd_hda_intel joydev coretemp nfs_acl videodev snd_hda_codec mac80211 v4l1_compat snd_hwdep sbp2 v4l2_compat_ioctl32 uhci_hcd psmouse auth_rpcgss ohci1394 cfg80211 ehci_hcd video ieee1394 snd_pcm serio_raw battery ac nvidia(P) usbcore output sunrpc evdev lirc_ene0100 snd_page_alloc rfkill tg3 libphy fuse lzo lzo_decompress lzo_compress <6>[ 7290.414486] Pid: 0, comm: swapper Tainted: P 2.6.32-rc8-wl #213 Aspire 5720 <6>[ 7290.414507] RIP: 0010:[<ffffffffa0dd53a1>] [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <6>[ 7290.414541] RSP: 0018:ffff880002203d60 EFLAGS: 00010246 <6>[ 7290.414557] RAX: 000000000000004f RBX: ffff880064c11600 RCX: 0000000000000013 <6>[ 7290.414576] RDX: ffffffffa0ddcf20 RSI: ffff8800512b7008 RDI: 0000000000000038 <6>[ 7290.414596] RBP: ffff880002203dd0 R08: 0000000000000000 R09: 0000000000000100 <6>[ 7290.414616] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000000000a0 <6>[ 7290.414635] R13: 0000000000000002 R14: 0000000000000013 R15: 0000000000020201 <6>[ 7290.414655] FS: 0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000 <6>[ 7290.414677] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b <6>[ 7290.414693] CR2: 0000000000000041 CR3: 0000000001001000 CR4: 00000000000006f0 <6>[ 7290.414712] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <6>[ 7290.414732] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 <4>[ 7290.414752] Process swapper (pid: 0, threadinfo ffffffff81524000, task ffffffff81528b60) <0>[ 7290.414772] Stack: <4>[ 7290.414780] ffff880002203da0 0000000000000046 0000000000000000 0000000000000046 <4>[ 7290.414804] <0> 0000000000000282 0000000000000282 0000000000000282 ffff880064c12010 <4>[ 7290.414830] <0> ffff880002203db0 ffff880064c11600 ffff880064c12e50 ffff8800512b7000 <0>[ 7290.414858] Call Trace: <0>[ 7290.414867] <IRQ> <4>[ 7290.414884] [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945] <4>[ 7290.414910] [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60 <4>[ 7290.414931] [<ffffffff81049a21>] tasklet_action+0x101/0x110 <4>[ 7290.414950] [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160 <4>[ 7290.414968] [<ffffffff8100d01c>] call_softirq+0x1c/0x30 <4>[ 7290.414986] [<ffffffff8100eff5>] do_softirq+0x75/0xb0 <4>[ 7290.415003] [<ffffffff81049ee5>] irq_exit+0x95/0xa0 <4>[ 7290.415020] [<ffffffff8100e547>] do_IRQ+0x77/0xf0 <4>[ 7290.415038] [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf <0>[ 7290.415052] <EOI> <4>[ 7290.415067] [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415087] [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5 <4>[ 7290.415107] [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415130] [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0 <4>[ 7290.415149] [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110 <4>[ 7290.415168] [<ffffffff8137b3d5>] ? rest_init+0x75/0x80 <4>[ 7290.415187] [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3 <4>[ 7290.415206] [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129 <4>[ 7290.415227] [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb <0>[ 7290.415243] Code: 00 41 39 ce 0f 8d e8 01 00 00 48 8b 47 40 48 63 d2 48 69 d2 98 00 00 00 4c 8b 04 02 48 c7 c2 20 cf dd a0 49 8d 78 38 49 8d 40 4f <c6> 47 09 00 c6 47 0c 00 c6 47 0f 00 c6 47 12 00 c6 47 15 00 49 <1>[ 7290.415382] RIP [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <4>[ 7290.415410] RSP <ffff880002203d60> <0>[ 7290.415421] CR2: 0000000000000041 <4>[ 7290.415436] ---[ end trace ec46807277caa515 ]--- <0>[ 7290.415450] Kernel panic - not syncing: Fatal exception in interrupt <4>[ 7290.415468] Pid: 0, comm: swapper Tainted: P D 2.6.32-rc8-wl #213 <4>[ 7290.415486] Call Trace: <4>[ 7290.415495] <IRQ> [<ffffffff8138c040>] panic+0x7d/0x13a <4>[ 7290.415519] [<ffffffff8101071a>] oops_end+0xda/0xe0 <4>[ 7290.415538] [<ffffffff8102e1ea>] no_context+0xea/0x250 <4>[ 7290.415557] [<ffffffff81038991>] ? select_task_rq_fair+0x511/0x780 <4>[ 7290.415578] [<ffffffff8102e475>] __bad_area_nosemaphore+0x125/0x1e0 <4>[ 7290.415597] [<ffffffff81038d0c>] ? __enqueue_entity+0x7c/0x80 <4>[ 7290.415616] [<ffffffff81039201>] ? enqueue_task_fair+0x111/0x150 <4>[ 7290.415636] [<ffffffff8102e53e>] bad_area_nosemaphore+0xe/0x10 <4>[ 7290.415656] [<ffffffff8102e8fa>] do_page_fault+0x26a/0x320 <4>[ 7290.415674] [<ffffffff813905df>] page_fault+0x1f/0x30 <4>[ 7290.415697] [<ffffffffa0dd53a1>] ? iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <4>[ 7290.415723] [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945] <4>[ 7290.415746] [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60 <4>[ 7290.415764] [<ffffffff81049a21>] tasklet_action+0x101/0x110 <4>[ 7290.415783] [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160 <4>[ 7290.415801] [<ffffffff8100d01c>] call_softirq+0x1c/0x30 <4>[ 7290.415818] [<ffffffff8100eff5>] do_softirq+0x75/0xb0 <4>[ 7290.415835] [<ffffffff81049ee5>] irq_exit+0x95/0xa0 <4>[ 7290.415852] [<ffffffff8100e547>] do_IRQ+0x77/0xf0 <4>[ 7290.415869] [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf <4>[ 7290.415883] <EOI> [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415911] [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5 <4>[ 7290.415931] [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415952] [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0 <4>[ 7290.415971] [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110 <4>[ 7290.415989] [<ffffffff8137b3d5>] ? rest_init+0x75/0x80 <4>[ 7290.416007] [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3 <4>[ 7290.416026] [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129 <4>[ 7290.416047] [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb Reported-by: NMaxim Levitsky <maximlevitsky@gmail.com> Tested-by: NMaxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> CC: stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
Recent powersaving work resulted in power management ops being called during EEPROM initialization. The lock used by these functions is not initialized at this time. Ensure lock is initialized before it is used. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
we see from http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2125 that power saving does not work well on 3945. Since then power saving has also been connected with association problems where an AP deathenticates a 3945 after it is unable to transmit data to it - this happens when 3945 enters power savings mode. Disable power save support until issues are resolved. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> CC: stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
I've also for a long time had a problem with the temperature calculation code, which I had fixed by byte-swapping the values, and now it turns out that was the correct fix after all. Also, any use of iwl_eeprom_query_addr() that is for more than a u8 must be cast to little endian, and some structs as well. Fix all this. Again, no real impact on platforms that already are little endian. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Cc: stable@kernel.org Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
The construct "le16_to_cpu((__force __le16)(r >> 16))" has always bothered me when looking through the iwlwifi code, it shouldn't be necessary to __force anything, and before this code, "r" was obtained with an ioread32, which swaps each of the two u16 values in it properly when swapping the entire u32 value. I've had arguments about this code with people before, but always conceded they were right because removing it only made things not work at all on big endian platforms. However, analysing a failure of the OTP reading code, I now finally figured out what is going on, and why my intuition about that code being wrong was right all along. It turns out that the 'priv->eeprom' u8 array really wants to have the data in it in little endian. So the force code above and all really converts *to* little endian, not from it. Cf., for instance, the function iwl_eeprom_query16() -- it reads two u8 values and combines them into a u16, in a little-endian way. And considering it more, it makes sense to have the eeprom array as on the device, after all not all values really are 16-bit values, the MAC address for instance is not. Now, what this really means is that all the annotations are completely wrong. The eeprom reading code should fill the priv->eeprom array as a __le16 array, with __le16 values. This also means that iwl_read_otp_word() should really have a __le16 pointer as the data argument, since it should be filling that in a format suitable for priv->eeprom. Propagating these changes throughout, iwl_find_otp_image() is found to be, now obviously visible, defective -- it uses the data returned by iwl_read_otp_word() directly as if it was CPU endianness. Fixing that, which is this hunk of the patch: - next_link_addr = link_value * sizeof(u16); + next_link_addr = le16_to_cpu(link_value) * sizeof(u16); is the only real change of this patch. Everything else is just fixing the sparse annotations. Also, the bug only shows up on big endian platforms with a 1000 series card. 5000 and previous series do not use OTP, and 6000 series has shadow RAM support which means we don't ever use the defective code on any cards but 1000. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Cc: stable@kernel.org Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gertjan van Wingerde 提交于
We've had many reports of rt61pci failures with powersaving enabled. Therefore, as a stop-gap measure, disable powersaving of the rt61pci until we have found a proper solution. Also disable powersaving on rt2800pci as it most probably will show the same problem. Cc: stable@kernel.org Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Julia Lawall 提交于
sizeof(iv16) and sizeof(iv32) are the sizes of pointers. Change them to the size of the copied data. Furthermore, iveiv_entry is a local structure that has just been initialized and is not visible outside this function. Thus, there would seem to be no point to copy data into it. The order of the arguments is thus changed to copy the data into the parameters, which are provided as pointers, suggesting in this case that they should be used to return values. A simplified version of the semantic patch that finds the first problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression *x; expression f; type T; @@ *f(...,(T)x,...) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Benoit Papillault 提交于
First, we copy/paste the padding stuff from ath9k_tx to ath_tx_cabq since it needs to same kind of padding, but for internally generated beacons. Next, software padding done on TX needs to be removed before calling ieee80211_tx_status. The code was already there in ath_tx_complete but it was wrong. Fix it by using ath9k_cmn_padpos. This later code has been tested by sending packets to a monitor interface and reading packets from the same interface. Signed-off-by: NBenoit PAPILLAULT <benoit.papillault@free.fr> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
When trigger event log dumping from debugfs, the entire event log should be dumped and the size should match the number of events being dump. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
Recent commits "iwlwifi: remove power-wasting calls to apm_ops.init()" and "iwlagn: power up device before initializing EEPROM" had the goal of reducing device power consumption from the time the module is loaded until the interface is brought up and the device's power saving mechanisms kick in. The idea is that once the module is loaded there is no need for the device to consume power until the interface is brought up. With the current solution the device is only powered up during EEPROM read, and then so also only if the EEPROM type is OTP. We have found that on certain platforms even non-OTP devices require power to be up during EEPROM read. On these platforms the driver never loads and the system log contains the following: iwlagn 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x080403D8 We thus now power up all devices during EEPROM read. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Zhu Yi 提交于
In iwlwifi, priv->alloc_rxb_page is used to keep track of the Rx pages allocated by the driver. This cleans up the page free routines by introducing __iwl_free_pages/iwl_free_pages so that the accounting is more accurate and less error prone. This also fixes two instances where the counter was not updated. Signed-off-by: NZhu Yi <yi.zhu@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
- 21 12月, 2009 1 次提交
-
-
由 Michael Chan 提交于
The error was introduced while merging: commit 4529819c bnx2: reset_task is crashing the kernel. Fixing it. Signed-off-by: Michael Chan <mchan@broadcom.com>k Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 19 12月, 2009 8 次提交
-
-
由 Sandeep Gopalpet 提交于
Signed-off-by: NSandeep Gopalpet <Sandeep.Kumar@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sandeep Gopalpet 提交于
This patch updates the per rx/tx queue stats. To update the per rx queue stats a new structure has been introduced rx_q_stats. The per tx queue stats are updated via the netdev_queue structure itself. Note that we update only the tx_packtes, tx_bytes, rx_packets, rx_bytes and rx_dropped stats on a per queue basis. Signed-off-by: NSandeep Gopalpet <Sandeep.Kumar@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sandeep Gopalpet 提交于
We need to enable filer whenever we need to use multiple RX queues. Also, need to program RIR0 register with the required distribution we require, if using RX filer hashing support for packet distribution to multiple queues. Signed-off-by: NSandeep Gopalpet <Sandeep.Kumar@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Breno Leitao 提交于
When running the following script on an active bnx2 interface: while(true); do ifconfig ethX mtu 9000; ifconfig ethX mtu 1500; done A timeout error appears and dumps the following stack: NETDEV WATCHDOG: eth4 (bnx2): transmit queue 0 timed out ------------[ cut here ]------------ Badness at net/sched/sch_generic.c:261 <snip> This patch just fixes the way that ->trans_start is refreshed. Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com> Acked-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Uwe Kleine-König 提交于
platform_get_irq returns -ENXIO on failure, so !irq was probably always true. Better use (int)irq <= 0. Note that a return value of zero is still handled as error even though this could mean irq0. This is a followup to 305b3228 that changed the return value of platform_get_irq from 0 to -ENXIO on error. Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NWolfgang Grandegger <wg@grandegger.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yong Zhang 提交于
The _ONSTACK variant should be used for on-stack completion, otherwise it will break lockdep. Signed-off-by: NYong Zhang <yong.zhang0@gmail.com> Acked-by: NKarsten Keil <keil@b1-systems.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Breno Leitao 提交于
If bnx2 schedules a reset via the reset_task, e.g., due to a TX timeout, it's possible for the NIC to be disabled with packets pending for transmit. In this case, napi_disable will loop forever, eventually crashing the kernel. This patch moves the disable of the device to after the napi_disable call. Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com> Acked-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yang Hongyang 提交于
When I do an ipv6 module force unload,I got the following oops: #rmmod -f ipv6 ------------[ cut here ]------------ kernel BUG at mm/slub.c:2969! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:11.0/0000:02:03.0/net/eth2/ifindex Modules linked in: ipv6(-) dm_multipath uinput ppdev tpm_tis tpm tpm_bios pcspkr pcnet32 mii parport_pc i2c_piix4 parport i2c_core floppy mptspi mptscsih mptbase scsi_transport_spi Pid: 2530, comm: rmmod Tainted: G R 2.6.32 #2 440BX Desktop Reference Platform/VMware Virtual Platform EIP: 0060:[<c04b73f2>] EFLAGS: 00010246 CPU: 0 EIP is at kfree+0x6a/0xdd EAX: 00000000 EBX: c09e86bc ECX: c043e4dd EDX: c14293e0 ESI: e141f1d8 EDI: e140fc31 EBP: dec58ef0 ESP: dec58ed0 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process rmmod (pid: 2530, ti=dec58000 task=decb1940 task.ti=dec58000) Stack: c14293e0 00000282 df624240 c0897d08 c09e86bc c09e86bc e141f1d8 dec58f1c <0> dec58f00 e140fc31 c09e84c4 e141f1bc dec58f14 c0689d21 dec58f1c e141f1bc <0> 00000000 dec58f2c c0689eff c09e84d8 c09e84d8 e141f1bc bff33a90 dec58f38 Call Trace: [<e140fc31>] ? ipv6_frags_exit_net+0x22/0x32 [ipv6] [<c0689d21>] ? ops_exit_list+0x19/0x3d [<c0689eff>] ? unregister_pernet_operations+0x2a/0x51 [<c0689f70>] ? unregister_pernet_subsys+0x17/0x24 [<e140fbfe>] ? ipv6_frag_exit+0x21/0x32 [ipv6] [<e141a361>] ? inet6_exit+0x47/0x122 [ipv6] [<c045f5de>] ? sys_delete_module+0x198/0x1f6 [<c04a8acf>] ? remove_vma+0x57/0x5d [<c070f63f>] ? do_page_fault+0x2e7/0x315 [<c0403218>] ? sysenter_do_call+0x12/0x28 Code: 86 00 00 00 40 c1 e8 0c c1 e0 05 01 d0 89 45 e0 66 83 38 00 79 06 8b 40 0c 89 45 e0 8b 55 e0 8b 02 84 c0 78 14 66 a9 00 c0 75 04 <0f> 0b eb fe 8b 45 e0 e8 35 15 fe ff eb 5d 8b 45 04 8b 55 e0 89 EIP: [<c04b73f2>] kfree+0x6a/0xdd SS:ESP 0068:dec58ed0 ---[ end trace 4475d1a5b0afa7e5 ]--- It's because in ip6_frags_ns_sysctl_register, "table" only alloced when "net" is not equals to "init_net".So when we free "table" in ip6_frags_ns_sysctl_unregister,we should check this first. This patch fix the problem. Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-