| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
now. The following upstream commits are reverted from hwregs.c:
https://github.com/acpica/acpica/commit/96ece05
https://github.com/acpica/acpica/commit/3d8583a
https://github.com/acpica/acpica/commit/48eea5e
https://github.com/acpica/acpica/commit/0a212c3
https://github.com/acpica/acpica/commit/41f6aef
https://github.com/acpica/acpica/commit/26434b9
https://github.com/acpica/acpica/commit/c23034a
https://github.com/acpica/acpica/commit/c49a751
Note this commit will be reverted when the upstream fixes the code properly.
|
| |
|
|\ |
|
| |
| |
| |
| | |
Submitted by: kevlo
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
ichan is only used if AH_DEBUG_ALQ if defined
Pointyhat to: adrian
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Sorry y'all.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| |
| |
| |
| | |
Obtained from: 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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| | |
logical negation when used in this fashion.
Tested:
* compile only
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 TDMA slave mode.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\ \
| |/ |
|
| |
| |
| |
| | |
under HALDEBUG().
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| | |
- Update GUIDs for new NFIT tables.
- Fix ill-formed GUID strings for NFIT tables.
- Fix a possible fault when performing a UUID search.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This dramatically improves RX sensitivity and behaviour on the
AR9331 hardware I have, including the Carambola 2.
Tested:
* AR9331, Carambola 2 board
Submitted by: Zilvinas Valinskas <zilvinas.valinskas@gmail.com>
|
|\ \
| |/ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
the ar9300_* definitions.
.. which of course don't match, and athstats was reading garbage ANI
data.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is used by the 'athsurvey' command to print out channel survey
statistics - % busy times transmit, receive and airtime.
It's as buggy and incomplete as the rest of the HAL survey support -
notably, tying into the ANI code to read channel stats and occasionally
getting garbage counters isn't very nice. It also doesn't (yet!) get
channel survey information during a scan. But it's good enough for
basic air-time debugging, which is why I'm committing it in this state.
Tested:
* AR9380, STA mode
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
path.
* For now there's no exposed control over classic / LNA antenna diversity,
so just stub them out. Adding this will take quite a bit of time.
* Add a function to fetch the CTS timeout.
PR: kern/198558
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I don't like having it in this function; I may migrate it to ar9300_freebsd.c
at some point to keep the HAL code pollution down.
This allows ANI to be disabled via a sysctl.
Tested:
* AR9331, STA/TDMA modes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a custom FreeBSD HAL method that is used by the TDMA code
to program the beacon timers directly without any guesswork/assumptions
by the HAL.
This brings up basic TDMA master/slave support on the AR9380 HAL,
however there are other issues preventing it from being stable.
(I'm seeing beacon interval instability, which may be due to
busy 2GHz air, but also may be due to some HAL configuration
issues with regards to ANI, or hardware timer programming, etc.)
Tested:
* AR9331 (Carambola2), STA, AP, adhoc and TDMA master mode.
|
| |
| |
| |
| |
| |
| | |
It trips up gcc builds.
Pointy-hat-from: jenkins, kib
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The QCA9565 can have RFKILL on GPIO Pin 11, and thus we need to configure
it up correctly or the NIC may not function.
I'm not sure why the AR9382 can't use GPIO 8 / GPIO 11 ; it's likely
hooked up to some external LNA or filter. The real solution is to
make it only block pin 8 / pin 11 for AR9382, but the AR9382 probes
like an AR9380. Sigh.
Submitted by: Anthony Jenkins <scoobi_doo@yahoo.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I've been sitting on this for a year or so now; I've finally
tested it on enough devices to be reasonably sure it won't
cause too much drama. But, if you see issues, please email me.
Tested (all STA mode):
PCIe:
* AR9380
* AR9390
* AR9580
* AR9462
* AR9485
SoC:
* QCA9550
* AR9331
* AR9342
|
| |
| |
| |
| | |
Committed over the D-Link DWA-525 rev A2 on amd64 with WPA.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
hw.x2apic_enable tunable allows disabling it from the loader prompt.
To closely repeat effects of the uncached memory ops when accessing
registers in the xAPIC mode, the x2APIC writes to MSRs are preceeded
by mfence, except for the EOI notifications. This is probably too
strict, only ICR writes to send IPI require serialization to ensure
that other CPUs see the previous actions when IPI is delivered. This
may be changed later.
In vmm justreturn IPI handler, call doreti_iret instead of doing iretd
inline, to handle corner conditions.
Note that the patch only switches LAPICs into x2APIC mode. It does not
enables FreeBSD to support > 255 CPUs, which requires parsing x2APIC
MADT entries and doing interrupts remapping, but is the required step
on the way.
Reviewed by: neel
Tested by: pho (real hardware), neel (on bhyve)
Discussed with: jhb, grehan
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the ia_array field of struct ar9300_ini_array const, and removing the
const-dropping casts. No functional change.
Reviewed by: adrian
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D1725
|
| |
| |
| |
| | |
(It's only an issue in AP/adhoc modes. But, still. Grr.)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
to zero - TX drops are otherwise reported.
Tested:
* AR9462 (WB222), STA mode
Obtained from: Linux ath9k
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
AR9462/AR9565.
This and some upcoming changes to the HAL for these chips should
address some of the signal sensitivity reported by users.
Tested:
* AR9462 (WB222), STA mode
Obtained from: Linux ath9k
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
AR9565 (Aphrodite.) These need to use the MCI routines, not
the legacy 2-wire / 3-wire bluetooth coexistence methods.
Tested:
* AR9462 (WB222); STA mode
|
| |
| |
| |
| |
| |
| | |
Tested:
* AR9462 (WB222)
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
images into the kernel as currently included into iwn6000g2{a,b}fw.ko
and delete the old files, missed in r254199 and r259135 respectively.
MFC after: 3 days
|
| | |
|
| |
| |
| |
| | |
Reviewed by: adrian
|
|\ \
| |/ |
|