o The CP2101 and CP2102 do not support GPIO pin use at all, enforce this.
o Support reading the GPIO status on the second port of the CP2105. More
work is needed before the CP2105 GPIO pins can be used as outputs.
Hardware donated by: Silicon Labs
MFC after: 3 weeks
tree is used to maintain the object's collection of resident pages,
vm_page_lookup() no longer needs an exclusive lock.
Reviewed by: attilio
Sponsored by: EMC / Isilon Storage Division
doesn't match the actual hardware queue this frame is queued to.
I'm trying to ensure that the holding buffers are actually being queued
to the same TX queue as the holding buffer that they end up on.
I'm pretty sure this is all correct so if this complains, it'll be due
to some kind of subtle broken-ness that needs fixing.
This is only done for legacy hardware, not EDMA hardware.
Tested:
* AR5416 STA mode, very lightly
recreating the filesystem, check for and output the -i, -k, and -l
options if appropriate.
Note the remaining deficiencies of the -m option in the dumpfs(8)
manual page. Specifically that newfs(8) options -E, -R, -S, and -T
options are not handled and that -p is not useful so is omitted.
Also document that newfs(8) options -n and -r are neither checked
for nor output but should be. The -r flag is needed if the filesystem
uses gjournal(8).
PR: bin/163992
Reported by: Dieter <freebsd@sopwith.solgatos.com>
Submitted by: Andy Kosela <akosela@andykosela.com>
MFC after: 1 week
should be noted that newlines are both preserved and included in said byte-
count. If you want to truncate single-line values without regard to line
termination, there's always f_substr() which already exists herein.
FreeBSD. In the IPv6 case, try each interface before returning an error;
each IPv6-enabled interface will have a link-local address even if the link
isn't up.
MFC after: 1 week
PS-POLL support.
This implements PS-POLL awareness i nthe
* Implement frame "leaking", which allows for a software queue
to be scheduled even though it's asleep
* Track whether a frame has been leaked or not
* Leak out a single non-AMPDU frame when transmitting aggregates
* Queue BAR frames if the node is asleep
* Direct-dispatch the rest of control and management frames.
This allows for things like re-association to occur (which involves
sending probe req/resp as well as assoc request/response) when
the node is asleep and then tries reassociating.
* Limit how many frames can set in the software node queue whilst
the node is asleep. net80211 is already buffering frames for us
so this is mostly just paranoia.
* Add a PS-POLL method which leaks out a frame if there's something
in the software queue, else it calls net80211's ps-poll routine.
Since the ath PS-POLL routine marks the node as having a single frame
to leak, either a software queued frame would leak, OR the next queued
frame would leak. The next queued frame could be something from the
net80211 power save queue, OR it could be a NULL frame from net80211.
TODO:
* Don't transmit further BAR frames (eg via a timeout) if the node is
currently asleep. Otherwise we may end up exhausting management frames
due to the lots of queued BAR frames.
I may just undo this bit later on and direct-dispatch BAR frames
even if the node is asleep.
* It would be nice to burst out a single A-MPDU frame if both ends
support this. I may end adding a FreeBSD IE soon to negotiate
this power save behaviour.
* I should make STAs timeout of power save mode if they've been in power
save for more than a handful of seconds. This way cards that get
"stuck" in power save mode don't stay there for the "inactivity" timeout
in net80211.
* Move the queue depth check into the driver layer (ath_start / ath_transmit)
rather than doing it in the TX path.
* There could be some naughty corner cases with ps-poll leaking.
Specifically, if net80211 generates a NULL data frame whilst another
transmitter sends a normal data frame out net80211 output / transmit,
we need to ensure that the NULL data frame goes out first.
This is one of those things that should occur inside the VAP/ic TX lock.
Grr, more investigations to do..
Tested:
* STA: AR5416, AR9280
* AP: AR5416, AR9280, AR9160
If an expander returns 0x00 (no device attached) in the ATTACHED DEVICE
field of the SMP DISCOVER response, ignore the value of ATTACHED SAS
ADDRESS, because it is invalid. Some expanders zero out the address
when the attached device is removed, but others do not. Section
9.4.3.10 of the SAS Protocol Layer 2 revision 04b does not require them
to do so.
Approved by: ken (mentor)
MFC after: 3 weeks
QLogic 8300 Series Adapters
Submitted by: David C Somayajulu (davidcs@freebsd.org) QLogic Corporation
Approved by: George Neville-Neil (gnn@freebsd.org)
specified by passing the XCC, XCXX, and XCPP variables (corresponding to
CC, CXX, and CPP) to buildworld/buildkernel. The compiler must be clang
or be configured to target the appropriate architecture.
To speed build times, if XCC is an absolute path or
WITHOUT_CROSS_COMPILER is defined then no cross compiler will be built
during the cross-tools stage.
Limited documentation of this feature can currently be found at:
https://wiki.freebsd.org/ExternalToolchain
This functionality should be considered experimental and is subject to
change without notice.
Sponsored by: DARPA, AFRL
Discussed with: imp, sjg
