isp: Fix endianness conversion in isp_read_flash_data()

Reported by: Jenkins
Fixes: 10ed63fc06cb ("isp(4): Rework firmware handling/loading")

isp(4): Rework firmware handling/loading

Correctly identify the active firmware in flash on adapters with
primary and secondary firmware region in flash.
Correctly identify the active NVRAM on adapters with primary
and secondary NVRAM region in flash.

Loading ispfw(4) moved from isp_pci_attach() to isp_reset().
Drop the reference to ispfw(4) after using it so one can kldunload(8) it.
New isp_load_ram() function to load either ispfw(4) or flash firmware
into RISC's RAM.
New functions to read data from flash. The old ones will be removed later.
A bunch of new helper functions to identify and validate active flash
regions for firmware, auxiliary and NVRAM.
Overhaul ISP_FW_* macros and make use of it when comparing firmware
versions. We can handle firmware versions up to 255.255.255.

Firmware load priority slightly changed:
For 27xx and newer adapters:
- load ispfw(4) firmware
- request (active) flash firmware information
- compare version numbers of ispfw(4) and flash firmware
- load firmware with highest version into RISC's RAM
- if loading ispfw(4) is disabled or failed - load firmware from flash
- if everything else fails use MBOX_LOAD_FLASH_FIRMWARE as fallback

For 26xx and older adapters nothing changed:
- load ispfw(4) firmware and load it into RISC's RAM
- if loading ispfw(4) is disabled or failed use MBOX_EXEC_FIRMWARE
- for 26xx a preceding MBOX_LOAD_FLASH_FIRMWARE is used

New read only sysctl(8)'s:
dev.isp.N.fw_version_run: the firmware version actually running
dev.isp.N.fw_version_ispfw: the firmware version provided by ispfw(4)
dev.isp.N.fw_version_flash: the (active) firmware version in flash

While here:
- firmware attribute handling/parsing reworked
+ renamed defines from ISP2400_FW_ATTR_* to ISP_FW_ATTR_*
+ changed values to match new handling/parsing
+ added some more attributes
- enable FLT support on 26xx based adapters
- log level adjustments
- new function return status codes (some for now, some for later use)
- some minor style changes

Tested and approved to work on real hardware with:
- Qlogic ISP 2532 (QLogic QLE2560 8Gb FC Adapter)
- Qlogic ISP 2031 (QLogic QLE2662 16Gbit 2Port FC Adapter)
- Qlogic ISP 2722 (QLogic QLE2690 16Gb FC Adapter)
- Qlogic ISP 2812 (QLogic QLE2772 32Gbit 2Port FC Adapter)

PR: 273263
Reviewed by: mav
Pull Request: https://github.com/freebsd/freebsd-src/pull/877
MFC after: 1 month
Sponsored by: Technical University of Munich

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

isp(4): Style changes

Please tools/build/checkstyle9.pl as mentioned by imp@

PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726

isp(4): Remove redundant functions for reading data from FLT and flash

Rename isp_rd_2400_nvram to isp_rd_2xxx_flash.
Cleanup some leftovers.
Hide all output regarding FLT parsing behind ISP_LOGDEBUG0.

Thanks to imp@ and mav@ for reviewing and commenting.

PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726

isp(4): Use the FLT on all supported controllers

The ISP26xx based HBAs are left as is for now with static NVRAM addressing.
Those HBAs are known as 83xx (2031 and 8031 for real) and need special handling.
This is left for further investigation for now.

Cosmetics:
- rename functions and defines as they are no longer specific to 28xx
- set reasonable log levels
- sort FLT and NVRAM functions (in the order they are used)

Tested and approved to work on real hardware with:
- Qlogic ISP 2532 (QLogic QLE2562 8Gb 2Port FC Adapter)
- Qlogic ISP 2722 (QLogic QLE2690 16Gb FC Adapter)
- Qlogic ISP 2812 (QLogic QLE2772 32Gbit 2Port FC Adapter)

PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726

isp(4): Add support to read contents of the FLT (flash layout table)

The FLT is like a TOC for the flash area and contains entries for every flash
region with start/end address, size and flags.
Start using NVRAM addresses from FLT instead of hardcoded ones for ISP28xx
based HBAs.

The FLT should be available on earlier HBAs too, probably since ISP24xx based.
This needs further investigation and testing.

PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726

isp(4): Fix reading NVRAM contents for 28xx based devices

Use correct NVRAM address for ISP28xx based HBAs to read NVRAM contents.
WWPN/WWNN and framesize are correctly read from NVRAM now.

PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726

isp(4): Add support for QLogic 28xx devices

This covers the following HBAs:
ISP2812-based 64/32G Fibre Channel to PCIe Controller:
QLE2770 Single Port 32GFC PCIe Gen4 x8 Adapter
QLE2772 Dual Port 32GFC PCIe Gen4 x8 Adapter
QLE2870 Single Port 64GFC PCIe Gen4 x8 Adapter
QLE2872 Dual Port 64GFC PCIe Gen4 x8 Adapter

ISP2814-based 64/32G Fibre Channel to PCIe Controller:
QLE2774 Quad Port 32GFC PCIe Gen4 x16 Adapter
QLE2874 Quad Port 64GFC PCIe Gen4 x16 Adapter

While here, add required bits to support 64GB FC.

Default framesize is set to 2048 for ISP28xx based HBAs for now.

PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

isp(4): Fix two typos in source code comments

- s/overriden/overridden/

MFC after: 3 days

isp(4): Allow more than 2 ports to read WWNs from NVRAM.

It appears at least on QLE2694L cards 3rd and 4th ports follow the
same NVRAM addressing logic as the first two. In lack of proper
documentation this guess is as good as it can be.

MFC after: 1 week
Sponsored by: iXsystems, Inc.

FIx "set but not used" in the isp driver.

Sponsored by: Rubicon Communications, LLC ("Netgate")

Some code reorganization.

- Remove code duplication by adding two new functions to execute prepared
queue entry via either mbox or request queue and wait for result.
- Since the new function executing via request queue sleeps any way, make
it sleep also in case of overflows or handle shortages. It should make it
more reliable and less affecting other less flexible request queue users.
- Turn isp_target_put_entry() into not target-specific isp_send_entry().
- Make handling of responses with control handles more universal.
- Move RQSTYPE_RPT_ID_ACQ handling into new function.
- Inline isp_handle_other_response(), becoming trivial after above.
- Clean the list of IOCBs from pre-24xx ones.

More cleanup in response queue and reset code.

Some minor FCoE bits I had lying around.

Update RQSFLAG_* definitions.

Remove concept of mbox_sleep_ok.

It was broken by design and unused for years due to conflicts between
different threads, fighting for the same set of mailbox registers, not
designed for multiple requests at a time. So either request has to be
synchronous and spin under the lock, or it should be sent asynchronously
through the queues as Mailbox Command IOCB or some other way.

This removes any OS specifics from the wait code, so it can be inlined.

Implement request queue overflow protection.

Before this change in case of request queue overflow driver just froze the
device queue for 100ms to retry after. It was pretty bad for performance.
This change introduces SIM queue freezing when free space on the request
queue drops below 255 entries (worst case of maximum I/O size S/G list),
checking for a chance to release it on I/O completion. If the queue still
get overflowed somehow, the old mechanism is still in place, just with
delay reduced to 10ms.

With the earlier queue length increase overflows should not happen often,
but it is still easily reachable on synthetic tests.

Fix build after 367926.

Option ISP_TARGET_MODE is evil.

Make handlers and atpds overflows unlikely.

- Allocate 256 handlers more than payload commands for management purposes.
- Increase maximum number of handlers from 8K to 16K by tuning the format.
- Just to be safe limit the number of payload commands to 16K - 256.
- Limit number of target exchanges in mixed mode to the number of atpds.
- If we still somehow get out of atpds -- return BUSY, since we really are.

Remove remnants of execthrottle and maxalloc parameters.

The first was obsolete since 26xx, not used on 25xx and not needed on 24xx.
The second seems never worked on 24xx and up.

Increase queue depths from 1024/256 to 8192/1024 IOCBs.

Qlogic chips store S/G lists in the same queue as requests themselves. In
the worst case 1MB I/O may require up to 52 IOCBs, that means queue of 1024
IOCBs can store only 19 of such requests. The increase reduces chances of
overflow, while we should be able to afford additional 512KB of RAM per HBA.
The Linux driver uses comparable numbers.

While there, decouple ATIO queue size from response queue size. There is
no reason for them to be equal.

Cleanup DMA handling.

- Make isp_start() to set all the IOCB fields aside of S/G list, removing
extra information from isp_send_cmd(), now only doing S/G lists and sending.
- Turn DMA setup/free from being card and PCI-specific into OS-specific,
instead add new card-specific method for isp_send_cmd(). Previously this
function was a monster handling all the cards.
- Remove double error code translation.

Remove parallel SCSI and 1/2Gb FC support from isp(4).

This removes 288KB (36%) of the driver code and zillions of hacks and
workarounds, making single driver uniformly support several different
generations of hardware interfaces, not counting minor card variations.
After years of the hopeless fight, I don't think it worth to continue
support for hardware obsolete for 15-20 years. Instead much cleaner
now code should allow to move forward toward better locking, multiple
queues and other cool features.

All the remaining Qlogic cards starting from 4Gb 24xx to 32Gb 27xx use
the same hardware/firmware interface with minor incremental improvements,
so it seems to be a good new starting point. Except one PCI-X model all
all of them are PCIe and so still usable in modern systems.

Discussed with: ken, scottl, jpaetzel, imp
Relnotes: yes

Introduce support of SCSI Command Priority.

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.

MFC after: 1 month
Relnotes: yes
Sponsored by: iXsystems, Inc.

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
MFC after: 3 days

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.

MFC after: 1 week
Sponsored by: Spectra Logic
Differential Revision: https://reviews.freebsd.org/D19472

Increase ABOUT FIRMWARE command timeout to 5s.

It seems default timeout of 100ms is not enough for my 2694L card,
while it was perfectly fine for others, even for full-height 2694.

MFC after: 1 week
Sponsored by: iXsystems, Inc.

Add support for Enhanced Gen 5 (16Gb) and Gen 6 (32Gb) QLogic FC HBAs.

MFC after: 2 weeks
Sponsored by: iXsystems, Inc.

sys/dev: further adoption of SPDX licensing ID tags.

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.

Remove duplicate assignments from r321622.

Submitted by: mav
MFC after: 3 days
Sponsored by: Spectra Logic

Fix probing FC targets with hard addressing turned on.

This largely reverts FreeBSD SVN change 289937 from October 25th, 2015.

The intent of that change was to keep loop IDs persistent across
chip reinits.

The problem is that the change turned on the PREVLOOP /
PREV_ADDRESS bit (bit 7 in Firmware Options 2), which tells the
Qlogic chip to not participate in the loop if it can't get the
requested loop address. It also turned off soft addressing on 2400
(4Gb) and newer controllers.

The isp(4) driver defaults to loop address 0, and the tape drives
I have tested default to loop address 0 if hard addressing is turned
on. So when hard loop addressing is turned on on the drive, the isp(4)
driver just refuses to participate in the loop.

The solution is to largely revert that change. I left some elements
in place that are related to virtual ports, since they were new.

This does work with IBM tape drives with hard and soft addressing
turned on. I have tested it with 4Gb, 8Gb, and 16Gb controllers.

sys/dev/isp.c:
Largely revert FreeBSD SVN change 289937. I left the
ispmbox.h changes in place.

Don't use the PREV_ADDRESS bit on initialization. It tells
the chip to not participate if it can't get the requested
loop ID.

Do use soft addressing on 2400 and newer chips.

Use hard addressing when the user has requested a specific
initiator ID. (hint.isp.X.iid=N in /boot/loader.conf)

Leave some of the virtual port options from that change in
place, but don't turn on the PREV_ADDRESS bit.

Reviewed by: mav
MFC after: 3 days
Sponsored by: Spectra Logic

"Port Type not registered" is not a real error for GIT_PT.

Switch fabric scans from GID_FT to GID_PT+GFF_ID/GFT_ID.

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.

Move comment respecting previous commit.

Slightly unify SNS requests for post- and pre-24xx.

Correct loop mode CRN resets to adhere to FCP-4 section 4.10

