tests/kernel/setjmp_tester: Apparently kmods have .debug data too!

(Fix set list.)

PR port-riscv/59304: kernel longjmp(9) fails to make setjmp(9) return 1
PR port-hppa/59305: kernel longjmp(9) fails to make setjmp(9) return 1
PR port-powerpc/59306: kernel longjmp(9) fails to make setjmp(9) return 1
PR port-sparc/59307: kernel longjmp(9) fails to make setjmp(9) return 1
PR port-vax/59308: kernel longjmp(9) fails to make setjmp(9) return 1

A driver and userland utility for a couple of families of the
Microchip Technology / SMSC fan controller chips.

The driver and utility supports the:

o EMC2101 and EMC2101-R
o EMC2103-1, EMC2102-2 and EMC2103-4
o EMC2104
o EMC2106
o EMC2301
o EMC2302
o EMC2303
o EMC2305

The EMC210X family supports 1 or 2 fans with tachometer. Depending on
the chip, it may support 2 additional fans without tach and might
support a high side attachment (i.e. a fan, usually 5v, driven
directly from the chip and not PWM or DAC). All versions of EMC210X
support internal temperature measurements, and depending on the chip,
may support up to 5 additional temperature zones. The tachometers and
temperature measurements are provided to the system via the envsys(4)
framework. Some chip types support GPIO pins and support is provided
via the gpio(4) framework.

The EMC230X family supports 1, 2, 3 or 5 fans with the same number of
tachometers. No temperature zone or GPIO support. The tachometers
are provided to the system via the envsys(4) framework. The fan
support can be provided by PWM signaling or DAC.

The two chip families mostly do PWM signaling for the fan speed, but a
number of them support DAC output, a 0 to 3v or so voltage. When the
chip supports external temperature zones, this is done usually by a
bipolar NPN or PNP transister configured as a diode, but some of the
chip varients support thermistors.

The emcfan(4) kernel driver provides a simple read / write / seek
device in /dev/ to the register set in the chip. The heavy lifting is
done in the userland utility emcfanctl(8) which provides the ability
to read and write to any valid register and provides some basic higher
level commands to control fan behavior. The output is simple text
lines, or JSON.

The kernel driver does not reset or other mess with the chip, aside
from reading registers. It is entirely possible that something else
in any particular system is the major manager of the fan controller
and it would not do for the kernel driver to mess too much with the
attached device. All interactions are intentional via the userland
utility.

It is known that a EMC2301 is present on the Raspberry PI 4 Compute IO
module (not to be confused with the Raspberry PI 4 Compute module
itself) and there is a breakout board from Adafruit with a EMC2101 on
it. The chips themselves are pretty inexpensive from Mouser or
Digi-key and can be soldered using the simpler SMD soldering
techniques. A number of the variants are QFN packages, but the pads
are exposed to the side of the chip. No other external components are
required to use these fan controllers.

A driver for the DS28E17 1-Wire to I2C bridge chip.

This chip acts like a 1-Wire slave device and provides a iic(4) master
at the end of the 1-Wire bus. More or less it is the polar opposite
of the DS2482 [ds2482ow(4)] chip.

This device couples well with ds2482ow(4) and can be used to provide a
I2C bus at very great lengths from the controlling computer.

All features of the chip are supported, except for 1-Wire overdrive
support, which requires more work from the onewire(4) infrastructure.

The chip does not support Read without Stop. Attempts to do this will
get turned into a Read with Stop and one will have to hope for the
best. The chip also does not support zero length I2C reads or zero
length I2C writes. This has the side effect of making the default
mode, a zero length I2C write, for i2scan(8) return false positives.
The alternative mode that i2cscan(8) can use, the single byte read,
should work as expected.

The chip has automatic support for end devices that do I2C clock
stretching.

It was noticed that this chip does not work with the gpioow(4) driver.
That might be an interesting thing to debug if one has a good logic
analyzer on hand. While the presence pulse is detected, the gpioow(4)
driver is not able to complete the initial ROM enumeration. The
DS28E17 works flawlessly when driven by a DS2482 [ds2482ow(4)] driver
chip. Poke me if you want any more details.

The chip is pretty inexpensive and only requires a single cap to get
it hooked up. However, the package it comes in is only a 16-QFN
package, so it could provide to be hard to solider onto a board for
some. There are side tabs, so it was possible with a very small iron
and lots of flux. There is a slightly expensive breakout board sold
by Mikroe that probably works well -> https://www.mikroe.com/1-wire-i2c-click

Add ncm(4) a driver for USB Network Control Model

Seen on my Google Pixel 8, which implements ncm instead of urndis.

typo

