ath_hal/ar9300: allow JUPITER cards to read eeprom

Summary:
In ar9300_eeprom_read_word() also allow JUPITER cards read the eeprom
instead of returning an error. While this will not help all the
9462, 9485, 9565 OEM cards to work, it will make debugging of the
next steps a lot easier.

While here fix a typo in the error message if we do not get CAL.

PR: 255337
Tested by: John Nielsen (john jnielsen net)
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D44328

[ar9300] Disable unconditionally reducing transmit power in the case of FCC.

Ok, yeah, the commit title is a bit misleading.

This has to do with CDD (cyclic delay diversity) - how this and later
wifi hardware transmits lower rates over more antennas. Eg, if you're
transmitting legacy 11abg rates on 2 or 3 antennas, you COULD just
send them all at the same time or you could delay each by tens/hundreds
of nanoseconds to try and get some better diversity characteristics.

However, this has a fun side effect - the antenna pattern is no longer
a bunch of interacting dipoles, but are a bunch of interacting dipoles
plus a bunch of changing phases. And it's frequency dependent - 50-200nS
is not exactly the same fraction of a wavelength across all of 2GHz or 5GHz!

Thus the power spectral density and maximum directional gain that you're
effectively getting is not .. well, as flat as it once was.

For more information, look up FCC/OET 13TR1003 in the FCC technical report
database. It has pretty graphics and everything.

Anyway, the problem lies thusly - the CDD code just subtracts another 3dB
or 5dB for the lower rates based on transmit antenna configuration.
However, it's not done based on operating configuration and it doesn't
take into account how far from any regulatory limits the hardware is at.
It also doesn't let us do things like transmit legacy rates and frames
on a single antenna without losing up to 5dB when we absolutely don't
need to in that case (there's no CDD used when one antenna is used!)

This shows up as the hardware behaving even worse for longer distance links
at 20MHz because, well, those are the exact rates losing a bunch more
transmit power.

* For lower power NICs (ie the majority of what is out there!) it's highly
unlikely we're going to hit anywhere near the PSD limits.
* It's doing it based on the existing limits from the CTL table (conformance
testing limits) - this isn't the regulatory max! It's what the NIC is
allowed to put out in each frequency and rate configuration! So things like
band edges, power amplifier behaviour and maximum current draw apply here.
Blindly subtracting 3 to 5dB from /this/ value is /very/ conservative..
* /and/ ath9k just plainly doesn't do any of this at all.

So, for now disable it and get the TX power back, thus matching what ath9k
in Linux is doing. If/once I get some more cycles I'll look at making it
a bit more adaptive and really only kick in if we're a few dB away from
hard regulatory limits.

Tested:

* AR9344 (2GHz + SoC, 2x2 configuration) - AP and STA modes
* QCA9580 (5GHz 2x2 and 3x3 configurations) - AP and STA modes

Fix improper use of "its".

Sponsored by: Dell EMC Isilon

[ath_hal] add QCA9565 bluteooth antenna control.

This configures the LNA antenna diversity control, which should be on
if wlan owns the LNA for bluetooth coexistence. Otherwise, make sure
it's off.

I think this is eventually intended to allow 1-antenna bluetooth +
wifi setups for QCA9565, but I'm not sure where that's actually configured
in ath9k.

Obtained from: Linux ath9k

Add initial support for the QCA953x SoC (honeybee) wifi.

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

Add support for the tuning cap for Hornet/AR9331 boards.

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>

Update the AR9300 HAL to the latest public available HAL from QCA.

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

Add initial support for the AR9485 CUS198 / CUS230 variants.

These variants have a few differences from the default AR9485 NIC,
namely:

* a non-default antenna switch config;
* slightly different RX gain table setup;
* an external XLNA hooked up to a GPIO pin;
* (and not yet done) RSSI threshold differences when
doing slow diversity.

To make this possible:

* Add the PCI device list from Linux ath9k, complete with vendor and
sub-vendor IDs for various things to be enabled;
* .. and until FreeBSD learns about a PCI device list like this,
write a search function inspired by the USB device enumeration code;
* add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this
to initialise its local driver parameters upon attach;
* copy these parameters over in the AR9300 HAL;
* don't default to override the antenna switch - only do it for
the chips that require it;
* I brought over ar9300_attenuation_apply() from ath9k which is cleaner
and easier to read for this particular NIC.

This is a work in progress. I'm worried that there's some post-AR9380
NIC out there which doesn't work without the antenna override set as
I currently haven't implemented bluetooth coexistence for the AR9380
and later HAL. But I'd rather have this code in the tree and fix it
up before 11.0-RELEASE happens versus having a set of newer NICs
in laptops be effectively RX deaf.

Tested:

* AR9380 (STA)
* AR9485 CUS198 (STA)

Obtained from: Qualcomm Atheros, Linux ath9k

Bring over my FreeBSD modifications for the AR9300 HAL to make it
work in FreeBSD.

This is still heavily a work in progress but I'd rather it start
shipping in -HEAD sooner rather than later.

This doesn't (yet) link it into the build system either for a static
kernel or as a module; that will come later (after many, many make universe
tests.)