src/sys/dev/ciss, branch releng/12.4

ciss(4): Fix typo.

2021-10-19T15:13:31Z

(cherry picked from commit 5f8cb13cfb0c91a4ec1a9648a3ae245b1dff36f6)

ciss(4): Properly handle data underrun.

2021-10-19T15:13:31Z

For SCSI data underrun is a part of normal life. It should not be reported as error. This fixes MODE SENSE used by modern CAM. MFC after: 1 month (cherry picked from commit e8144a13e075ff13c1f162690c7f14dd3f0a4862)

MFC r359110: Add missing STAILQ_INIT() in ciss_disable_adapter().

2020-04-02T00:28:26Z

I think it should fix reported panic after "ADAPTER HEARTBEAT FAILED".

MFC r349011 (by imp):

2020-03-18T23:53:07Z

Don't print the request we may be aborting in ciss_notify_abort as part of ciss_detach. It's a left-over debug that isn't needed and also discloses a kernel address. Only root could provoke as part of a devctl or kldunload. Submitted by: Fuqian Huang

Reapply, with minor tweaks, r338025, from the original commit:

2018-09-26T17:12:14Z

Remove unused and easy to misuse PNP macro parameter Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS). Approved by: re (glen)

Back out r338035 until Warner is finished churning GSoC PNP patches

2018-08-19T00:46:22Z

I was not aware Warner was making or planning to make forward progress in this area and have since been informed of that. It's easy to apply/reapply when churn dies down.

Remove unused and easy to misuse PNP macro parameter

2018-08-19T00:22:21Z

Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS).

Add PNP info to PCI attachments of ciss driver

2018-07-08T20:40:10Z

Move the module declaration so that it's after the device table. The PNP_INFO must come after the module declaration. Reviewed by: imp, chuck Submitted by: Lakhan Shiva Kamireddy Sponsored by: Google, Inc. (GSoC 2018) Differential Revision: https://reviews.freebsd.org/D15995

Update a TBD string with a real model number

2018-03-25T06:08:18Z

Submitted by: Sam Gwydir

Revert r327828, r327949, r327953, r328016-r328026, r328041:

2018-01-21T15:42:36Z

Uses of mallocarray(9). The use of mallocarray(9) has rocketed the required swap to build FreeBSD. This is likely caused by the allocation size attributes which put extra pressure on the compiler. Given that most of these checks are superfluous we have to choose better where to use mallocarray(9). We still have more uses of mallocarray(9) but hopefully this is enough to bring swap usage to a reasonable level. Reported by: wosch PR: 225197