Move "tx power per chain" into ucode_tx_stats, it is debugging
information provided by uCode as part of statistics notification.
The "tx power per chain" parameters are optional parameters which only
supported by 6000 series device today; those are reserved fields for all
the other devices.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Return -EAGAIN when request tx power information and uCode is not ready;
so it will not confuse with tx power information not available.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
sensitivity calibration and chain noise calibration are not available
for all the devices; use .cfg to configure the availability of those
calibration functions
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Instead of checking device type for enable/disable continuous ucode
trace function; put it in .cfg for better control and more
flexibilities.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Instead of checking device type for enable/disable tx power control,
move it to .cfg for better control and more flexibilities.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
The "chain_tx_power" debugfs function is to display the tx power per
chain based. Name it "tx_power" is misleading.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
For the devices do not have power save support, remove the power save
control related debugfs files.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Add general, rx and tx uCode statistics to 3945. This will help
in debugging
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
"internal_scan" debugfs function serves the same propose of mode "0" of
"force_reset" debugfs function. Remove it to avoid duplicate.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
small code cleanup to remove un-necessary parameters
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
These files are incompatible with some changes
I'm making, and don't really belong into sysfs
anyway as they can only be used for debugging.
Since writing them will probably crash the
firmware, keep only the reading part and move
them into debugfs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Since rfkill integration, mac80211 can no
longer add an interface while the hardware
is not ready, so STATUS_MODE_PENDING can
never be set.
Also, remove another superfluous channel
sanity check and return the commit_rxon
return value in case it failed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Adding debugfs file to monitor the counters and other
information related to "force_reset" request.
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>
Until now it was only possible to have one synchronous command running at
any time. If a synchronous command is in progress when a second request
arrives then the second command will fail. Create a new mutex specific for
this purpose to only allow one synchronous command at a time, but enable
other commands to wait instead of fail if a synchronous command is in
progress.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adding function to force reset radio or reload firmware from debugfs.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
iwl_power_update_mode expects to be called with mutex held, for example to
protect priv->vif. Only one caller currently does not do this, fix this.
Also, add a comment to iwl_power_update_mode to indicate this requirement.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
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>
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>
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>
When reading current ucode statistics information from debugfs, in
current implementation, it will always send a new "statistics request" to
uCode. In normal operation, uCode should report the statistics per beacon
interval. Remove this extra request to reduce the additional command exchanges
between driver and uCode.
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>
Flowhandler handle the communication between driver and uCode, when any
uCode error happen, we also like to know what is the status of the
flowhandler; it can help to debug flowhandler related problem.
Also adding debugfs file to dump current value of flowhandler registers.
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>
When dumping event log in debugfs, iwl_dump_nic_event_log()
should return the correct error code instead of let the calling
function makes it own assumption.
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>
When uCode detects number of beacon missed consecutively above the
internal missed beacon threshold (set by uCode), it will reset and
re-tune the radio in order to get out of bad PHY state.
This "num_of_sos_states" counter monitors number of time uCode
encounters this bad condition and has to re-tune the radio.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To help debug uCode related problem, adding "delta" and "max"
information in debugfs statistics counters display.
Those information show the delta between two statistics report from
uCode, user can monitor the counters for any "un-normal" behavior.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Jay Sternberg<jay.e.sternberg@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
void pointers do not need to be cast to other pointer types.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update data structure to match latest statistics report from uCode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This feature enables the on-screen uCode event log dump. The original
method will append the event log to syslog; with this capability,
we also enable the user to write script to capture the
events which provide additional flexibility to help uCode debugging
Method
1) change to debugfs directory (sys/kernel/debug/phyX/iwlagn/data)
2) #cat log_event
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>
In order to help uCode debugging, adding the capability to provide
continuous uCode event logging function.
uCode events is located in round-robin event queue and filled by uCode,
by enable continuous event logging, driver check the write pointer
and log the newly added events in iwl_bg_ucode_trace() timer function.
There is still possibility of missing events if event queue being
wrapped before next event dump; but with this capability, we can have
much better understanding of the uCode behavior during runtime; it can
help to debug the uCode related issues.
Methods to enable/disable the continuous event log:
step 1: enable ucode trace timer
"echo 1 >
/sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing"
step 2: start ftrace
sudo ./trace-cmd record -e iwlwifi_ucode:* sleep 1d
step 3: stop ftrace
sudo ./trace-cmd report trace.dat
step 4: disable ucode trace timer
"echo 0 >
/sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing"
use "ucode_tracing" debugfs file to display number of event
queue wrapped when driver attempt the continuous event logging. If event
queue being wrapped more than once when driver has opportunity to log
the event; it indicated there are events missing in the event log trace.
This continuous event log function only available for 4965 and newer
NICs.
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>
When uCode HW/SW error detected, dumping important CSR (Control and Status
Registers) values.
Also add "csr" debugfs file to dump the current values of CSR defined in
CSR table to syslog.
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>
To help iwlagn uCode debugging, event log will dump to syslog when driver
detect uCode error occurred, but this only happen when compile with
CONFIG_IWLWIFI_DEBUG and debug flag is enabled; which is not always
the case. Also, there is another problem, if the flag is set, the entire
event log buffer will be dump to syslog, it can flood the syslog and
make it very difficult to debug the problem.
Change the default to only dump last 20 entries of event log to syslog
unless the following condition meets:
1. both compile with CONFIG_IWLWIFI_DEBUG and debug flag
is enabled, and then dump the entire event buffer to syslog.
2. dump event log request from debugfs
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Acked-by: Ben Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For "sram" debugfs file, if user did not specify the offset and length,
dump the entire data portion of sram by default.
Data portion is 0x800000 - 0x80ffff, but the actual data size is known
to the driver from the ucode file.
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>
Dynamically allocate memory for dumping SRAM based on the length of memory
to be displayed.
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>
For tx_queue, need to increase the buffer size allocated for it,
so all the queues information can be displayed
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>
Set the correct Read/Write file permission for iwlwifi debugfs files
based on the functionality of the files
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>
LED blink rate is based on the traffic load, when tx/rx traffic counts
got reset, we also need to reset the led_tpt to prevent incorrect
blink rate being calculated.
Merge both clear_tx_statistics() and clear_rx_statistics() into
single clear_traffic_statistics() function, when reset the traffic byte
counts, both tx and rx need to be reset at the same time, to make
sure calculated the correct led blink rate.
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>
Using the new mac80211 functionality, this makes
iwlwifi handle unicast PS buffering correctly.
The device works like this:
* when a station goes to sleep, the microcode notices
this and marks the station as asleep
* when the station is marked asleep, the microcode
refuses to transmit to the station and rejects all
frames queued to it with the failure status code
TX_STATUS_FAIL_DEST_PS (a previous patch handled
this correctly)
* when we need to send frames to the station _although_
it is asleep, we need to tell the ucode how many,
and this is asynchronous with sending so we cannot
just send the frames, we need to wait for all other
frames to be flushed, and then update the counter
before sending out the poll response frames. This
is handled partially in the driver and partially in
mac80211.
In order to do all this correctly, we need to
* keep track of how many frames are pending for each
associated client station (avoid doing it for other
stations to avoid the atomic ops)
* tell mac80211 that we driver-block the PS status
while there are still frames pending on the queues,
and once they are all rejected (due to the dest sta
being in PS) unblock mac80211
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>
Align the format for tx_statistics and rx_statistics debugfs output for
better readability
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>
When issue REPLY_STATISTICS_CMD to uCode, two possible flag
can be set in the configuration flags
bit 0: Clear statistics
0: Do not clear Statistics counters
1: Clear to zero Statistics counters
Allow "clear" parameter to be set from the caller.
Add debugfs file to clear the statistics counters to help monitor and
debug the uCode behavior.
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>
For static power save, the actual intervals are calculated by driver based on
the default table and DTIM flag, then sent to uCode when the scheme
is changed.
Three tables are defined based on DTIM period.
1. DTIM 0 - 2
2. DTIM 3 - 10
3. DTIM > 11
The actual number of DTIM a station may miss may not exceed the
following:
. Only 1 DTIM may be skipped at PI=4 when allowed
. Only 2 DTIMs may be skipped at PI=5 when allowed
. DTIM may be skipped only 5 sec after last activity
. DTIM may be skipped only 30 sec after connection establishment
Only allow user to override the power_level when rf is ready to make sure
power level gets changed upon request.
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>
Power save request is sent from driver to uCode, but there is no
indication from uCode about the current device power save state.
Reading GP_CNTRL register bit 25:24 to show the current power save
status
00: no power save
01: MAC power down
10: PHY power down
11: Error
The uCode could switch in and out of power save mode in the order of
once per 100-300 ms in many cases. The reading here should just be used for
reference on the current uCode power save status. Do not confuse this
reading with the PowerSave set by driver and mac80211.
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>
Adding accumulative statistics counters in iwlwifi driver.
Statistics counters are reported by uCode every beacon interval; but can
be reset by uCode when needed. The accumulative statistics counters is
maintained by driver to keep track of the history of all the counters.
Update the ucode stats files in debugfs to display both latest and
accumulative counters.
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>
Instead of always allocate the max number of tx queue structure,
use dynamic allocation based on the number of queues in device
configuration. With these changes, device does not have to allocate more
memory than the h/w can support.
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>
The sleep_level_override debugfs file is used by the user to request a
static power index instead of the dynamic sleep values. Users are expected
to provide value from 1 to 5 as an index or -1 to disable it.
The problem at the moment is that users can also provide 0 to this file
which, together with the value 1, is translated to index 1. This is
confusing and even more so when users write 0 to sleep_level_override and
then read 1 from it afterwards.
Modify checking to treat 0 as invalid.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The iwlwifi drivers have LED blinking requirements that
mac80211 cannot fulfill due to the use of just a single
LED instead of different ones for TX, RX, radio etc.
Instead, the single LED blinks according to transfers
and is solid on the rest of the time. As such, having
LED class devices registered that mac80211 triggers are
connected to is pointless as we don't use the triggers
anyway.
Remove all the useless code and add hooks into the
driver itself. At the same time, make the LED code
abstracted so the core code that determines blink rate
etc. can be shared between 3945 and agn in iwlcore.
At the same time, the fact that we removed the use of
the mac80211 LED triggers means we can also remove the
IWLWIFI_LEDS Kconfig symbol since the LED support is
now self-contained.
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>
When uCode detects critical temperature it should send "card state
notification" interrupt to driver and then shut itself down to prevent
overheating. There is a race condition where uCode shuts down before it
can deliver the interrupt to driver.
Additional method provided here for driver to enter CT_KILL state based
on temperature reading.
How it works:
Method 1:
If driver receive "card state notification" interrupt from uCode; it
enters "CT_KILL" state immediately
Method 2:
If the last temperature report by Card reach Critical temperature,
driver will send "statistic notification" request to uCode to verify the
temperature reading, if driver can not get reply from uCode within
300ms, driver will enter CT_KILL state automatically.
Method 3:
If the last temperature report by Card did not reach Critical
temperature, but uCode already shut down due to critical temperature.
All the host commands send to uCode will not get process by uCode;
when command queue reach the limit, driver will check the last reported
temperature reading, if it is within pre-defined margin, enter "CT_KILL"
state immediately. In this case, when uCode ready to exit from "CT_KILL" state,
driver need to restart the adapter in order to reset all the queues and
resume normal operation.
One additional issue being address here, when system is in CT_KILL
state, both tx and rx already stopped, but driver still can send host
command to uCode, it will flood the command queue since card was not
responding; adding STATUS_CT_KILL flag to reject enqueue host commands
to uCode if it is in CT_KILL state, when uCode is ready to come out of
CT_KILL, driver will clear the STATUS_CT_KILL bit and allow enqueue the host
commands to uCode to recover from CT_KILL state.
Signed-off-by: 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>
Show version number along with dumping NVM data, the version information
being removed from sysfs, add it back to debugfs to help debugging.
Signed-off-by: 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>
When hardware or uCode problem occurs driver captures significant
information from device to enable debugging. The format of this information
is different between 3945 and 4965 and later devices, yet currently the
3945 uses the 4965 and later format. Fix this by adding a new library call
that is initialized to the correct formatting routine based on device.
This moves the iwlagn event and error log handling back to iwl-agn.c to
make it part of iwlagn module.
Also remove the 3945 sysfs file that triggers dump of event log - there is
already a debugfs file that can do it for all drivers.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Wey-Yi Guy