Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"iwlwifi: use correct released ucode version" change
the ucode api ok from 6000G2 to 6000G2B, but it shall belong
to 6030 device series, not the 6005 device series. Fix it

Cc: stable@vger.kernel.org #3.3+
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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>

Currently cfg80211 fails to create a "phy80211" symlink in sysfs from
the net device to the wiphy device.  The latter needs to be registered
first.

Compile-tested only.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently cfg80211 fails to create a "phy80211" symlink in sysfs from
the net device to the wiphy device.  The latter needs to be registered
first.

Compile-tested only.
Reported-by: NCesare Leonardi <celeonar@gmail.com>
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

RFCSR is only used in rt2800. For other chipsets, the debug struct
for rfcsr should be zeroed, which isn't be an issue, since the code
can now cope with that.
Signed-off-by: NAnisse Astier <anisse@astier.eu>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Allow a register to be unspecified, therefore not creating its debugfs
file entry.
Signed-off-by: NAnisse Astier <anisse@astier.eu>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The problem was found by Stefan Lippers-Hollmann
http://marc.info/?l=linux-wireless&m=132720334512946&w=2

WARNING: at /tmp/buildd/linux-aptosid-3.2/debian/build/source_i386_none/net/wireless/core.c:562 wiphy_register+0x45/0x38d [cfg80211]()
Hardware name: TravelMate 290 \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff
Modules linked in: ipw2200(+) iTCO_wdt libipw joydev drm snd_seq snd_timer snd_seq_device iTCO_vendor_support yenta_socket snd intel_agp i2c_i801 pcmcia_rsrc cfg80211 soundcore parport_pc psmouse parport rng_core snd_page_alloc serio_raw pcspkr i2c_algo_bit intel_gtt pcmcia_core evdev irda crc_ccitt rfkill lib80211 processor container ac battery shpchp pci_hotplug button ext4 mbcache jbd2 crc16 dm_mod sd_mod sr_mod crc_t10dif cdrom ata_generic pata_acpi ata_piix libata scsi_mod firewire_ohci firewire_core crc_itu_t 8139too 8139cp mii uhci_hcd ehci_hcd usbcore usb_common [last unloaded: scsi_wait_scan]
Pid: 328, comm: modprobe Not tainted 3.2-1.slh.4-aptosid-686 #1
Call Trace:
[<c012eaf4>] ? warn_slowpath_common+0x7c/0x8f
[<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211]
[<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211]
[<c012eb22>] ? warn_slowpath_null+0x1b/0x1f
[<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211]
[<c01f89d7>] ? internal_create_group+0xf5/0xff
[<e0a2de1c>] ? ipw_pci_probe+0xa9a/0xbd0 [ipw2200]
[<c01519f4>] ? arch_local_irq_save+0xf/0x14
[<c0252986>] ? pci_device_probe+0x53/0x9a
[<c02c2820>] ? driver_probe_device+0x94/0x124
[<c0252871>] ? pci_match_id+0x15/0x34
[<c02c28f0>] ? __driver_attach+0x40/0x5b
[<c02c1d81>] ? bus_for_each_dev+0x37/0x60
[<c02c25aa>] ? driver_attach+0x17/0x1a
[<c02c28b0>] ? driver_probe_device+0x124/0x124
[<c02c22c4>] ? bus_add_driver+0x92/0x1d1
[<e099d000>] ? 0xe099cfff
[<c02c2cb8>] ? driver_register+0x7d/0xd4
[<c017cd50>] ? jump_label_module_notify+0xec/0x167
[<e099d000>] ? 0xe099cfff
[<c0253017>] ? __pci_register_driver+0x32/0x87
[<e099d000>] ? 0xe099cfff
[<e099d02e>] ? ipw_init+0x2e/0x72 [ipw2200]
[<c0101173>] ? do_one_initcall+0x7d/0x132
[<c0145016>] ? __blocking_notifier_call_chain+0x47/0x4f
[<c0154a73>] ? sys_init_module+0x13a4/0x159c
[<c03a639f>] ? sysenter_do_call+0x12/0x28

This warning appears only if we apply Ben Hutchings' fix
http://marc.info/?l=linux-wireless&m=132720195012653&w=2
for the bug reported by Cesare Leonardi
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656813
with cfg80211 warning during device registration
("cfg80211: failed to add phy80211 symlink to netdev!").

We separate device bring up and registration with network stack
to avoid the problem.

After that Ben Hutchings' fix can be applied to fix the bug.

Cc: stable@kernel.org
Signed-off-by: NStanislav Yakovlev <stas.yakovlev@gmail.com>
Tested-by: NStefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Change-Id: I10e42e0cc7dd91047f093ea2c5a55d65c004ada6
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Reviewed-on: http://git-mwg.jer.intel.com/gerrit/1939
Tested-by: Jenkins
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

If a mesh peer indicates it is operating as 20MHz-only in its HT
operation IE, have the rate control algorithm respect this by disabling
the equivalent bit in the ieee80211_sta HT capabilities.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Drivers need the station rate info when inserting a new sta_info. The
patch "mac80211: refactor mesh peer initialization" wrongly assumed the
rate info could be applied after insertion. After further review, this
is clearly not the case.

