handlers.
o Put the IVT in its own section and keep the supporting code close.
o Make sure the VHPT is sized so that it can be mapped using a single
translation.
o Map the PAL code and VHPT with a translation that has the right size.
Assume the platform has a PAL code size that can be mapped with a
single translations.
o Pass the pointer to the bootinfo structure as an argument to ia64_init().
o Get rid of LOG2_ID_PAGE_SIZE and IA64_ID_PAGE_SIZE. It was used to map
the regions 6 & 7 and was as large as possible. The problem is that we
can't support memory attributes easily if the granuratity is not a page.
We need to support memory attributes because the new USB stack violates
the BUS_DMA(9) interface.
o Update some comments...
NOTE: this is broken for SMP kernels, because the AP startup code hasn't
been updated yet.
can be put right at the front when put in its own section. This makes
sure that when the loader can only map a relatively small part of the
PBVM, the IVT and the startup code is wired.
This does a few things in particular:
* Abstracts out the gain control settings into a separate function;
* Configure antenna diversity, LNA and antenna gain parameters;
* Configure ob/db entries - the later v4k EEPROM modal revisions have
multiple OB/DB parameters which are used for some form of
calibration. Although the radio does have defaults for each,
the EEPROM can override them.
This resolves the AR2427 related issues I've been seeing and makes
it stable at all 11g rates for both TX and RX.
sizes are not supported.
o Map the PBVM page table.
o Map the PBVM using the largest possible power of 2 that is less than
the amount of PBVM used and round down to a valid page size. Note
that the current kernel is between 8MB and 16MB in size, which would
mean that 8MB would be the typical size of the mapping, if only 8MB
wasn't an invalid page size. In practice, we end up mapping the first
4MB of PBVM in most cases.
These already worked: $# ${#} ${##} ${#-} ${#?}
These now work as well: ${#+word} ${#-word} ${##word} ${#%word}
There is an ambiguity in the standard with ${#?}: it could be the length of
$? or it could be $# giving an error in the (impossible) case that it is not
set. We continue to use the former interpretation as it seems more useful.
in the archive instead of spinning through it to get a file count for the
progress bar. This speeds up installation a lot on systems with slow
CD drives.
The offsets didn't match the assumption that nfarray[] is ordered by the
chainmask bits and programmed via the register order in ar5416_cca_regs[].
This repairs that damage and ensures that chain 1 is programmed correctly.
(And extension channels will now be programmed correctly also.)
This fixes some of the stuck beacons I've been seeing on my AR9160/AR5416
setups - because Chain 1 would be programmed -80 or -85 dBm, which is
higher than the actual noise floor and thus convincing the radio that
indeed it can't ever transmit.
uses of ic_curchan occur. Due to the nature of a scan, switching
channels constantly and all this happening without any kind of locks
held, it might happen that ic_curchan points to nowhere leading to
panics. Fix this by not allowing frame injections while in SCAN state.
Tested by: Paul B. Mahol <onemda at gmail.com>
If multiple networks are available the max bandwidth is one
condition used for selecting the "best" BSS. To achieve that
we should consider all parameters which affect the max RX rate.
This includes 20/40MHz, SGI and the of course the MCS set.
If the TX MCS parameters are available we should use those,
because an AP announcing support for receiving frames at 450Mbps
might only be able to transmit at 150Mbps (1T3R). I haven't seen
devices with support for transmitting at higher rates then
receiving, so prefering TX over RX information should be safe.
While here, remove the hardcoded assumption that MCS15 is the max
possible MCS rate, use MCS31 instead which really is the highest
rate (according to the 802.11n std). Also, fix a mismatch of an
40MHz/SGI check.
Contrary to the rateset information in legacy frames the MCS Set
field also contains TX capability information in cases where the
number of available TX and RX spartial streams differ. Because a
rateset doesn't contain that information we have to pull the
those directly from the hardware capabilities.
Get rid of the assumption that every device is capable of 40MHz,
SGI and 2 spartial streams. Instead of printing, in the worst case,
8 times 76 MCS rates, print logically connect ranges and the
support RX/TX streams.
A device without 40MHz and SGI support looks like:
ath0: 2T2R
ath0: 11na MCS 20Mhz
ath0: MCS 0-7: 6.5Mbps - 65Mbps
ath0: MCS 8-15: 13Mbps - 130Mbps
ath0: 11ng MCS 20Mhz
ath0: MCS 0-7: 6.5Mbps - 65Mbps
ath0: MCS 8-15: 13Mbps - 130Mbps
Initialize ic_rxstream/ic_txstream with 2, for compatibility reasons.
Introduce 4 new HTC flags, which are used in addition to ic_rxstream
and ic_txstream to compute the hc_mcsset content and also for initializing
ni_htrates. The number of spatial streams is enough to determine support
for MCS0-31 but not for MCS32-76 as well as some TX parameters in the
hc_mcsset field.
rather than duplicating them for the v14 (ar5416+) and v4k (ar9285) codebases.
Further chipsets (eg the AR9287) have yet another EEPROM format which will use
these routines to calculate things.
to the TX closed-loop power control registers.
* Modify a couple of functions to take the register chain number,
rather than the regChainOffset value. This allows for the
register chain to be logged.
i386 and amd64. This involved moving the memstick generation script to
the arch directories from scripts/, in analogy to mkisoimages.sh. This
script was never called from /usr/src/release/Makefile, so that hasn't
been updated.