Prior to this change, the CRN (Command Reference Number) is reset on any
firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which
specifies that the CRN should only be reset in response to a LIP Reset
(LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS
actions as conditions for resetting the CRN for the associated initiator
port.

These violations manifest themselves when the HBA is removed from the
loop, or a target device is removed (especially during an outstanding
command) without power cycling. If the HBA and and the target device
determine upon re-establishing the loop that no PLOGI or PRLI is
required, and the target does not issue a LIPxy to the initiator, the
CRN for the target will have been improperly reset by the isp driver. As
a result, the target port will silently ignore all FCP commands issued
during the device probe (which will time out) preventing the device from
attaching.

This change corrects thie CRN reset behavior in response to loop state
changes, also introduces CRN resets for the above mentioned ELS actions
as encountered through async PDB change events.

This change also adds cleanup of outstanding commands in isp_loop_dead()
that was previously missing.

sys/dev/isp/isp.c
Add the last login state to debug output when syncing the pdb

sys/dev/isp/isp_freebsd.c
Replace binary statement setting aborted ccb status in
isp_watchdog() with the XS_SETERR macro used elsewhere

In isp_loop_dead(), abort or complete pending commands as done
in isp_watchdog()

In isp_async(), segregate the ISPASYNC_LOOP_RESET action from
ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP
fallthroughs, and only reset the CRN in the RESET case. Also add
checks to handle false LOOP RESET actions that do not have a
proper associated LIP primitive, and log the primitive in the
debug messages

In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and
only reset the CRN in the DEV_CHANGED action

In isp_async(), when processing an ISPASYNC_CHANGE_PDB status,
reset CRN(s) for the associated nphdl (or all ports) if the
change reason is some form of ELS login/logout. Also remove
assignment to fc since it is not used in the scope

sys/dev/isp/ispmbox.h
Add macro definition for the global N-Port handle, and correct a
macro typo 'PDB24XX_AE_PRLI_DONJE'

sys/dev/isp/ispvar.h
Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for
more legible code when determining if an AL_PD port matches the
portid for a given struct fcparam* by value or by virtue of the
AL_PD port being 0xFF

Submitted by: Reid Linnemann
Sponsored by: Spectra Logic
MFC after: 1 week

Switch isp_reset to scratchpad not requiring ISP_MBOXDMASETUP.

MFC after: 1 week

Fix few minor issues found by Clang Analyzer.

MFC after: 2 weeks

Cleanup response queue processing.

MFC after: 2 weeks

Improve command timeout handling.

Let firmware do its best first, and if it can't, try software recovery.
I would remove software timeout handler completely, but found bunch of
complains on command timeout on sparc64 mailing list few years ago, so
better be safe in case of interrupt loss.

MFC after: 2 weeks

Remove questionable reqp->req_time access.

MFC after: 2 weeks

Remove some useless code.

MFC after: 2 weeks

Add initial support for multiple MSI-X vectors.

For 24xx and above use 2 vectors (default and response queue).
For 26xx and above use 3 vectors (default, response and ATIO queues).
Due to global lock interrupt hardlers never run simultaneously now, but
at least this allows to save one regitster read per interrupt.

MFC after: 2 weeks

Remove hackish code delaying ATIOs to unknown virtual port.

Since we support RQSTYPE_RPT_ID_ACQ, that functionality is only useful
in loop mode, which probably doesn't worth having this hack in 2017.

MFC after: 2 weeks

Remove dead remnants of SPI target.

MFC after: 2 weeks

Refactor interrupt handling.

Instead of single isp_intr() function doing all possible magic, introduce
four different functions to handle mailbox operation completions, async
events, response and ATIO queues. The goal is to isolate different code
paths to make code more readable, and to make easier support for multiple
interrupt vectors. Even oldest hardware in many cases can identify what
code path it should run on interrupt. Contemporary hardware can assign
them to different interrupt vectors.

MFC after: 2 weeks

Remove some dead/broken code paths around async handling

MFC after: 2 weeks

Remove tangled isp_mbox_continue() mechanism.

It was implemented to reduce context switches when uploading firmware to
card's RAM. But this mechanism is not used last 10 years since all mbox
operations are now polled, and it was never used for cards produced in
last 15 years. Newer cards can use DMA to upload firmware.

MFC after: 2 weeks

Remove dangerous and questionable isp_mboxcmd_qnw() call.

MFC after: 2 weeks

Improvements around attach, reset and detach.

This change fixes DMA resource leak on driver unload. Also it removes
DMA resources allocation for hardcoded number of requests before fetching
the real number from firmware. Also it prepares ground for more flexible
IRQs allocation according to firmware capabilities.

MFC after: 2 weeks

Try to slight untangle I/O and loop status handling.

MFC after: 2 weeks

Remove code for unsupported FreeBSD versions.

MFC after: 2 weeks

Send TERMINATE to firmware when aborting active ATIO.

MFC after: 2 weeks

Return better error code in case of too long CDB.

Its more important for SPI HBAs, as they don't support CDBs above 12 bytes.
The new error code makes CAM to fall back to alternative commands.

MFC after: 2 weeks

Change the isp(4) driver to not adjust the tag type for REQUEST SENSE.

The isp(4) driver was changing the tag type for REQUEST SENSE
commands to Head of Queue, when the CAM CCB flag
CAM_TAG_ACTION_VALID was NOT set. CAM_TAG_ACTION_VALID is set
when the tag action in the XPT_SCSI_IO is not CAM_TAG_ACTION_NONE
and when the target has tagged queueing turned on.

In most cases when CAM_TAG_ACTION_VALID is not set, it is because
the target is not doing tagged queueing. In those cases, trying to
send a Head of Queue tag may cause problems. Instead, default to
sending a simple tag.

IBM tape drives claim to support tagged queueing in their standard
Inquiry data, but have the DQue bit set in the control mode page
(mode page 10). CAM correctly detects that these drives do not
support tagged queueing, and clears the CAM_TAG_ACTION_VALID flag
on CCBs sent down to the drives.

This caused the isp(4) driver to go down the path of setting the
tag action to a default value, and for Request Sense commands only,
set the tag action to Head of Queue.

If an IBM tape drive does get a Head of Queue tag, it rejects it with
Invalid Message Error (0x49,0x00). (The Qlogic firmware translates that
to a Transport Error, which the driver translates to an Unrecoverable
HBA Error, or CAM_UNREC_HBA_ERROR.) So, by default, it wasn't possible
to get a good response from a REQUEST SENSE to an FC-attached IBM
tape drive with the isp(4) driver.

IBM tape drives (tested on an LTO-5 with G9N1 firmware and a TS1150
with 4470 firmware) also have a bug in that sending a command with a
non-simple tag attribute breaks the tape drive's Command Reference
Number (CRN) accounting and causes it to ignore all subsequent
commands because it and the initiator disagree about the next
expected CRN. The drives do reject the initial command with a head
of queue tag with an Invalid Message Error (0x49,0x00), but after that
they ignore any subsequent commands. IBM confirmed that it is a bug,
and sent me test firmware that fixes the bug. However tape drives in
the field will still exhibit the bug until they are upgraded.

Request Sense is not often sent to targets because most errors are
reported automatically through autosense in Fibre Channel and other
modern transports. ("Modern" meaning post SCSI-2.) So this is not
an error that would crop up frequently. But Request Sense is useful on
tape devices to report status information, aside from error reporting.

This problem is less serious without FC-Tape features turned on,
specifically precise delivery of commands (which enables Command
Reference Numbers), enabled on the target and initiator. Without
FC-Tape features turned on, the target would return an error and
things would continue on.

And it also does not cause problems for targets that do tagged
queueing, because in those cases the isp(4) driver just uses the
tag type that is specified in the CCB, assuming the
CAM_TAG_ACTION_VALID flag is set, and defaults to sending a Simple
tag action if it isn't an ordered or head of queue tag.

sys/dev/isp/isp.c:
In isp_start(), don't try to send Request Sense commands
with the Head of Queue tag attribute if the CCB doesn't
have a valid tag action. The tag action likely isn't valid
because the target doesn't support tagged queueing.

Sponsored by: Spectra Logic
MFC after: 3 days

"Buses" is the preferred plural of "bus"

Replace archaic "busses" with modern form "buses."

Intentionally excluded:
* Old/random drivers I didn't recognize
* Old hardware in general
* Use of "busses" in code as identifiers

No functional change.

http://grammarist.com/spelling/buses-busses/

PR: 216099
Reported by: bltsrc at mail.ru
Sponsored by: Dell EMC Isilon

Fix delaying requests to unknown virtual ports 2s after init.

This code was originally implemented 7 years ago, but never really worked
due to trivial error. I think this functionality may be not required.
Initiators supporting optional periodic command status checks detected
those terminated commands and retried them 3 seconds later. But thinking
about less featured initiators and the fact that it is our race makes
virtual ports "unknown" it may be good to have this feature.

Add IOCB debugging for ISPCTL_RESET_DEV and ISPCTL_ABORT_CMD.

Make RQCS_PORT_LOGGED_OUT for ZOMBIE ports retriable.

It is normal for ZOMBIE ports to be logged out. This status is not really
an error until Gone Device Timeout expires, so make CAM retry after delay.

MFC after: 1 week

Completely remove broken now autologin port flag.

Firmware automatically logs in only to local loop ports, and those ports
can be easily identified without extra flag by zero domain and area IDs.

MFC after: 1 week

No need to check login status for ZOMBIE ports.

ZOMBIE ports are always logged out, and so initiator may try to relogin.

MFC after: 1 weeks

sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

Simplify memory allocation for NS requests.

Since we no longer need additional buffers for request and response IOCBs,
we can increase receive space by 192 bytes, that is enough for fetching 48
more ports. The new limit is 1020 fabric ports per virtual port.

MFC after: 1 month

Extract virtual port address from RQSTYPE_RPT_ID_ACQ.

This should close the race between request arriving on new target mode
virtual port and its scanner thread finally fetch its address for request
routing.

Filter Port Database Changed notifications.

For some reason firmware sends Port Database Changed notifications in case
of explicit login requests from the driver when target port is unavailabe.
Those notifications don't give driver any new information, but only cause
infinite scan loop.

Respect NVRAM topology settings on 24xx and above chips.

Make all CT Pass-Through (name server requests) asynchronous.

Previously we had to do it synchronously because we could not drop the lock
due to potential scratch memory use conflicts. Previous commits fixed that
collision, so here it goes -- slower and less reliable external requests
are executed asynchronously without spinning in tight loop and with more
safe timeout handling.

Switch isp_getpdb() to synchronous IOCB DMA area.

While technically it is not IOCB, it is synchronous and can be called from
different places, so calling FC_SCRATCH_ACQUIRE() here is inconvenient.

Allocate separate DMA area for synchronous IOCB execution.

Usually IOCBs should be put on queue for asynchronous processing and should
not require additional DMA memory. But there are some cases like aborts and
resets that for external reasons has to be synchronous. Give those cases
separate 2*64 byte DMA area to decouple them from other DMA scratch area
users, using it for asynchronous requests.

Add couple missing memory barriers.

Polish debugging IOCB dumping.

Add few more missing cases, unify byte order.

MFC after: 1 month

Register symbolic port/node names in FC name server.

This is cosmetics that simplifies identification of new ports on FC switch.

It would be good to use target name from CTL here instead of hostname, but
it is not passed here through CAM now.

MFC after: 2 weeks

Reduce code duplication when executing Passthrough IOCB.

MFC after: 2 weeks

Allocate separate scratch space for scanner purposes.

This space does not require DMA syncing. It reduces lock scope of the DMA
scratch space. It allows whole DMA scratch space to be used to I/O, so now
we can fetch up to ~1000 ports from SNS.

Due to the last fact, increase maximal number of ports from 256 to 1024.

Make port logins asynchronous, following r292739 logic.

This is even more important since it involves more network operations and
more prone to delays and timeouts.

Make virtual ports control asynchronous.

Before this change virtual ports control IOCBs were executed synchronously
via Execute IOCB mailbox command. It required exclusive use of scratch
space of driver and mailbox registers of the hardware. Because of that
shared resources use this code could not really sleep, having to spin for
completion, blocking any other operation.

This change introduces new asynchronous design, sending the IOCBs directly
on request queue and gracefully waiting for their return on response queue.
Returned IOCBs are identified with unified handle space from r292725.

Unify handles allocation for initiator and target IOCBs.

I am not sure why this was split long ago, but I see no reason for it.
At this point this unification just slightly reduces memory usage, but
as next step I plan to reuse shared handle space for other IOCB types.

Clear virtual port's port database when disabling it.

Previously it was done only on full chip reinit, that caused old ports
resurrect in case of virtual port reenabling.

Some polishing for command timeouts handling.

Fix speed setting by NVRAM for 24xx and above chips.

Guess NVRAM address for 16Gbps Qlogic cards.

I have feeling this approach is wrong, but it works for me so far and
it is better then nothing.

There is no priority request queue on 16Gig chips.

Enable interrupt handshake for 16Gig chips.

We don't support MSI-X so far, so it is always required.

Add initial support for 16Gbps FC QLogic chips.

I still don't know how to read NVRAM there, so WWNs and other parameters
are incorrect, but other then that driver seems like attaching normally.

One more round of port scanner rewrite.

- Make scan aborted by event restart immediately and infinitely.
- Improve handling of some loop events from firmware.
- Remove loop down timer, adding its functionality to scanner thread.
- Some more unification and simplification.

Rename ASYNC_LIP_F8 to ASYNC_LIP_NOS_OLS_RECV.

New name better repsents its meaning for modern chips.

Fix target mode support for Qlogic 2200 FC adapters.

Now target mode works for all supported FC adapters except ancient 2100,
which is not tested.

Rip off target mode support for parallel SCSI QLogic adapters.

Hacks to enable target mode there complicated code, while didn't really
work. And for outdated hardware fixing it is not really interesting.

Initiator mode tested with Qlogic 1080 adapter is still working fine.

Explicitly call SEND CHANGE REQUEST for pre-24xx chips in target mode.

While later firmware always registers for RSCN requests, older one does
it only in initiator mode. But in target mode there RSCN can be the only
way to detect gone intiator.

Gracefully stop firmware before resetting chip when changing role.

Add some more asynchronous event status codes.

Add mode mailbox command codes.

Fix target mode with fabric for pre-24xx chips.

For those chips we are not receiving login events, adding initiators
based on ATIO requests. But there is no port ID in that structure, so
in fabric mode we have to explicitly fetch it from firmware to be able
to do normal scan after that.

Some cosmetics for ancient cards.

Optimize SNS_GID_FT request scratch memory usage.

Now with present 4K of scratch we can fetch up to 508 ports (16 more).

Another round of port scanner rewrite.

This change simplifies and unifies port adding/updating for loop and
fabric scanners. It also fixes problems with scanning restarts due to
concurrent port databases changes. It also fixes many cosmetic issues.

Simplify fabric tasting code.

Except cosmetic changes this removes fabric ports from our port database.
It is always firmware duty to manage them, so driver don't need to worry.

Remove some confusions between loopid and nphdl.

Modern cards in most cases operate abstract port handles, that have no
any relation to real loop IDs. Leave loopid used only where it really
goes about local loop IDs.

While there, fix few more cases where LUNs were still printed in decimal.

Register our FC4 Features in SNS.

Cosmetic addition to r290993.

Unify and cleanup FC ports scan.

Off-by-one correctiont to r290980.

Make firmware handle virtual ports SNS logins for us.

Add real initial support for RQSTYPE_RPT_ID_ACQ.

Rework r290504.

Specify VP when sending a marker.

Make ISP_SLEEP() really sleep instead of spinning.

While there, simplify the wait logic.

Remove some unneeded code.

Remove reset delays for which I see neither explanation nor need.

Fix and improve error masking and reporting.

Change the way how target mode is enabled on 23xx chips.

Without docs I am not completely sure about this, but on my tests new
method works better then previous, at least with our latest firmware.

Improve/fix loop scanning routine.

For the most of chips (except anscient ones) port handlers have no relation
to port IDs. In such situation old code scanning first 125 handlers was
quite naive. Instead of doing that, send to chip single request to get full
list of port handlers available on specific virtual port and scan only them.

Old code had problems with case of several virtual ports enabled, when port
handlers allocated from global address space could easily go above 125.
This change was successfully tested on 23xx, 24xx and 25xx chips in loop
mode with 4 virtual initiator ports, each seing 50 virtual target ports.

Reimplement next port handle generation.

For some reason port handles should be allocated from HBA-global space,
while old code was not very specific, mixing per-HBA and per-VP logic.

Reimplement enable and implement disable of virtual ports.

Now on 24xx and above chips it is really possible to simulate several
virtual FC ports with single physical one. For example, it allows to
configure several targets in ctl.conf, assign each of them to separate
virtual port, and let user to control access to them with switch zoning.

I still doubt that all problems are solved there, but at now it passes
at least basic tests.

Rework r289933 using already existing macro.

Try to keep Loop IDs persistent across chip reinits.

Improve Port Database Changed handling and reporting.

Formalize/unify chip (re-)inits.

Skip reserved IP Broadcast handle from using.

Add PIM_EXTLUNS support to isp(4) driver.

Now 24xx and above chips support full 8-byte LUN address space.
Older FC chips may support up to 16K LUNs when firmware allows.
Tested in both initiator and target modes for 23xx, 24xx and 25xx.

Decode few more response info codes.

Though CAM still does not send any requests that would require those.

Some polishing and unification in ISR code.

Some more defines and polishing for INIT_FIRMWARE.

Zero mbox[0] for INIT_FIRMWARE to fix version 7.3 firmware.

While there, add new fields to isp_icb_2400_t structure.

Decode more firmware attributes.

MULTI_ID supported does not mean it is used.

Unify port database use for target and initiator roles.

Aside from cleaner and more consistent code, this allows ports to be both
target and initiator same time, and easily switch from any role to any.

Sponsored by: iXsystems, Inc.

Remove extra level of target ID indirection (isp_dev_map).

FreeBSD never had limitation on number of target IDs, and there is no
any other requirement to allocate them densely. Since slots of port
database already populated just sequentially, there is no much need
for another indirection to allocate sequentially too.

Drop discovered targets when initiator role is disabled.

Remove limitations on setting WWNNs starting from 2.

It is odd that driver first tries to generate synthetic WWNN based on
WWPN starting from 2, but then refuses to use it. If we don't trust
generated WWNN, we should probably not generate it. Same time this
limitation prevents potentially valid WWNN setting by user.

Dump additional config bytes for INIT_FIRMWARE_MULTI_ID.

Add logging of executed mailbox command names.

Previously those commands were logged only as part of register dump,
that is not very readable.

Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards.

The newer boards don't have the response field that indicates
whether the SCSI status byte is present. You have to just look to
see whether it is non-zero.

The code was looking to see whether the sense length was valid
before propagating the SCSI status byte (and sense information) up
the stack. With a status like Reservation Conflict, there is no
sense information, only the SCSI status byte. So it wasn't getting
correctly returned.

isp.c:
In isp_intr(), if we are on a 2400 or 2500 type board and
get a response, look at the actual contents of the
SCSI status value and set the RQSF_GOT_STATUS flag
accordingly so that return any SCSI status value we get. The
RQSF_GOT_SENSE flag will get set later on if there is
actual sense information returned.

Submitted by: ken
MFC after: 1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 1112791 on 2015/01/15

Fix incorrect check, blocking MULTIID functionality.

MFC after: 1 week

Harvest one no longer used constant string.

Remove another and place it into play in the
normally ifdef protected zone it would be used
int.

Noticed by: dim

Some more registers access optimizations:
- Process ATIO queue only if interrupt status tells so;
- Do not update queue out pointers after each processed command, do it
only once at the end of the loop.

Optimize isp(4) to reduce CPU usage, especially in target mode:
- Remove two excessive and slow register reads from isp_intr(). Instead
of rereading value every time, assume that registers contain what we have
written there.
- Avoid sequential search through 4096 array elements when looking for
command tag. Use hash of lists to store active tags separately from free
ones and so greatly speedup the searches.

Reviewed by: mjacob

When fiddling with options of which registers to copy out for
a mailbox command and which registers to copy back in when
the command completes, the bits being set need to not only
specify what bits you want to add from the default from the
table but also what bits you want *subtract* (mask) from the
default from the table.

A failing ISP2200 command pointed this out.

Much appreciation to: marius, who persisted and narrowed down what
the failure delta was, and shamed me into actually fixing it.
MFC after: 1 week

Turn off fast posting for the ISP2100- I'd forgotten that it actually
might have been enabled for them- now that we use all 32 bits of handle.
Fast Posting doesn't pass the full 32 bits.

Noticed by: Bugs in NetBSD. Only a NetBSD user might actually still use such old hardware.
MFC after: 1 week

Remove extraneous newline.

MFC after: 1 month

-----------
MISC CHANGES

Add a new async event- ISP_TARGET_NOTIFY_ACK, that will guarantee
eventual delivery of a NOTIFY ACK. This is tons better than just
ignoring the return from isp_notify_ack and hoping for the best.

Clean up the lower level lun enable code to be a bit more sensible.

Fix a botch in isp_endcmd which was messing up the sense data.

Fix notify ack for SRR to use a sensible error code in the case
of a reject.

Clean up and make clear what kind of firmware we've loaded and
what capabilities it has.
-----------
FULL (252 byte) SENSE DATA

In CTIOs for the ISP, there's only a limimted amount of space
to load SENSE DATA for associated CHECK CONDITIONS (24 or 26
bytes). This makes it difficult to send full SENSE DATA that can
be up to 252 bytes.

Implement MODE 2 responses which have us build the FCP Response
in system memory which the ISP will put onto the wire directly.

On the initiator side, the same problem occurs in that a command
status response only has a limited amount of space for SENSE DATA.
This data is supplemented by status continuation responses that
the ISP pushes onto the response queue after the status response.
We now pull them all together so that full sense data can be
returned to the periph driver.

This is supported on 23XX, 24XX and 25XX cards.

This is also preparation for doing >16 byte CDBs.

-----------
FC TAPE

Implement full FC-TAPE on both initiator and target mode side. This
capability is driven by firmware loaded, board type, board NVRAM
settings, or hint configuration options to enable or disable. This
is supported for 23XX, 24XX and 25XX cards.

On the initiator side, we pretty much just have to generate a command
reference number for each command we send out. This is FCP-4 compliant
in that we do this per ITL nexus to generate the allowed 1 thru 255
CRN.

In order to support the target side of FC-TAPE, we now pay attention
to more of the PRLI word 3 parameters which will tell us whether
an initiator wants confirmed responses. While we're at it, we'll
pay attention to the initiator view too and report it.

On sending back CTIOs, we will notice whether the initiator wants
confirmed responses and we'll set up flags to do so.

If a response or data frame is lost the initiator sends us an SRR
(Sequence Retransmit Request) ELS which shows up as an SRR notify
and all outstanding CTIOs are nuked with SRR Received status. The
SRR notify contains the offset that the initiator wants us to restart
the data transfer from or to retransmit the response frame.

If the ISP driver still has the CCB around for which the data segment
or response applies, it will retransmit.

However, we typically don't know about a lost data frame until we
send the FCP Response and the initiator totes up counters for data
moved and notices missing segments. In this case we've already
completed the data CCBs already and sent themn back up to the periph
driver. Because there's no really clean mechanism yet in CAM to
handle this, a hack has been put into place to complete the CTIO
CCB with the CAM_MESSAGE_RECV status which will have a MODIFY DATA
POINTER extended message in it. The internal ISP target groks this
and ctl(8) will be modified to deal with this as well.

At any rate, the data is retransmitted and an an FCP response is
sent. The whole point here is to successfully complete a command
so that you don't have to depend on ULP (SCSI) to have to recover,
which in the case of tape is not really possible (hence the name
FC-TAPE).

Sponsored by: Spectralogic
MFC after: 1 month

Fix typo in a message.

Obtained from: DragonFly BSD (change 7a817ab191e4898404a9037c55850e47d177308c)
MFC after: 3 days

Unbreak register tests for parallel SCSI.
You can't overwrite registers 7 and 8.
MFC after: 3 days

Clean up multi-id mode so it's driven by the f/w loaded,
not by some hint setting. Do more preparations for FC-Tape.
Clean up resource counting for 24XX or later chipsets so
we find out after EXEC_FIRMWARE what is actually supported.
Set target mode exchange count based upon whether or not
we are supporting simultaneous target/initiator mode. Clean
up some old (pre-24XX) xfwoption and zfwoption issues.

Sponsored by: Spectralogic
MFC after: 3 days

Prepare for FC-Tape support. This involved doing a lot of little cleanups
and crosschecks against firmware documentation. We now check and report
FC firmware attributes and at least are now prepared for the upper 48 bits
of f/w attributes (which are probably for the 8100 or later cards). This
involed changing how inbits and outbits are calculated for varios commands,
hopefully clearer and cleaner. This also caused me to clean up the actual
mailbox register usage. Finally, we are now unconditionally using a CRN
for initiator mode.

A longstanding issue with the 2400/2500 is that they do *not* support
a "Prefer PTP followed by loop", which explains why enabling that
caused the f/w to crash.

A slightly more invasive change is to let the firmware load entirely
drive whether multi_id support is enabled or not.

Sponsored by: Spectralogic
MFC after: 1 week

Clean up and complete the incomplete deferred enable code.
Make the default role NONE if target mode is selected. This
allows ctl(8) to switch to/from target mode via knob settings.
If we default to role 'none', this causes a reset of the
24XX f/w which then causes initiators to wake up and notice
when we come online.

Reviewed by: kdm
MFC after: 2 weeks
Sponsored by: Spectralogic

Was chasing down a failure to load f/w on a 2400. It turns out that the card
is actually broken, or needs a BIOS upgrade for 64 bit loads, but this uncovered
a couple of misplaced opcode definitions and some missing continual mbox command
cases, so might as well update them here.

Most of these changes to isp are to allow for isp.ko unloading.
We also revive loop down freezes. We also externaliz within isp
isp_prt_endcmd so something outside the core module can print
something about a command completing. Also some work in progress to
assist in handling timed out commands better.

Partially Sponsored by: Panasas
Approved by: re (kib)
MFC after: 1 month

Sync FreeBSD ISP with mercurial tree. Minor changes having to do with
a macro for minima.

- Use the correct DMA tag/map pair for synchronize the FC scratch area.
- Allocate coherent DMA memory for the request/response queue area and
and the FC scratch area.

These changes allow isp(4) to work properly on sparc64 with usage of the
IOMMU streaming buffers enabled.

Approved by: mjacob
MFC after: 2 weeks

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.

Be more specific about which CDB length we're going to use. Not really a likely
bug but we might as well be clearer.

Found with: Coverity Prevent(tm)
CID: 3981

MFC after: 2 weeks

Various minor and not so minor fixes suggested by Coverity.
In at least one case, it's amazing that target mode worked at all.

Found by: Coverity.
MFC after: 2 weeks

This is an MFC of 204050.

Don't try and re-use a handle, even if the firmware tells you that's what is logged in.

PR: kern/144026

This is an MFC of 205698

Clean up some printing stuff so that we can have a bit finer control
on debug output. Add a new platform function requirement to allow
for printing based upon the ITL nexus instead of the isp unit plus
channel, target and lun. This allows some printouts and error messages
from the core code to appear in the same format as the platform's
subsystem (in FreeBSD's case, CAM path).

Clean up some printing stuff so that we can have a bit finer control
on debug output. Add a new platform function requirement to allow
for printing based upon the ITL nexus instead of the isp unit plus
channel, target and lun. This allows some printouts and error messages
from the core code to appear in the same format as the platform's
subsystem (in FreeBSD's case, CAM path).

MFC after: 1 week

MFC of 204397: fix problems with fast posting handles

Revamp the pieces of some of the stuff I forgot to do when shifting to
32 bit handles. The RIO (reduced interrupt operation) and fast posting
for the parallel SCSI cards were all 16 bit handles. Furthermore,
target mode parallel SCSI only can have 16 bit handles.

Use part of a supplied patch to switch over to using 32 bit handles.
Be a bit more conservative here and only do this for parallel SCSI
for the 12160 (Ultra3) cards. There were a lot of marginal Ultra2
cards, and, frankly, few are findable now for testing.

Fix the target handle routine to only do 16 bit handles for parallel
SCSI cards. This is okay because the upper sixteen bits of the new
32 bit handles is a sequence number to help protect against duplicate
completions. This would be very unlikely to happen with parallel
SCSI target mode, and wasn't present before, so we're no worse off
than we used to be.

While we're at it, finally split the async mailbox completion handlers
into FC and parallel SCSI functions. This makes it much cleaner and
easier to figure out what is or isn't a legal async mailbox completion
code for different card classes.

PR: kern/144250
Submitted partially by: Charles D
MFC after: 1 week

Don't try and re-use a handle, even if the firmware tells you that's what is logged in.

PR: kern/144026
MFC after: 1 week

Pick up some changes the the MFC missed.

MFC a number of changes from head for ISP (203478,203463,203444,202418,201758,
201408,201325,200089,198822,197373,197372,197214,196162). Since one of those
changes was a semicolon cleanup from somebody else, this touches a lot more.

Redo how commands handles are created and managed and implement sequence
numbers and handle types in rational way. This will better protect from
(unwittingly) dealing with stale handles/commands.

Fix the watchdog timeout code to better protect itself from mistakes.

If we run an abort on a putatively timed out command, the command
may in fact get completed, so check to make sure the command we're
timing it out is still around. If the abort succeeds, btw, the command
should get returned via a different path.

Amazingly we've been freeing a handle and using that which it refers to
for years. Bad!

MFC after: 1 week

Remove extraneous semicolons, no functional changes.

Submitted by: Marc Balmer <marc@msys.ch>
MFC after: 1 week

Make sure that the WWNN is also created for 2100..2300 cards.
MFC after: 1 day

Create a Node WWN from the *Port* WWN, not vice versa, for 2400s.

If the NAA is type 2, the Node WWN is the Port WWN with the 12 bits
of port (48..60) cleared. This iff a wwn fetched from NVRAM is zero.

MFC after: 1 week

(semiforced commit to add comment missed in last delta)
Add a maximum response length for FCP RSPNS IUs.

Clarify some of the FC option words for setting parameters
and try and disable automatic PRLI when in target mode- this
should correct some cases of N-port topologies with 23XX cards
where we put out an illegal PRLI (in target mode only we're
not supposed to put out a PRLI).

Remove file unused in freebsd.

Accomodate old style XPT_IMMED_NOTIFY and XPT_NOTIFY_ACK so that
we at least don't panic.

We don't really support dual role mode (INITIATOR/TARGET) any more. We
should but it's broken and will take a fair amount of effort to fix
and correctly manage both initiator and target roles sharing the port
database. So, for now, disallow it.

Add 8Gb support (isp_2500). Fix a fair number of configuration and
firmware loading bugs.

Target mode support has received some serious attention to make it
more usable and stable.

Some backward compatible additions to CAM have been made that make
target mode async events easier to deal with have also been put
into place.

Further refinement and better support for NP-IV (N-port Virtualization)
is now in place.

Code for release prior to RELENG_7 has been stripped away for code clarity.

Sponsored by: Copan Systems

Reviewed by: scottl, ken, jung-uk kim
Approved by: re

Don't try reading the SXP_PINS_DIFF on the 10160 and 12160 SCSI
controllers. Reading this register, for which there are indications
that it doesn't really exist, returns 0 on at least some 12160
and doing so on Sun Fire V880 causes a data access error exception.

Reported and tested by: Beat Gaetzi
Approved by: mjacob
Obtained from: OpenBSD (modulo setting isp_lvdmode)

- Import the HEAD csup code which is the basis for the cvsmode work.

Be more conservative- turn off fast posting and RIO for 22XX cards.

Approved by: re (ken)
MFC after: 3 days

Recover from some major omissions/problems with the 24XX port.
First, we were never correctly checking for a 24XX Status Type 0
response- that cased us to fall through to evaluate status for
commands as if this were a 2100/2200/2300 Status Type 0 response.
This is *close*, but not quite the same. This has been reported
to be apparent with some wierd lun configuration problems with
some arrays. It became glaringly apparent on sparc64 where none
of the correct byte swap things were done.

Fixing this omission then caused a whole universe shifting debug
cycle of endian issues for the 2400. The manual for 24XX f/w turns
out to be wrong about the endianness of a couple of entities. The
lun and cdb fields for the type 7 request are *not* unconditionally
big endian- they happen to be opposite of whatever the endian of
the current machine type is. Same with the sense data for the
24XX type 0 response.

While we're at it investigate and resolve some NVRAM endian
issues.

Approved by: re (ken)
MFC after: 3 days

If we're going to (for 23XX and 24XX cards) DMA firmware from the
request queues rather than shove it down a word at a time, we have
to remember to put it into little endian format. Use the macros
ISP_IOXPUT_{16,32} for this purpose. Otherwise, on sparc the firmware
is loaded garbled and we get a (not surprisingly) firmware checksum
failure and the card won't start and we don't attach it.

Approved by: re (bruce)
MFC after: 3 days

Make this an MP safe driver but also still be multi-release.
Seems to work on RELENG_4 through -current and also on sparc64
now. There may still be some issues with the auto attach/detach
code to sort out.

MFC after: 3 days

some minor error message cleanups

MFP4: a) Some constification from NetBSD (gcc 4.1.2)
b) Split default param fetching/setting into scsi and fibre functions
and retry the fibre fetch more than once.

MFC after: 1 week

Don't call isp_intr from isp_start- this seems to, in rare cases,
cause confusion with at least the 23XX chipsets where the output
queue index pointer just gets a bit whacko.

MFC after: 1 day

Restore optr if you trash it for 24XX target mode.

MFC after: 3 days

Fix compilation issues found in RELENG_4 port and merge the
diffs back to -current to keep versions identical.

Fix some stupid copyright mistakes that have been there for quite some time.

Don't attempt to load illegal hard loop addresses into
an ICB. This shows up on card restarts, and usually for
2200-2300 cards. What happens is that we start up,
attempting to acquire a hard address. We end up instead
being an F-port topology, which reports out a loop id
of 0xff (or 0xffff for 2K Login f/w). Then, if we restart,
we end up telling the card to go off an acquire this loop
address, which the card then rejects. Bah.

Compilation fixes from Solaris port.

Be a bit more restrictive about printing out 'bad' pdb entries
during loop rescans. They're not bad so much as unstable, so
don't print this stuff out unless ISP_LOGSANCFG is set.

MFP4: Move default setting to the end of isp_reset instead of the
front of isp_init so we can read NVRAM even if we're role ISP_NONE.
Prepare for reintroduction of channels (for FC) for N-Port
Virtualization.

Fix a botch in handle assignment that caused us to nuke one device
when a new one arrives and end up with two devices with the same
identity in the virtual target mapping table.

Check the return from registering FC4 types with the fabric name
server.

Don't complain about a hard loop id of 0xffff- we get this in
point-to-point topologies with the 2300 and 2K Login firmware.

Up the timeout on register FC4 types commands.

Try an experiment with using DMA to load firmware into a 2200- VERIFY
CHECKSUM fails. Oh well, but keep a couple of the changes.

Avoid overflow in usec counters when waiting for mailbox completion.

Implement ISP_RESET0 for PCI and SBUS attachments- isp_reset has
been modified to call ISP_RESET0 if it fails to do a reset. This
gives us a chance to disable interrupts.

Make ISPCTL_PLOGX find a handle to log into the management server
with- not hope for the best. Change some things which were gated
off of 24XX to be gated off of 2K login support. Convert some
isp_prt calls to xpt_print calls.

Make the SAN login/logout stuff more common between different chipsets
and provied an isp_control entry point so that the outer layers can
do PLOGI/LOGO explicitly. Add MS IOCB support. This completes the cycle
for base support for SMI-S.

Increase the timeout for some SAN commands.

Only complain about FC Reponse errors if they're nonzero.

Shorten some PortID printouts for local loop.

Add an internal isp_xcmd_t data structure which we'll use for some
CT-Passthru support as part of adding SMI-S.

minor change to reduce some diff noise

Push things closer to path failover by implementing loop down and
gone device timers and zombie state entries. There are tunables
that can be used to select a number of parameters.

loop_down_limit - how long to wait for loop to come back up before
declaring
all devices dead (default 300 seconds)

gone_device_time- how long to wait for a device that has appeared
to leave the loop or fabric to reappear (default 30 seconds)

Internal tunables include (which should be externalized):

quick_boot_time- how long to wait when booting for loop to come up

change_is_bad- whether or not to accept devices with the same
WWNN/WWPN that reappear at a different PortID as being the 'same'
device.

Keen students of some of the subtle issues here will ask how
one can keep devices from being re-accepted at all (the answer
is to set a gone_device_time to zero- that effectively would
be the same thing).

Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.

fix bug in 2322 receive sequencer f/w load

Fix 2KLOGIN code to specify *ibits* (not *obits*) so that the
options field in register 10 will be deterministic, not random.

Correct the number of input bits for EXECUTE_FIRMWARE 0..1 to
0..2- the 2322 and 24XX cards use mailbox register 2 to specify
whether the f/w being executed is freshly loaded or not.

Correct the number of input bits for {READ,WRITE}_RAM_WORD_EXTENDED
so that register 8 gets picked up.

Fix the indexing and offset for the 2322 f/w download so that it
correctly puts the different code segments where they belong.

Move VERIFY_CHECKSUM to be the 'else' clause to 2322 f/w downloads-
the EXECUTE_FIRMWARE command for 2322 and 24XX cards will tell you
if the f/w checksum is incorrect and VERIFY_CHECKSUM only works for
RISC SRAM address < 64K so you can only do a VERIFY_CHECKSUM on the
first of the 3 f/w segments for the 2322.

Shorten the delay for the continuation mailbox commands- 1ms is
ridiculous (100us is more likely).

All of the more or less is really only for the 2322/6322 cards.

Remove reference to PTI cards. They haven't been functioning
or around for probably at least 5 years.

Initialize 2300 request/response pointers in isp_reset- not in
isp_fibre_init.

Some rearrangement of headers to minimize diffs with outside of
FreeBSD repository and to clean up the license header so as to
not pollute the license with file function.

Zero all mailbox structures prior to use (just in case). Change
the outgoing mailbox count for INIT_FIRMWARE to be correct.

Add some missing braces.

Add MEMORY_BARRIER for the few scratch dma ops that were missing
them plus add a couple of hi 32 bit dma ops (we could probably
allow 64 bit scratch and request/response queue dma now).

What the heck - make the last (most recent) 2200 f/w also do
Hard Loop acquisition.

Do various fixes to support firmware loading for the 2322
(and by extension, the 2422).

One peculiar thing I've found with the 2322 is that if you
don't force it to do Hard LoopID acquisition, the firmware
crashes. This took a while to figure out.

While we're at it, fix various bugs having to do with NVRAM
reading and option setting with respect to pieces of NVRAM.

Redo some code based upon issues found by Coverity.

Some more gratuitous format and name changes.

Pull in some target mode changes from a private branch.
Pull in some more RELENG_4 compilation changes.

A lot of lines changed, but not much content change yet.

a) clean up some declaration stuff (i.e., make more modern with respect
to getting rid u_int for uint and so on).

