It is not a problem of UINT_MAX, it is a problem to ignore potentially correct reported value.

I agree with everything you say we should do. But we are not there yet, and until that time SIMs have to keep some sort of mapping table for CAM to use. From the CAM point now all target IDs of the SCSI domain the HBA is connected to, including the initiator_id are from that mapping table. I am not sure what exactly makes no sense to you in my descrintion of how things are working for FC now and why exactly the same is not applicable to SAS to add this dirty hack?

I have no objections, but it would be good to request review from some port committers.

The patch will make XPT_SCAN_TGT/XPT_SCAN_BUS to scan target they should not.

As I have told, SAS may also work as target, we just miss respective SIM. And the code skipping the initiaror_id during scan allows to not scan own target, if we ever have non-FC targets. What is so difficult in fixing few SAS SIMs to report initiator_id out of the range of valid initiator role targets?

I think it is a wrong way to go. While specific initiator ID value has sense only on parallel SCSI and loop mode FC and is obsolete these days, the idea of having some id reserved for the local HBA itself makes a lot of sense for FC now, when isp(4) driver can operate both initiator and target role same time, and the initiator id is used to represent target role periphs, while other ids are used rot initiator role. Such concepts looks totally valid to me. Even though we do not have SAS target driver (I dreamed about it for years), I don't think we should make it impossible instead of trivially fixing few drivers.

Hi. Does the Hygon really have only one AHCI ID where AMD had 5?

I won't object too much, but first addition of quite specialized command and then workaround for it does not make me particularly happy.

I would honestly prefer drivers to report reasonable errors on unknown commands. That would fix the issue once and for all.

Looks good to me.

I am not sure what is the point of atomic there, except may be preventing compiler from optimizing it out, if that can happen somehow. Otherwise it looks fine to me. I don't remember the interrupt teardown semantics here to say whether use-after-free is possible, but I agree with @galatin that flags may change in run time, causing epoch leak, so this code must be here.

I have no objections, other than I would not use braces for the if's, or at least put the opening one in the first case on the same like, as Ryan proposed.

EFRAGS seems not to be really used on FreeBSD. It is mentioned once in code, but it seems to be dead from the day one -- used on Illumos to support dumping to ZVOL. I am not sure why ZoL haven't dropped it yet.
About ECKSUM->EINTEGRITY I have no objections, other then Linux maps it into some nonsense, so some applications may get surprised if notice the difference. But that may be unavoidable.