src/sys/dev/twa, branch release/12.3.0

MFC r346386, r347890, r347896, r349895:

2020-07-08T17:59:00Z

remove the 4GB boundary requirement on PCI DMA segments

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

2017-11-27T14:52:40Z

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.

Update tw_cl_share.h to allow 255 LUNs

2017-03-01T04:40:57Z

TW_CL_MAX_NUM_LUNS should not be 16 but I presume 255. I have a 3ware controller with more than 16 volumes (LUN's) and otherwise all LUN's above the 16'th are not working. Submitted by: jcatrysse Pull Request: https://github.com/freebsd/freebsd/pull/100

In the same vein as r311350, fix whitespace in handling of XPT_PATH_INQ in

2017-01-05T03:08:57Z

several more drivers. Sponsored by: Panasas

Always null-terminate ccb_pathinq.(sim_vid|hba_vid|dev_name)

2017-01-04T20:26:42Z

The sim_vid, hba_vid, and dev_name fields of struct ccb_pathinq are fixed-length strings. AFAICT the only place they're read is in sbin/camcontrol/camcontrol.c, which assumes they'll be null-terminated. However, the kernel doesn't null-terminate them. A bunch of copy-pasted code uses strncpy to write them, and doesn't guarantee null-termination. For at least 4 drivers (mpr, mps, ciss, and hyperv), the hba_vid field actually overflows. You can see the result by doing "camcontrol negotiate da0 -v". This change null-terminates those fields everywhere they're set in the kernel. It also shortens a few strings to ensure they'll fit within the 16-character field. PR: 215474 Reported by: Coverity CID: 1009997 1010000 1010001 1010002 1010003 1010004 1010005 CID: 1331519 1010006 1215097 1010007 1288967 1010008 1306000 CID: 1211924 1010009 1010010 1010011 1010012 1010013 1010014 CID: 1147190 1010017 1010016 1010018 1216435 1010020 1010021 CID: 1010022 1009666 1018185 1010023 1010025 1010026 1010027 CID: 1010028 1010029 1010030 1010031 1010033 1018186 1018187 CID: 1010035 1010036 1010042 1010041 1010040 1010039 Reviewed by: imp, sephe, slm MFC after: 4 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D9037 Differential Revision: https://reviews.freebsd.org/D9038

Replace several bus_alloc_resource() calls using default arguments with bus_alloc_resource_any()

2016-02-19T03:37:56Z

Since these calls only use default arguments, bus_alloc_resource_any() is the right call. Differential Revision: https://reviews.freebsd.org/D5306

CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten

2015-05-22T17:05:21Z

years for head. However, it is continuously misused as the mpsafe argument for callout_init(9). Deprecate the flag and clean up callout_init() calls to make them more consistent. Differential Revision: https://reviews.freebsd.org/D2613 Reviewed by: jhb MFC after: 2 weeks

Adjust various SCSI drivers to handle either a 32-bit or 64-bit lun_id_t,

2013-10-30T14:04:47Z

mostly by adjustments to debugging printf() format specifiers. For high numbered LUNs, also switch to printing them in hex as per SAM-5. MFC after: 2 weeks

Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCI

2013-08-12T23:30:01Z

command register. The lazy BAR allocation code in FreeBSD sometimes disables this bit when it detects a range conflict, and will re-enable it on demand when a driver allocates the BAR. Thus, the bit is no longer a reliable indication of capability, and should not be checked. This results in the elimination of a lot of code from drivers, and also gives the opportunity to simplify a lot of drivers to use a helper API to set the busmaster enable bit. This changes fixes some recent reports of disk controllers and their associated drives/enclosures disappearing during boot. Submitted by: jhb Reviewed by: jfv, marius, achadd, achim MFC after: 1 day

MFprojects/camlock r248982:

2013-04-14T09:55:48Z

Stop abusing xpt_periph in random plases that really have no periph related to CCB, for example, bus scanning. NULL value is fine in such cases and it is correctly logged in debug messages as "noperiph". If at some point we need some real XPT periphs (alike to pmpX now), quite likely they will be per-bus, and not a single global instance as xpt_periph now.