SAM-3 specification introduced concept of Task Priority, that was renamed
to Command Priority in SAM-4, and supported by all modern SCSI transports.
It provides 15 levels of relative priorities: 1 - highest, 15 - lowest and
0 - default.  SAT specification for SATA devices translates priorities 1-3
into NCQ high priority.

This change adds new "priority" field into empty spots of struct ccb_scsiio
and struct ccb_accept_tio of CAM and struct ctl_scsiio of CTL.  Respective
support is added into iscsi(4), isp(4), mpr(4), mps(4) and ocs_fc(4) drivers
for both initiator and where applicable target roles.  Minimal support was
added to CTL to receive the priority value from different frontends, pass it
between HA controllers and report in few places.

This patch does not add consumers of this functionality, so nothing should
really change yet, since the field is still set to 0 (default) on initiator
and not actively used on target.  Those are to be implemented separately.

I've confirmed priority working on WD Red SATA disks connected via mpr(4)
and properly transferred to CTL target via iscsi(4), isp(4) and ocs_fc(4).

While there, added missing tag_action support to ocs_fc(4) initiator role.

  ------------------------------------------------------------------------
  r348247 | ken | 2019-05-24 13:58:29 -0400 (Fri, 24 May 2019) | 57 lines

  Fix FC-Tape bugs caused in part by r345008.

  The point of r345008 was to reset the Command Reference Number (CRN)
  in some situations where a device stayed in the topology, but had
  changed somehow.

  This can include moving from a switch connection to a direct
  connection or vice versa, or a device that temporarily goes away
  and comes back.  (e.g. moving to a different switch port)

  There were a couple of bugs in that change:
  - We were reporting that a device had not changed whenever the
    Establish Image Pair bit was not set.  That is not quite correct.
    Instead, if the Establish Image Pair bit stays the same (set or
    not), the device hasn't changed in that way.

  - We weren't setting PRLI Word0 in the port database when a new
    device arrived, so comparisons with the old value for the
    Establish Image Pair bit weren't really possible.  So, make sure
    PRLI Word0 is set in the port database for new devices.

  - We were resetting the CRN whenever the Establish Image Pair bit
    was set for a device, even when the device had stayed the same
    and the value of the bit hadn't changed.  Now, only reset the
    CRN for devices that have changed, not devices that sayed the
    same.

  The result of all of this was that if we had a single FC device on
  an FC port and it went away and came back, we would wind up
  correctly resetting the CRN.

  But, if we had multiple devices connected via a switch, and there
  was any change in one or more of those devices, all of the devices
  that stayed the same would also have their CRN values reset.

  The result, from a user standpoint, is that the tape drives, etc.
  would all start to time out commands and the initiator would send
  aborts.

  sys/dev/isp/isp.c:
  	In isp_pdb_add_update(), look at whether the Establish
  	Image Pair bit has changed as part of the check to
  	determine whether a device is still the same.   This was
  	causing erroneous change notifications.  Also, when
  	creating a new port database entry, initialize the
  	PRLI Word 0 values.

  sys/dev/isp/isp_freebsd.c:
  	In isp_async(), in the changed/stayed case, instead of
  	looking at the Establish Image Pair bit to determine
  	whether to reset the CRN, look at the command value.
  	(Changed vs. Stayed.)  Only reset the CRN for devices
  	that have changed.

  ------------------------------------------------------------------------

