Arithmetic on pointers takes into account the size of the type. Properly cast the pointer to avoid incorrect pointer scaling.

MFC after:	1 Week


git-svn-id: svn://svn.freebsd.org/base/head@245908 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Further cleanups to use of timestamps in NFS:
- Use NFSD_MONOSEC (which maps to time_uptime) instead of the seconds
  portion of wall-time stamps to manage timeouts on events.
- Remove unused nd_starttime from the per-request structure in the new
  NFS server.
- Use nanotime() for the modification time on a delegation to get as
  precise a time as possible.
- Use time_second instead of extracting the second from a call to
  getmicrotime().

Submitted by:	bde (3)
Reviewed by:	bde, rmacklem
MFC after:	2 weeks


git-svn-id: svn://svn.freebsd.org/base/head@245909 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Expand description of how gptboot and gptzfsboot choose a partition for
booting.

Reviewed by:	ae
MFC after:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@245910 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
MK_* variable should be compared to "no" not "NO".

Submitted by:	"b.f." <bf1783@googlemail.com>


git-svn-id: svn://svn.freebsd.org/base/head@245911 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Don't time travel back and use a present date.

Noticed by:	mckusick


git-svn-id: svn://svn.freebsd.org/base/head@245912 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Remove redundant test, we know inp_lport is 0.

MFC after:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@245914 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Heed SO_NO_OFFLOAD.

MFC after:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@245915 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Teach toe_4tuple_check() to deal with IPv6 4-tuples too.

Reviewed by:	bz@


git-svn-id: svn://svn.freebsd.org/base/head@245916 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Always allow access to the sysenter cs/esp/eip MSRs since they
are automatically saved and restored in the VMCS.

Reviewed by:	neel
Obtained from:	NetApp


git-svn-id: svn://svn.freebsd.org/base/head@245917 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Fix update method (s/SUP/CVS) warning.

Submitted by:	Ryan Stone
MFC after:	1 day


git-svn-id: svn://svn.freebsd.org/base/head@245918 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Add TCP_OFFLOAD hook in syncache_respond for IPv6 too, just like the one
that exists for IPv4.

Reviewed by:	bz@


git-svn-id: svn://svn.freebsd.org/base/head@245919 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Improve correctness of rtc register implementation.

Submitted by:	tycho nightingale at pluribusnetworks com


git-svn-id: svn://svn.freebsd.org/base/head@245920 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
There is no need to call into the TOE driver twice in pru_rcvd (tod_rcvd
and then tod_output right after that).

Reviewed by:	bz@


