The pidx argument of isc_rxd_flush() indicates which is the last valid
receive descriptor to be used by the NIC. However, current code has
multiple issues:
  - Intel drivers write pidx to their RDT register, which means that
    NICs will only use the descriptors up to pidx-1 (modulo ring size N),
    and won't actually use the one pointed by pidx. This does not break
    reception, but it is anyway confusing and suboptimal (the NIC will
    actually see only N-2 descriptors as available, rather than N-1).
    Other drivers (if_vmx, if_bnxt, if_mgb) adhere to this semantic).
  - The semantic used by Intel (RDT is one descriptor past the last
     valid one) is used by most (if not all) NICs, and it is also used
     on the TX side (also in iflib). Since iflib is not currently
     using this semantic for RX, it must decrement fl->ifl_pidx
     (modulo N) before calling isc_rxd_flush(), and then the
     per-driver callback implementation must increment the index
     again (to match the real semantic). This is confusing and suboptimal.
  -  The iflib refill function is also called at initialization.
     However, in case the ring size is smaller than 128 (e.g. if_mgb),
     the refill function will actually prepare all the receive
     descriptors (N), without leaving one unused, as most of NICs assume
     (e.g. to avoid RDT to overrun RDH). I can speculate that the code
     looks like this right now because this issue showed up during
     testing (e.g. with if_mgb), and it was easy to workaround by
     decrementing pidx before isc_rxd_flush().

The goal of this change is to simplify the code (removing a bunch
of instructions from the RX fast path), and to make the semantic of
isc_rxd_flush() consistent across drivers. To achieve this, we:
  - change the semantics of the pidx argument to the usual one (that
    is the index one past the last valid one), so that both iflib and
    drivers avoid the decrement/increment dance.
  - fix the initialization code to prepare at most N-1 descriptors.

Reviewed by:	markj
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D26191

Previously we were relying on ether_ifattach() to set if_mtu, but
max_frame_size is initialized earlier.  This fixes a regression
introduced by r250375.

PR:		249050
Submitted by:	Christian Vallières <novacrash_@hotmail.com>
MFC after:	3 days

upstream iicbus to configure this device using hints.

Reported by:	Thomas Laus
Sponsored by:	iXsystems, Inc.

The only output from fsck that should go to stderr is the usage message.
if setup() fails then exit with EEXIT rather than 0.

Reviewed by:	mckusick
Sponsored by:	Netflix

getln() returns 'len' valid characters.  line[len] is out of bounds.

Reported by:	CHERI
Reviewed by:	brooks
Obtained from:	CheriBSD
MFC after:	2 weeks
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D26197

Implement support for an eSDHC controller found in NXP QorIQ Layerscape SoCs.

This driver has been tested with NXP LS1046A and LX2160A (Honeycomb board),
which is incompatible with the existing sdhci_fsl driver (aiming at older
chips from this family). As such, it is not intended as replacement for
the old driver, but rather serves as an improved alternative for SoCs that
support it.
It comes with support for both PIO and Single DMA modes and samples the
clock from the extres clk API.

Submitted by: Artur Rojek <ar@semihalf.com>
Reviewed by: manu, mmel, kibab
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential Revision: https://reviews.freebsd.org/D26153

In the util-linux version of script, it will always exit with succes.
Except when run with -e, in which case it will have the exit value of
the child. BSD Script already uses the child's exit value for its exit
value. Some config and other helper scripts depend on being able to
specify -e. Accept it for compatibility since we'll already to the
right thing, but otherwise we ignore it.

Coverity detected this error.  The fix duplicates the assignment on line 171.

Submitted by:	bret_ketchum@dell.com
Reported by:	Coverity
MFC after:	2 weeks
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D26227

