The synth programming here requires the real centre frequency,
which for HT20 channels is the normal channel, but HT40 is
/not/ the primary channel. Everything else was using 'freq',
which is the correct centre frequency, but the hornet config
was using 'ichan' to do the lookup which was also the primary
channel.
So, modify the HAL call that does the mapping to take a frequency
in MHz and return the channel number.
Tested:
* Carambola 2, AR9331, tested both HT/20 and HT/40 operation.
This is a 2x2 2GHz 802.11n part. It works enough at the moment to
bring up, scan and associate. I haven't started using this as
a day to day AP.
The specifics:
* add honeybee initvals
* add in changes; a mix from the QCA HAL and ath9k;
* fix a bug in AR_SREV_AR9580_10_OR_LATER(), which is only used
for one capability check and we don't even implement it - so it's
a big no-op.
Shady things:
* ath9k has the "platform data" define the 25/40MHz clock.
This HAL .. doesn't. Honeybee gets hard-coded to 25MHz which
it likely shouldn't be. I'll have to go and identify/fix those.
Tested:
* Qualcomm Atheros AP143 reference design board.
Obtained from: Qualcomm Atheros; Linux ath9k
Right now the only way to force a cold reset is:
* The HAL itself detects it's needed, or
* The sysctl, setting all resets to be cold.
Trouble is, cold resets take quite a bit longer than warm resets.
However, there are situations where a cold reset would be nice.
Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results,
etc.
The vendor HAL has a separate method to set the reset reason (which is
how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path
why it occured. This is almost but not quite the same; I may eventually
unify both approaches in the future.
This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC)
and type (eg do COLD.) None of the HAL code uses it yet though; that'll
come later.
It also is a big no-op in each HAL - I need to go teach each of the HALs
about cold/warm reset through this path.
by bus_dmamem_alloc() which creates associated bus_dmamap_t map for us.
When this memory is freed by bus_dmamem_free(), the map is freed as well.
Thus there is no need to free it explicitly by bus_dmamap_destroy(),
which leads to double freeing.
Discussed with: gonzo
Approved by: kib (mentor)
- Emulate Linux mutex API using sx(9) locks with only exclusive operations
instead of mutex(9), in Linux mutexes are sleepable.
- Emulate Linux rwlock_t using rwlock(9) instead of sx(9). rwlock_t
in Linux are spin locks
- Use pmap_quick_enter_page/pmap_quick_remove_page to bounce non-cacheline
aligned head and tail fragments
- Switch from static fragment size to configurable one, newer firmware
passes cache line size as cache_line_size DTB parameter.
With these changes both RPi and RPi2 pass functinal part of vchiq_test
We can't use copyout because destination memory is userland address
in another process but we have reference to respective page so map
the page into kernel address space and copy fragments there
This was off because the net80211 aggregation code was using the same
state pointers for both fast frames and ampdu tx support which led to some
pretty unfortunate panic-y behaviour.
Now that net80211 doesn't panic, let's flip this back on.
It doesn't (yet) do the horrific sounding thing of A-MPDU aggregates
of fast frames; that'll come next. It's a pre-requisite to supporting
AMSDU + AMPDU anyway, which actually speeds things up quite considerably
(think packing lots of little ACK frames into a single AMSDU.)
Tested:
* QCA955x SoC, AP mode
* AR5416, STA mode
* AR9170, STA mode (with local fast frame patches)
Atheros.
Thanks to OpenBSD for providing a driver based on the original
Atheros open source driver circa 2008. This uses the early, pre-carl9170
atheros provided firmware.
It only supports 11bg at the moment. I've not tested it with 11a
(and so the TX rate control logic may be slightly wrong!) so if
you do have the dual-band version of this hardware please do let me know.
Tested:
* AR9170, TP-Link WN821N 2GHz.
TODO:
* Hook this up to a non-module build.
- Add
nvlist_{add,get,take,move,exists,free}_{number,bool,string,nvlist,
descriptor} functions.
- Add support for (un)packing arrays.
- Add the nvl_array_next field to the nvlist structure.
If an array is added by the nvlist_{move,add}_nvlist_array function
this field will contains next element in the array.
- Add the nitems field to the nvpair and nvpair_header structure.
This field contains number of elements in the array.
- Add special flag (NV_FLAG_IN_ARRAY) which is set if nvlist is a part of
an array.
- Add special type (NV_TYPE_NVLIST_ARRAY_NEXT).This type is used only
on packing/unpacking.
- Add new API for traversing arrays (nvlist_get_array_next).
- Add the nvlist_get_pararr function which combines the
nvlist_get_array_next and nvlist_get_parent functions. If nvlist is in
the array it will return next element from array. If nvlist is last
element in array or it isn't in array it will return his
container (parent). This function should simplify traveling over nvlist.
- Add tests for new features.
- Add documentation for new functions.
- Add my copyright.
- Regenerate the sys/cddl/compat/opensolaris/sys/nvpair.h file.
PR: 191083
Reviewed by: allanjude (doc)
Approved by: pjd (mentor)
- the nvlist error is set, or
- the nvlist case ignore flag is not set and there is attend to
add element with duplicated name.
In both cases the nvlist_move_nvpair() function free nvpair structure.
If library will try to unpack a binary blob which contains duplicated
names it will end up with using memory after free.
To prevent that, the nvlist_move_nvpair() function interface is changed
to report about failure and checks are added to the nvpair_xunpack()
function.
Discovered thanks to the american fuzzy lop.
Approved by: pjd (mentor)
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
This is required for (more) correct TDMA support. Without it, the
code tries to calculate the required guard interval based on the
current rate, and since this is an 11n NIC and people try using
11n, it calls ath_hal_computetxtime() on an 11n rate which then
panics.
This doesn't fix TDMA slave mode on AR9300 - it just makes it
have one less bug.
Reported by: Berislav Purgar <bpurgar@gmail.com>
Futex object scopes have been renamed from using their own constants to
simply reusing the existing CLOUDABI_MAP_{PRIVATE,SHARED} flags, as they
are more accurate in this context.
Add support for the <sys/mman.h> functions by wrapping around our own
implementations. There are no kern_*() variants of these system calls,
but we also don't need them in this case. It is sufficient to just call
into the sys_*() functions.
Differential Revision: https://reviews.freebsd.org/D3033
Reviewed by: brooks
