Add my new trees to the MAINTAINERS file
for the components that I maintain in the
new trees.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
If a given interface combination doesn't contain
a required interface type then we missed checking
that and erroneously allowed it even though iface
type wasn't there at all. Add a check that makes
sure that all interface types are accounted for.
Cc: [email protected]
Reported-by: Mohammed Shafi Shajakhan <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Otherwise the LEDs stick around and cause issues the
next time around since they're still there but not
really hooked up.
Cc: [email protected]
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Linus reported that due to mac80211 failing to register
the device (due to WoWLAN) his machine crashed etc. as
we double-freed the vmalloc() firmware area. His patch
to fix it was very similar to this one but I noticed
that there's another bug in the area: we complete the
completion before starting, so since we're running in
a work struct context stop() could be called while in
the middle of start() which will almost certainly lead
to issues.
Make a modification similar to his to avoid the double-
free but also move the completion to another spot so it
is only done after start() either finished or failed so
that stop() can have a consistent state.
Reported-by: Linus Torvalds <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
If CONFIG_PM_SLEEP is disabled, then iwlwifi doesn't
support suspend/resume handlers and thus mac80211
(correctly) refuses advertising WoWLAN. Disable
WoWLAN in the driver in this case.
Cc: [email protected]
Reported-by: Sebastian Kemper <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
When any interface goes down, it could be the one that we
were doing a remain-on-channel with. We therefore need to
cancel the remain-on-channel and flush the related work
structs so they don't run after the interface has been
removed or even destroyed.
It's also possible in this case that an off-channel SKB
was never transmitted, so free it if this is the case.
Note that this can also happen if the driver finishes
the off-channel period without ever starting it.
Cc: [email protected]
Reported-by: Nirav Shah <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Enforcing interface combinations broke uses of hwsim
with multiple virtual interfaces. Advertise that all
combinations are possible to fix this.
Reported-by: Nirav Shah <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Since my commit
iwlwifi: use valid TX/RX antenna from hw_params
the config values are pure overrides, not the
real values for all hardware. Therefore, the
EEPROM TX power reading code checks the wrong
values, it should check the hw_params values.
Cc: [email protected] [3.4]
Reviewed-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
If drv->op_mode is NULL after trying to init the
opmode, we go to the wrong label. Fix this, and
clean up the code a bit.
Reviewed-by: Gregory Greenman <[email protected]>
Reviewed-by: Guy Cohen <[email protected]>
Reviewed-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The ucode16 option is still very much work in
progress, so there's no need to ask any users
about it. Remove the option and code for now,
we'll put it back when it's actually working.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Since mwifiex only supports managed and IBSS
modes, it doesn't need a set_channel call. The
callback might be called, but it won't matter
as nothing can use the channel.
Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Bing Zhao <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Since rndis_wlan only supports managed and IBSS
modes, it doesn't need a set_channel call. The
callback might be called, but it won't matter
as nothing can use the channel.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Support explicit monitor interface to keep
injection working after the HW queue changes.
This also finally enables sniffer mode.
Reviewed-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
There are four instances in nl80211 of getting the
channel type from the attribute and validating it,
refactor those.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
It should return bool, not int. The function even
does return true/false.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We don't really want/need to maintain the old
station flags API any more, so refuse changes
to new (not yet defined) flags from the old
flags API.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Add a flag for the HT format (mixed vs. greenfield)
to allow drivers to report that on receive. Not all
drivers will do that though, so allow drivers to set
which radiotap MCS details they report.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
cfg80211_calculate_bitrate() doesn't work for MCS
rates 32 or higher, and it has always returned 0
in that case. Warn if it ever really happens.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
cfg80211_calculate_bitrate() is defined in the external
header file cfg80211.h now, so no need to keep it in
the internal one as well.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
In commit 12d3952fc4
("mac80211: optimize aggregation session timeout handling")
two bugs were introduced:
1) RCU usage was completely broken since no locks are held
2) the timer must not rearm when agg session is stopping
Reported-and-tested-by: Larry Finger <[email protected]>
Cc: Felix Fietkau <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
My queue management rework broke drivers that don't
have multiple AC queues and register a single queue
only, causing a warning:
WARNING: at net/mac80211/iface.c:162 ieee80211_check_queues
This was due to filling the queues wrongly and then
noticing the error when checking later.
Reported-and-Tested-by: Larry Finger <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Neither compare_ether_addr() nor compare_ether_addr_64bits()
(as it can fall back to the former) have comparison semantics
like memcmp() where the sign of the return value indicates sort
order. We had a bug in the wireless code due to a blind memcmp
replacement because of this.
A cursory look suggests that the wireless bug was the only one
due to this semantic difference.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Newer devices have 20 (5000 series) or 30 (6000 series)
hardware queues, rather than the 16 that 4965 had. This
was added to the driver a long time ago, but improperly:
the queue registers for the higher queues aren't just
continuations of the registers for the first 16 queues,
they are in other places. Therefore, the hardware would
lock up when trying to activate queue 16 or above and
the device would have to be restarted.
Thanks goes to Emmanuel who identified this and told me
how the queue programming should be done.
Note that we don't use queues 20 and higher today and
doing so needs more work than this.
Cc: [email protected]
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
For now at least, all module parameters should be
with the core functionality, so move them there,
while at it rename to iwlwifi_mod_params. Also
rename iwl-shared.h to iwl-modparams.h to reflect
the real contents.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Since the transport allocates and frees itself in
the transport specific code, there's no need for
virtual functions for it. Remove the free method
and call the correct functions directly.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
We can't get rid of everything yet due to
the BT definitions that I'm not quite sure
yet how to handle, but we can get rid of
most unneeded includes.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Since the PCI core shouldn't include the
iwl-eeprom.h header file, move the OTP
definitions into iwl-agn-hw.h which can
be included.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Since they're used in the config, they
should be declared in iwl-config.h.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
The hardware files belong to the core PCI
functionality, but the eeprom header file
mixes higher-level functionality and the
defines, so move out the specific defines
and put them into the appropriate HW files
instead.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Since they're used in the config, they
should be declared in iwl-config.h.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Since they're used in the config, they
should be declared in iwl-config.h.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
These defines will have to be shared
between modules, but they seem better
placed in iwl-drv.h than iwl-shared.h.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
We only need one declaration, not multiple.
Keep the one in iwl-shared.h, which will
probably be renamed to iwl-modparams.h at
some point in the future.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Keeping statistics per frame type really isn't
very useful, and needs a huge amount of code
so remove it. Since that is the only thing in
iwl-core.{c,h} now, those files can be killed.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
That file is now holding just a few defines and
the module parameters, so it shouldn't include
anything. Make sure the right users include the
right files instead.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
They clearly belong into iwl-agn.h as they have no
relation to the (generic) debug logging framework.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
There really is no point in printing very verbose
error messages when somebody tries to access a
debugfs file before it is ready. Or even worse,
printing verbose messages when memory allocation
fails which *already* prints a huge warning.
Remove all IWL_ERR messages from debugfs.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
This fixes a long-standing bug: iwlwifi always assumes
that the CCK ACK rates are 1 and 2 MBps and the OFDM
ACK rates are 6, 12 and 24 MBps. Fix this problem by
using the basic rates the AP (or in AP case hostapd)
told us to use and add the necessary mandatory rates
to the mix.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Having cmd[], meta[] and skbs[] as separate arrays
in the TX queue structure is cache inefficient as
we need the data for a given entry together.
To improve this, create an array with these three
members (allocate meta as part of that struct) so
we have the data we need together located together
improving cache footprint.
The downside is that we need to allocate a lot of
memory in one chunk, about 10KiB (on 64-bit) which
isn't very efficient.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
The command strings are needed through the layers for
debug and error messages, but can differ with opmode.
As a result, we need to give the command names to the
transport layer as configuration.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Having a u32 before a potential 64-bit value is
not very efficient, move it last.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
The declaration isn't needed as the struct is only
used in code that includes the right header file.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
It doesn't even exist as a module parameter,
so just remove the item from the struct.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
We've never released firmware using the alternatives
mechanism and our build process makes that difficult
anyway. This means that in every file we have ever
built (except maybe by hand for testing) the listed
alternative was 0. Make the alternative field in the
TLVs part of the TLV number (thus expanding that to
32 bits); this gives us more TLV numbers (not really
needed) and more importantly protects against rogue
firmware files that actually do use the alternatives
mechanism -- those will now be rejected since they
don't contain any valid TLVs.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
My original idea with this was to adjust the sleep
pattern of the uCode based on the maximum network
latency userspace asked for. Due to nobody wanting
to test it, this logic was disabled by default. It
seems the time has come to remove it, since it's
not only always disabled but there also don't seem
to be any applications that actually request a max
network latency.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Not all stations are guaranteed to have the same
active (available) legacy rates, so calculate them
on rate control init instead of hard-coding them
based on our own available rates. I have no idea
why that was done here before.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Having the pointer to lib_ops in the config
makes it impossible to split the driver into
different modules. Determine the ops based on
the device family enumeration to get rid of
the direct pointer.
Also move all the opmode specific code from
the iwl-[1256]000.c files into a new file
iwl-agn-devices.c so that the former only
have configuration data now.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This will later be used to dynamically bind
the configuration data for DVM and MVM.
For now, we can use it to get rid of the
additional_nic_config() hook.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The iwl-shared.h header file will be going away
soon. There isn't much left in it that we keep,
other than the device configuration declarations.
Move those out now to a new iwl-config.h header.
iwl-cfg.h seemed like a possible alternative but
those declarations will later live in the PCIe
transport code.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The whole code around eeprom is distributed
across whole bunch of different files, most
of which belong to the to-be-DVM code. As a
result, it is currently very hard to split
out the EEPROM code to be generic. However,
it is also quite unlikely that the current
EEPROM code will be needed by the MVM code
as that has different mechanisms to query
the EEPROM (it does so through the uCode.)
So, at least temporarily, move everything
into priv. If it becomes necessary to use
the code from MVM, we will have to split it
out, but then it's also easier since we'll
know what pieces we need.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Split the force_reset debugfs file into two
different files:
* "rf_reset" triggers a reset of the RF when
written to and exposes statistics on RF
resets when read
* fw_restart triggers a firmware restart when
written to and lives in the transport
This cleans up all sources of firmware restart
to originate within the transport layer and
allows us to simplify some code.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This defaults to false, and we don't recommend
to use it anywhere, so just remove it.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The hw_params are mostly values that are
derived from the actual hardware config.
As such, while it is possible that MVM
will require similar ones, it makes more
sense -- at least for now -- to put them
into the DVM struct.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This removes one of the two sources of device
restarts in the upper layer -- those are a bit
inconvenient because normal restarts originate
in the transport. By moving the watchdog down
it can be treated the same.
Also rewrite the watchdog logic. Timers are
much more efficient when they never fire, so
instead firing a timer every 500ms set up a
timer for each TX queue and fire it only when
the queue is really stuck. This avoids the CPU
waking up when everything is working well.
While at it, remove the wd_disable config item
and replace it by simply setting wd_timeout to
IWL_WATCHHDOG_DISABLED (0).
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This file isn't really all that useful as
when the watchdog triggered it's already
too late, and the setting doesn't persist
unlike e.g. a module parameter that could
be added to the right config file.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
That way it isn't needed in hw_params, which
is shared data. It also isn't really what we
should configure in the transport, that is
better just 4k/8k, so configure a bool and
derive the page order in the transport. This
also means the transport doesn't need access
to the module parameter any more.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
In WoWLAN, we only get the triggers when we actually get
to suspend. As a consequence, drivers currently don't
know that the device should enable wakeup. However, the
device_set_wakeup_enable() API is intended to be called
when the wakeup is enabled, not later when needed.
Add a new set_wakeup() call to cfg80211 and mac80211 to
allow drivers to properly call device_set_wakeup_enable.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Eliad's comment prompted me to look closer at
the error paths in ieee80211_do_open() and I
found one that should use the error labels.
Also add a comment about the clear_bit since
in many error cases the bit hasn't been set.
Cc: Eliad Peller <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
mac80211 currently only supports one hardware queue
per AC. This is already problematic for off-channel
uses since if we go off channel while the BE queue
is full and then try to send an off-channel frame
the frame will never go out. This will become worse
when we support multi-channel since then a queue on
one channel might be full, but we have to stop the
software queue for all channels. That is obviously
not desirable.
To address this problem allow drivers to register
more hardware queues, and allow them to map them to
virtual interfaces. When they stop a hardware queue
the corresponding AC software queues on the correct
interfaces will be stopped as well. Additionally,
there's an off-channel queue to solve that problem
and a per-interface after-DTIM beacon queue. This
allows drivers to manage software queues closer to
how the hardware works.
Currently, there's a limit of 16 hardware queues.
This may or may not be sufficient, we can adjust it
as needed.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The queue mapping redesign that I'm planning to do
will break pure injection unless we handle monitor
interfaces explicitly. One possible option would
be to have the driver tell mac80211 about monitor
mode queues etc., but that would duplicate the API
since we already need to have queue assignments
handled per virtual interface.
So in order to solve this, have a virtual monitor
interface that is added whenever all active vifs
are monitors. We could also use the state of one
of the monitor interfaces, but managing that would
be complicated, so allocate separate state.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The AP netdev is really only active when beaconing, so
manage the carrier state accordingly. Also do that for
VLAN interfaces enslaved to a given AP interface.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
When comparing hw->queues to determine if the
device is QoS capable, use IEEE80211_NUM_ACS
instead of just 4.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
When adding pending SKBs there's no need to
stop all queues, we only need to stop those
that we're adding frames to. Implement that
by lazily stopping a queue as we add an SKB.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
When the queue status changes we need to do a fair
bit of work, so ignore no-op changes early.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
When we get more hardware queues, we'll still want
to only have netdev queues per AC, so set it up in
that way. If the hardware doesn't support QoS (by
not supporting at least 4 queues) the netdevs get
a single queue only (this is no change in behavior
as there are no drivers with 2 or 3 queues today.)
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Drivers that don't support QoS also don't support
setting up their ACs, catch that early. While at
it, remove the input check since cfg80211 does it
now.
Also fix up the restart code to not try to set up
the queues in this case.
Finally also change the tx_conf array to have
IEEE80211_NUM_ACS entries instead of # of queues
since that's what it really needs.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
With the plan to change mac80211's queue API to
not map ACs to queues 1:1, it seems necessary to
clarify some APIs that act on ACs rather than on
queues to spell that out explicitly. Do this.
Also verify that the AC number given is valid.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This field is never set to anything non-zero in
mac80211, so we should be able to remove it.
Unfortunately though, the iwlwifi and iwlegacy
drivers use it for their internal TX status
processing (which shouldn't be using the rate
control API to start with), so add a new field
"status.antenna" for them, at least for now.
In the future, I plan to use the new field to
hold the hardware queue, while the SKB's queue
mapping holds the AC.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Devices that have internal rate control need to be
notified when the bandwidth or SMPS state changes
just like external rate control algorithms get a
notification now.
Add this notification and clarify the change bits
while at it, the HT_CHANGED bit really meant only
bandwidth changed.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
We currently stop the queue when changing the rate
control between 20/40 MHz in the BSS. This seems to
have been necessary when we actually changed the
channel, but now that we just update the station it
doesn't seem right any more. Remove it.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The channel type argument to the rate_update()
callback isn't really the correct way to give
the rate control algorithm about the desired
RX bandwidth of the peer.
Remove this argument, and instead update the
STA capabilities with 20/40 appropriately. The
SMPS update done by this callback works in the
same way, so this makes the callback cleaner.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Changing the channel type during operation is
confusing to some drivers and will be hard to
handle in multi-channel scenarios. Instead of
changing the channel, set it to the right HT
channel before authenticating/associating and
don't change it -- just update the 20/40 MHz
restrictions in rate control as needed when
changed by the AP.
This also fixes a problem that Paul missed in
his fix for the "regulatory makes us deaf"
issue -- when we couldn't use 40 MHz we still
associated saying we were using 40 MHz, which
could in similarly broken APs make us never
even connect successfully.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Use the AC constants instead of hard-coding
the numbers with comments.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Clean up the code formatting and also replace
the constant 0 by IEEE80211_AC_VO.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
IEEE80211_MAX_QUEUES is an internal mac80211 value,
it is not guaranteed to be always 4. The firmware
API in mwifiex almost certainly doesn't care about
mac80211 changing though, so mwifiex shouldn't use
this value.
Maybe it should use IEEE80211_NUM_ACS instead and
that is what I'm doing here as at least that value
will probably never change, but maybe it should
have its own define instead.
Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Bing Zhao <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Not all devices are really capable of implementing
remain-on-channel, even if it is implemented in SW,
as they can't necessarily deal with channel changes
while associated.
Remove the WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL and add
it only if either the driver has remain_on_channel
implemented in the driver/device.
Also add it to all drivers that advertise P2P right
now since those definitely have to have it working.
Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Luciano Coelho <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
No other component is accessing it any more,
so it can move to the correct place in priv.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The queue mapping is not only dynamic, it
is also dependent on the uCode, as we can
already see today with the dual-mode and
non-dual-mode being different.
Move the queue mapping out of the transport
layer and let the higher layer manage it.
Part of the transport configuration is how
to set up the queues.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
As idle is just a deep powersave mode for
the device, it will easily scan while idle
since that turns off powersave.
This reduces the number of commands sent
to the device when scanning.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This is not (no longer?) used by any device
so just remove it.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This is used only by 2000 class devices, but
they all use it so remove the configuration
parameter and hard-code the programming.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
It talks about treating different uCode APIs
as different pieces of hardware which really
isn't how we handle things.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
A whole bunch of messages, even some recent ones,
didn't include a trailing newline so add it.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The calibration results all come in while we're
waiting for the calibration complete notification.
As a consequence, there's no need to install a
global RX handler for them, we can use the newly
extended notification wait framework for this and
make the code easier to follow.
It is now quite explicit that we are processing
the calibration results while waiting for the
complete notification, before this was implicit
and developers had to know this to understand why
we wait for the calibration complete notification
and what happens while we wait.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Sometimes, for example when we ask the uCode
for calibration, we wait for the "complete"
response while we also need the results that
are sent in other, interim, notifications.
Currently we handle this by installing an RX
handler globally, but that isn't needed as
this is the only time we want to use these
notifications.
So in order to be able to simplify at least
future code that does the same, extend the
notification wait framework to allow you to
wait for multiple commands and decide based
on the command whether the wait finished.
While at it, also fix a race that can then
become relevant -- if the wait function has
returned true once it shouldn't be called
again, today this can happen due to races
between the triggering and the wakeup.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The flow handler (hardware) can put multiple
frames into a single RX buffer. To handle
this, walk the RX buffer and check if there
are multiple valid packets in it.
To let the upper layer handle this correctly
introduce rxb_offset() which is needed when
we pass pages to mac80211 -- we need to know
the offset into the page there.
Also change the page handling scheme to use
refcounting. Anyone who needs a page will
"steal" it, which marks it as having been
used & refcounts it. The RX handler then has
to free its own reference and must not reuse
the page.
Finally, do not set the bit asking the FH to
give us each packet in a single buffer. This
really enables the feature.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Since some of the HT code pre-dates 802.11n-2009
some names are wrong. The one that bothers me most
is that "HT operation" is called "HT information"
in our code and that causes confusion.
Rename "HT information" to "HT operation" and also
the control_chan field to primary_chan to match
the name used in the spec.
Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Bing Zhao <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Johannes Berg