b) Turn back on 64 bit DAC support. Cheeze it a bit in that we have two
DMA callback functions- one when we have bus_addr_t > 4 bits in width and
the other which should be normal. Even Cheezier in that we turn off setting
up DMA maps to be BUS_SPACE_MAXADDR if we're in ISP_TARGET_MODE. More work
on this in a week or so.

c) Tested under amd64 and 1MB DFLTPHYS, sparc64, i386 (PAE, but insufficient
memory to really test > 4GB). LINT check under amd64.

MFC after: 1 month

Make sure we don't pick up a loopid that's larger than our
current portdb max (MAX_FC_TARG == 256) now that we support
2K Login f/w.

MFC after: 3 days

First of several commits as this driver is dusted off and maybe brought
up to date. Principle changes for this reelase is to support 2K Port Login
firmware. This allows us to support the 2322 (and 2422 4Gb) cards which only
come with the 2K Port Login firmware. The 2322 should now work- but we don't
have firmware sets for it in ispfw (as the change to load 2K Port Login f/w
hasn't been made- that f/w is so big it has to be loaded in more than one
chunk).

Other changes are the beginnings of cleaning up some long standing target
mode issues. The next changes here will incorporate a lot of bug fixes
from others.

Finally, some copyright cleanup and attempts to make the parts of the
driver that are FreeBSD specific start conforming more to FreeBSD style.