Add new ds2482ow module debug info

modules: Build `ipl` module only if MKIPFILTER is enabled

distrib/sets/lists: Add a blank comment line between RCS id and body.

This serves as a buffer between RCS id changes and other changes to
the set lists, in an attempt to reduce the pain of merge conflicts
around mass set list changes.

No functional change intended.

branches: 1.25.2;
make owtemp a module

add compat_100 module setlist entries

branches: 1.23.2;


Split the BMP280 / BME280 driver into common code and create I2C and
SPI attachments.

A driver for the Bosch BMP280 / BME280 temperature, humidity and
atmospheric pressure sensor. This is an inexpensive to moderately
expensive chip available from a large number of places. The driver
supports all aspects of the two chips, except for the repeating read
mode which would allow for sub-second queries, such as fall detection
or perhaps even as an altimeter. This driver also only supports the
I2C interface and not the SPI interface.

The BME280, the one with humidity, is not fully tested at this point,
awaiting upon a breakout board and may not show proper humidity.

A driver for the Aosong AHT20 temperature and humidity sensor. While
slow for an I2C sensor it is inexpensive and should work well enough
in most indoor conditions. All features of the chip are supported.

Add sets-lists entries for the new combined midi_seq module

Add the new scsi_subr module to sets lists.

Create a loaable adiantum module, and make cgd require it.

This enablees use of a loadable cgd module, rather thtan requiring
it to be built-in.

Partially resolves kern/56772

Split i2c_subr.c into a separate module rather than including it in
the iic module. There are valid configurations where i2c_subr code
can be both built-in and part of a loaded module (eg, piixpm is in
the kernel, but the iic module is loaded later). This causes the
in-kernel linker to detect a duplicate symbol.

A driver and user land utility for the Sparkfun Serial Controlled Motor
Driver module as illustrated here:

https://www.sparkfun.com/products/13911

A SCMD module is a ARM SOC simular to a Arduino in front of a motor
driver chip. The single SCMD module can control two motors and up to
16 additional modules can be chained together using an internal I2C
bus. One can interface with the SCMD using tty uart commands, SPI or
I2C. The driver in this commit adds a kernel driver for the I2C and
SPI interfaces. The command line utility provides a set of
convenience commands that support most of the functions of the SCMD
and is able to use the tty uart mode, SPI user land or the included
kernel driver in a uniform manor.

The use of the SCMD module is mostly for small robots and the like,
but it can control anything that is controllable by voltage.

Driver for the Sensirion SHT30/SHT31/SHT35 temperature and humidity
sensor such as:

https://www.adafruit.com/product/2857

This is a higher priced sensor with a lot of features, including the
ability to do sub-second periodic updates. The driver supports
everything about the sensor except for the alert pin.

A driver for the Sensirion SGP40 MOx gas sensor. An example of this
chip from Adafruit is:

https://www.adafruit.com/product/4829

This is a moderately priced gas sensor that can detect volatile
organic compounds in the air. The driver uses the 3-clause BSD
licensed VOC algorithm provided by Sensirion to turn the raw sensor
metric into a VOC index which can indicate the quality of the air in a
particular indoor environment. All published functions of the chip
are supported and one unpublished feature.

Sorry.. missed the debug module build in the previous commit.

Build and install the if_run module. run(4) is not necessarily included
in all GENERIC kernels (as reported on libera IRC).

don't mark sodium as solaris

modules for if_wg, blake2s, libsodium

Add a new link-aggregation pseudo interface named lagg(4)

- FreeBSD's lagg(4) based implementation
- MP-safe and MP-scalable

branches: 1.8.2;
Move pad module to MI debug set lists

branches: 1.7.2;
Fix build for mips; move from mi to module.mi debug symbols for
test cases only available when MKKMOD=yes.

Add HAVE_NVMM and use it to control the build of NVMM related components.
Defined to "yes" on amd64, "no" everywhere else.

Add module debug sets

Move the rump module test programs in the regular mi file. These are not
really kernel modules and the other md module test is in the md.amd64 file
already.

Register t_ufetchstore.debug in distrib files

add missing debug file for kcov.

branches: 1.1.2; 1.1.6; 1.1.36;
Add a new "debug" set that gets built when ${MKDEBUG} is set. On evbarm:
-rw-r--r-- 1 root src 35806068 Jan 16 10:47 base.tgz
-rw-r--r-- 1 root src 57374069 Jan 16 10:48 comp.tgz
-rw-r--r-- 1 root src 101286193 Jan 16 10:49 debug.tgz
...
This allows always building the debugging code and libraries but not
installing it (although now it is placed in the default sets if ${MKDEBUG}
is set