This fixes a regression where HT parameters were not applied before
inserting the sta_info, causing performance degradation.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"oui_type" in structure "ieee_types_vendor_header" is not used separately,
so include it in "oui" array. Now complete oui will be compared fixing
following warnings.

drivers/net/wireless/mwifiex/sta_ioctl.c:1410 mwifiex_set_gen_ie_helper()
        error: memcmp() 'pvendor_ie->oui' too small (3 vs 4)
drivers/net/wireless/mwifiex/sta_ioctl.c:1435 mwifiex_set_gen_ie_helper()
        error: memcmp() 'pvendor_ie->oui' too small (3 vs 4)
drivers/net/wireless/mwifiex/scan.c:1177 mwifiex_update_bss_desc_with_ie()
        error: memcmp() 'vendor_ie->vend_hdr.oui' too small (3 vs 4)
drivers/net/wireless/mwifiex/scan.c:1185 mwifiex_update_bss_desc_with_ie()
        error: memcmp() 'vendor_ie->vend_hdr.oui' too small (3 vs 4)
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The rate control updation never be called on 2040 BSS change.
The station should update its rate control on receiving beacon
with different HT mode in the HT operation IE. Not doing so,
leads to sending frames with higher(ht40) rates whereas AP is
operating in lower mode (ht20).
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

	modified:   drivers/net/wireless/mwifiex/Kconfig
	- notate additional chipset
	modified:   drivers/net/wireless/mwifiex/sdio.c
	- add definition of id (0x9116)
	- add to switch for firmware load
	- add MODULE_FIRMWARE
	modified:   drivers/net/wireless/mwifiex/sdio.h
	- add definition of default firmware name
Signed-off-by: NJason Plum <max@warheads.net>
Acked-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is a cut and paste mistake, sizeof(struct mib_local) was intended
instead of sizeof(struct mib_phy).  The call to at76_get_mib() uses
sizeof(struct mib_local) correctly, although I changed that to
sizeof(*m) for style reasons after discussion with some of the wireless
maintainers.

The current code works fine because mib_phy structs are larger than
mib_local structs.  But we may as well clean it up.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This doesn't make any sense. Init it from the transport instead.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

There are various problems happened on 5GHz band not observed on
2.4 GHz (microcode errors, queue stuck, etc... ) . Also roaming
between 5GHz AP and 2GHz does not work very well. To workaround
the problems add option to disable 5GHz support. This will help
on environments where APs are dual-band, and devices will not try
to associate on band where issues happen.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Also remove a debug print when allocation error occurred.
The kernel will complain anyway.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Add the Loose coex LUT and will use later for better bt coex tpt
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

In bt coex, consider reduce tx power as part of ack/cts kill mask
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Add the reduce tx power information in bt coex host command
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When bluetooth coex is active and certain condition matched,
driver need to decide should the tx power been reduce or not.
Adding the logic to manage it.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Do not assume we have our subsystem including this for us,
at least for older kernels this is not true. Lets just be
explicit about this requirement for the usage of wake_up().
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch removes ip_queue support which was marked as obsolete
years ago. The nfnetlink_queue modules provides more advanced
user-space packet queueing mechanism.

This patch also removes capability code included in SELinux that
refers to ip_queue. Otherwise, we break compilation.

Several warning has been sent regarding this to the mailing list
in the past month without anyone rising the hand to stop this
with some strong argument.
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

Explicit helper attachment via the CT target is broken with NAT
if non-standard ports are used. This problem was hidden behind
the automatic helper assignment routine. Thus, it becomes more
noticeable now that we can disable the automatic helper assignment
with Eric Leblond's:

9e8ac5a netfilter: nf_ct_helper: allow to disable automatic helper assignment

Basically, nf_conntrack_alter_reply asks for looking up the helper
up if NAT is enabled. Unfortunately, we don't have the conntrack
template at that point anymore.

Since we don't want to rely on the automatic helper assignment,
we can skip the second look-up and stick to the helper that was
attached by iptables. With the CT target, the user is in full
control of helper attachment, thus, the policy is to trust what
the user explicitly configures via iptables (no automatic magic
anymore).

Interestingly, this bug was hidden by the automatic helper look-up
code. But it can be easily trigger if you attach the helper in
a non-standard port, eg.

iptables -I PREROUTING -t raw -p tcp --dport 8888 \
	-j CT --helper ftp

And you disabled the automatic helper assignment.

I added the IPS_HELPER_BIT that allows us to differenciate between
a helper that has been explicitly attached and those that have been
automatically assigned. I didn't come up with a better solution
(having backward compatibility in mind).
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

This refreshes the "timeout" attribute in existing expectations if one is
given.

The use case for this would be for userspace helpers to extend the lifetime
of the expectation when requested, as this is not possible right now
without deleting/recreating the expectation.

I use this specifically for forwarding DCERPC traffic through:

