if_iwm - GC some dead code, left by a partially applied OpenBSD change.
Taken-From: OpenBSD (if_iwm.c r1.69)
Submitted by: Imre Vadasz <imre@vdsz.com>
Obtained from: DragonflyBSD git 07dfed32ea39b980b0b80d27ff938e7c3ca4c0b5
The Linux driver sets the rate_n_flags regardless of whether it's being
sent using firmware rate control or local rate control. This includes
the antenna configuration.
Thanks to Kyle Evans <kevans91@ksu.edu> for pointing this out to me
and doing some investigation/testing on his end.
Tested:
* Intel 7260 STA, 2G and 5G networks
Introduced in r298594. There is no path before the 'vap == NULL' check where
vap is not already dereferenced.
Reported by: Coverity
CID: 1354979
Sponsored by: EMC / Isilon Storage Division
I'm seeing 5GHz association work but data not work until the rate drops,
so I need way more information about what's being programmed into the
transmit descriptors.
Tested:
* 7260AC, STA mode
Always print out the firmware panic info before restarting; don't
put it behind IWM_DEBUG.
Submitted by: bapt
Differential Revision: https://reviews.freebsd.org/D6081
The iwm firmware has separate commands for add, modify and delete for
various things (mac, phy context, etc.) The openbsd driver has a habit
of just completely resetting the NIC each time, which is technically
mostly okay (as long as the reset doesn't actually fail!) but it means
a lot of the code is doing ADD when it should do MODIFY.
The firmware responds in kind - it just asserts.
This fixes auth attempts that occur after the NIC has been already
configured.
(I'm sure there are more instances of this!)
Tested:
iwm0: <Intel Dual Band Wireless AC 7260> mem 0xf1400000-0xf1401fff irq 17 at device 0.0 on pci2
iwm0: revision: 0x140, firmware 25.228 (API ver. 9)
.. STA mode.
Submitted by: Masachika ISHIZUKA <ish@amail.plala.or.jp>
we want to use it.
The rate table was being initialised in low->high, but the link quality
table was being initialised high->low. So, when we did a lookup, we
would get the indexes wrong.
This started by a patch from dragonflybsd which reversed how the ni->in_ridx[]
array is being used; I'd rather it all be consistent. So, this is consistent.
Inspired by: what I did to iwn(4) a while ago
Inspired by: DragonflyBSD; <imre@vdsz.com>
This optimization is not proper (and causes kernel panic),
since driver checks fw_status to optimize away parsing stage
if it was already done.
Reported by: dchagin
iwn(4) / wpi(4) works in the same way
(read_firmware() -> hw_init() -> firmware_put())
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4766
- Simplify defragmentation code.
- Use proper number of dma segments for data.
Approved by: adrian (mentor)
Obtained from: DragonFlyBSD (mostly)
Differential Revision: https://reviews.freebsd.org/D4754
- Change order of data in if_iwmvar.h
(like it is in other drivers: defines, data structures,
vap/node structures, softc struct and locks); use indentation.
- Fix IWM_LOCK(_sc) / IWM_UNLOCK(_sc) macro.
- Add IWM_LOCK_INIT / DESTROY(sc) + fix mtx_init() usage.
- Wrap iwm_node casts into IWM_NODE() macro.
- Drop some fields:
* wt_hwqueue from Tx radiotap header;
* macaddr[6] from iwm_vap;
Approved by: adrian
Differential Revision: https://reviews.freebsd.org/D4753
This doesn't free the mbuf upon error; the driver ic_raw_xmit method is still
doing that.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3774
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.
There are still several bugs, but I've been using it for a while now.
Thanks to all the testers and to Adrian for his help with this
driver.
This driver isn't connected to the build yet, but it will be soon.
There's no MFC planned because the driver isn't very stable yet.
Reviewed by: adrian
Obtained from: https://github.com/rpaulo/iwm
Tested by: adrian, gjb, dumbbell (others that I forgot).
Relnotes: yes
