According to Intel Wimax i3200, i5x50 and i6x50 device specification
documents, the maximum number of payloads per message can be up to 60.
Increasing the number of payloads to 60 per message helps to
accommodate smaller payloads in a single transaction. This patch
increases the maximum number of payloads from 12 to 60 per message.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
This patch makes sure whenever tx_setup() is invoked during driver
initialization or device reset where TX FIFO is released and re-allocated,
the indices tx_in, tx_out, tx_msg_size, tx_sequence, tx_msg are properly
initialized.
When a device reset happens and the TX FIFO is released/re-allocated,
a new block of memory may be allocated for the TX FIFO, therefore tx_msg
should be cleared so that no any TX threads (tx_worker, tx) would access
to the out-of-date addresses.
Also, the TX threads use tx_in and tx_out to decide where to put the new
host-to-device messages and from where to copy them to the device HW FIFO,
these indices have to be cleared so after the TX FIFO is re-allocated during
the reset, the indices both refer to the head of the FIFO, ie. a new start.
The same rational applies to tx_msg_size and tx_sequence.
To protect the indices from being accessed by multiple threads simultaneously,
the lock tx_lock has to be obtained before the initializations and released
afterwards.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
When bus_setup fails in i2400m_post_reset(), it falls to the error path handler
"error_bus_setup:" which includes unlock the mutext. However, we didn't ever
try to the obtain the lock when running bus_setup.
The patch is to fix the misplaced error path handler "error_bus_setup:".
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
This patch adds an error recovery mechanism on TX path.
The intention is to bring back the device to some known state
whenever TX sees -110 (-ETIMEOUT) on copying the data to the HW FIFO.
The TX failure could mean a device bus stuck or function stuck, so
the current error recovery implementation is to trigger a bus reset
and expect this can bring back the device.
Since the TX work is done in a thread context, there may be a queue of TX works
already that all hit the -ETIMEOUT error condition because the device has
somewhat stuck already. We don't want any consecutive bus resets simply because
multiple TX works in the queue all hit the same device erratum, the flag
"error_recovery" is introduced to denote if we are ready for taking any
error recovery. See @error_recovery doc in i2400m.h.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
The problem is only seen on SDIO interface since on USB, a bus reset would
really re-probe the driver, but on SDIO interface, a bus reset will not
re-enumerate the SDIO bus, so no driver re-probe is happening. Therefore,
on SDIO interface, the reset event should be still detected and handled by
dev_reset_handle().
Problem description:
Whenever a reboot barker is received during operational mode (i2400m->boot_mode == 0),
dev_reset_handle() is invoked to handle that function reset event.
dev_reset_handle() then sets the flag i2400m->boot_mode to 1 indicating the device is
back to bootmode before proceeding to dev_stop() and dev_start().
If dev_start() returns failure, a bus reset is triggered by dev_reset_handle().
The flag i2400m->boot_mode then remains 1 when the second reboot barker arrives.
However the interrupt service routine i2400ms_rx() instead of invoking dev_reset_handle()
to handle that reset event, it filters out that boot event to bootmode because it sees
the flag i2400m->boot_mode equal to 1.
The fix:
Maintain the flag i2400m->boot_mode within dev_reset_handle() and set the flag
i2400m->boot_mode to 1 when entering dev_reset_handle(). It remains 1
until the dev_reset_handle() issues a bus reset. ie: the bus reset is
taking place just like it happens for the first time during operational mode.
To denote the actual device state and the state we expect, a flag i2400m->alive
is introduced in addition to the existing flag i2400m->updown.
It's maintained with the same way for i2400m->updown but instead of reflecting
the actual state like i2400m->updown does, i2400m->alive maintains the state
we expect. i2400m->alive is set 1 just like whenever i2400m->updown is set 1.
Yet i2400m->alive remains 1 since we expect the device to be up all the time
until the driver is removed. See the doc for @alive in i2400m.h.
An enumeration I2400M_BUS_RESET_RETRIES is added to define the maximum number of
bus resets that a device reboot can retry.
A counter i2400m->bus_reset_retries is added to track how many bus resets
have been retried in one device reboot. If I2400M_BUS_RESET_RETRIES bus resets
were retried in this boot, we give up any further retrying so the device would enter
low power state. The counter i2400m->bus_reset_retries is incremented whenever
dev_reset_handle() is issuing a bus reset and is cleared to 0 when dev_start() is
successfully done, ie: a successful reboot.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
This fix is to correct order of the handlers in the error path
of dev_start(). When i2400m_firmware_check fails, all the works done
before it should be released or cleared.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
The race condition happens when the TX queue is accessed by
the TX work while the same TX queue is being destroyed because
a bus reset is triggered either by debugfs entry or simply
by failing waking up the device from WiMAX IDLE mode.
This fix is to prevent the TX queue from being accessed by
multiple threads
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
This patch increases the Tx buffer size so as to accommodate 12 payloads
of 1408 (1400 MTU 16 bytes aligned). Currently Tx buffer is 32 KiB which
is insufficient to accommodate 12 payloads of 1408 size.
This patch
- increases I2400M_TX_BUF_SIZE from 32KiB to 64KiB
- Adds a BUILD_BUG_ON if the calculated buffer size based
on the given MTU exceeds the I2400M_TX_BUF_SIZE.
Below is how we calculate the size of the Tx buffer.
Payload + 4 bytes prefix for each payload (1400 MTU 16 bytes boundary aligned)
= (1408 + sizeof(struct i2400m_pl_data_hdr)) * I2400M_TX_PLD_MAX
Adding 16 byte message header = + sizeof(struct i2400m_msg_hdr)
Aligning to 256 byte boundary
Total Tx buffer = (((((1408 + sizeof(struct i2400m_pl_data_hdr))
* I2400M_TX_PLD_MAX )+ sizeof(struct i2400m_msg_hdr))
/ 256) + 1) * 256 * 2
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
This patch moves I2400M_MAX_MTU enum defined in netdev.c to i2400m.h.
Follow up changes will make use of this value in other location,
thus requiring it to be moved to a global header file i2400m.h.
Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
i2400m_tx() routine was returning -ESHUTDOWN even when there was no Tx buffer
available. This patch fixes the i2400m_tx() to return -ESHUTDOWN only when
the device is down(i2400m->tx_buf is NULL) and also to return -ENOSPC
when there is no Tx buffer. Error seen in the kernel log.
kernel: i2400m_sdio mmc0:0001:1: can't send message 0x5606: -108
kernel: i2400m_sdio mmc0:0001:1: Failed to issue 'Enter power save'command: -108
Signed-off-by: Prasanna S.Panchamukhi <prasannax.s.panchamukhi@intel.com>
These changes include:
* For PAPRD, the TXRF3.capdiv5G, TXRF3.rdiv5G and TXRF3.rdiv2G
are set to 0x0, the TXRF6.capdiv2G is set to 0x2 for all
three chains.
* The d2cas5G/d3cas5G/d4cas5G was updated to 4/4/4 in lowest_ob_db
Tx gain table.
* To improve DPPM, three parameters were updated (Released from Madhan):
1. RANGE_OSDAC is set to 0x1 for 2G, 0x0 for 5G
2. offsetC1 is set to 0xc
3. inv_clk320_adc is set to 0x1
* To reduce PHY error(from spur), cycpwr_thr1 and cycpwr_thr1_ext
are increased to 0x8 at 2G.
* The 2G Rx gain tables are updated with mixer gain setting 3,1,0.
The new checksums yield:
initvals -f ar9003
0x00000000c2bfa7d5 ar9300_2p0_radio_postamble
0x00000000ada2b114 ar9300Modes_lowest_ob_db_tx_gain_table_2p0
0x00000000e0bc2c84 ar9300Modes_fast_clock_2p0
0x00000000056eaf74 ar9300_2p0_radio_core
0x0000000000000000 ar9300Common_rx_gain_table_merlin_2p0
0x0000000078658fb5 ar9300_2p0_mac_postamble
0x0000000023235333 ar9300_2p0_soc_postamble
0x0000000054d41904 ar9200_merlin_2p0_radio_core
0x00000000748572cf ar9300_2p0_baseband_postamble
0x000000009aa5a0a4 ar9300_2p0_baseband_core
0x000000003df9a326 ar9300Modes_high_power_tx_gain_table_2p0
0x000000001cfba124 ar9300Modes_high_ob_db_tx_gain_table_2p0
0x0000000011302700 ar9300Common_rx_gain_table_2p0
0x00000000e3eab114 ar9300Modes_low_ob_db_tx_gain_table_2p0
0x00000000c9d66d40 ar9300_2p0_mac_core
0x000000001e1d0800 ar9300Common_wo_xlna_rx_gain_table_2p0
0x00000000a0c54980 ar9300_2p0_soc_preamble
0x00000000292e2544 ar9300PciePhy_pll_on_clkreq_disable_L1_2p0
0x000000002d3e2544 ar9300PciePhy_clkreq_enable_L1_2p0
0x00000000293e2544 ar9300PciePhy_clkreq_disable_L1_2p0
Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jumbo frames are not supported, and if they are seen it is likely
a bogus frame so just silently discard them instead of warning on
them all time. Also, instead of dropping them immediately though
move the check *after* we check for all sort of frame errors. This
should enable us to discard these frames if the hardware picks
other bogus items first. Lets see if we still get those jumbo
counters increasing still with this.
Jumbo frames would happen if we tell hardware we can support
a small 802.11 chunks of DMA'd frame, hardware would split RX'd
frames into parts and we'd have to reconstruct them in software.
This is done with USB due to the bulk size but with ath5k we
already provide a good limit to hardware and this should not be
happening.
This is reported quite often and if it fills the logs then this
needs to be addressed and to avoid spurious reports.
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The goto and the break are equivelent. I removed the goto in memory of
Edsger Dijkstra who famously hated gotos and who would have been eighty
years old next Tuesday.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The "(wl == NULL)" test doesn't work here because "wl" is always
non-null. The intent of the code is to return if the interface
was not supported by the driver.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
net: Fix FDDI and TR config checks in ipv4 arp and LLC.
IPv4: unresolved multicast route cleanup
mac80211: remove association work when processing deauth request
ar9170: wait for asynchronous firmware loading
ipv4: udp: fix short packet and bad checksum logging
phy: Fix initialization in micrel driver.
sctp: Fix a race between ICMP protocol unreachable and connect()
veth: Dont kfree_skb() after dev_forward_skb()
IPv6: fix IPV6_RECVERR handling of locally-generated errors
net/gianfar: drop recycled skbs on MTU change
iwlwifi: work around passive scan issue
During a hw restart, mac80211 will attempt to
reconfigure all stations. Currently, that fails
and leads to warnings because we still have the
stations marked active. Therefore, clear all
stations when doing down.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Remove the check before invoking iwl_set_ht_add_station(),
since neither of the conditions in this check makes sense,
as either we pass in a NULL ht_info (first branch) or in
the IBSS case an ht_info with ht_enabled=false.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
This function is now only used for the special
IBSS BSSID station, so rename it to indicate
this. The new name is iwl_add_bssid_station.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
4965 code is the only thing that now still
needs iwl_find_station(), so move it there
and make it static. Everything else can
rely on the station data passed by mac80211.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
With the station ID being stored in the
station struct, which mac80211 gives us
for TKIP phase 1 key updates, we can also
remove the use of iwl_find_station() in
that code path.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
With the station ID being stored in the
station struct, which mac80211 gives us
for aggregation callbacks, we can also
remove the use of iwl_find_station() in
those code paths.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Since we now store the station ID in each station
struct, many places need not look at the station
table any more since they can just pull the station
ID out of the struct. Remove iwl_get_sta_id() and
use iwl_sta_id() instead as appropriate.
This reduces the amount of code needed to find the
right station significantly, and works since
mac80211 passes the station only after it has been
fully initialised, ie. even if TX races with
station addition it will only be passed to TX once
the addition is complete.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
In places where the station struct is
guaranteed to exist (presumably), use
this helper to get the station ID out
of it (and warn if there's no station
struct after all).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
mac80211 allows us to store private data per
station, so put the station ID there. This
allows us to avoid the station ID lookup when
removing regular stations. To also be able to
avoid the lookup to remove the special IBSS
BSSID station, track its ID in the per-vif
private data.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
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>
When station is using an HT channel to communicate to AP and communication
is lost then driver will first be notified that channel is not an HT
channel anymore before AP station is removed. A consequence of that is that
the driver will know that it is not communicating on HT anymore, but the
rate scaling table is still under the impression it is operating in HT. Any
time after driver has been notified channel is not HT anymore there will
thus be a firmware SYSASSERT when the current active LQ command is sent.
A workaround for this issue is to not send a LQ command in the short time between
being notified channel is not HT anymore and rate scaling table being
updated.
This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2173
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Currently, the broadcast station is managed along
with the interface type, rather than always being
present. That leads to a bug with injection -- it
is currently not possible to inject frames when
the only virtual interface is a monitor, because
in that the required broadcast station is missing.
Additionally, allocating and deallocating the
broadcast station's LQ all the time is wasteful,
and the code to support this is fairly complex.
So this changes completely the way we manage the
broadcast station. Rather than manage it along
with any interface, we now allocate it when we
bring the device up, and remove it again when we
bring the device down. When we bring the device
up, we don't immediately program the broadcast
station into it, instead we just mark it active
and rely on the next restore cycle to upload it
to the device. This works because an unassociated
RXON is always required at least once to set up
device parameters, which implies a reprogramming
of stations into the device.
As we now manage all stations properly, there no
longer is a need for forcing a clearing of them
via iwl_clear_ucode_stations(), which can become
a lot simpler.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Rename iwl_sta_init_lq to iwl_sta_alloc_lq and
move sending it out into the caller.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
The "is_ap" argument to iwl_sta_init_lq is never true,
so it and the corresponding code can be removed. However,
it needs to have the station ID because it is also used
for the IBSS BSSID station, and that doesn't have the
broadcast ID.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
The bssid member of struct iwl_priv is now
only used by 3945 code, so note that. It
shouldn't be used by any other code in the
future.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Pass the virtual interface pointer to iwl_ht_conf()
so it doesn't need to rely on iw_mode and other
global variables.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
This check is not useful, since we now no
longer dereference priv->vif at this spot.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Most of the TX aggregation handling can be passed
the virtual interface directly instead of having
to rely on priv->vif.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Rather than keeping every bit of information
around in priv and the virtual interface, add
a virtual interface to many functions and use
the information directly from it.
This removes beacon_int, assoc_capability and
assoc_id from struct iwl_priv.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Since iwl_configure_filter can now sleep since
the mac80211 callback was changed, we can now
apply filter flags changes directly.
Also, while at it, make the code a bit more
generic with a local macro. There's no need
to check changed_flags since we apply all at
the same time anyway.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
This function is only needed by 4965, so
it need not be in core code and can be
made static.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Add plcp error checking for 3945. After threshold of plcp
is reached , it resets the radio
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
The old firmware file type does not allow indicating
any firmware capabilities, which we frequently want
to make things easier.
This implements a new firmware type that is based on
a TLV structure, and adds a TLV for the maximum length
of probe requests in scans.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Currently the first four bytes in a firmware file
indicate the major, minor and api versions as well
as the serial number. These combined can never be
zero, so we can use that special case for a new,
future, file format.
This patch simply shuffles the code and prepares
for that new format.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
It doesn't belong into firmware loading,
it should instead be printed after loading
the EEPROM.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
AGN devices all use the same ucode operations,
except for 4965, because 4965 uses only v1 file
headers.
Therefore, we can remove all the indirection
we have here and just code the API distinction
in place, with a small special case for 4965.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