PR:	249047
Reported by: Dries Michiels <driesm.michiels at gmail.com>
--This line, and those below, will be ignored--
> Description of fields to fill in above:                     76 columns --|
> PR:                       If and which Problem Report is related.
> Submitted by:             If someone else sent in the change.
> Reported by:              If someone else reported the issue.
> Reviewed by:              If someone else reviewed your modification.
> Approved by:              If you needed approval for this commit.
> Obtained from:            If the change is from a third party.
> MFC after:                N [day[s]|week[s]|month[s]].  Request a reminder email.
> MFH:                      Ports tree branch name.  Request approval for merge.
> Relnotes:                 Set to 'yes' for mention in release notes.
> Security:                 Vulnerability reference (one per line) or description.
> Sponsored by:             If the change was sponsored by an organization (each collaborator).
> Differential Revision:    https://reviews.freebsd.org/D### (*full* phabric URL needed).
> Empty fields above will be automatically removed.

M    pchtherm.c

It's no longer unusual to be able to build a release with a single
command, so drop "actually" that hints at a surprise.  Also just use
"network install directory" instead of referencing FTP; it's more
likely to be HTTP now.

Reviewed by:	gjb
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D26260

Avoid assuming that the kernel was compiled with
-fno-omit-frame-pointer.

MFC after:	1 week
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.

MFC after:	1 week
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.

Reported by:	Coverity
MFC after:	1 week
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.

Reported by:	Coverity
MFC after:	1 week
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.

The caller-supplied pointer is unconditionally dereferenced at the
beginning of the function, so there is no point in comparing it with
NULL thereafter.

Reported by:	Coverity
MFC after:	1 week
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.

Reported by:	Coverity
MFC after:	1 week
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.

from the kernel, but let's try to be on the safe side.

Reviewed by:	mav
MFC after:	2 weeks
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D26246

When diff is invoked with -l it will spawn the pr(1) program.
In some circumpstances the pr(1) was not properly killed when diff program
exits.

Submitted by:	Bret Ketchum
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D26232

the wrong length to strlcpy(3). It looks like it could overflow into
the next field, isc_user, which is properly long to accomodate for it;
I don't think it could cause any harm other than breaking the connection.

Reviewed by:	mav
MFC after:	2 weeks
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D26247

When enabling the MMU on arm64 we need to ensure the tlb invalidation has
completed before setting the enable bit in the SCTLR register.

Reported by:	alc
Sponsored by:	Innovate UK

POSIX is pretty clear that command -v, command -V and type shall write
absolute pathnames. Therefore, we need to prepend the current directory's
name to relative pathnames.

This can happen either when PATH contains a relative pathname or when the
operand contains a slash but is not an absolute pathname.

Previously the send tag was setup in the background, and all packets for
the given send tag were dropped until ready. Change this to be blocking
behaviour so that once the setsocketopt() for enabling TLS completes,
the socket is ready to send packets. Do this by simply flushing the
work request which does the needed firmware programming during send
tag allocation.

MFC after:	1 week
Sponsored by:	Mellanox Technologies // Nvidia

PMCLOG macros were always using 32-bit addresses, even on PPC64.
This resulted in truncated addresses in logs, when running on 64-bit PPC
machines.

Sponsored by:	Eldorado Research Institute (eldorado.org.br)
Differential Revision:	https://reviews.freebsd.org/D26112

Calling pmc_hook inside a critical section may result in a panic.

This happens when the user callchain is fetched, because it uses
pmap_map_user_ptr, that tries to get the (sleepable) pmap lock when the
needed vsid is not found.

Judging by the implementation in other platforms, intr_irq_handler in
kern/subr_intr.c and what pmc_hook do, it seems safe to move pmc_hook
outside the critical section.

Sponsored by:	Eldorado Research Institute (eldorado.org.br)
Differential Revision:	https://reviews.freebsd.org/D26111

Add support for stage 2 pmap to pmap_pte_dirty, pmap_release, and more
of pmap_enter. This adds support in all placess I have hit while testing
bhyve ehile faulting pages in as needed.

Sponsored by:	Innovate UK
Differential Revision:	https://reviews.freebsd.org/D26065