DCERPC has a port mapper daemon that chooses a (seemingly) random port for
future traffic to go to. We expect this traffic (with a reasonable
timeout), but sometimes the port mapper will tell the client to continue
using the same port. This allows us to extend the expectation accordingly.
Signed-off-by: NKelvie Wong <kelvie@ieee.org>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

To build ip_vs as a module sysctl_rmem_max and sysctl_wmem_max
needs to be exported.

The dependency was added by "ipvs: wakeup master thread" patch.
Signed-off-by: NHans Schillstrom <hans.schillstrom@ericsson.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

Functions not referenced outside of a source file should be marked
static to prevent it from being exposed globally.

This quiets the sparse warnings:

warning: symbol '__ipvs_proto_data_get' was not declared. Should it be static?
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>

Functions not referenced outside of a source file should be marked
static to prevent it from being exposed globally.

This quiets the sparse warnings:

warning: symbol 'ip_vs_ftp_init' was not declared. Should it be static?
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>

	cp->flags is marked volatile but ip_vs_bind_dest
can safely modify the flags, so save some CPU cycles by
using temp variable.
Signed-off-by: NJulian Anastasov <ja@ssi.bg>
Signed-off-by: NSimon Horman <horms@verge.net.au>

	Allow master and backup servers to use many threads
for sync traffic. Add sysctl var "sync_ports" to define the
number of threads. Every thread will use single UDP port,
thread 0 will use the default port 8848 while last thread
will use port 8848+sync_ports-1.

	The sync traffic for connections is scheduled to many
master threads based on the cp address but one connection is
always assigned to same thread to avoid reordering of the
sync messages.

	Remove ip_vs_sync_switch_mode because this check
for sync mode change is still risky. Instead, check for mode
change under sync_buff_lock.

	Make sure the backup socks do not block on reading.

Special thanks to Aleksey Chudov for helping in all tests.
Signed-off-by: NJulian Anastasov <ja@ssi.bg>
Tested-by: NAleksey Chudov <aleksey.chudov@gmail.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>

	Add two new sysctl vars to control the sync rate with the
main idea to reduce the rate for connection templates because
currently it depends on the packet rate for controlled connections.
This mechanism should be useful also for normal connections
with high traffic.

sync_refresh_period: in seconds, difference in reported connection
	timer that triggers new sync message. It can be used to
	avoid sync messages for the specified period (or half of
	the connection timeout if it is lower) if connection state
	is not changed from last sync.

sync_retries: integer, 0..3, defines sync retries with period of
	sync_refresh_period/8. Useful to protect against loss of
	sync messages.

	Allow sysctl_sync_threshold to be used with
sysctl_sync_period=0, so that only single sync message is sent
if sync_refresh_period is also 0.

	Add new field "sync_endtime" in connection structure to
hold the reported time when connection expires. The 2 lowest
bits will represent the retry count.

	As the sysctl_sync_period now can be 0 use ACCESS_ONCE to
avoid division by zero.

	Special thanks to Aleksey Chudov for being patient with me,
for his extensive reports and helping in all tests.
Signed-off-by: NJulian Anastasov <ja@ssi.bg>
Tested-by: NAleksey Chudov <aleksey.chudov@gmail.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>

	High rate of sync messages in master can lead to
overflowing the socket buffer and dropping the messages.
Fixed sleep of 1 second without wakeup events is not suitable
for loaded masters,

	Use delayed_work to schedule sending for queued messages
and limit the delay to IPVS_SYNC_SEND_DELAY (20ms). This will
reduce the rate of wakeups but to avoid sending long bursts we
wakeup the master thread after IPVS_SYNC_WAKEUP_RATE (8) messages.

	Add hard limit for the queued messages before sending
by using "sync_qlen_max" sysctl var. It defaults to 1/32 of
the memory pages but actually represents number of messages.
It will protect us from allocating large parts of memory
when the sending rate is lower than the queuing rate.

	As suggested by Pablo, add new sysctl var
"sync_sock_size" to configure the SNDBUF (master) or
RCVBUF (slave) socket limit. Default value is 0 (preserve
system defaults).

	Change the master thread to detect and block on
SNDBUF overflow, so that we do not drop messages when
the socket limit is low but the sync_qlen_max limit is
not reached. On ENOBUFS or other errors just drop the
messages.

	Change master thread to enter TASK_INTERRUPTIBLE
state early, so that we do not miss wakeups due to messages or
kthread_should_stop event.

Thanks to Pablo Neira Ayuso for his valuable feedback!
Signed-off-by: NJulian Anastasov <ja@ssi.bg>
Signed-off-by: NSimon Horman <horms@verge.net.au>

	As the goal is to mirror the inactconns/activeconns
counters in the backup server, make sure the cp->flags are
updated even if cp is still not bound to dest. If cp->flags
are not updated ip_vs_bind_dest will rely only on the initial
flags when updating the counters. To avoid mistakes and
complicated checks for protocol state rely only on the
IP_VS_CONN_F_INACTIVE bit when updating the counters.
Signed-off-by: NJulian Anastasov <ja@ssi.bg>
Tested-by: NAleksey Chudov <aleksey.chudov@gmail.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>