MFC after: 1 month

Add an ioctl framework for doing FC task management functions from
a user space tool- useful for doing FC target mode certification.

Don't set ZIO for 23XX for target mode (use fast posting instead).
Use the correct number of handles for multihandle returns.

Very, very, rarely on some SMP systems we've seen an 'unstable' type
in the response queue. I dunno whether or not it's a bug in our
handling, or whether there's a cache incoherency issue, but
try to guard against it.

MFC after: 2 weeks

Start each of the license/copyright comments with /*-, minor shuffle of lines

Store the target handles in a separate list from normal commands. Add a
CTIO fast post routine to handle CTIO completions.

Submitted by: mjacob

Add case to handle ISPCTL_GET_PDB.

MFC after: 1 week

If we have ISP_ROLE_INITIATOR set, make sure that we clear ICBOPT_INI_DISABLE
from the fwoptions. Likewise, we *set* ICBOPT_INI_DISABLE if we don't have
initiator role.

On reset, make sure that we have some parameters set correctly. This
fixes a longstanding issue WRT resetting the chip after startup- it
would fail if we were connected as an F-port to a switch. If we
were connected as an F-port, we got assigned a hard loop ID of 255,
which is really a bogus loop id. Then when we turned around to
reset ourselves, the firmware would reject the ICB_INIT request
because the loop id was bogus. *sputter*

Minor fixlet from somebody in NetBSD with too much time on their
hands (dma -> DMA).

Revert previous commit. Violates Maintainer (O'Brien knows how to
reach me directly), but more importantly, breaks compiles on
non-FreeBSD platforms.

Use __FBSDID().
Also some minor style cleanups.

Restore parentheses removed inappropriately in last commit.

Remove unused variables
Add /* FALLTHROUGH */

