Tom Quetchenbach [Sun, 21 Sep 2008 07:21:51 +0000 (00:21 -0700)]
tcp: advertise MSS requested by user
I'm trying to use the TCP_MAXSEG option to setsockopt() to set the MSS
for both sides of a bidirectional connection.
man tcp says: "If this option is set before connection establishment, it
also changes the MSS value announced to the other end in the initial
packet."
However, the kernel only uses the MTU/route cache to set the advertised
MSS. That means if I set the MSS to, say, 500 before calling connect(),
I will send at most 500-byte packets, but I will still receive 1500-byte
packets in reply.
This is a bug, either in the kernel or the documentation.
This patch (applies to latest net-2.6) reduces the advertised value to
that requested by the user as long as setsockopt() is called before
connect() or accept(). This seems like the behavior that one would
expect as well as that which is documented.
I've tried to make sure that things that depend on the advertised MSS
are set correctly.
Signed-off-by: Tom Quetchenbach <virtualphtn@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck [Sun, 21 Sep 2008 05:07:34 +0000 (22:07 -0700)]
multiq: requeue should rewind the current_band
Currently dequeueing a packet and requeueing the same packet will cause a
different packet to be pulled on the next dequeue. This change forces
requeue to rewind the current_band.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sun, 21 Sep 2008 04:26:22 +0000 (21:26 -0700)]
tcp: back retransmit_high when it over-estimated
If lost skb is sacked, we might have nothing to retransmit
as high as the retransmit_high is pointing to, so place
it lower to avoid unnecessary walking.
This is mainly for the case where high L'ed skbs gets sacked.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sun, 21 Sep 2008 04:25:52 +0000 (21:25 -0700)]
tcp: don't clear lost_skb_hint when not necessary
Most importantly avoid doing it with cumulative ACK. However,
since we have lost_cnt_hint in the picture as well needing
adjustments, it's not as trivial as dealing with
retransmit_skb_hint (and cannot be done in the all place we
could trivially leave retransmit_skb_hint untouched).
With the previous patch, this should mostly remove O(n^2)
behavior while cumulative ACKs start flowing once rexmit
after a lossy round-trip made it through.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sun, 21 Sep 2008 04:24:49 +0000 (21:24 -0700)]
tcp: remove retransmit_skb_hint clearing from failure
This doesn't much sense here afaict, probably never has. Since
fragmenting and collapsing deal the hints by themselves, there
should be very little reason for the rexmit loop to do that.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sun, 21 Sep 2008 04:21:16 +0000 (21:21 -0700)]
tcp: No need to clear retransmit_skb_hint when SACKing
Because lost counter no longer requires tuning, this is
trivial to remove (the tuning wouldn't have been too
hard either) because no "new" retransmittable skb appeared
below retransmit_skb_hint when SACKing for sure.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Ilpo Järvinen [Sun, 21 Sep 2008 04:20:20 +0000 (21:20 -0700)]
tcp: convert retransmit_cnt_hint to seqno
Main benefit in this is that we can then freely point
the retransmit_skb_hint to anywhere we want to because
there's no longer need to know what would be the count
changes involve, and since this is really used only as a
terminator, unnecessary work is one time walk at most,
and if some retransmissions are necessary after that
point later on, the walk is not full waste of time
anyway.
Since retransmit_high must be kept valid, all lost
markers must ensure that.
Now I also have learned how those "holes" in the
rexmittable skbs can appear, mtu probe does them. So
I removed the misleading comment as well.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 19 Sep 2008 23:13:05 +0000 (16:13 -0700)]
qlge: Fix warnings in debugging code.
drivers/net/qlge/qlge_dbg.c: In function ‘ql_dump_qdev’:
drivers/net/qlge/qlge_dbg.c:369: warning: cast to pointer from integer of different size
drivers/net/qlge/qlge_dbg.c:373: warning: cast to pointer from integer of different size
drivers/net/qlge/qlge_dbg.c: In function ‘ql_dump_tx_ring’:
drivers/net/qlge/qlge_dbg.c:457: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘long unsigned int’
drivers/net/qlge/qlge_dbg.c:461: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘long unsigned int’
drivers/net/qlge/qlge_dbg.c: In function ‘ql_dump_rx_ring’:
drivers/net/qlge/qlge_dbg.c:557: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘long unsigned int’
drivers/net/qlge/qlge_dbg.c:565: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘long unsigned int’
drivers/net/qlge/qlge_dbg.c:575: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘long unsigned int’
drivers/net/qlge/qlge_dbg.c:579: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘long unsigned int’
drivers/net/qlge/qlge_dbg.c:598: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘long unsigned int’
drivers/net/qlge/qlge_dbg.c:602: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘long unsigned int’
Signed-off-by: David S. Miller <davem@davemloft.net>
Benjamin Li [Thu, 18 Sep 2008 23:40:49 +0000 (16:40 -0700)]
bnx2: Remove timer_interval field from the bnx2 structure
The timer_interval field is only assigned once, and never reassigned.
We can safely replace all instances of the timer_interval with a
constant value.
Signed-off-by: Benjamin Li <benli@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Benjamin Li [Thu, 18 Sep 2008 23:40:03 +0000 (16:40 -0700)]
bnx2: Remove name field from bnx2 structure
The name of the board is only used during the initialization of
the adapter. We can save the space of a pointer by not storing
this information.
Signed-off-by: Benjamin Li <benli@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Benjamin Li [Thu, 18 Sep 2008 23:39:16 +0000 (16:39 -0700)]
bnx2: Update MODULE_DESCRIPTION to include the 5716
Signed-off-by: Benjamin Li <benli@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Benjamin Li [Thu, 18 Sep 2008 23:38:24 +0000 (16:38 -0700)]
bnx2: In bnx2_set_mac_link() return void rather then int
bnx2_set_mac_link() doesn't need to return any error codes. And
all the callers don't check the return code. It is safe to
change the return type to a void.
Signed-off-by: Benjamin Li <benli@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: David S. Miller <davem@davemloft.net>
John W. Linville [Mon, 15 Sep 2008 21:25:54 +0000 (17:25 -0400)]
libertas: correct "limited range of data type" warning
CC [M] drivers/net/wireless/libertas/wext.o
drivers/net/wireless/libertas/wext.c: In function ‘lbs_get_rts’:
drivers/net/wireless/libertas/wext.c:307: warning: comparison is always
false due to limited range of data type
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 : Fix mode change hard_start_xmit function
When monitor mode is changed to BSS or IBSS, data trasnfer can not happen
because proper transmit function is not assigend for BSS ,IBSS mode.
This patch fixes this problem by assigning the ieee80211_subif_start_xmit
to device's hard_start_xmit function.
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com> Acked-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 12 Sep 2008 13:22:53 +0000 (15:22 +0200)]
mac80211: remove debug frame dumping
You can just pull up a monitor interface to get much more
detailed information, or, when debugging a driver, insert
dump code into the driver (which usually you will have to
do anyway to dump the driver-specific information). Hence
this option is useless.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 12 Sep 2008 09:05:39 +0000 (11:05 +0200)]
mac80211: remove beacon counters
The beacon counters mac80211 keeps are only used for debugfs,
unfortunately, they are incorrect for many hardware designs,
namely any design that has a beacon template. Hence, remove the
counters so we don't create the impression they are usable.
This also allows removing the beacon MESH #ifdef again.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 12 Sep 2008 08:18:44 +0000 (10:18 +0200)]
mac80211: clean up kdoc
A few errors sneaked in over time, some functions no longer exist,
for some alternatives exist. This changes the docbook template to
include the right things.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 12 Sep 2008 07:53:27 +0000 (09:53 +0200)]
mac80211: fix sta_info kernel-doc warning
Sorry, forgot to run kernel-doc and just got the output from the nightly
run by email, this fixes a warning which I introduced when doing the
first RC API cleanups.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 11 Sep 2008 22:39:22 +0000 (00:39 +0200)]
mac80211 hwsim: make radio list dynamic
This paves the way for dynamic radio additions while the module
is loaded. Also restrict the number of radios to 100 because
creating that many already takes forever.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 12 Sep 2008 20:52:47 +0000 (22:52 +0200)]
mac80211: fix virtual interfaces vs. injection
Currently, virtual interface pointers passed to drivers might be
from monitor interfaces and as such completely uninitialised
because we do not tell the driver about monitor interfaces when
those are created. Instead of passing them, we should therefore
indicate to the driver that there is no information; do that by
passing a NULL value and adjust drivers to cope with it.
As a result, some mac80211 API functions also need to cope with
a NULL vif pointer so drivers can still call them unconditionally.
Also, when injecting frames we really don't want to pass NULL all
the time, if we know we are the source address of a frame and have
a local interface for that address, we can to use that interface.
This also helps with processing the frame correctly for that
interface which will help the 802.11w implementation. It's not
entirely correct for VLANs or WDS interfaces because there the MAC
address isn't unique, but it's already a lot better than what we
do now.
Finally, when injecting without a matching local interface, don't
assign sequence numbers at all.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Javier Cardona [Thu, 11 Sep 2008 22:32:50 +0000 (15:32 -0700)]
libertas: Reduce the WPA key installation time.
WPA requires that the PTK is installed immediately after the 4-way handshake
in order to properly decrypt the subsequent incoming EAPOL-GTK frame. If the
PTK is not enabled by the time the EAPOL-GTK frame arrives, the frame is
dropped and the supplicant does not receive the group key.
This will happen with fast Access Points that send the EAPOL-GTK frame before
the suplicant has successfully installed and enabled the PTK. To mitigate
this situation, this patch simplifies and accelerates the SIOCSIWENCODEEXT
execution.
This patch resolves OLPC ticket 7825 (http://dev.laptop.org/ticket/7825)
Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, rfkill would stand in the way of properly supporting wireless
devices that are capable of waking the system up from sleep or hibernation
when they receive a special wireless message. It would also get in the way
of mesh devices that need to remain operational even during platform
suspend.
To avoid that, stop trying to block the transmitters on the rfkill class
suspend handler.
Drivers that need rfkill's older behaviour will have to implement it by
themselves in their own suspend handling.
Do note that rfkill *will* attempt to restore the transmitter state on
resume in any situation. This happens after the driver's resume method is
called by the suspend core (class devices resume after the devices they are
attached to have been resumed).
The following drivers need to check if they need to explicitly block
their transmitters in their own suspend handlers (maintainers Cc'd):
arch/arm/mach-pxa/tosa-bt.c
drivers/net/usb/hso.c
drivers/net/wireless/rt2x00/* (USB might need it?)
drivers/net/wireless/b43/ (SSB over USB might need it?)
drivers/misc/hp-wmi.c
eeepc-laptop w/rfkill support (not in mainline yet)
Compal laptop w/rfkill support (not in mainline yet)
toshiba-acpi w/rfkill support (not in mainline yet)
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Andrew Bird <ajb@spheresystems.co.uk> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com> Cc: Philip Langdale <philipl@overt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Lorenzo Nava [Thu, 11 Sep 2008 13:06:24 +0000 (15:06 +0200)]
b43: fix QoS parameters initialization
This fixes the initialization of QoS parameters.
Reported-by: Lorenzo Nava, Francesco Gringoli Signed-off-by: Francesco Gringoli <francesco.gringoli@ing.unibs.it> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tomas Winkler [Thu, 11 Sep 2008 03:45:21 +0000 (11:45 +0800)]
iwlwifi: add MODULE_FIRMWARE for 5000 HW
This patch adds MODULE_FIRMWARE statement for 5000 HW.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tomas Winkler [Thu, 11 Sep 2008 03:45:20 +0000 (11:45 +0800)]
iwlwifi: update 5350 Wifi PCI IDs
This patch updates PCI IDs for 5350 Wifi/WiMax.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 11 Sep 2008 01:17:05 +0000 (03:17 +0200)]
iwlwifi: don't access mac80211's AMPDU state machine
There really is no need, at worst ieee80211_start_tx_ba_session
will log a message when debugging is enabled, and poking such
internals of mac80211 definitely doesn't belong into an RC
algorithm.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 11 Sep 2008 01:04:36 +0000 (03:04 +0200)]
mac80211: move txrate_idx into RC algorithms
The sta_info->txrate_idx member isn't used by all RC algorithms
in the way it was intended to be used, move it into those that
require it (only PID) and keep track in the core code of which
rate was last used for reporting to userspace and the mesh MLME.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 11 Sep 2008 00:03:28 +0000 (02:03 +0200)]
mac80211: small rate control changes
This patch fixes mac80211 to not rely on the rate control
algorithm to update sta->tx_retry_failed and sta->tx_retry_count
(even if we don't currently use them), removes a number of
completely unused values we don't even show in debugfs and
changes the code in ieee80211_tx_status() to not look up the
sta_info repeatedly.
The only behaviour change here would be not calling the rate
control function rate_control_tx_status() when no sta_info is
found, but all rate control algorithms ignore such calls anyway.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 11 Sep 2008 00:17:01 +0000 (02:17 +0200)]
mac80211 hwsim: verify sta pointers
In analogy with the previous patch to make mac80211-hwsim
verify that the virtual interface pointers are correct,
this makes it very that it knows about all station structs.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 10 Sep 2008 22:02:02 +0000 (00:02 +0200)]
mac80211: share STA information with driver
This patch changes mac80211 to share some more data about
stations with drivers. Should help iwlwifi and ath9k when
they get around to updating, and might also help with
implementing rate control algorithms without internals.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Cc: Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 11 Sep 2008 00:16:36 +0000 (02:16 +0200)]
mac80211 hwsim: verify vif pointers
mac80211-hwsim is a debugging tool for mac80211, and as such
it can very well verify that mac80211 isn't passing junk to
drivers, especially the vif pointer is prone to this because
for vlan interfaces the AP interface pointer needs to be passed.
This makes mac80211-hwsim add a magic cookie to the private vif
area and verify it whenever an operation is called that gets a
vif pointer.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 10 Sep 2008 22:01:58 +0000 (00:01 +0200)]
mac80211: use nl80211 interface types
There's really no reason for mac80211 to be using its
own interface type defines. Use the nl80211 types and
simplify the configuration code a bit: there's no need
to translate them any more now.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 10 Sep 2008 22:01:54 +0000 (00:01 +0200)]
mac80211: make bridge_packets a virtual interface option
The bridge_packets configuration really should be per virtual
interface (theoretically per AP/VLAN, but this is much easier);
there currently is no way to set it yet though. Also invert
the option to "NO_BRIDGE_PACKETS" so the default is to bridge.
While at it, also document the flags properly.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 10 Sep 2008 22:01:52 +0000 (00:01 +0200)]
mac80211: reorder MLME code more
This way all the utility functions are at the top, then the
state machine and externally callable functions are moved to
the bottom. Also clean up ieee80211_i.h a bit and add a few
comments about which functions are called from where.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 10 Sep 2008 22:01:51 +0000 (00:01 +0200)]
mac80211: fix scan vs. interface removal race
When we remove an interface, we can currently end up having
a pointer to it left in local->scan_sdata after it has been
set down, and then with a hardware scan the scan completion
can try to access it which is a bug. Alternatively, a scan
that started as a hardware scan may terminate as though it
was a software scan, if the timing is just right.
On SMP systems, software scan also has a similar problem,
just canceling the delayed work and setting a flag isn't
enough since it may be running concurrently; in this case
we would also never restore state of other interfaces.
This patch hopefully fixes the problems by always invoking
ieee80211_scan_completed or requiring it to be invoked by
the driver, I suspect the drivers that have ->hw_scan() are
buggy. The bug will not manifest itself unless you remove
the interface while hw-scanning which will also turn off
the hw, and then add a new interface which will be unusable
until you scan once.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 10 Sep 2008 22:01:50 +0000 (00:01 +0200)]
mac80211: fix work race
When we stop an interface, the work on it may still be pending
or running. We do cancel the timer, but we do not currently
protect against the work struct. The race is very unlikely to
hit -- it'll happen only when the driver is using mac80211's
workqueue to run long-running tasks and the sta/mesh works are
delayed for quite a bit.
This patch fixes it by cancelling the work explicitly.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 10 Sep 2008 22:01:49 +0000 (00:01 +0200)]
mac80211: split off mesh handling entirely
This patch splits off mesh handling from the STA/IBSS.
Unfortunately it increases mesh code size a bit, but I
think it makes things clearer. The patch also reduces
per-interface run-time memory usage.
Also clean up a few places where ifdef is not required.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 10 Sep 2008 22:01:48 +0000 (00:01 +0200)]
mac80211: dont set REQ_RUN when scan finishes
The timer restart is done wrongly, we shouldn't set the REQ_RUN
bit when the scan has finished if it hadn't been set before the
scan started. If the timer fires during the scan, it will set
REQ_RUN and then we can run the work for it, if it didn't fire
then we shouldn't run its work either.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Dan Williams [Wed, 10 Sep 2008 13:04:33 +0000 (09:04 -0400)]
libertas: remove unused generic RESET command
The generic reset command is unused. Each interface type needs to
handle the reset command differently since after reset, the firmware is
dead and interface-specific mechanisms must be used to reinitialize the
card.
Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
cfg80211: Add new wireless regulatory infrastructure
This adds the new wireless regulatory infrastructure. The
main motiviation behind this was to centralize regulatory
code as each driver was implementing their own regulatory solution,
and to replace the initial centralized code we have where:
* only 3 regulatory domains are supported: US, JP and EU
* regulatory domains can only be changed through module parameter
* all rules were built statically in the kernel
We now have support for regulatory domains for many countries
and regulatory domains are now queried through a userspace agent
through udev allowing distributions to update regulatory rules
without updating the kernel.
Each driver can regulatory_hint() a regulatory domain
based on either their EEPROM mapped regulatory domain value to a
respective ISO/IEC 3166-1 country code or pass an internally built
regulatory domain. We also add support to let the user set the
regulatory domain through userspace in case of faulty EEPROMs to
further help compliance.
Support for world roaming will be added soon for cards capable of
this.
For now we leave an option to enable the old module parameter,
ieee80211_regdom, and to build the 3 old regdomains statically
(US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY.
These old static definitions and the module parameter is being
scheduled for removal for 2.6.29. Note that if you use this
you won't make use of a world regulatory domain as its pointless.
If you leave this option enabled and if CRDA is present and you
use US or JP we will try to ask CRDA to update us a regulatory
domain for us.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Alexander Duyck [Sat, 13 Sep 2008 00:57:23 +0000 (17:57 -0700)]
multiq: Further multiqueue cleanup
This patch resolves a few issues found with multiq including wording
suggestions and a problem seen in the allocation of queues.
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>
Alexander Duyck [Sat, 13 Sep 2008 00:56:50 +0000 (17:56 -0700)]
skbedit: Fix a typo in the documentation
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>
Alexander Duyck [Fri, 12 Sep 2008 23:30:20 +0000 (16:30 -0700)]
pkt_action: add new action skbedit
This new action will have the ability to change the priority and/or
queue_mapping fields on an sk_buff.
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>
Alexander Duyck [Fri, 12 Sep 2008 23:29:34 +0000 (16:29 -0700)]
pkt_sched: Add multiqueue scheduler support
This patch is intended to add a qdisc to support the new tx multiqueue
architecture by providing a band for each hardware queue. By doing
this it is possible to support a different qdisc per physical hardware
queue.
This qdisc uses the skb->queue_mapping to select which band to place
the traffic onto. It then uses a round robin w/ a check to see if the
subqueue is stopped to determine which band to dequeue the packet from.
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>
inet6_rsk() is called on a struct request_sock * before we
have checked whether the socket is an ipv6 socket or a ipv6-
mapped ipv4 socket. The access that triggers this is the
inet_rsk(rsk)->inet6_rsk_offset dereference in inet6_rsk().
This is arguably not a critical error as the inet6_rsk_offset
is only used to compute a pointer which is never really used
(in the code path in question) anyway. But it might be a
latent error, so let's fix it.
Spotted by kmemcheck.
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Benjamin Thery [Fri, 12 Sep 2008 23:16:37 +0000 (16:16 -0700)]
net: fix scheduling of dst_gc_task by __dst_free
The dst garbage collector dst_gc_task() may not be scheduled as we
expect it to be in __dst_free().
Indeed, when the dst_gc_timer was replaced by the delayed_work
dst_gc_work, the mod_timer() call used to schedule the garbage
collector at an earlier date was replaced by a schedule_delayed_work()
(see commit 86bba269d08f0c545ae76c90b56727f65d62d57f).
But, the behaviour of mod_timer() and schedule_delayed_work() is
different in the way they handle the delay.
mod_timer() stops the timer and re-arm it with the new given delay,
whereas schedule_delayed_work() only check if the work is already
queued in the workqueue (and queue it (with delay) if it is not)
BUT it does NOT take into account the new delay (even if the new delay
is earlier in time).
schedule_delayed_work() returns 0 if it didn't queue the work,
but we don't check the return code in __dst_free().
If I understand the code in __dst_free() correctly, we want dst_gc_task
to be queued after DST_GC_INC jiffies if we pass the test (and not in
some undetermined time in the future), so I think we should add a call
to cancel_delayed_work() before schedule_delayed_work(). Patch below.
Or we should at least test the return code of schedule_delayed_work(),
and reset the values of dst_garbage.timer_inc and dst_garbage.timer_expires
back to their former values if schedule_delayed_work() failed.
Otherwise the subsequent calls to __dst_free will test the wrong values
and assume wrong thing about when the garbage collector is supposed to
be scheduled.
dst_gc_task() also calls schedule_delayed_work() without checking
its return code (or calling cancel_scheduled_work() first), but it
should fine there: dst_gc_task is the routine of the delayed_work, so
no dst_gc_work should be pending in the queue when it's running.
Signed-off-by: Benjamin Thery <benjamin.thery@bull.net> Acked-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck [Fri, 12 Sep 2008 03:17:05 +0000 (20:17 -0700)]
vlan: vlan device not reading gso max size of parent.
The vlan devices are not reading the gso max size of the parent device. As
a result devices that do not support 64K max gso size are currently
failing.
This issue is seen on 2.6.26 kernels as well and the same patch should be
able to be applied without any issues.
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>
projects / linux-beck.git / log