The debugfs code can be made a whole lot more
efficient by using debugfs_remove_recursive(),
the large chunk of variables can completely go
away and by moving two variables we no longer
need to allocate an extra chunk of memory.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is better to first notify cfg80211 about the hw
rfkill state (so the rfkill device that will be
registered won't have the wrong state while being
registered), and the power/tt variable init can
(and probably should) also be done first.
Also rename iwl_setup_mac to
iwl_mac_setup_register to better describe what it
really does.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It really hasn't been for a long time, not sure
why this stuck around.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adding "bt_coex_active" module parameter for iwlcore to enable/disable
BT coexist; if bt_coex_active is true (default), uCode will do kill/defer
every time the priority line is asserted (BT is sending signals on the
priority line in the PCIx). By disable the bt_coex_active, uCode will
ignore the BT activity and perform the normal operation.
Users might experience transmit issue on some platform due to this
WiFi/BT co-exist problem. The possible symptoms are: NetworkManager and
other similar programs can scan and find all the available APs, but will
timeout and unable to associate with any of the APs; no out-going frames
can be found with wireless sniffer tools.
On those platforms, WiFi communication can be restored by set "bt_coex_active"
module parameter to "false"
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Give better bit filed define and description for flag parameter
in REPLY_BT_CONFIG command:
flags:
bit 0 - 1: BT channel announcement enabled
0: disable
bit 1 - 1: priority of BT device enabled
0: disable
bit 2 - 1: BT 2 wire support enabled
0: disable
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add function pointer for broadcast station addition so that we can call it
in from iwlcore at a later time. We only distinguish between iwlagn and
iwl3945 broadcast station addition. For the iwl3945 station addition we add
that function to iwlcore since that is where most station functionality
resides, making it part of iwl3945 will require significant code
reorganization that will dilute station management functionality. This
seems to be an efficient solution.
It may seem as though we are removing error checking when adding the 3945
broadcast station but this error checking was never really necessary since
the function returns the station id and the broadcast station id is always
set.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The work done when a station is added is very similar whether the station
is added synchronously or asynchronously. Centralize this work. At the same
time increase the status flags being checked for when the command returns
with accompanying debug messages. Also increase checking when setting the
"ucode active" state with accompanying debugging.
This work is done in preparation for station notification support.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
From: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
For 6X50 DC calibration needs to be initialized
else uCode will run an endless loop.
Enbale DC calibration in hw config.
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We have seen the throughput dropped due to external noisy environment
and the radio is out of tune. There are lot of plcp errors indicating
this condition. Eventually the station can get de-authenticated by the
Access Point. By resetting and tuning the radio, the plcp errors are
reduced or eliminated and the throughput starts to rise.
To prevent unexpected behavior such as drop in throughput or deauthentication,
- The change provides the driver feature to monitor and tune the radio base on
the statistics notification from the uCode.
- It also allows the setting of the plcp error rate threshold via
the plcp_delta under debugfs interface.
Signed-off-by: Trieu 'Andrew' Nguyen <trieux.t.nguyen@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add additional logic for internal scan routine to control how
frequent this function should be performed.
The intent of this function is to reset/re-tune the radio and bring the
RF/PHY back to normal state, it does not make sense calling it too
frequent,
if reset the radio can not bring it back to normal state, it indicate
there are other reason to cause the radio not operate correctly.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch allows A band to be scanned when driver is associated to AP.
Scan mechanism is that mac80211/cfg80211 requests driver to scan G band
first and then immediately to scan A band. Original code require
driver to wait for 2 seconds after any scan before another scan will be
performed. This caused driver to service G band scan request from
mac80211/cfg80211 but deny the A band scan request.
Signed-off-by: Henry Zhangh <hongx.c.zhang@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adding "radio reset" function to help reset and stabilize the radio.
During normal operation, sometime for unknown reason, radio encounter
problem and can not recover by itself; the best way to
recover from it is to reset and re-tune the radio. Currently, there is
no RF reset command available, but since radio will get reset when
switching channel, use internal hw scan request to force radio
reset and get back to normal operation state.
The internal hw scan will only perform passive scan on the first
available channel (not the channel being used) in associated state. The
request should be ignored if already performing scan operation or STA is
not in associated state.
Also include an "internal_scan" debugfs file to help trigger the
internal scan from user mode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add support to configure missed beacon threshold, by default, if receive
"missed beacon" notification from uCode and has more than 5 consecutive
beacon missed, then perform sensitivity calibration; with this change,
allow user to adjust the missed beacon threshold from debugfs in case
more sensitivity calibration required for better performance in noisy
environment
The default value (=5) should be good enough for the normal condition,
but for very noisy environment, more sensitivity calibration could help
improve the throughput, so by setting the missed beacon threshold to
lower number, user might experience better performance result.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch introduces three macros to work with uc list from net drivers.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Among other changes, this commit:
commit 06d0f0663e
Author: Sujith <Sujith.Manoharan@atheros.com>
Date: Thu Feb 12 10:06:45 2009 +0530
ath9k: Enable Fractional N mode
changed the hw attach code to fix up initialization values only for
dual band devices, however the commit message did not give a reason as
to why this would be useful or necessary.
According to tests by Jorge Boncompte, this breaks at least some
2GHz-only cards, so the code should be changed back to the
unconditional INI fixup.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Jorge Boncompte <jorge@dti2.net>
Cc: stable@kernel.org
Tested-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are a few station addresses that are
char *, instead of the normal u8 *; gcc
gives pointer signedness warnings for some
of those, so use u8 * consistently.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
GC is non-existent in netns, so after you hit GC threshold, no new
dst entries will be created until someone triggers cleanup in init_net.
Make xfrm4_dst_ops and xfrm6_dst_ops per-netns.
This is not done in a generic way, because it woule waste
(AF_MAX - 2) * sizeof(struct dst_ops) bytes per-netns.
Reorder GC threshold initialization so it'd be done before registering
XFRM policies.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Obviously, this register had some other impact that is causing
the regression. Either it is masking some other access or needs
to be reset in some path.
Either, way it is best to just revert the change for 2.6.33
This reverts commit 166a0fd4c7.
Signed-off-by: David S. Miller <davem@davemloft.net>
Bruno Prémont found commit 9793241fe9
(vlan: Precise RX stats accounting) added a regression for non
hw accelerated vlans.
[ 26.390576] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 26.396369] IP: [<df856b89>] vlan_skb_recv+0x89/0x280 [8021q]
vlan_dev_info() was used with original device, instead of
skb->dev. Also spotted by Américo Wang.
Reported-By: Bruno Prémont <bonbons@linux-vserver.org>
Tested-By: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
"ip xfrm state|policy count" report SA/SP count from init_net,
not from netns of caller process.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pavel Roskin reported a crash in ieee80211_tx_h_select_key():
http://marc.info/?l=linux-wireless&m=126419655108528&w=2
This is a regression from patch "mac80211: move control.hw_key assignment".
Fix it as suggested by Johannes, adding an else statement to make sure
that tx->key is not accessed when it's null.
Compile-tested only.
Reported-by: Pavel Roskin <proski@gnu.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
Tested-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Y2_HW_WOL_ON/Y2_HW_WOL_OFF should be set and cleared per chip,
not per port. On dual port cards, Y2_HW_WOL_ON should be
enabled if either sky2 port has WOL enabled.
Found while reviewing code for a WOL regression, though this is
probably not the cause of the regression.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Based on patch from Sridhar Samudrala
The following patch fixes the check for IPv6 GSO packet in ixgbevf
driver to use skb_is_gso_v6(). SKB_GSO_DODGY is also set
when packets are forwarded from a guest.
CC: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Found this problem when testing IPv6 from a KVM guest to a remote
host via e1000e device on the host.
The following patch fixes the check for IPv6 GSO packet in Intel
ethernet drivers to use skb_is_gso_v6(). SKB_GSO_DODGY is also set
when packets are forwarded from a guest.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
No matter whether connection track is enabled, an end host should send
an ICMPv4 "Fragment Reassembly Timeout" message when defrag timeout.
The reasons are following two points:
1. RFC 792 says:
>>>> >> > > If a host reassembling a fragmented datagram cannot complete the
>>>> >> > > reassembly due to missing fragments within its time limit it
>>>> >> > > discards the datagram, and it may send a time exceeded message.
>>>> >> > >
>>>> >> > > If fragment zero is not available then no time exceeded need be
>>>> >> > > sent at all.
>>>> >> > >
>>>> >> > > Read more: http://www.faqs.org/rfcs/rfc792.html#ixzz0aOXRD7Wp
2. Patrick McHardy also agrees with this opinion. :-)
About the discussion of this opinion, refer to http://patchwork.ozlabs.org/patch/41649
The patch fixed the problem like this:
When enabling connection track, fragments are received at PRE_ROUTING HOOK.
If they are failed to reassemble, ip_expire() will be called.
Before sending an ICMP "Fragment Reassembly Timeout" message,
the patch searches router table to get the destination entry only for host type.
The patch has been tested on both host type and route type.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After removing the skb_dma_map/unmap calls the exception handling in
igb_tx_map_adv is not correct. The issue is that the count value was not
being correctly handled so as a result we were not rewinding the ring as
back as we should have been.
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>
Simpily pass 'struct neigh_table' with seq_file private pointer,
and save one dereference. Proc entry itself isn't interesting.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After netdev_ops compat code HAVE_* macros aren't needed, in fact
they _will_ result in compile breakage for out of tree drivers.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add igbvf to the list of supported Intel drivers and Alex to the list of
maintainers.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the VF detects that the PF has reset turn off carrier and stop all
tx queues.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix panics in the VF driver that occur when you bring it down after
having already brought the PF down.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the VF driver gets a control message from the PF that indicates the
PF is about to reset or go down we schedule the watchdog timer so that
it will detect the PF has gone offline and take appropriate action.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Inadequate coordination between the PF driver and the VF driver results
in tx hangs in the VF driver when you perform certain actions that will
lead to a re-init of the PF. Add feature to notify active VFs when the PF
is about to re-initialize so that the VFs can take appropriate action.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The PF Reset Done bit should not be set in the extended control register
until the PF has actually completed the bring up process. It is a mis-
interpretation of the purpose of this bit to assume it should be set
when the physical reset of the device is done. Instead it should be used
to indicate to the VFs when the PF is ready to provide them with required
services. This is not until after the PF is finished coming up and ready
to process mailbox events.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This data storage for SW emulated MAC addresses is unlikely to ever be used
so pull it.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When VFs are allocated (as indicated by adapter->num_vfs is non-zero) then
the PF pool is no longer zero. Instead it will be the same as the number
of VFs allocated. When setting the VLVF entry for the PF we need to use
the correct pool otherwise the PF will get VLAN packets from the wire
because the packet will pass VFTA filtering and the PF has the default
pool, but it will not get VLAN packets from the VFs because it has
not set the correct pool bit in the VLVF entry.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When testing the "e1000: enhance frame fragment detection" (and e1000e)
patches we found some bugs with reducing the MTU size. The 1024 byte
descriptor used with the 1000 mtu test also (re) introduced the
(originally) reported bug, and causes us to need the e1000_clean_tx_irq
"enhance frame fragment detection" fix.
So what has occured here is that 2.6.32 is only vulnerable for mtu <
1500 due to the jumbo specific routines in both e1000 and e1000e.
So, 2.6.32 needs the 2kB buffer len fix for those smaller MTUs, but
is not vulnerable to the original issue reported. It has been pointed
out that this vulnerability needs to be patched in older kernels that
don't have the e1000 jumbo routine. Without the jumbo routines, we
need the "enhance frame fragment detection" fix the e1000, old
e1000e is only vulnerable for < 1500 mtu, and needs a similar
fix. We split the patches up to provide easy backport paths.
There is only a slight bit of extra code when this fix and the
original "enhance frame fragment detection" fixes are applied, so
please apply both, even though it is a bit of overkill.
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>
fmvj18x_cs, serial_cs:
add new id
Panasonic lan & modem card (model name:AL-VML101)
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
Only the first two fields of mcc wrb - embedded, payload_len
need to be cpu_to_le32() swapped while issuing a cmd to the hw.
The fields tag0, tag1 are opaque and returned back to cpu as is...
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Please add support for Microsoft MN-120 PCMCIA network card. It's an
old card, I know, but adding support is very easy. You just need to
get tulip_core.c to recognise its vendor/device ID.
Patch for kernel 2.6.32.4 (and many previous) attached.
.....Ron Murray
Signed-off-by: Ron Murray <rjmx@rjmx.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
ieee80211_tx_h_select_key might decide that a frame
need not be encrypted at all, in which case it will
clear tx->key. In that case it may crash if a key
was previously selected, e.g. as the default key.
This is also due to my patch
"mac80211: move control.hw_key assignment".
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch continues the effort which began with:
"[PATCH] p54pci: move tx cleanup into tasklet".
Thanks to these changes, p54pci's interrupt & tx
cleanup routines can be made lock-less.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