Found by: FlexeLint

Pick up some compilation warning fixes from NetBSD.

If we don't have ISP_FW_CRASH_DUMP defined, we have to do
a isp_reinit in the core code- not the platform code- so
fix the ISP_CONN_FATAL case.

Correct typos, mostly s/ a / an / where appropriate. Some whitespace cleanup,
especially in troff files.

Fix typos, mostly s/ an / a / where appropriate and a few s/an/and/
Add FreeBSD Id tag where missing.

This should enable 10160 support. As best as I can tell, the same
f/w as 12160 is used, and otherwise, this is just a single channel
variant of the 10160.

MFC after: 0 days

If we have a 1240 or an ULTRA2 or better card, use MBOX_INIT_RES_QUEUE_A64
(preparation for DAC/A64 support)

The size argument to snprintf does not have to be backed off by one
to account for a NULL byte.

Submitted by: Jacques A. Vidrine <nectar@celabo.org>

Remove STRNCAT (==>strncat) usage. Apparently I never read the man
page correctly and it wasn't doing what I thought it was.

Noticed by: Brooks Davis <brooks@one-eyed-alien.net>

If we're using ancient (pre 1.17.0) 2100 f/w (for the cards that cannot
load f/w images > 0x7fff words), set ISP_FW_ATTR_SCCLUN. We explicitly
don't believe we can find attributes if f/w is < 1.17.0, so we have to
set SCCLUN for the 1.15.37 f/w we're using manually- otherwise every
target will replicate itself across all 16 supported luns for non-SCCLUN
f/w.

Correctly set things up for 23XX and either fast posting or ZIO. The
23XX, it turns out, does not support RIO. If you put a non-zero value
in xfwoptions, this will disable fast posting. If you put ICBXOPT_ZIO
in xfwoptions, then the 23XX will do interrupt delays but post to the
response queue- apparently QLogic *now* believes that reading multiple
handles from registers is less of a win than writing (and delaying)
multiple 64 byte responses to the response queue.

At the end of taking a a good f/w crash dump, send the ISPASYNC_FW_DUMPED
event to the outer layers (who can then do things like wake a user
daemon to *fetch* the crash image, etc.).

Remove the 'bogus registrant' hack for fabric searches. It really
turns out that there's something of a hole in our new fabric name
server stuff. We ask the name server for entities that have
registered as a specific type. That type is FC-SCSI. If the entity
hasn't performed a REGISTER FC4 TYPES, the fabric nameserver won't
return it.

This brings this driver to a bit of a fork in the road as to what
the right thing to do is. For servicing the needs of accessing
FC-SCSI devices, this method is fine, and to be preferred. It is
extremely unlikely we're interested in fabric devices that *don't*
register correctly. If I ever get around to adding an FC-IP stack,
then asking for devices that have registers as FC-IP types is also
the right thing to do.

So- asking the fabric nameserver for a specific type is fine, *as
long as you are only interested in specific types*. If, on the other
hand, you want to create (as for management tool support) a picture
of everything on the fabric, this is *not* so fine. There are a
large class of FC-SCSI *initiators* who *don't* correctly register,
so we never will *see* them.

Is this a problem? Yes, but only a little one. If we want to do such
management tool support, we should probably run a *different* fabric
nameserver query algorithm. Better yet, we should talk to the management
nameserver in Brocade switches instead of the standard FC-GS-2 fabric
nameserver (which can be unwieldy).

Other changes: if we've overrrides marked, don't set some default
values from reading NVRAM. This allows us to override things like
EXEC throttle without having to ignore NVRAM entirely.

MFC after: 1 week

If the HBA is already 'touched', still set maxluns. Othewise for
CAM_QUIRK_HILUN devices we loop thru 32bits of lun. Oops.

Switch to using USEC_DELAY rather than USEC_SLEEP at isp_reset time.

Try to paper around a defect in clients that don't correctly registers
themeselves with the fabric nameserver.

Minor updates for Mirapoint support- they still use code that is not
HANDLE_LOOPSTATE_IN_OUTER_LAYERS, and, surprise surprise, this old
stuff had some bugs in it.

Clean up some target mode stuff.

MFC after: 1 week

If we get a DATA UNDERRUN error from QLogic FC cards, but the RQCS_RU bit
is not set in the scsi completion status, or if the residual is clearly
nonsense, then this was a command that suffered the loss of one or more
FC frames in the middle of the exchange.

Set HBA_BOTCH and hope it will get retried. It's the only thing we can do.

MFC after: 1 day

Scale back # of luns supported for SCC to 16384- oops- top 3 bits are a
lun address modifier of sorts. Only an HP XP-512 seems to have cared.

Fix a few misplaced pointers for the new fabric goop, which has been
demonstrated to work on newer Brocades and McData switches now.
Put in commented out code which would run GFF_ID if the QLogic f/w
allowed it.

Don't whine about not being able to find a handle for a command if it
was a command aborted (by us).

Fix bus dma segment count to be based off of MAXPHYS, not BUS_SPACE_MAXSIZE.
Grumble. I've seen better documented architectures out of Redmond.

Redo fabric evaluation to not use GET ALL NEXT (GA_NXT). Switches seem
to be trying to wriggle out of supporting this well. Instead, use
GID_FT to get a list of Port IDs and then use GPN_ID/GNN_ID to find the
port and node wwn. This should make working on fabrics a bit cleaner and
more stable.

This also caused some cleanup of SNS subcommand canonicalization so that
we can actually check for FS_ACC and FS_RJT, and if we get an FS_RJT,
print out the reason and explanation codes.

We'll keep the old GA_NXT method around if people want to uncomment a
controlling definition in ispvar.h.

This also had us clean up ISPASYNC_FABRICDEV to use a local lportdb argument
and to have the caller explicitly say that a device is at the end of the
fabric list.

MFC after: 1 week

Limit fabric search to a default 256 entries. This will all go away
soon because it's just getting harder and harder to find switches
that correctly implement the GET ALL NEXT subcommands for the SNS
protocol.

Latch up result out pointer and set a busy flag when we're looking
at the response queue. This allows for a cleaner way to make sure
we don't get multiple CPUs trying to read the same response queue
entries.

Change how isp_handle_other_response returns values (clarity).

Make PORT UNAVAILABLE the same as PORT LOGOUT (force a LIP).

Do some formatting changes.

MFC after: 0 days

Disable RIO (reduced interrupt operation) for 2200 boards- it seemed like
it worked- but I ran into a case with a 2204 where commands were being lost
right and left. Best be safe.

For target mode, or things called if we call isp_handle_other response- note
that we might have dropped locks by changing the output pointer so we bail
from the loop. It's the responsibility of the entity dropping the lock to
make sure that we let the f/w know we've read thus far into the response
queue (else we begin processing the same entries again- blech!).

MFC after: 1 day

Fix a problem where a local loop disk logs out- and we get a PORT LOGGED
OUT status. We are, apparently, required to force the f/w to log back in
if we want to try and talk to that disk again. This means either issuing
a LOGIN LOCAL LOOP PORT mailbox command, or by issuing a LIP. I've elected
to issue a LIP because this has a better chance of waking up the disk which
clearly just crashed and burned.

These should not occur at all. If they do, they should be darned rare.

MFC after: 1 week

More for f/w crash dumps (bug fixing and adding ioctl entry points
and hints to enable for specific units)

MFC after: 1 week

Support for f/w crash dumps (2200 && 23XX).

If you want QLogic to look at a potential f/w problem for FC cards, you really
have to provide them info in the format they expect. This involves dumping
a lot of hardware registers (> 300 16 bit registers) and a lot of SRAM
(> 128KB minimum). Thus all of this code is #ifdef protected which will
become an option so that the memory allocation of where to dump the crash
image is pretty expensive. It's worth it if you have a reproducible problem
because they have some tools that can tell them, given the f/w version,
the precise state of everything.

MFC after: 1 week

+ A variety of 23XX changes:
disable MWI on 2300

based on function code, set an 'isp_port' for the 2312- it's a
separate instance, but the NVRAM is shared, and the second port's
NVRAM is at offset 256.

+ Enable RIO operation for LVD SCSI cards. This makes a *big* difference
as even under reasonable load we get batched completions of about 30
commands at a time on, say, an ISP1080.

+ Do 'continuation' mailbox commands- this allows us to specify a work
area within the softc and 'continue' repeated mailbox commands. This is
more or less on an ad hoc basis and is currently only used for firmware
loading (which f/w now loads substantially faster becuase the calling
thread is only woken when all the f/w words are loaded- not for each
one of the 40000 f/w words that gets loaded).

+ If we're about to return from isp_intr with a 'bogus interrupt' indication,
and we're not a 23XX card, check to see whether the semaphore register is
currently *2* (not *1* as it should be) and whether there's an async completion
sitting in outgoing mailbox0. This seems to capture cases of lost fast posting
and RIO interrupts that the 12160 && 1080 have been known to pump out under
extreme load (extreme, as in > 250 active commands).

