- 08 10月, 2009 31 次提交
-
-
由 Johannes Berg 提交于
In order to have an easier way to debug issues, create trace events (using the ftrace framework) that will allow us to follow exactly what the driver is doing with the device. The text format isn't all that useful, but the binary format can also be obtained easily via debugfs and then analysed on the fly or offline with debugging tools. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Multiple MPDUs can be aggregated, transmitted, and finally acknowledged together using a single BA frame. Block ACK (BA) contains bitmap size of 64*16 bits so the maximum frame count is 64. The default value of aggregation frame count suggested by uCode is 31 to achieve best performance. 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>
-
由 Huaxu Wan 提交于
Driver should clear the translate table area after receiving "Alive" response from uCode. This patch corrects a mistake when doing this. Signed-off-by: NHuaxu Wan <huaxu.wan@linux.intel.com> Signed-off-by: NGuo Chaohong <chaohong.guo@linux.intel.com> Acked-by: NBen M Cahill <ben.m.cahill@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
In order to support different type of 1000 series NICs we release to customers before the production release, iwlwifi driver need to support all the NICs has EEPROM version greater than 0x15c. 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>
-
由 Wey-Yi Guy 提交于
When uCode detects critical temperature it should send "card state notification" interrupt to driver and then shut itself down to prevent overheating. There is a race condition where uCode shuts down before it can deliver the interrupt to driver. Additional method provided here for driver to enter CT_KILL state based on temperature reading. How it works: Method 1: If driver receive "card state notification" interrupt from uCode; it enters "CT_KILL" state immediately Method 2: If the last temperature report by Card reach Critical temperature, driver will send "statistic notification" request to uCode to verify the temperature reading, if driver can not get reply from uCode within 300ms, driver will enter CT_KILL state automatically. Method 3: If the last temperature report by Card did not reach Critical temperature, but uCode already shut down due to critical temperature. All the host commands send to uCode will not get process by uCode; when command queue reach the limit, driver will check the last reported temperature reading, if it is within pre-defined margin, enter "CT_KILL" state immediately. In this case, when uCode ready to exit from "CT_KILL" state, driver need to restart the adapter in order to reset all the queues and resume normal operation. One additional issue being address here, when system is in CT_KILL state, both tx and rx already stopped, but driver still can send host command to uCode, it will flood the command queue since card was not responding; adding STATUS_CT_KILL flag to reject enqueue host commands to uCode if it is in CT_KILL state, when uCode is ready to come out of CT_KILL, driver will clear the STATUS_CT_KILL bit and allow enqueue the host commands to uCode to recover from CT_KILL state. 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>
-
由 Christian Lamparter 提交于
Ever since Johannes' "iwlwifi: improve scan support" iwlwifi no longer needs any of lib80211's functions or definitions. This patch updates iwlwifi's Kconfig _selections_ and removes all left lib80211.h inclusions from the source files. Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Acked-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Huaxu Wan 提交于
The module firmware information of 1000 series is missing from iwlagn. Signed-off-by: NHuaxu Wan <huaxu.wan@linux.intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Using powersave while idle saves a lot of power, but we've had problems with this on some cards (5150 has been reported to be problematic). However, on the new 6000 series we're seeing no problems, so for now let that hardware benefit from idle mode, we can look at the problems with other hardware one by one and then enable those once we figure out the problems. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Adding support of Chain Noise Calibration for 6000 series NICs. 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>
-
由 Johannes Berg 提交于
When instructing the microcode to use just a single chain when we have power saving enabled, we should also tell the AP that we are doing SM powersave. However, using a single chain doesn't actually have any power saving advantage while idle -- measurements show that the power consumption is no different when using one vs. two or three chains. Therefore, always instruct the microcode to use all chains. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
We never have four chains, but let's fix the typo while we noticed it. You count 0, 1, 2, 3, not 0, 1, 2, 4 :) Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Today's implementation allow LED to blink based on the traffic condition. We introduce an additional LED mode that reflects the RF state. The supported LED modes after this are: IWL_LED_BLINK (current/default) - blink rate based on current Tx/Rx traffic IWL_LED_RF_STATE (new) - LED OFF: No power/RF disabled, the LED is emitting no light LED ON: Powered/RF enabled, the LED is emitting light in a stable non-flashing state. In order to provide the flexibility to support different LED behavior per user/system preference we add "led_mode" iwlcore module parameter. 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>
-
由 Wey-Yi Guy 提交于
Update PCI Subsystem ID for 60x0 series based on HW SKU. Adding new SKU for "ABG" and "BG" only devices. 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>
-
由 Wey-Yi Guy 提交于
Update PCI Subsystem ID for 1000 series based on HW SKU. Adding new SKU for "BG" only devices. 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>
-
由 Wey-Yi Guy 提交于
In order for uCode to select the valid antennas for transmit, driver need to configure the allowed tx antennas through host command. The TX_ANT_CONFIGURATION_CMD should be used for 5000 series and up 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>
-
由 Daniel C Halperin 提交于
Current rate scale algorithm fluctuates between different MIMO modes fairly rapidly, causing widely varying performance. These fluctuations occur because in the rate_scale tables for expected throughput the values are not very different for different modes. However, when aggregation is turned on and MAC overhead is reduced, the expected throughput for different MIMO modes grows and different modes have vastly different performance. Add expected throughput tables for this case. We also need to keep track of aggregation status per-station, so we add the "is_agg" field to struct lq_sta. Also includes cleanup of comments and variable names in/around the affected code. Signed-off-by: NDaniel C Halperin <daniel.c.halperin@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel C Halperin 提交于
OR-in AMPDU flags rather than assigning them. This lets the TX status for aggregated packets be processed by rs_tx_status. Signed-off-by: NDaniel C Halperin <daniel.c.halperin@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel C Halperin 提交于
Cut down on redundant code, reorganize structure, and add/improve comments. Should contain no functional changes. Signed-off-by: NDaniel C Halperin <daniel.c.halperin@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Instead of hardcode module parameter's permissions, use pre-defined. 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>
-
由 Wey-Yi Guy 提交于
Update EEPROM version requirement for 1000 and 6000 series of NIC for EEPROM version verification. 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>
-
由 Wey-Yi Guy 提交于
Allow user to change protection mechanism for HT between RTS/CTS and CTS-to-self through sysfs: Show current protection mechanism for HT cat /sys/class/net/wlan0/device/rts_ht_protection Change protection mechanism for HT (only allowed while not-associated) CTS-to-self: echo 0 > /sys/class/net/wlan0/device/rts_ht_protection RTS/CTS: echo 1 > /sys/class/net/wlan0/device/rts_ht_protection 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>
-
由 Wey-Yi Guy 提交于
When 802.11g was introduced, we had RTS/CTS and CTS-to-Self protection mechanisms. In an HT Beacon, HT stations use the "Operating Mode" field in the HT Information Element to determine whether or not to use protection. The Operating Mode field has 4 possible settings: 0-3: Mode 0: If all stations in the BSS are 20/40 MHz HT capable, or if the BSS is 20/40 MHz capable, or if all stations in the BSS are 20 MHz HT stations in a 20 MHz BSS Mode 1: used if there are non-HT stations or APs using the primary or secondary channels Mode 2: if only HT stations are associated in the BSS and at least one 20 MHz HT station is associated. Mode 3: used if one or more non-HT stations are associated in the BSS. When in operating modes 1 or 3, and the Use_Protection field is 1 in the Beacon's ERP IE, all HT transmissions must be protected using RTS/CTS or CTS-to-Self. By default, CTS-to-self is the preferred protection mechanism for less overhead and higher throughput; but using the full RTS/CTS will better protect the inner exchange from interference, especially in highly-congested environment. For 6000 series WIFI NIC, RTS/CTS protection mechanism is the recommended choice for HT traffic based on the HW design. 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>
-
由 Johannes Berg 提交于
The chain settings we currently use in iwlwifi are rather confusing -- and we also go by the wrong settings entirely under certain circumstances. To clean it up, create a new variable in the current HT config -- single_chain_sufficient -- that tells us whether we need more than one chain. Calculate that based on the AP and operating mode (no IBSS HT implemented -- so no need for multiple chains, for station mode we use the AP's capabilities). Additionally, since APs always send disabled SM PS mode, keeping track of their sm_ps mode isn't very useful -- doubly not so for our _own_ RX config since that should depend on our, not the AP's, SM PS mode. Finally, document that our configuration of the number of RX chains used is currently wrong when in powersave (by adding a comment). All together this removes the two remaining items in struct iwl_ht_config that were done wrong there. For the future, the number of RX chains and some SM PS handshaking needs to be added to mac80211, which then needs to tell us, and the new variable current_ht_config.single_chain_sufficient should also be calculated by mac80211. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NDaniel C Halperin <daniel.c.halperin@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Show version number along with dumping NVM data, the version information being removed from sysfs, add it back to debugfs to help debugging. 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>
-
由 Johannes Berg 提交于
Daniel Halperin pointed out that the naming here is rather inconsistent with at least 3 different names being used for one thing in different contexts. Rename the struct to iwl_ht_config (rather than iwl_ht_info) and use ht_conf as a variable for it. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NDaniel C Halperin <daniel.c.halperin@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Adjust led blink rate to compensate on a MAC Clock difference on every HW. Led blink rate analysis showed an average deviation of 0% on 3945, 5% on 4965 HW and 20% on 5000 series and up. Need to compensate on the led on/off time per HW according to the deviation to achieve the desired led frequency The calculation is: (100-averageDeviation)/100 * blinkTime For code efficiency the calculation will be: compensation = (100 - averageDeviation) * 64 / 100 NewBlinkTime = (compensation * BlinkTime) / 64 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>
-
由 Johannes Berg 提交于
is_ht can be bool instead of u8, and there's no need to use IWL_CHANNEL_WIDTH_* constants in supported_chan_width when that could just be named is_40mhz instead. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Separate set_hw_params() function for 6000 series from 5000/1000 series because: 1) 6000 series use different set of sensitivity range table 2) 6000 series has different uCode image size Also include the new sensitivity parameters needed by sensitivity algorithm. 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>
-
由 Wey-Yi Guy 提交于
Different NIC has different requirements for configuration. Currently all 5000 series hardware and later share the same configuration function even though they do not need the same configurations. Fix this by separating the needed configuration actions for each hardware model. .5000 series: L1-ASPM H/W bug work-around configure radio write CSR_HW_IF_CONFIG_REG for uCode use work-around for NIC get stuck after early PCIe power off .1000 series: write CSR_HW_IF_CONFIG_REG for uCode use setting digital SVR for 1000 card to 1.32V .6000 series: configure radio write CSR_HW_IF_CONFIG_REG for uCode use write CSR_GP_DRIVER_REG to indicate radio sku 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>
-
由 Wey-Yi Guy 提交于
Remove few of the parameters not used and no longer valid in EEPROM. 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>
-
由 Wey-Yi Guy 提交于
Modify LED blink index table to include 1Mbps. 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>
-
- 29 9月, 2009 3 次提交
-
-
由 Reinette Chatre 提交于
When hardware or uCode problem occurs driver captures significant information from device to enable debugging. The format of this information is different between 3945 and 4965 and later devices, yet currently the 3945 uses the 4965 and later format. Fix this by adding a new library call that is initialized to the correct formatting routine based on device. This moves the iwlagn event and error log handling back to iwl-agn.c to make it part of iwlagn module. Also remove the 3945 sysfs file that triggers dump of event log - there is already a debugfs file that can do it for all drivers. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
Also free the array of command pointers and meta data of each command buffer when command queue is freed. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
We keep track of where to write into a buffer by keeping a count of how much has been written so far. When writing to the buffer we thus take the buffer pointer and adding the count of what has been written so far. Keeping track of what has been written so far is done by incrementing this number every time something is written to the buffer with how much has been written at that time. Currently this number is incremented incorrectly when using the "hex_dump_to_buffer" call to add data to the buffer. Fix this by only adding what has been added to the buffer in that call instead of what has been added since beginning of buffer. Issue was discovered and discussed during testing of https://bugzilla.redhat.com/show_bug.cgi?id=464598 . When a user views any of these files they will see something like: [ 179.355202] ------------[ cut here ]------------ [ 179.355209] WARNING: at ../lib/vsprintf.c:989 vsnprintf+0x5ec/0x5f0() [ 179.355212] Hardware name: VGN-Z540N [ 179.355213] Modules linked in: i915 drm i2c_algo_bit i2c_core ipv6 acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative cpufreq_stats freq_table container sbs sbshc arc4 ecb iwlagn iwlcore joydev led_class mac80211 af_packet pcmcia psmouse sony_laptop cfg80211 iTCO_wdt iTCO_vendor_support pcspkr serio_raw rfkill intel_agp video output tpm_infineon tpm tpm_bios button battery yenta_socket rsrc_nonstatic pcmcia_core processor ac evdev ext3 jbd mbcache sr_mod sg cdrom sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore thermal fan thermal_sys [ 179.355262] Pid: 5449, comm: cat Not tainted 2.6.31-wl-54419-ge881071 #62 [ 179.355264] Call Trace: [ 179.355267] [<ffffffff811ad14c>] ? vsnprintf+0x5ec/0x5f0 [ 179.355271] [<ffffffff81041348>] warn_slowpath_common+0x78/0xd0 [ 179.355275] [<ffffffff810413af>] warn_slowpath_null+0xf/0x20 [ 179.355277] [<ffffffff811ad14c>] vsnprintf+0x5ec/0x5f0 [ 179.355280] [<ffffffff811ad23d>] ? scnprintf+0x5d/0x80 [ 179.355283] [<ffffffff811ad23d>] scnprintf+0x5d/0x80 [ 179.355286] [<ffffffff811aed29>] ? hex_dump_to_buffer+0x189/0x340 [ 179.355290] [<ffffffff810e91d7>] ? __kmalloc+0x207/0x260 [ 179.355303] [<ffffffffa02a02f8>] iwl_dbgfs_nvm_read+0xe8/0x220 [iwlcore] [ 179.355306] [<ffffffff811a9b62>] ? __up_read+0x92/0xb0 [ 179.355310] [<ffffffff810f0988>] vfs_read+0xc8/0x1a0 [ 179.355313] [<ffffffff810f0b50>] sys_read+0x50/0x90 [ 179.355316] [<ffffffff8100bd6b>] system_call_fastpath+0x16/0x1b [ 179.355319] ---[ end trace 2383d0d5e0752ca0 ]--- Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 9月, 2009 6 次提交
-
-
由 Stanislaw Gruszka 提交于
In some cases firmware can give us bad value of index in transmit buffers array. This patch add sanity check for such values and return from processing function instantly when it happens. https://bugzilla.redhat.com/show_bug.cgi?id=521931 Patch was tested by reporter on iwl5000. I think check can be also helpful for 4965. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
Replenishment of receive buffers is done in the tasklet handling received frames as well as in a workqueue. When we are in the tasklet we cannot sleep and thus attempt atomic skb allocations. It is generally not a big problem if this fails since iwl_rx_allocate is always followed by a call to iwl_rx_queue_restock which will queue the work to replenish the buffers at a time when sleeping is allowed. We thus add the __GFP_NOWARN to the skb allocation in iwl_rx_allocate to reduce the noise if such an allocation fails while we still have enough buffers. We do maintain the warning and the error message when we are low on buffers to communicate to the user that there is a potential problem with memory availability on system This addresses issue reported upstream in thread "iwlagn: order 2 page allocation failures" in http://thread.gmane.org/gmane.linux.kernel.wireless.general/39187Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Acked-by: NMel Gorman <mel@csn.ul.ie> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Reinette Chatre 提交于
commit 10c994ca70e8e94bbc85a5bf13de5911ee8de4d2 "iwlwifi: fix remove key error" fixed an error reported by mac80211 during interface down. The fix involved changing an async command to synchronous. Unfortunately this was inside a spinlock section in which we cannot sleep. Modify the sending of the command back to async. This causes the mac80211 error "mac80211-phy0: failed to remove key (0, ff:ff:ff:ff:ff:ff) from hardware (-16)." to return. This error is not serious since this occurs during interface down and the keys will be cleared anyway when ucode is unloaded. Having this error message is thus less serious than a potential deadlock introduced when sleeping while holding a spinlock. We will have to find another fix for that error. This is a revert of the abovementioned commit. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
There's a bug in 4965 powersave that appears to be related to the way it keeps track of its data during sleep, but we haven't found it yet. Due to that, using powersave may spontaneously cause the device to SYSASSERT when transitioning from sleep to wake. Therefore, disable powersave for 4965, until (if ever, unfortunately) we can identify and fix the problem. Cf. http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1982 which was closed, but now has re-appeared with IDLE mode, which probably means we never really fixed it. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
We can not assume antenna "A" is the first valid anttena for all the NIC. Need to make sure choice the correct antenna based on h/w configuration for transmit to avoid sending frame on invalid antenna 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 提交于
RX handling maintains a few lists that keep track of the RX buffers. Buffers move from one list to the other as they are used, replenished, and again made available for usage. In one such instance, when a buffer is used it enters the "rx_used" list. When buffers are replenished an skb is attached to the buffer and it is moved to the "rx_free" list. The problem here is that the buffer is first removed from the "rx_used" list _before_ the skb is allocated. Thus, if the skb allocation fails this buffer remains removed from the "rx_used" list and is thus lost for future usage. Fix this by first allocating the skb before trying to attach it to a list. We add an additional check to not do this unnecessarily. Reported-by: NRick Farrington <rickdic@hotmail.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-