Sponsored by:	Spectra Logic

  ------------------------------------------------------------------------
  r345008 | ken | 2019-03-11 10:21:14 -0400 (Mon, 11 Mar 2019) | 59 lines

  Fix CRN resets in the isp(4) driver in certain situations.

  The Command Reference Number (CRN) is part of the FC-Tape features
  that we enable when talking to tape drives.  It starts at 1, and
  goes to 255 and wraps around to 1.  There are a number of reset
  type conditions that result in the CRN getting reset to 1.  These
  are detailed in section 4.10 (table 8) of the FCP-4r02b specification.

  One of the conditions is when a PRLI (Process Login) is sent by
  the initiator, and the Establish Image Pair bit is set in Word 0
  of the PRLI.

  Previously, the isp(4) driver core sent a notification via
  isp_async() that the target had changed or stayed in place, but
  there was no indication of whether a PRLI was sent and whether the
  Establish Image Pair bit was set.

  The result of this was that in some situations, notably
  switching back and forth between a direct connection and a switch
  connection to a tape drive, the isp(4) driver would fail to reset
  the CRN in situations that require it according to the spec.  When
  the CRN isn't reset in a situation that requires it, the tape drive
  then rejects every subsequent command that is sent to the drive.
  It is assuming that the commands are being sent out of order.

  So, modify the isp(4) driver to include Word 0 of the PRLI command
  when it sends isp_async() notifications of target changes.  Look at
  the Establish Image Pair bit, and reset the CRN if that bit is set.

  With this change, I am able to switch a tape drive back and forth
  between a direct connection and a switch connection, and the isp(4)
  driver resets the CRN when it should.

  sys/dev/isp_stds.h:
  	Add bit definitions for PRLI Word 0.

  sys/dev/ispmbox.h:
  	Add PRLI Word 0 to the port database type, isp_pdb_t.

  sys/dev/ispvar.h
  	Add PRLI Word 0 to fcportdb_t.

  sys/dev/isp.c:
  	Populate the new prli_word0 parameter in the port database.

  	In isp_pdb_add_update(), add a check to see if the
  	Establish Image Pair bit is set in PRLI Word 0.  If it is,
  	then that is an additional reason to create a change
  	notification.

  sys/dev/isp_freebsd.c:
  	In isp_async(), if the device changed or stayed, look at
  	PRLI Word 0 to see if the Establish Image Pair bit is set.
  	If it is, reset the CRN if we haven't already.

  Sponsored by:	Spectra Logic

  ------------------------------------------------------------------------
Differential Revision:	https://reviews.freebsd.org/D19472

The timespecadd(3) family of macros were imported from NetBSD back in
r35029. However, they were initially guarded by #ifdef _KERNEL. In the
meantime, we have grown at least 28 syscalls that use timespecs in some
way, leading many programs both inside and outside of the base system to
redefine those macros. It's better just to make the definitions public.

Our kernel currently defines two-argument versions of timespecadd and
timespecsub.  NetBSD, OpenBSD, and FreeDesktop.org's libbsd, however, define
three-argument versions.  Solaris also defines a three-argument version, but
only in its kernel.  This revision changes our definition to match the
common three-argument version.

Bump _FreeBSD_version due to the breaking KPI change.

Discussed with:	cem, jilles, ian, bde
Differential Revision:	https://reviews.freebsd.org/D14725

For _IO() ioctls, addr is a pointer to uap->data which is a caddr_t.
When the caddr_t stores an int, dereferencing addr as an (int *) results
in truncation on little-endian 64-bit systems and corruption (owing to
extracting top bits) on big-endian 64-bit systems. In practice the
value of chan was probably always zero on systems of the latter type as
all such FreeBSD platforms use a register-based calling convention.

Reviewed by:	mav
Obtained from:	CheriBSD
MFC after:	1 week
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D14673

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

MFC after:	1 week

Instead of using GID_FT SNS request to get list of registered FCP ports,
use GID_PT to get list of all Nx_Ports, and then use GFF_ID and/or GFT_ID
requests to find whether they are FCP and target capable.

The problem with old approach is that GID_FT does not report ports without
FC-4 type registered.  In particular it was impossible to boot OS from
FreeBSD FC target using QLogic FC BIOS, since one does not register FC-4
type even on new cards and so ignored by old code as incompatible.

As a side bonus this allows initiator to skip pointless logins to other
initiators by fetching that information from SNS instead.

In case some switches do not implement GFF_ID/GFT_ID correctly, add sysctls
to disable that functionality.  I handled broken GFF_ID of my Brocade 200E,
but there may be other switches with different bugs.

Linux also uses GID_PT, but GFF_ID is disabled by default there, and GFT_ID
is not supported.

Sponsored by:	iXsystems, Inc.

For ATIOs it is pointless to report isp_loopid to CAM, since in other
places it operates with port database record IDs, not with loop IDs.

For INOTs target_id/target_lun seems were never set, so wildcard INOTs
probably were not working correctly when LUN IDs were important.