+ FC_SCRATCH_ACQUIRE/FC_SCRATCH_RELEASE macros.

+ Endian correct swizzle/unswizzle of an ATIO2 that has a WWPN in it.

MFC after: 1 week

Implement REDUCED INTERRUPT OPERATION usage form FC cards- this allows the
firmware to delay completion of commands so that it can attempt to batch
a bunch of completions at once- either returning 16 bit handles in mailbox
registers, or in a resposne queue entry that has a whole wad of 16 bit handles.

Distinguish between 2300 and 2312 chipsets- if only because the revisions
on the chips have different meanings.

Add more instrumentation plus ISP_GET_STATS and ISP_CLR_STATS ioctls.
Run up the maximum number of response queue entities we'll look at
per interrupt.

If we haven't set HBA role yet, always return success from isp_fc_runstate.

MFC after: 2 weeks

Explicitly decode GetAllNext SNS Response back *as*
a GetAllNext response. Otherwise, we won't unswizzle
it correctly. This was found on linux/PPC.

This mandated creating another inline: isp_get_gan_response.

Major restructuring for swizzling to the request queue and unswizzling from
the response queue. Instead of the ad hoc ISP_SWIZZLE_REQUEST, we now have
a complete set of inline functions in isp_inline.h. Each platform is
responsible for providing just one of a set of ISP_IOX_{GET,PUT}{8,16,32}
macros.

The reason this needs to be done is that we need to have a single set of
functions that will work correctly on multiple architectures for both little
and big endian machines. It also needs to work correctly in the case that
we have the request or response queues in memory that has to be treated
specially (e.g., have ddi_dma_sync called on it for Solaris after we update
it or before we read from it). It also has to handle the SBus cards (for
platforms that have them) which, while on a Big Endian machine, do *not*
require *most* of the request/response queue entry fields to be swizzled
or unswizzled.

One thing that falls out of this is that we no longer build requests in the
request queue itself. Instead, we build the request locally (e.g., on the
stack) and then as part of the swizzling operation, copy it to the request
queue entry we've allocated. I thought long and hard about whether this was
too expensive a change to make as it in a lot of cases requires an extra
copy. On balance, the flexbility is worth it. With any luck, the entry that
we build locally stays in a processor writeback cache (after all, it's only
64 bytes) so that the cost of actually flushing it to the memory area that is
the shared queue with the PCI device is not all that expensive. We may examine
this again and try to get clever in the future to try and avoid copies.

Another change that falls out of this is that MEMORYBARRIER should be taken
a lot more seriously. The macro ISP_ADD_REQUEST does a MEMORYBARRIER on the
entry being added. But there had been many other places this had been missing.
It's now very important that it be done.

Additional changes:

Fix a longstanding buglet of sorts. When we get an entry via isp_getrqentry,
the iptr value that gets returned is the value we intend to eventually plug
into the ISP registers as the entry *one past* the last one we've written-
*not* the current entry we're updating. All along we've been calling sync
functions on the wrong index value. Argh. The 'fix' here is to rename all
'iptr' variables as 'nxti' to remember that this is the 'next' pointer-
not the current pointer.

Devote a single bit to mboxbsy- and set aside bits for output mbox registers
that we need to pick up- we can have at least one command which does not
have any defined output registers (MBOX_EXECUTE_FIRMWARE).

MFC after: 2 weeks

Tra-La, another QLogic f/w funny- this time with the 2300.
If we get a completion status of RQCS_QUEUE_FULL, it means
that the internal queues are full. Other QLogic boards set
the QFULL SCSI status. But *nooooooooooo*, not the 2300.

MFC after: 1 day

Protect against deranged fabric nameservers that spit out 10000 identical
port numbers.

MFC after: 1 day

Misunderstanding documentation caused me to try and set 1Gbps/2Gps/Auto
connection speed for the 2300 in the wrong offset in the ICB. Oops.

Respect some QLogic errat wrt PCI errors on certain shared host/RISC registers.

Implement a call to get the actual link data rate (if 23XX) so we can
set whether it's a 2Gps or 1Gps link.

MFC after: 1 week

When calling isp_reset, set the request/response in/out pointers all at
once so there isn't a window with the ones for the 23XX cards being wrong.

When being verbose, print out some more FC NVRAM values (like framesize).

MFC after: 1 week

Clarify issues about whether we have SCCLUN (65535 luns) or non-SCCLUN (16
luns) firmware for the Fibre Channel cards.

We used to assume that if we didn't download firmware, we couldn't know
what the firmware capability with respect to SCCLUNs is- and it's important
because the lun field changes in the request queue entry based upon which
firmware it is.

At any rate, we *do* get back firmware attributes in mailbox register 6
when we do ABOUT FIRMWARE for all 2200/2300 cards- and for 2100 cards
with at least 1.17.0 firmware. So- we now assume non-SCCLUN behaviour
for 2100 cards with firmware < 1.17.0- and we check the firmware attributes
for other cards (loaded firmware or not).

This also allows us to get rid of the crappy test of isp_maxluns > 16-
we simply can check firmware attributes for SCCLUN behaviour.

This required an 'oops' fix to the outgoing mailbox count field for
ABOUT FIRMWARE for FC cards.

Also- while here, hardwire firmware revisions for loaded code for SBus
cards. Apparently the 1.35 or 1.37 f/w we've been loading into isp1000
just doesn't report firmware revisions out to mailbox regs 1, 2 and 3
like everyone else. Grumble. Not that this fix hardly matters for FreeBSD.

MFC after: 4 weeks

Add 2 Gigabit Fibre Channel support (2300 && 2312 cards). This required
some reworking (and consequent cleanup) of the interrupt service code.

Also begin to start a cleanup of target mode support that will (eventually)
not require more inforamtion routed with the ATIO to come back with the
CTIO other than tag.

MFC after: 4 weeks

Clean up some ways in which we set defaults for SCSI cards
that do not have valid NVRAM. In particular, we were leaving
a retry count set (to retry selection timeouts) when thats
not really what we want. Do some constant string additions
so that LOGDEBUG0 info is useful across all cards.

MFC after: 2 weeks

oops- typo in a previous commit

Enable LIP F8, LIP Reset async events.
Be more chatty about SNS failures. Fix
typo for skipped phase mesage. Correct
MBOX_GET_PORT_QUEUE_PARAMS options in
table.

MFC after: 2 weeks

Oops- don't set 'goal' twice when you mean to set 'nvrm' as well.
This breaks bogus NVRAM boards.

MFC after: 1 day

Redo how we manage SCSI device settings- have a 3rd flags (nvram) that records
either what's in NVRAM or what the safe defaults would be if we lack NVRAM.
Then we rename cur_XXXX to actv_XXXX (these are the currently active settings)
and the dev_XXX settings to goal_XXXX (these are the settings which we want
cur_XXXX to converge to).

Hmm. Let's try this on for size...

We originally had it such that if the connection topology was FL-loop
(public loop), we never looked at any local loop addresses. The reason
for not doing that was fear or concern that we'd see the same local
loop disks reflected from the name server and we'd attach them twice.

However, when I recently hooked up a JBOD and a system to an ANCOR SA-8
switch, the disks did *not* show up on the fabric. So at least the
ANCOR is screening those disks from appearing on the fabric. Now, it's
possible this is a 'feature' of the ANCOR. When I get a chance, I'll
check the Brocade (it's hard to do this on a low budget).

In any case, if they *do* also show up on the fabric, we should
simply elect to not log into them because we already have an
entry for the local loop. There is relatively unexercised code
just for this case.

MFC after: 2 weeks

More 2300 support prep- the Request/Response in/out pointers are
part of the PCI block for the 2300- not software convention usage
of the mailbox registers- so we macrosize in/out pointer usage.

Only report that a LIP destroyed commands if it actually destroyed
commands. Get the chan/tgt/lun order correct. Fix a longstanding
stupid bug that caused us to try and issue a command with a tag on
Channel B because we were checking the tagged capability for the
target against Channel A.

A firmware crash is now vectored out to platform specific code
as an async event.

Some minor formatting tweaks.

We've had problems with data corruption occuring on
commands that complete (with no apparent error) after
we receive a LIP. This has been observed mostly on
Local Loop topologies. To be safe, let's just mark
all active commands as dead if we get a LIP and we're
on a private or public loop.

MFC after: 4 weeks

Fix botch for state levels. Role minor release. Start adding code for a
'force logout' path.

MFC after: 4 weeks

Spring MegaChange #1.

----

Make a device for each ISP- really usable only with devfs and add an ioctl
entry point (this can be used to (re)set debug levels, reset the HBA,
rescan the fabric, issue lips, etc).

----

Add in a kernel thread for Fibre Channel cards. The purpose of this
thread is to be woken up to clean up after Fibre Channel events
block things. Basically, any FC event that casts doubt on the
location or identify of FC devices blocks the queues. When, and
if, we get the PORT DATABASE CHANGED or NAME SERVER DATABASE CHANGED
async event, we activate the kthread which will then, in full thread
context, re-evaluate the local loop and/or the fabric. When it's
satisfied that things are stable, it can then release the blocked
queues and let commands flow again.

The prior mechanism was a lazy evaluation. That is, the next command
to come down the pipe after change events would pay the full price
for re-evaluation. And if this was done off of a softcall, it really
could hang up the system.

These changes brings the FreeBSD port more in line with the Solaris,
Linux and NetBSD ports. It also, more importantly, gets us being
more proactive about topology changes which could then be reflected
upwards to CAM so that the periph driver can be informed sooner
rather than later when things arrive or depart.

---

Add in the (correct) usage of locking macros- we now have lock transition
macros which allow us to transition from holding the CAM lock (Giant)
and grabbing the softc lock and vice versa. Switch over to having this
HBA do real locking. Some folks claim this won't be a win. They're right.
But you have to start somewhere, and this will begin to teach us how
to DTRT for HBAs, etc.

--

Start putting in prototype 2300 support. Add back in LIP
and Loop Reset as async events that each platform will handle.
Add in another int_bogus instrumentation point.

Do some more substantial target mode cleanups.

MFC after: 8 weeks

After loading f/w, for FC cards print out Firmware Attributes.

Redo establishment of default SCSI parameters whether or not
we've been compiled for target mode. Unfortunately, the Qlogic
f/w is confused so that if we set all targets to be 'safe' (i.e.,
narrow/async), it will also then report narrow, async if we're
contacted in target mode from that target (acting in initiator
role). D'oh!

Fix ISPCTL_TOGGLE_TMODE to correctly enable the right channel for
dual channel cards. Add some more opcodes. Fix a stupid NULL
pointer bug.

In order to save ourselves grief with the SUNPRO compiler under
Solaris (which, for reasons unknown to me, chokes on u_int16_t
as a typedef of unsigned short if used in a transitional (mixed K&R
and ANSI) way), we'll go the extra mile and fully ANSIfy things.

Remove a superfluous newline in a string (isp_prt adds this).
Fix a missed conversion of 32 to 16 bit handles.

Switch to using 16 bit handles instead of 32 bit handles.
This is a pretty invasive change, but there are three good
reasons to do this:

1. We'll never have > 16 bits of handle.
2. We can (eventually) enable the RIO (Reduced Interrupt Operation)
bits which return multiple completing 16 bit handles in mailbox
registers.
3. The !)$*)$*~)@$*~)$* Qlogic target mode for parallel SCSI spec
changed such that at_reserved (which was 32 bits) was split into
two pieces- and one of which was a 16 bit handle id that functions
like the at_rxid for Fibre Channel (a tag for the f/w to correlate
CTIOs with a particular command). Since we had to muck with that
and this changed the whole handler architecture, we might as well...

Propagate new at_handle on through int ct_fwhandle. Follow
implications of changing to 16 bit handles.

These above changes at least get Qlogic 1040 cards working in target
mode again. 1080/12160 cards don't work yet.

In isp.c:
Prepare for doing all loop management in outer layers.

Fix a longstanding bug- we had the sense of what bit 14
for the ICB firmware options meant- *I* had taken it to
mean that if you set it, Node Name would be ignored and
derived from Port Name. Actually, it meant the opposite.
As a consequence- change ICBOPT_USE_PORTNAME to the
define ICBOPT_BOTH_WWNS- makes more sense.

Fix wrong input bitmap for MBOX_DUMP_RAM command. Call
ISP_DUMPREGS if we get a f/w crash. Add ISPCTL_RUN_MBOXCMD
control command (so outer layers can run a mailbox command
directly) and add a ISPASYNC_UNHANDLED_RESPONSE hook so
outer layers can understand response queue entries we
might not know about.

Minor stuff:

Remove ISP2100_FABRIC defines- we always handle fabric now. Insert
isp_getmap helper function (for getting Loop Position map). Make
sure we (for our own benefit) mark req_state_flags with RQSF_GOT_SENSE
for Fibre Channel if we got sense data- the !*$)!*$)~*$)*$ Qlogic
f/w doesn't do so. Add ISPCTL_SCAN_FABRIC, ISPCTL_SCAN_LOOP, ISPCTL_SEND_LIP,
and ISPCTL_GET_POSMAP isp_control functions. Correctly send async notifications
upstream for changes in the name server, changes in the port database, and
f/w crashes. Correctly set topology when we get a ASYNC_PTPMODE event.

Major stuff:
Quite massively redo how we handle Loop events- we've now added several
intermediate states between LOOP_PDB_RCVD and LOOP_READY. This allows us
a lot finer control about how we scan fabric, whether we go further
than scanning fabric, how we look at the local loop, and whether we
merge entries at the level or not. This is the next to last step for
moving managing loop state out of the core module entirely (whereupon
loop && fabric events will simply freeze the command queue and a thread
will run to figure out what's changed and *it* will re-enable the queu).
This fine amount of control also gets us closer to having an external
policy engine decide which fabric devices we really want to log into.

When resetting the Qlogic 2X00 units, reset the FPM (Fibre Protocol
Module) and FBM (Fibre Buffer Modules). Also remember to clear the
semaphore registers. Tell the RISC processor to not halt on FPM
parity errors.

Throw out the ISP_CFG_NOINIT silliness and instead go to the use of
adapter 'roles' to see whether one completes initialization or not
(mostly for Fibre Channel). The ultimate intent, btw, of all of this
is to have a warm standby adapter for failover reasons. Because
we do roles now, setting of Target Capable Class 3 service parameters
in the ICB for the 2x00 cards reflects from role. Also, in isp_start,
if we're not supporting an initiator role, we bounce outgoing commands
with a Selection Timeout error. Also clean out the TOGGLE_TMODE
goop for FC- there is no toggling of target mode like there is
for parallel SCSI cards.

Do more cleanup with respect to using target ids 0..125 in F-port
topologies. Also keep track of things which *were* fabric devices
so that when you rescan the fabric you can notify the outer layers
when fabric devices go away.

Only force a LOGOUT for fabric devices if they're still logged in
(i.e., you cat their Port Database entry. Clean up the Get All Next
scanning.

Finally, use a new tag in the softc to store the opcode for the
last mailbox command used so we can report which opcode timed
out.

Add a isp_register_fc4_type function so that we work with McData switches
that require us to register our FC4 types of interest. Allow ourselves, in
F-port topologies, to start logging in fabric devices in the target 0..125
range. Change ISPASYNC_PDB_CHANGED (misnamed) to ISPASYNC_LOGGED_INOUT.
Fix (*SMACK*) again some default WWN stuff. This is *really* hard to get
right across all the range of platforms.

Change the modification of what could be a const string. Apparently the
construct:

char *foo;
...
foo = "XXX";
...
foo[1] = 'Y';

is wrong. IT blew up on NetBSD-sparc64 because that platform write-protects
constant strings.

Add in Bill Sommerfelds -Wformat changes. Set up default node && port
WWNs correctly (Again!) - this time for the case that we're not going
to fully init the adapter if isp_init is called (with ISP_CFG_NOINIT
set in options). The pupose for this is to bring the adapter up to
almost ready to go, get info out of NVRAM, but to not start it up- leaving
it until later to actually start things up if wanted (and possibly with
different roles selected).

Make the Not RESPONSE in RESPONSE QUEUE message have a bit more info
(specifically, how many entries we've looked at so far). Maintain
interrupt instrumentation. Use USEC_SLEEP instead of USEC_DELAY in
a number of places (this allows us to drop locks and sleep instead
of spin). Track changes to configuration options for topology preference.
Fix botched order of printout for Channel, Target, Lun.

Redo how default Node and Port WWNs are determined (again!). This is so
we don't stomp on the differences between ports for a Qlogic 2202.

some copyright cleanups

Inintialize the queue index stuff from what the f/w sends back- just
in case it's insane enough to not do what you tell it to.

Print out (LOGINFO level) initiator ID.

various fixes

Major whacking for core version 2.0. A major motivator for 2.0 and these
changes is that there's now a Solaris port of this driver, so some things
in the core version had to change (not much, but some).

In order, from the top.....:

A lot of error strings are gathered in one place at the head of the file.
This caused me to rewrite them to look consistent (with respect to
things like 'Port 0x%' and 'Target %d' and 'Loop ID 0x%x'.

The major mailbox function, isp_mboxcmd, now takes a third argument,
which is a mask that selectively says whether mailbox command failures
will be logged. This will substantially reduce a lot of spurious noise
from the driver.

At the first run through isp_reset we used to try and get the current
running firmware's revision by issuing a mailbox command. This would
invariably fail on alpha's with anything but a Qlogic 1040 since SRM
doesn't *start* the f/w on these cards. Instead, we now see whether we're
sitting ROM state before trying to get a running BIOS loaded f/w version.

All CFGPRINTF/PRINTF/IDPRINTF macros have been replaced with calls to
isp_prt. There are seperate print levels that can be independently
set (see ispvar.h), which include debugging, etc.

All SYS_DELAY macros are now USEC_DELAY macros. RQUEST_QUEUE_LEN and
RESULT_QUEUE_LEN now take ispsoftc as a parameter- the Fibre Channel
cards and the Ultra2/Ultra3 cards can have 16 bit request queue entry
indices, so we can make a 1024 entry index for them instead of the
256 entries we've had until now.

A major change it to fix isp_fclink_test to actually only wait the
delay of time specified in the microsecond argument being passed.
The problem has always been that a call to isp_mboxcmd to get he
current firmware state takes an unknown (sometimes long) amount of
time- this is if the firmware is busy doing PLOGIs while we ask
it what's up. So, up until now, the usdelay argument has been
a joke. The net effect has been that if you boot without being plugged
into a good loop or into a switch, you hang. Massively annonying, and
hard to fix because the actual time delta was impossible to know
from just guessing. Now, using the new GET_NANOTIME macros, a precise
and measured amount of USEC_DELAY calls are done so that only the
specified usecdelay is allowed to pass. This means that if the initial
startup of the firmware if followed by a call from isp_freebsd.c:isp_attach
to isp_control(isp, ISP_FCLINK_TEST, &tdelay) where tdelay is 2 * 1000000,
no more than two seconds will actually elapse before we leave concluding
that the cable is unhooked. Jeez. About time....

Change the ispscsicmd entry point to isp_start, and the XS_CMD_DONE
macro to a call to the platform supplied isp_done (sane naming).

Limit our size of request queue completions we'll look at at interrupt
time. Since we've increased the size of the Request Queue (and the
size of the Response Queue proportionally), let's not create an
interrupt stack overflow by having to keep a max completion list
(forw links are not an option because this is common code with
some platforms that don't have link space in their XS_T structures).
A limit of 32 is not unreasonable- I doubt there'd be even this many
request queue completions at a time- remember, most boards now use
fast posting for normal command completion instead of filling out
response queue entries.

In the isp_mboxcmd cleanup, also create an array of command
names so that "ABOUT FIRMWARE" can be printed instead of "CMD #8".

Remove the isp_lostcmd function- it's been deprecated for a while.
Remove isp_dumpregs- the ISP_DUMPREGS goes to the specific bus
register dump fucntion.

Various other cleanups.

Raise debug level for some messages. Fix botched inversion
about MBOX_COMMAND_ERROR vs. MBOX_COMMAND_PARAM_ERROR.

Clean up ISPCTL_ABORT_CMD function to not be too chatty if it succeeds,
or even if it fails with INVALID_PARM (which just means that the handle
doesn't refer to an active commane).

Change delay loop in new isp_mboxcmd to the use of the new MBOX_WAIT_COMPLETE
macro. Change notification of completion of a mailbox command in isp_intr
to MBOX_NOTIFY_COMPLETE macro.

Fix usage of DELAY (SYS_DELAY is the platform independent local
define). Fix stupidity wrt checking whether we've gone to
LOOP_PDB_RCVD loopstate- it's okay to be greater than this state.
D'oh! Protect calls to isp_pdb_sync and isp_fclink_state with IS_FC
macros.

Completely redo mailbox command routine (in preparation to make this
possibly wait rather than poll for completion).

Make a major attempt to solve the 'lost interrupt' problem

1. Problem

The Qlogic cards would appear to 'lose' interrupts, i.e., a legitimate
regular SCSI command placed on the request queue would never complete
and the watchdog routine in the driver would eventually wakeup and
catch it. This would typically only happen on Alphas, although a
couple folks with 700MHz Intel platforms have also seen this.

For a long time I thought it was a foulup with f/w negotiations of
SYNC and/or WIDE as it always seemed to happen right after the
platform it was running on had done a SET TARGET PARAMETERS mailbox
command to (re)enable sync && wide (after initially forcing
ASYNC/NARROW at startup). However, occasionally, the same thing
would also occur for the Fibre Channel cards as well (which, ahem,
have no SET TARGET PARAMETERS for transfer mode).

After finally putting in a better set of watchdog routines for the
platforms for this driver, it seemed to be the case that the command
in question (usually a READ CAPACITY) just had up and died- the
watchdog routine would catch it after ~10 seconds. For some platforms
(NetBSD/OpenBSD)- an ABORT COMMAND mailbox command was sent (which
would always fail- indicating that the f/w denied knowledge of this
command, i.e., the f/w thought it was a done command). In any case,
retrying the command worked. But this whole problem needed to be
really fixed.

2. A False Step That Went in The Right Direction

The mailbox code was completely rewritten to no longer try and grab
the mailbox semaphore register and to try and 'by hand' complete
async fast posting completions. It was also rewritten to now have
separate in && out bitpatterns for registers to load to start and
retrieve to complete. This means that isp_intr now handles mailbox
completions.

This substantially simplifies the mailbox handling code, and carries
things 90% toward getting this to be a non-polled routine for this
driver.

This did not solve the problem, though.

3. Register Debouncing

I saw some comments in some errata sheets and some notes in a Qlogic
produced Linux driver (for the Qlogic 2100) that seemed to indicate
that debouncing of reads of the mailbox registers might be needed,
so I added this. This did not affect the problem. In fact, it made
the problem worse for non-2100 cards.

5. Interrupt masking/unmasking

The driver *used* to do a substantial amount of masking/unmasking
of the interrupt control register. This was done to make sure that
the core common code could just assume it would never get pre-empted.

This apparently substantially contributed to the lost interrupt
problem. The rewrite of the ICR (Interrupt Control Register),
which is a separate register from the ISR (Interrupt Status Register)
should not have caused any change to interrupt assertions pending.
The manual does not state that it will, and the register layout
seems to imply that the ICR is just an active route gate. We only
enable PCI Interrupts and RISC Interrupts- this should mean that
when the f/w asserts a RISC interrupt and (and the ICR allows RISC
Interrupts) and we have PCI Interrupts enabled, we should get a
PCI interrupt. Apparently this is a latch- not a signal route.

Removing this got rid of *most* but not all, lost interrupts.

5. Watchdog Smartening

I made sure that the watchdog routine would catch cases where the
Qlogic's ISR showed an interrupt assertion. The watchdog routine
now calls the interrupt service routine if it sees this. Some
additional internal state flags were added so that the watchdog
routine could then know whether the command it was in the middle
of burying (because we had time it out) was in fact completed by
the interrupt service routine.

6. Occasional Constipation Of Commands..

In running some very strenous high IOPs tests (generating about
11000 interrupts/second across one Qlogic 1040, one Qlogic 1080
and one Qlogic 2200 on an Alpha PC164), I found that I would get
occasional but regular 'watchdog timeouts' on both the 1080 and
the 2100 cards. This is under FreeBSD, and the watchdog timeout
routine just marks the command in error and retries it.

Invariably, right after this 'watchdog timeout' error, I'd get a
command completion for the command that I had thought timed out.
That is, I'd get a command completion, but the handle returned by
the firmware mapped to no current command. The frequency of this
problem is low under such a load- it would usually take an 30
minutes per 'lost' interrupt.

I doubled the timeout for commands to see if it just was an edge
case of waiting too short a period. This has no effect.

I gathered and printed out microtimes for the watchdog completed
command and the completion that couldn't find a command- it was
always the case that the order of occurrence was "timeout, completion"
separated by a time on the order of 100 to 150 ms.

This caused me to consider 'firmware constipation' as to be a
possible culprit. That is, resubmission of a command to the device
that had suffered a watchdog timeout seemed to cause the presumed
dead command to show back up.

I added code in the watchdog routine that, when first entered for
the command, marks the command with a flag, reissues a local timeout
call for one second later, but also then issues a MARKER Request
Queue entry to the Qlogic f/w. A MARKER entry is used typically
after a Bus Reset to cause the f/w to get synchronized with respect
to either a Bus, a Nexus or a Target.

Since I've added this code, I always now see the occasional watchdog
timeout, but the command that was about to be terminated always
now seems to be completed after the MARKER entry is issued (and
before the timeout extension fires, which would come back and
*really* terminate the command).

Once we have firmware running (if isp_reset) and this is the first time
through, establish what our LUN width is. Unfortunately, we can't ask
the f/w. If we loaded the f/w, we'll now assume we have expanded LUNs
(SCCLUN for fibre channel, just plain 32 LUN for SCSI). If we didn't
load firmware, assume 8 LUNs for SCSI and 1 LUN for Fibre Channel. We
have to assume only one LUN for Fibre Channel because the LUN setting
in Request Queue entries is in different places whether we have SCCLUN
firmware or not, so the only LUN guaranteed to work for both is LUN 0.

Clean up the rest of isp.c so that ISP2100_SCCLUN defines aren't used-
instead use run time determinants based upon isp->isp_maxluns.

After starting firmware, delay 500us to give it a chance to get rolling.

Fix the interrupt service routine to check for both isr && sema being zero
before thinking this was a spurious interrupt. Following the manuals,
allow for both Mailbox as well as Queue Reponse type interrupts for regular
SCSI.

Fix some breakage about how we build WWNs. Do some other fabric related
changes: consider a new PDB entry different if Class 3 service parameter
roles change (!!!). Do some checking as we're getting a port database
that traps whether things change while we're doing so. Handle N-port
and F-ports correctly. Fix the fabric login loop to retain a login/binding
if things haven't changed (I mean, why logout a device only to log it back
in). No longer accept, after fabric logins, garbage if we can't get a PDB
entry that matches the device we've just logged into- if it doesn't, log
it out as it is very unlikely to still be what we thought it was. Get rid
of some of the debounce loops because we could get stuck there.

Pick up topology more sanely at f/w startup. Change the restrictions of
where we can have targets (based on topology).

Much more importantly, make sure all mods to isp_sendmarker or |= so
we don't lose the marking of a bus that needs to have a marker sent for it.

Slightly cleaner fabric support (whiter whites! redder reds!).. No,
seriously- only attempt to logout a previously logged in fabric device.

Fix a longstanding bug for aborting overtime commands- handle halves
have always been reversed.

Clean up some error messages to indicate channel number.

Approved:jkh

Clean out residual bogosity for fast posting stuff- ISP_NO_FASTPOST_SCSI
is gone as a define. We just don't support fast posting for anything less
than the 1240/1080/1280/12160 or Fibre Channel cards.

Put in support for CDB's larger than 12 bytes for parallel SCSI (up to 44
bytes are allowed).

Approved: jkh

Restructure nvram reading routine to split out to separate functions
for 1020/1X80/12160/2X00- for readability. Add in 12160 (Ultra3)
support- but not with PPR just yet. Fix and clarify fetching of
return parameter for getting firmware rev which for the 2200 contains
the connection topology (Private Loop (NL-port), N-port, FL-port,
F-port). Synthesize the connection topology for the 2100 which can
only be Private Loop or FL-port. Handle a couple of new async
mailbox commands which signify connection in Point-to-Point mode
(N-port or F-port) or indicate various toe stubbing getting to same.

Approved: jkh@freebsd.org

clean up for SBus Ultra (yes, we do not do that here yet)

change debug printout lefvels for a couple of places

Make Fibre Channel cards correctly note the presence/absence
of ARQ data and punt the dealing with its presence/absence
to the platform layers.

Raise default FCP logintime to 60 seconds. Move the position
of where we could have seen the loop up at least once so it
makes sense. Change some stuff in ispscsicmd so we don't get
stuck there if the loop has never come up yet. Add in some
target mode support code.

Clean up some f/w revision checking wrt enabling fast posting.
Make sure we set defaults sanely for dual-bus adapters.

Add Dual LVD bus (1280) support

turn some messages into CFGPRINT messages

Clean up stupidity in the isp_handle_other_response function- indexes
of queue entries have to be at least 16 bits now! If we're running
a 2100 less than rev 5, turn off loop fairness (per Qlogic errata). Fix
typo in checking against 2200 F/W revision. Slightly fix/reorder fabric
login stuff. Change to usage of isp_getrqentry for code clarity. Add some
defensive dual bus assumptions. Various cleanups, etc...

correct moronic typo

Use pointer to f/w in md structure as to whether f/w exists or not.
If firmware length isn't specified, extract from the 4th short into
the firmware.

I was misinformed. I cannot get away from specifying tags for FC. Some devices
are happy w/o them- some are unhappy (IBM drives).

nuke a debug printout I thought I had already nuked

remember to initialize mailbox 2 for FC isp bus resets

Remove some target mode stuff. It will get re-introduced in a different
file later. Do some pencil-sharpening types of minor changes. Change
how active commands are remembered (using new inline functions to get
handles, etc..). Now do a GET FIRMWARE STATUS after firing up the f/w as
outgoing mailbox 2 will tell you the f/w's notion of the max commands
that can be supported. Attempt to retrieve loop topology. Add in the
appropriate SWIZZLE/UNSWIZZLE macros calls (this is a no-op on Little
Endian machines but is needed for sparc (on other platforms)). Move
the temp port database we use to find out where things have moved to
after a LIP to the softc and off the kernel stack. Follow Qlogic's
hint and don't bother setting a tag for commands that don't have
this enabled (presumably the f/w will do it's own selection then).
Use an INT_PENDING macro to check for an interrupt. The call to
ISP_DMAFREE now just takes the handle- not the 'handle-1' which was
a layering violation. Use CFGPRINTF in a couple of places to make
things less chatty if not booting verbose, or CAMDEBUG compiles, etc..

$Id$ -> $FreeBSD$

More code cleanup. Go back to using FULL_LOGIN Fibre Chan if f/w is less than
1.17.0 level. Change where we do the loop database init. Add in the CMD_RQLATER
return. Add some register debounce.

add 2200 f/w; fix botched define

Roll revision levels. Add support for the Qlogic 2200 (warn about
not having SCSI_ISP_SCCLUN config defined if we don't have f/w for
the 2200- it's resident firmware uses SCCLUN (65535 luns)). Change
the way the default LoopID is gathered (it's now a platform specific
define so that some attempt at a synthetic WWN can be made in case
NVRAM isn't readable).

Change initialization of options a bit- don't use ADISC. Set
FullDuplex mode if config options tells us to do so. Do not use
FULL_LOGIN after LIP- it's the right thing to do but it causes too
much loop disruption (Loop Resets). Sanity check some default
values. Redo construction of port and node WWNs based upon what we
have- if we have 2 in the top nibble, we can have distinct port
and node WWNs. Clean up some SCCLUN related code that we obviously
had never compiled (:-(). Audit commands coming int ispscsicmd and
don't throw commands at Fibre devices that do not have Class 3
service parameters TARGET ROLE defined.

Clean up f/w initialization a bit. Add Fabric support (or at least
the first blush of it). Whew - way too much to describe here.
Basically, after a LIP, hang out until we see a Loop Up or a Port
DataBase Change async event, then see if we're on a Fabric
(GET_PORT_NAME of FL_PORT_ID). If we are, try and scan the fabric
controller for fabric devices using the GetAllNext SNS subcommand.
As we find devices, announce them to the outer layer. Try and do
some guard code for broken (Brocade) SNS servers (that get stuck
in loops- gotta maybe do this a different way using the GP_ID3 cmd
instead). Then do a scan of the lower (local loop) ids using a
GET_PORT_NAME to see if the f/w has logged into anything at that
loop id. If so, then do a GET_PORT_DATABASE command. Do this scan
into a local database. At this point we can say the loop is 'Ready'.
After this, we merge our local loop port database with our stored
port database- in a as yet to be really fully exercised fashion we
try and follow the logic of something having moved around. The
first time we see something at a Loop ID, we fix it, for the purpose
of this system instance, at that Loop ID. If things shift around
so it ends up somewhere else, we still keep it at this Loop ID (our
'Target') but use the new (moved) Loop ID when we actually throw
commands at it. Check for insane cases of different Loop IDs both
claiming to have the same WWN- if that happens, invalidate both.
Notify the outer layer of devices that have arrived and devices
that have gone away. *Finally*, when this is done, search the
softc's database of Fabric devices and perform logout/login actions.
The Qlogic f/w maintains logout/login for all local loop devices.
We have to maintain logout/login for fabric devices- total PITA.
Expect to see this area undergo more change over time.

be a bit more chatty about some speed negotiations

Some massive thwunking in initialization to handle dual bus adapters. More
massive thwunking to include an XS_CHANNEL value. Some changes of how
parameters are reported to outer layers (including bus, e.g.). Yet more
stirring around in isp_mboxcmd to try and get it right. Decode of 1080/1240
NVRAM.

temp fix for internal queue overflow problem

Make firmware revision a triple. Clean up some FC init stuff for
board versions with no BIOS. Separate mailbox interrupts from
IOCB interrupts. Read OUTMAILBOX5 while RISC_INT is active- not
after you clear it (potential race condition). Clear out older broken
BIG_ENDIAN goop. Don't negotiate narrow/async for LVD busses at startup
if already in LVD mode. Note usage of presumptive 1040C revision. For
all the LIP, PDB Changed, Loop UP/DOWN async events, mark fw state
as unknown as well as marking the need to do a getpdb on targets- after
a LIP for certain the f/w has to do PRLI/PLOGI for all targets again
and marking f/w state as unknown gives us a fighting chance to (start
to) hold up for that to complete.

Annoying little nigglet- apparently *some* Qlogic temporarily ignore
settings you've just sent them and return random values if you follow
the set by a get. This causes problems when you latter run a Tag-enabled
command when you've command tagged mode off.

Add in 1080 LVD support and some basis also for the 1240. The port database
printout is now enabled.

A wad of changes- prepping for 1080/1240 support (which caused a massive
thwank in register layout goop). A different mboxcmd approach. Some PDB change
infrastructure. Some better management of loopdown/loopup events (keep them
distinct from resource starvation for simq freeze/unfreeze actions).

Roll internal release tag. Print out if we're in a 64 bit PCI slot.
Use fast memory timing NVRAM parameter. Clean up and fix establishment
of default target parameters. Don't use NVRAM if are flagged as not to
do so (I had a busted NVRAM setup which I couldn't edit that enabled SYNC
mode but disabled disconnect/reconnect and wide!!). Fix delays after
resets. BUS resets not done in isp_init anymore- relegated to OS
specific outer layers. Fix a buglet where you can get in a loop for
a NULL xs in the completion list in isp_intr. Add in some defines that
can disable fast posting. Add in code for Loop Up/Loop Down events that
call into the outer layers as to what to do.

Implement and use Fast Posting for both parallel && fibre. Redo a bit of
the startup code. Implement a call to outer framework function so that
asynchronous events can be handled (e.g., speed negotiation, target mode).

Roll internal release tags.

Suggested by bde@freebsd.org- memcpy not necessarily good to use. D'oh- not in
the BSD DKI. Stop being lazy and finish the defines so MEMCPY becomes bzero
for FreeBSD.

Add some prototype deadchip detection. Set FIFO bursting (1XX0 only-
it's already on for the 2XX0) and detect the broken 1040A FIFO. Change
bzero to MEMZERO (portability with **nux). Use memcpy for same reason.

Finally detect QUEUE FULL conditions and return this as an error that
will get cam_periph_error to do it's 'tagged openings now XXX' dance.

clarify headers;move uninit to outer layer;remove watchdog

oops on last

Remove the Target mode functions until they're in better shape. Implement some
suggested compilation cleanups from Eklund. Wire down a hard loop id if we are
not on a platform that has the ability to get to a PCI BIOS (it still will
float to the ID it gets after a LIP but at least we can try). Clarify that the
expanded lun is based upon SCCLUN defines (in f/w).

per bde (who is right about this) that an inlined fucntion with const
char * strings being returned defined in a header file included several
places but only used in one module, is, uh, silly.

Cleanliness. Don't leave defined a const char array that's only used
if target mode is defined (which it isn't, yet).

ISP_DMASETUP now returns a value to be possibly punted to outer layers.
Turn request queue overflow messages into debug messages. Ensure on
isp_restarts that we nullify the xflist array.

fix reported compile error flying blind- I do not have the new compiler yet

Update QLogic ISP support for CAM. Add preliminary target mode support.

Submitted by: Matthew Jacob <mjacob@feral.com>

Add support for the Qlogic ISP SCSI && FC/AL Adapters