bits.
The ROUERSTATION and RSPRO variants contain:
* the board specific bits (eg the RTC for RSPRO, later on it'll
include the GPIO/LED definitions);
* the boot specific bits (eg, on-board flash, usb flash, etc).
For now the AR71XX_BASE file contains the common board config,
drivers and net80211/ath wireless drivers.
I'll follow this up with config files for the other boards I
have (eg the Ubiquiti LSSR71, as well as some Mikrotik boards
that use the AR71XX and atheros reference boards) which will
be quite easy to do now.
no reason why it should be limited to 64K of DFLTPHYS. DMA data tag is any
way set to allow MAXPHYS, S/G lists (chain elements) are sufficient and
overflows are also handled. On my tests even 1MB I/Os are working fine.
Reviewed by: ken@
paravirtualized pmap implementations for i386. This includes some
style fixes to the native pmap and several bug fixes that were not
previously applied to the paravirtualized pmap.
Tested by: sbruno
MFC after: 3 weeks
In an example of boot command:
- rename wd(4) IDE disk drives name to ad(4) for the time being.
- update the used kernel path "/kernel" to the current default.
[It still worked occasionally by looking into the /boot/kernel directory,
so the resulting path was "/boot//kernel/kernel", with two slashes.]
Bump .Dd for this and previous changes.
MFC after: 1 week
doing split software/hardware LED configuration, we can now simply
treat "softled" as an "output" mux type.
This works fine on this DWA-552. Previous generation (pre-11n NICs) don't
have a GPIO mux - only input/output configuration - so they ignore this
field.
The hardware (MAC) LED blinking involves a few things:
* Selecting which GPIO pins map to the MAC "power" and "network" lines;
* Configuring the MAC LED state (associated, scanning, idle);
* Configuring the MAC LED blinking type and speed.
The AR5416 HAL configures the normal blinking setup - ie, blink rate based
on TX/RX throughput. The default AR5212 HAL doesn't program in any
specific blinking type, but the default of 0 is the same.
This code introduces a few things:
* The hardware led override is configured via sysctl 'hardled';
* The MAC network and power LED GPIO lines can be set, or left at -1
if needed. This is intended to allow only one of the hardware MUX
entries to be configured (eg for PCIe cards which only have one LED
exposed.)
TODO:
* For AR2417, the software LED blinking involves software blinking the
Network LED. For the AR5416 and later, this can just be configured
as a GPIO output line. I'll chase that up with a subsequent commit.
* Add another software LED blink for "Link", separate from "activity",
which blinks based on the association state. This would make my
D-Link DWA-552 have consistent and useful LED behaviour (as they're
marked "Link" and "Activity."
* Don't expose the hardware LED override unless it's an AR5416 or later,
as the previous generation hardware doesn't have this multiplexing
setup.
Some of the NICs I have here power up with the LEDs blinking, which is
incorrect. The blinking should only occur when the NIC is attempting
to associate.
* On powerup, set the state to HAL_LED_INIT, which turns on the "Power" MAC
LED but leaves the "Network" MAC LED the way it is.
* On resume, also init it to HAL_LED_INIT unless in station mode, where
it's forced to HAL_LED_RUN. Hopefully the net80211 state machine will
call newstate() at some point, which will refiddle the LEDs.
I've tested this on a handful of 11n and pre-11n NICs. The blinking
behaviour is slightly more sensible now.
relying on what the register defaults are.
This forces the blink mode to be proportional to the TX and RX frames
which match the RX filter.
This (along with a few tweaks to if_ath_led.c to configure the correct
GPIO pins) allows my DWA-552 AR5416 NIC to blink the LEDs in a useful
fashion, however those LEDs are marked "Link" and "Act(ivity)", which
don't really map well to the "power" / "network" LED interface which
the MAC provides. Some further tinkering is needed to see what other
useful operating modes are possible.
kernel builds. All the instances of this warning in our tree are
completely harmless, and many people seem to like adding extra
parentheses to make precedence clearer.
MFC after: 1 week
builds. All the instances of this warning in our tree are completely
harmless. (Most of the empty bodies look to be used simply as reminder
for the developer to add something later.)
While here, assign to CWARNEXTRA with ?=, so it can be overridden
easily, if needed.
MFC after: 1 week
to always evaluate to 0 if we are using a compiler that doesn't implement them.
This lets us use the macros easily in standard headers (e.g. stdatomic.h, which
should be the subject of my next commit).
Approved by: dim (mentor)
sysclock_getsnapshot() function allows the caller to obtain a snapshot of all
the system clock and timecounter state required to create time stamps at a later
point. The sysclock_snap2bintime() function converts a previously obtained
snapshot into a bintime time stamp according to the specified flags e.g. which
system clock, uptime vs absolute time, etc.
These KPIs enable useful functionality, including direct comparison of the
feedback and feed-forward system clocks and generation of multiple time stamps
with different formats from a single timecounter read.
Committed on behalf of Julien Ridoux and Darryl Veitch from the University of
Melbourne, Australia, as part of the FreeBSD Foundation funded "Feed-Forward
Clock Synchronization Algorithms" project.
For more information, see http://www.synclab.org/radclock/
In collaboration with: Julien Ridoux (jridoux at unimelb edu au)
these to trigger a NOTE_ATTRIB EVFILT_VNODE kevent when the extended
attributes of a vnode are changed.
Note that OS X already implements this behavior.
Reviewed by: rwatson
MFC after: 2 weeks
As soon as not all devices support READ CAPACITY(16), automatically fall
back to READ CAPACITY(10) if CAM_REQ_INVALID or SSD_KEY_ILLEGAL_REQUEST
status returned.
It also provides first bits of information about Logical Block Provisioning
(aka UNMAP/TRIM) support by the device.
CWARNEXTRA variable, which gets included into the initial CWARNFLAGS
setting. This makes it easier to override CWARNFLAGS with completely
custom settings (including enabling any disabled warnings).
Reminded by: arundel
MFC after: 1 week
MS_SYNC flag. The system must guarantee that all writes are finished
before syscalls returned. Schedule the writes in async mode, which is
much faster and allows the clustering to occur. Wait for writes using
VOP_FSYNC(), since we are syncing the whole file mapping.
Potentially, the restriction to only apply the optimization can be
relaxed by not requiring that the mapping cover whole file, as it is
done by other OSes.
Reported and tested by: az
Reviewed by: alc
MFC after: 2 weeks