git-svn-id: svn://svn.freebsd.org/base/head@245921 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Avoid NULL dereference in nd6_storelladdr when no mbuf is provided.  It
is called this way from a couple of places in the OFED code.  (toecore
calls it too but that's going to change shortly).

Reviewed by:	bz@


git-svn-id: svn://svn.freebsd.org/base/head@245922 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
- Check the return value of taskqueue_start_threads().
- At least the Saturn chips of 501-6738 cards need a delay after freezing
  the external GMII pins before the internal PHY is accessible again. So
  wait a bit after (un)freezing these. Also don't touch the other bits of
  that configuration register. [1]
- Take advantage of nitems().

Reported and tested by: Paul Keusemann [1]

MFC after:	3 days


git-svn-id: svn://svn.freebsd.org/base/head@245923 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Move lle_event to if_llatbl.h

lle_event replaced arp_update_event after the ARP rewrite and ended up
in if_ether.h simply because arp_update_event used to be there too.
IPv6 neighbor discovery is going to grow lle_event support and this is a
good time to move it to if_llatbl.h.

The two in-tree consumers of this event - OFED and toecore - are not
affected.

Reviewed by:	bz@


git-svn-id: svn://svn.freebsd.org/base/head@245924 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Generate lle_event in the IPv6 neighbor discovery code too.

Reviewed by:	bz@


git-svn-id: svn://svn.freebsd.org/base/head@245925 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
- Improve some comments.
- Make bge_lookup_{rev,vendor}() static.
- Factor out chip identification rather than duplicating the code.
- Sanitize bge_probe() a bit (don't hardcode buffer sizes, allow
  bge_lookup_vendor() to return NULL so the excessive panic() three
  can be removed there, etc.) and return BUS_PROBE_DEFAULT rather than
  hardcoding 0.
- According to the Linux tg3 driver, BCM57791 and BCM57795 aren't
  capable of Gigabit Ethernet.
- Check the return value of taskqueue_start_threads().


git-svn-id: svn://svn.freebsd.org/base/head@245926 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Migrate the TX sending code out from under the ath0 taskq and into
the separate ath0 TX taskq.

Whilst here, make sure that the TX software scheduler is also
running out of the TX task, rather than the ath0 taskqueue.

Make sure that the tx taskqueue is blocked/unblocked as necessary.

This allows for a little more parallelism on multi-core machines,
as well as (eventually) supporting a higher task priority for TX
tasks, allowing said TX task to preempt an already running RX or
TX completion task.

Tested:

* AR5416, AR9280 hostap and STA modes


git-svn-id: svn://svn.freebsd.org/base/head@245927 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Initial cut at making IBSS support 802.11n aware.

* Add HTINFO field decoding to ieee80211_ies_expand() - it's likely not
  100% correct as it's not looking at the draft 11n HTINFO location,
  but I don't think anyone will care.

* When doing an IBSS join make sure the 11n channel configuration
  is used - otherwise the 11a/11bg channel will be used
  and there won't be any chance for an upgrade to 11n.

* When creating an IBSS network, ensure the channel is updated to an
  11n channel so other 11n nodes can see it and speak to it with MCS
  rates.

* Add a bit of code that's disabled for now which handles the HT
  field updating.  This won't work out very well with lots of adhoc
  nodes as we'd end up ping-ponging between the HT configuration for
  each node.  Instead, we should likely only pay attention to the
  "master" node we initially associated against and then ensure we
  propagate that information forward in our subsequent beacons.  However,
  due to the nature of IBSS (ie, there's no specific "master" node in
  the specification) it's unclear which node we should lift the HT
  parameters from.

  So for now this assumes the HT parameters are squirreled away in the
  initial beacon/probe response.

So there's some trickiness here.

With ap/sta pairing, the probe response just populates a legacy node
and the association request/response is what is used for negotiation
11n-ness (and upgrading things as needed.)

With ibss networks, the pairing is done with probe request/response,
with discovery being done by creating nodes when new beacons in the
IBSS / BSSID are heard.  There's no assoc request/response frames going on.

So the trick here has been to figure out where to upgrade things.
I don't like how I just taught ieee80211_sta_join() to "speak" HT -
I'd rather there be an upgrade path when an IBSS node joins and there
are HT parameters present.  Once I've done that, I'll kill this
HT special casing that's going on in ieee80211_sta_join().

Tested:

* AR9280, AR5416, AR5212 - basic iperf and ping interoperability tests
  whilst in a non-encrypted adhoc network.

TODO:

* Fix up the HT upgrade path for IBSS nodes rather than adding code
  in ieee80211_sta_join(), then remove my code from there.

* When associating, there's a concept of a "master" node in the IBSS
  which is the node you first joined the network through.  It's possible
  the correct thing to do is to listen to HT updates and configure WME
  parameters from that node.  However, once that node goes away, which
  node(s) should be listened to for configuration changes?

  For things like HT channel width, it's likely going to be ok to
  just associate as HT40 and then use the per-neighbor rate control
  and HTINFO/HTCAP fields to figure out which rates and configuration
  to speak.  Ie, for a 20MHz 11n node, just speak 20MHz rates to
  it.  It shouldn't "change", like what goes on in AP/STA configurations.


git-svn-id: svn://svn.freebsd.org/base/head@245928 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f