freebsd-skq/sys/dev/iwn/if_iwnvar.h

438 lines
11 KiB
C
Raw Normal View History

/* $FreeBSD$ */
/* $OpenBSD: if_iwnvar.h,v 1.18 2010/04/30 16:06:46 damien Exp $ */
/*-
* Copyright (c) 2013 Cedric GROSS <cg@cgross.info>
* Copyright (c) 2011 Intel Corporation
* Copyright (c) 2007, 2008
* Damien Bergamini <damien.bergamini@free.fr>
* Copyright (c) 2008 Sam Leffler, Errno Consulting
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
enum iwn_rxon_ctx_id {
IWN_RXON_BSS_CTX,
IWN_RXON_PAN_CTX,
IWN_NUM_RXON_CTX
};
struct iwn_pan_slot {
uint16_t time;
uint8_t type;
uint8_t reserved;
} __packed;
struct iwn_pan_params_cmd {
uint16_t flags;
#define IWN_PAN_PARAMS_FLG_SLOTTED_MODE (1 << 3)
uint8_t reserved;
uint8_t num_slots;
struct iwn_pan_slot slots[10];
} __packed;
struct iwn_led_mode
{
uint8_t led_cur_mode;
uint64_t led_cur_bt;
uint64_t led_last_bt;
uint64_t led_cur_tpt;
uint64_t led_last_tpt;
uint64_t led_bt_diff;
int led_cur_time;
int led_last_time;
};
struct iwn_rx_radiotap_header {
struct ieee80211_radiotap_header wr_ihdr;
uint64_t wr_tsft;
uint8_t wr_flags;
uint8_t wr_rate;
uint16_t wr_chan_freq;
uint16_t wr_chan_flags;
int8_t wr_dbm_antsignal;
int8_t wr_dbm_antnoise;
} __packed;
#define IWN_RX_RADIOTAP_PRESENT \
((1 << IEEE80211_RADIOTAP_TSFT) | \
(1 << IEEE80211_RADIOTAP_FLAGS) | \
(1 << IEEE80211_RADIOTAP_RATE) | \
(1 << IEEE80211_RADIOTAP_CHANNEL) | \
(1 << IEEE80211_RADIOTAP_DBM_ANTSIGNAL) | \
(1 << IEEE80211_RADIOTAP_DBM_ANTNOISE))
struct iwn_tx_radiotap_header {
struct ieee80211_radiotap_header wt_ihdr;
uint8_t wt_flags;
uint8_t wt_rate;
uint16_t wt_chan_freq;
uint16_t wt_chan_flags;
} __packed;
#define IWN_TX_RADIOTAP_PRESENT \
((1 << IEEE80211_RADIOTAP_FLAGS) | \
(1 << IEEE80211_RADIOTAP_RATE) | \
(1 << IEEE80211_RADIOTAP_CHANNEL))
struct iwn_dma_info {
bus_dma_tag_t tag;
bus_dmamap_t map;
bus_dma_segment_t seg;
bus_addr_t paddr;
caddr_t vaddr;
bus_size_t size;
};
struct iwn_tx_data {
bus_dmamap_t map;
bus_addr_t cmd_paddr;
bus_addr_t scratch_paddr;
struct mbuf *m;
struct ieee80211_node *ni;
};
struct iwn_tx_ring {
struct iwn_dma_info desc_dma;
struct iwn_dma_info cmd_dma;
struct iwn_tx_desc *desc;
struct iwn_tx_cmd *cmd;
struct iwn_tx_data data[IWN_TX_RING_COUNT];
bus_dma_tag_t data_dmat;
int qid;
int queued;
int cur;
2011-05-08 12:06:12 +00:00
int read;
};
struct iwn_softc;
struct iwn_rx_data {
struct mbuf *m;
bus_dmamap_t map;
};
struct iwn_rx_ring {
struct iwn_dma_info desc_dma;
struct iwn_dma_info stat_dma;
uint32_t *desc;
struct iwn_rx_status *stat;
struct iwn_rx_data data[IWN_RX_RING_COUNT];
bus_dma_tag_t data_dmat;
int cur;
};
struct iwn_node {
struct ieee80211_node ni; /* must be the first */
uint16_t disable_tid;
uint8_t id;
2011-05-08 12:06:12 +00:00
struct {
uint64_t bitmap;
int startidx;
int nframes;
} agg[IEEE80211_TID_SIZE];
};
struct iwn_calib_state {
uint8_t state;
#define IWN_CALIB_STATE_INIT 0
#define IWN_CALIB_STATE_ASSOC 1
#define IWN_CALIB_STATE_RUN 2
u_int nbeacons;
uint32_t noise[3];
uint32_t rssi[3];
uint32_t ofdm_x1;
uint32_t ofdm_mrc_x1;
uint32_t ofdm_x4;
uint32_t ofdm_mrc_x4;
uint32_t cck_x4;
uint32_t cck_mrc_x4;
uint32_t bad_plcp_ofdm;
uint32_t fa_ofdm;
uint32_t bad_plcp_cck;
uint32_t fa_cck;
uint32_t low_fa;
uint32_t bad_plcp_ht;
uint8_t cck_state;
#define IWN_CCK_STATE_INIT 0
#define IWN_CCK_STATE_LOFA 1
#define IWN_CCK_STATE_HIFA 2
uint8_t noise_samples[20];
u_int cur_noise_sample;
uint8_t noise_ref;
uint32_t energy_samples[10];
u_int cur_energy_sample;
uint32_t energy_cck;
};
struct iwn_calib_info {
uint8_t *buf;
u_int len;
};
struct iwn_fw_part {
const uint8_t *text;
uint32_t textsz;
const uint8_t *data;
uint32_t datasz;
};
struct iwn_fw_info {
const uint8_t *data;
size_t size;
struct iwn_fw_part init;
struct iwn_fw_part main;
struct iwn_fw_part boot;
};
struct iwn_ops {
int (*load_firmware)(struct iwn_softc *);
void (*read_eeprom)(struct iwn_softc *);
int (*post_alive)(struct iwn_softc *);
int (*nic_config)(struct iwn_softc *);
void (*update_sched)(struct iwn_softc *, int, int, uint8_t,
uint16_t);
int (*get_temperature)(struct iwn_softc *);
int (*get_rssi)(struct iwn_softc *, struct iwn_rx_stat *);
int (*set_txpower)(struct iwn_softc *,
struct ieee80211_channel *, int);
int (*init_gains)(struct iwn_softc *);
int (*set_gains)(struct iwn_softc *);
int (*add_node)(struct iwn_softc *, struct iwn_node_info *,
int);
void (*tx_done)(struct iwn_softc *, struct iwn_rx_desc *,
struct iwn_rx_data *);
void (*ampdu_tx_start)(struct iwn_softc *,
2011-05-08 12:06:12 +00:00
struct ieee80211_node *, int, uint8_t, uint16_t);
void (*ampdu_tx_stop)(struct iwn_softc *, int, uint8_t,
uint16_t);
};
struct iwn_vap {
struct ieee80211vap iv_vap;
uint8_t iv_ridx;
int (*iv_newstate)(struct ieee80211vap *,
enum ieee80211_state, int);
int ctx;
int beacon_int;
};
#define IWN_VAP(_vap) ((struct iwn_vap *)(_vap))
struct iwn_softc {
device_t sc_dev;
int sc_debug;
struct cdev *sc_cdev;
struct mtx sc_mtx;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com sc_ic;
u_int sc_flags;
#define IWN_FLAG_HAS_OTPROM (1 << 1)
#define IWN_FLAG_CALIB_DONE (1 << 2)
#define IWN_FLAG_USE_ICT (1 << 3)
#define IWN_FLAG_INTERNAL_PA (1 << 4)
#define IWN_FLAG_HAS_11N (1 << 6)
#define IWN_FLAG_ENH_SENS (1 << 7)
#define IWN_FLAG_ADV_BTCOEX (1 << 8)
#define IWN_FLAG_PAN_SUPPORT (1 << 9)
#define IWN_FLAG_BTCOEX (1 << 10)
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
#define IWN_FLAG_RUNNING (1 << 11)
uint8_t hw_type;
/* subdevice_id used to adjust configuration */
uint16_t subdevice_id;
struct iwn_ops ops;
const char *fwname;
const struct iwn_sensitivity_limits
*limits;
int ntxqs;
2011-05-08 12:06:12 +00:00
int firstaggqueue;
int ndmachnls;
uint8_t broadcast_id;
int rxonsz;
int schedsz;
uint32_t fw_text_maxsz;
uint32_t fw_data_maxsz;
uint32_t fwsz;
bus_size_t sched_txfact_addr;
uint32_t reset_noise_gain;
uint32_t noise_gain;
/* TX scheduler rings. */
struct iwn_dma_info sched_dma;
uint16_t *sched;
uint32_t sched_base;
/* "Keep Warm" page. */
struct iwn_dma_info kw_dma;
/* Firmware image. */
const struct firmware *fw_fp;
/* Firmware DMA transfer. */
struct iwn_dma_info fw_dma;
/* ICT table. */
struct iwn_dma_info ict_dma;
uint32_t *ict;
int ict_cur;
/* TX/RX rings. */
struct iwn_tx_ring txq[IWN5000_NTXQUEUES];
struct iwn_rx_ring rxq;
struct resource *mem;
bus_space_tag_t sc_st;
bus_space_handle_t sc_sh;
struct resource *irq;
void *sc_ih;
bus_size_t sc_sz;
int sc_cap_off; /* PCIe Capabilities. */
/* Tasks used by the driver */
struct task sc_reinit_task;
struct task sc_radioon_task;
struct task sc_radiooff_task;
struct task sc_panic_task;
First cut at attempting to buffer frames until we see a beacon. The iwn(4) firmware forgets most of its channel state after an RXON command. This means that any beacons its seen on passive 5GHz channels are forgotten upon an association/authorisation request. This unfortuantely means that 5GHz association almost always fails - the assoc and/or auth frames are dropped with a status of "passive channel, haven't seen a beacon yet." (0x90.) So: * add an xmit queue, global, to buffer frames * modify the xmit path to use the mbuf tag from net80211 to specify raw frame details * buffer xmit frames from both raw and non-raw paths * if a beacon is seen in the RX path, schedule a taskqueue to send said frames and un-buffer things. * flush frames during state change back to INIT, or NIC down/up/detach. This isn't the final shape I'd like this to be in but it certainly is better than 5GHz "not working at all". Tested: * Intel 5100, STA mode (before spilling coffee) * Intel 5300, STA mode (after spilling coffee) Story: * This has been bugging me at work for months, which I just worked around by throwing an ath(4) into my Lenovo T400 cardbus slot. * Our ops director discovered indeed FreeBSD runs well on the Lenovo T420p, except for that pesky 5GHz thing. So now developers also can have a T420p running FreeBSD to do work with. Their #1 feedback to me - "boy it'd be nice if 5GHz wifi worked." * .. then, I was at NANOG but stuck with 5GHz only wifi and no ath(4) NIC to put in a laptop - and I snapped. Thus, the reason this is actually work related. MFC after: 2 weeks Sponsored by: Norse Corp, Inc.
2015-06-19 01:44:17 +00:00
struct task sc_xmit_task;
/* Taskqueue */
struct taskqueue *sc_tq;
/* Calibration information */
struct callout calib_to;
int calib_cnt;
struct iwn_calib_state calib;
int last_calib_ticks;
struct callout watchdog_to;
struct iwn_fw_info fw;
struct iwn_calib_info calibcmd[IWN5000_PHY_CALIB_MAX_RESULT];
uint32_t errptr;
struct iwn_rx_stat last_rx_stat;
int last_rx_valid;
struct iwn_ucode_info ucode_info;
struct iwn_rxon rx_on[IWN_NUM_RXON_CTX];
struct iwn_rxon *rxon;
int ctx;
struct ieee80211vap *ivap[IWN_NUM_RXON_CTX];
/* General statistics */
/*
* The statistics are reset after each channel
* change. So it may be zeroed after things like
* a background scan.
*
* So for now, this is just a cheap hack to
* expose the last received statistics dump
* via an ioctl(). Later versions of this
* could expose the last 'n' messages, or just
* provide a pipeline for the firmware responses
* via something like BPF.
*/
struct iwn_stats last_stat;
int last_stat_valid;
uint8_t uc_scan_progress;
uint32_t rawtemp;
int temp;
int noise;
uint32_t qfullmsk;
uint32_t prom_base;
struct iwn4965_eeprom_band
bands[IWN_NBANDS];
struct iwn_eeprom_chan eeprom_channels[IWN_NBANDS][IWN_MAX_CHAN_PER_BAND];
uint16_t rfcfg;
uint8_t calib_ver;
char eeprom_domain[4];
uint32_t eeprom_crystal;
int16_t eeprom_temp;
int16_t eeprom_temp_high;
int16_t eeprom_voltage;
int8_t maxpwr2GHz;
int8_t maxpwr5GHz;
int8_t maxpwr[IEEE80211_CHAN_MAX];
uint32_t tlv_feature_flags;
int32_t temp_off;
uint32_t int_mask;
uint8_t ntxchains;
uint8_t nrxchains;
uint8_t txchainmask;
uint8_t rxchainmask;
uint8_t chainmask;
int sc_tx_timer;
int sc_scan_timer;
Overhaul the iwn(4) scan infrastructure to be slightly more "correct" for these chipsets. * Correctly set the active/passive flag in the scan request - this is NOT a "is the channel active|passive"; it's to do with whether we have an SSID to actively scan for or not. The firmware takes care of the active/passive setup of the channel. * Calculate the active/passive dwell time based on the beacon interval and the channel mode, rather than using a hard coded value. * For now, hardcode the scan service_time. It's defined as: 31:22 - number of beacon intervals to come back onto the home channel for; 0:21 - time (microseconds) to come back onto the home channel for. When doing an active scan when the NIC is active (whether we're associated or not - it only matters if we've setup the NIC to a destination or not) this determines how much time to stay on the home channel for when scanning. We can tune this based on the amount of active traffic. For now it's 4 beacon intervals and 100 microseconds. * Fix the "good crc threshold" setting. It differs based on the NIC firmware. Some older firmware required a workaround; the later firmware instead treats the field as a flag. * Enforce that we are not sending a scan command if one is already pending. Any time this is done is a bug and it absolutely needs to be fixed - so be very loud. * Add the SCAN flag to a few debug messages that are scan related but only occuring under STATE. Now, this does get noisy when you're scanning in an actively busy 2GHz network as the firmware (for reason I don't quite yet understand) seems hell bent on staying on some passive channels longer than it should. However, it should eventually recover and complete the scan. This is a work in progress; please let me know if things get stuck or if things improve! Tested: * intel centrino 2200 * intel centrino 2230 * intel 6200 * intel 5100 * intel 4965 (gets upset, but that's a known issue) Obtained from: linux iwlwifi
2013-12-02 03:59:45 +00:00
/* Are we doing a scan? */
int sc_is_scanning;
First cut at attempting to buffer frames until we see a beacon. The iwn(4) firmware forgets most of its channel state after an RXON command. This means that any beacons its seen on passive 5GHz channels are forgotten upon an association/authorisation request. This unfortuantely means that 5GHz association almost always fails - the assoc and/or auth frames are dropped with a status of "passive channel, haven't seen a beacon yet." (0x90.) So: * add an xmit queue, global, to buffer frames * modify the xmit path to use the mbuf tag from net80211 to specify raw frame details * buffer xmit frames from both raw and non-raw paths * if a beacon is seen in the RX path, schedule a taskqueue to send said frames and un-buffer things. * flush frames during state change back to INIT, or NIC down/up/detach. This isn't the final shape I'd like this to be in but it certainly is better than 5GHz "not working at all". Tested: * Intel 5100, STA mode (before spilling coffee) * Intel 5300, STA mode (after spilling coffee) Story: * This has been bugging me at work for months, which I just worked around by throwing an ath(4) into my Lenovo T400 cardbus slot. * Our ops director discovered indeed FreeBSD runs well on the Lenovo T420p, except for that pesky 5GHz thing. So now developers also can have a T420p running FreeBSD to do work with. Their #1 feedback to me - "boy it'd be nice if 5GHz wifi worked." * .. then, I was at NANOG but stuck with 5GHz only wifi and no ath(4) NIC to put in a laptop - and I snapped. Thus, the reason this is actually work related. MFC after: 2 weeks Sponsored by: Norse Corp, Inc.
2015-06-19 01:44:17 +00:00
/* Are we waiting for a beacon before xmit? */
int sc_beacon_wait;
2011-05-08 12:06:12 +00:00
struct ieee80211_tx_ampdu *qid2tap[IWN5000_NTXQUEUES];
2011-05-08 11:58:23 +00:00
int (*sc_ampdu_rx_start)(struct ieee80211_node *,
struct ieee80211_rx_ampdu *, int, int, int);
void (*sc_ampdu_rx_stop)(struct ieee80211_node *,
struct ieee80211_rx_ampdu *);
2011-05-08 12:06:12 +00:00
int (*sc_addba_request)(struct ieee80211_node *,
struct ieee80211_tx_ampdu *, int, int, int);
int (*sc_addba_response)(struct ieee80211_node *,
struct ieee80211_tx_ampdu *, int, int, int);
void (*sc_addba_stop)(struct ieee80211_node *,
struct ieee80211_tx_ampdu *);
struct iwn_led_mode sc_led;
2011-05-08 11:58:23 +00:00
struct iwn_rx_radiotap_header sc_rxtap;
struct iwn_tx_radiotap_header sc_txtap;
/* The power save level originally configured by user */
int desired_pwrsave_level;
/*
* The current power save level, this may differ from the
* configured value due to thermal throttling etc.
*/
int current_pwrsave_level;
/* For specific params */
const struct iwn_base_params *base_params;
Fix antenna configuration, microcode version checks and rate selection in preparation for the 5300 3x3 NIC. During this particular adventure, I did indeed discover that a whole swath of things made little to no sense. Those included, and are fixed here: * A lot of the antenna configuration bits assume the NIC has two receive chains. That's blatantly untrue for NICs that don't. * There was some disconnect between the antenna configuration when forming a PLCP rate DWORD (which includes the transmit antenna configuration), separate to the link quality antenna configuration. So now there's helper functions to return which antenna configurations to use and those are used wherever an antenna config is required. * The 5300 does up to three stream TX/RX (so MCS0->23), however the link quality table has only 16 slots. This means all of the rate entries are .. well, dual-stream rates. If this is the case, the "last MIMO" parameter can't be 16 or it panics the firmware. Set it to 15. * .. and since yes it has 16 slots, it only would try retransmitting from MCS8->MCS23, which can be quite .. terrible. Hard-code the last two retry slots to be the lowest configured rate. * I noticed some transmit configuration command stuff is different based on firmware API version, so I lifted that code from Linux. * Add / augment some more logging to make it easier to capture this stuff. Now, 3x3 is still terrible because the link quality configuration is plainly not good enough. I'll have to think about that. However, the original goal of this - 3x3 operation on the Intel 5300 NIC - actually worked. There are also rate control bugs in the way this driver handles notifying the net80211 rate control code when AMPDU is enabled. It always steps the rate up to the maximum rate possible - and this eventually ends in much sadness. I'll fix that later. As a side note - 2GHz HT40 now works on all the NICs I have tested. As a second side note - this exposed some bad 3x3 behaviour in the ath(4) rate control code where it starts off at a 3-stream rate and doesn't downgrade quickly enough. This makes the initial dhcp exchange take a long time. I'll fix the ath(4) rate code to start at a low fixed 1x1 MCS rate and step up if everything works out. Tested: * Intel 2200 * Intel 2230 * Intel 5300 * Intel 5100 * Intel 6205 * Intel 100 TODO: * Test the other NICs more thoroughly! Thank you to Michael Kosarev <russiane39@gmail.com> for donating the Intel 5300 NIC and pestering me about it since last year to try and make it all work.
2014-08-28 03:18:27 +00:00
#define IWN_UCODE_API(ver) (((ver) & 0x0000FF00) >> 8)
uint32_t ucode_rev;
First cut at attempting to buffer frames until we see a beacon. The iwn(4) firmware forgets most of its channel state after an RXON command. This means that any beacons its seen on passive 5GHz channels are forgotten upon an association/authorisation request. This unfortuantely means that 5GHz association almost always fails - the assoc and/or auth frames are dropped with a status of "passive channel, haven't seen a beacon yet." (0x90.) So: * add an xmit queue, global, to buffer frames * modify the xmit path to use the mbuf tag from net80211 to specify raw frame details * buffer xmit frames from both raw and non-raw paths * if a beacon is seen in the RX path, schedule a taskqueue to send said frames and un-buffer things. * flush frames during state change back to INIT, or NIC down/up/detach. This isn't the final shape I'd like this to be in but it certainly is better than 5GHz "not working at all". Tested: * Intel 5100, STA mode (before spilling coffee) * Intel 5300, STA mode (after spilling coffee) Story: * This has been bugging me at work for months, which I just worked around by throwing an ath(4) into my Lenovo T400 cardbus slot. * Our ops director discovered indeed FreeBSD runs well on the Lenovo T420p, except for that pesky 5GHz thing. So now developers also can have a T420p running FreeBSD to do work with. Their #1 feedback to me - "boy it'd be nice if 5GHz wifi worked." * .. then, I was at NANOG but stuck with 5GHz only wifi and no ath(4) NIC to put in a laptop - and I snapped. Thus, the reason this is actually work related. MFC after: 2 weeks Sponsored by: Norse Corp, Inc.
2015-06-19 01:44:17 +00:00
/*
* Global queue for queuing xmit frames
* when we can't yet transmit (eg raw
* frames whilst waiting for beacons.)
*/
struct mbufq sc_xmit_queue;
};
#define IWN_LOCK_INIT(_sc) \
mtx_init(&(_sc)->sc_mtx, device_get_nameunit((_sc)->sc_dev), \
MTX_NETWORK_LOCK, MTX_DEF)
#define IWN_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx)
#define IWN_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->sc_mtx, MA_OWNED)
#define IWN_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx)
#define IWN_LOCK_DESTROY(_sc) mtx_destroy(&(_sc)->sc_mtx)