Edit: my card DOES work with this patch!

This patch definitely improves the situation for my card, though not enough to make it actually function:

ath0@pci0:4:0:0: class=0x028000 rev=0x01 hdr=0x00 vendor=0x168c device=0x0034 subvendor=0x1028 subdevice=0x020d

vendor     = 'Qualcomm Atheros'
device     = 'AR9462 Wireless Network Adapter'
class      = network

Without the patch I would get a bogus MAC address and the "No vaid CAL, calling default template" message. With the patch I get these ah_debug messages which match what I get under Linux (where the card works)
ar9300_eeprom_restore_internal_address: Found block at 3ff: code=3 ref=4 length=794 major=4 minor=6
ar9300_eeprom_restore_internal_address: checksum a5cc a5cc
ar9300_eeprom_restore_internal_address: restore eeprom 0: block, reference 4, length 794
ar9300_uncompress_block: Restore at 0: spot=2 offset=2 length=22

After many more uncompress_block messages I get:
ar9300_hw_attach: ar9300_eeprom_attach returned 0
ar9300_fill_capability_info: (MCI) MCI support = 1
assignPrivateChannels: 109 public, 37 private channels
ar9300_get_spectral_params: chan is NULL - no ss nf values

I suspect the above is why I still can't scan any SSIDs, etc. However the regular messages correctly state the number of MIMO streams (2x2 instead of 3x3) and I get a legitimate MAC address for the wlan0 interface.

ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] LDPC transmit/receive enabled
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9460 mac 640.2 RF5110 phy 803.5
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000

In D44328#1011038, @adrian wrote:

oh, you have a jupiter card with eeprom, rather than just OTP? ooer. Good catch! I likely only have OTP AR9462s :(

There's a couple of OEMs (e.g. Dell) which seem to be this way. I still do not think we'll have all the quirks for them but hey, progress is progress... ;-)