<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <link>http://nxr.netbsd.org/rss/src/sys/modules/Makefile</link>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2005</copyright>
    <generator>Java</generator>
    
<item>
    <title>Add Policy based routing by interface in NPF</title>
    <description>/src/sys/modules/Makefile - 1.301</description>
    <pubDate>Wed Apr 08 00:33:06 UTC 2026</pubDate>
    <dc:creator>joe</dc:creator>
</item>

<item>
    <title>pchtemp: add a simple driver for intel pch thermal sensor<br/><br/>tested on PCI_PRODUCT_INTEL_2HS_THERM, which was found on HP Z4 G4.<br/>although other variants look compatible, i have not actually tested them.<br/>(no hardware)<br/><br/>dmesg:<br/>```<br/>[   512.596379] pchtemp0 at pci0 dev 20 function 2: Intel PCH Temperature Sensor<br/>```<br/><br/>envstat:<br/>```<br/>[pchtemp0]<br/>  pchtemp0 temperature:    41.500                                      degC<br/>```<br/><br/>enable in kernel configs where amdtemp is enabled.<br/><br/>the man page is mostly copy-and-paste from amdtemp.4.</title>
    <description>/src/sys/modules/Makefile - 1.300</description>
    <pubDate>Fri Feb 20 07:54:26 UTC 2026</pubDate>
    <dc:creator>yamt</dc:creator>
</item>

<item>
    <title>Cross-ref to PR/59716</title>
    <description>/src/sys/modules/Makefile - 1.299</description>
    <pubDate>Sun Dec 28 20:24:56 UTC 2025</pubDate>
    <dc:creator>pgoyette</dc:creator>
</item>

<item>
    <title>Add MODULE glue and build infrasructure.<br/><br/>XXX	We won't actually build or install it due to kern/59716 but<br/>XXX	it can be manually built and installed if you want.</title>
    <description>/src/sys/modules/Makefile - 1.298</description>
    <pubDate>Tue Oct 21 07:23:05 UTC 2025</pubDate>
    <dc:creator>pgoyette</dc:creator>
</item>

<item>
    <title>Disable a few modules that need serious work to build.<br/><br/>Add if_rge to the list of {bus,attachment}-specific modules</title>
    <description>/src/sys/modules/Makefile - 1.297</description>
    <pubDate>Tue Oct 21 04:29:49 UTC 2025</pubDate>
    <dc:creator>pgoyette</dc:creator>
</item>

<item>
    <title>A driver and userland utility for a couple of families of the<br/>Microchip Technology / SMSC fan controller chips.<br/><br/>The driver and utility supports the:<br/><br/>o EMC2101 and EMC2101-R<br/>o EMC2103-1, EMC2102-2 and EMC2103-4<br/>o EMC2104<br/>o EMC2106<br/>o EMC2301<br/>o EMC2302<br/>o EMC2303<br/>o EMC2305<br/><br/>The EMC210X family supports 1 or 2 fans with tachometer.  Depending on<br/>the chip, it may support 2 additional fans without tach and might<br/>support a high side attachment (i.e. a fan, usually 5v, driven<br/>directly from the chip and not PWM or DAC).  All versions of EMC210X<br/>support internal temperature measurements, and depending on the chip,<br/>may support up to 5 additional temperature zones.  The tachometers and<br/>temperature measurements are provided to the system via the envsys(4)<br/>framework.  Some chip types support GPIO pins and support is provided<br/>via the gpio(4) framework.<br/><br/>The EMC230X family supports 1, 2, 3 or 5 fans with the same number of<br/>tachometers.  No temperature zone or GPIO support.  The tachometers<br/>are provided to the system via the envsys(4) framework.  The fan<br/>support can be provided by PWM signaling or DAC.<br/><br/>The two chip families mostly do PWM signaling for the fan speed, but a<br/>number of them support DAC output, a 0 to 3v or so voltage.  When the<br/>chip supports external temperature zones, this is done usually by a<br/>bipolar NPN or PNP transister configured as a diode, but some of the<br/>chip varients support thermistors.<br/><br/>The emcfan(4) kernel driver provides a simple read / write / seek<br/>device in /dev/ to the register set in the chip.  The heavy lifting is<br/>done in the userland utility emcfanctl(8) which provides the ability<br/>to read and write to any valid register and provides some basic higher<br/>level commands to control fan behavior.  The output is simple text<br/>lines, or JSON.<br/><br/>The kernel driver does not reset or other mess with the chip, aside<br/>from reading registers.  It is entirely possible that something else<br/>in any particular system is the major manager of the fan controller<br/>and it would not do for the kernel driver to mess too much with the<br/>attached device.  All interactions are intentional via the userland<br/>utility.<br/><br/>It is known that a EMC2301 is present on the Raspberry PI 4 Compute IO<br/>module (not to be confused with the Raspberry PI 4 Compute module<br/>itself) and there is a breakout board from Adafruit with a EMC2101 on<br/>it.  The chips themselves are pretty inexpensive from Mouser or<br/>Digi-key and can be soldered using the simpler SMD soldering<br/>techniques.  A number of the variants are QFN packages, but the pads<br/>are exposed to the side of the chip.  No other external components are<br/>required to use these fan controllers.</title>
    <description>/src/sys/modules/Makefile - 1.296</description>
    <pubDate>Tue Mar 11 13:56:46 UTC 2025</pubDate>
    <dc:creator>brad</dc:creator>
</item>

<item>
    <title>A driver for the DS28E17 1-Wire to I2C bridge chip.<br/><br/>This chip acts like a 1-Wire slave device and provides a iic(4) master<br/>at the end of the 1-Wire bus.  More or less it is the polar opposite<br/>of the DS2482 [ds2482ow(4)] chip.<br/><br/>This device couples well with ds2482ow(4) and can be used to provide a<br/>I2C bus at very great lengths from the controlling computer.<br/><br/>All features of the chip are supported, except for 1-Wire overdrive<br/>support, which requires more work from the onewire(4) infrastructure.<br/><br/>The chip does not support Read without Stop.  Attempts to do this will<br/>get turned into a Read with Stop and one will have to hope for the<br/>best.  The chip also does not support zero length I2C reads or zero<br/>length I2C writes.  This has the side effect of making the default<br/>mode, a zero length I2C write, for i2scan(8) return false positives.<br/>The alternative mode that i2cscan(8) can use, the single byte read,<br/>should work as expected.<br/><br/>The chip has automatic support for end devices that do I2C clock<br/>stretching.<br/><br/>It was noticed that this chip does not work with the gpioow(4) driver.<br/>That might be an interesting thing to debug if one has a good logic<br/>analyzer on hand.  While the presence pulse is detected, the gpioow(4)<br/>driver is not able to complete the initial ROM enumeration.  The<br/>DS28E17 works flawlessly when driven by a DS2482 [ds2482ow(4)] driver<br/>chip.  Poke me if you want any more details.<br/><br/>The chip is pretty inexpensive and only requires a single cap to get<br/>it hooked up.  However, the package it comes in is only a 16-QFN<br/>package, so it could provide to be hard to solider onto a board for<br/>some.  There are side tabs, so it was possible with a very small iron<br/>and lots of flux.  There is a slightly expensive breakout board sold<br/>by Mikroe that probably works well -&gt; https://www.mikroe.com/1-wire-i2c-click</title>
    <description>/src/sys/modules/Makefile - 1.295</description>
    <pubDate>Thu Jan 23 19:02:42 UTC 2025</pubDate>
    <dc:creator>brad</dc:creator>
</item>

<item>
    <title>Add ncm(4) a driver for USB Network Control Model<br/><br/>Seen on my Google Pixel 8, which implements ncm instead of urndis.</title>
    <description>/src/sys/modules/Makefile - 1.294</description>
    <pubDate>Mon Jan 20 13:54:55 UTC 2025</pubDate>
    <dc:creator>maya</dc:creator>
</item>

<item>
    <title>Add a driver for the Maxim DS2482-100 and DS2482-800 I2C to 1-Wire<br/>bridge.<br/><br/>This chip provides a I2C device that then has 1 or 8 1-Wire busses on<br/>the other side.  The 1-Wire buses show up as onewire(4) buses in the<br/>NetBSD.<br/><br/>The chip can be used in situations where:<br/><br/>* You have a I2C bus extended a long distance, say with a LTC4311<br/>  active terminator / extender or one of the differential I2C<br/>  extenders and you would like to have a 1-Wire device on the far end<br/>  and it isn't possible to add wiring to get to the far end.<br/><br/>* You are either out of GPIO pins or the GPIO pins are not reliable<br/>  enough to use gpioow(4), but you do have working I2C.<br/><br/>The DS2482 does all of the 1-Wire signals in hardware and provides for<br/>a couple of pullup options for the 1-Wire devices.<br/><br/>All of the functions of the DS2482-100 and -800 are supported except<br/>for overdrive speed support.  To do this will likely require some API<br/>changes to onewire(4).<br/><br/>Breakout boards exist for the DS2482 for both variants, but they<br/>appear to be more expensive than expected.  The chip itself is quiet<br/>cheap and wasn't all that hard to SMD solder to a board.  No other<br/>components are really needed.<br/><br/>There are other members in the same family, the DS2482-101, DS2484 and<br/>DS2485.  The DS2482-101 has a sleep pin, but from the datasheet<br/>appears to program the same as the -100 variant.  The DS2484 has a<br/>slightly different way to set configuration information and probably<br/>won't quite work with the driver, but isn't far off.  The DS2485 is<br/>very different and would require a new driver to function.</title>
    <description>/src/sys/modules/Makefile - 1.293</description>
    <pubDate>Mon Nov 04 20:43:38 UTC 2024</pubDate>
    <dc:creator>brad</dc:creator>
</item>

<item>
    <title>acpivmgenid(4): New driver for virtual machine generation ID.<br/><br/>Added to amd64/ALL and i386/ALL kernel configurations, and made<br/>available as a loadable module acpivmgenid.kmod on x86, for now.<br/><br/>TBD: Add to all ACPI-supporting GENERIC kernels.<br/><br/>PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM<br/>fork</title>
    <description>/src/sys/modules/Makefile - 1.292</description>
    <pubDate>Mon Aug 26 13:38:28 UTC 2024</pubDate>
    <dc:creator>riastradh</dc:creator>
</item>

<item>
    <title>modules: Build `ipl` module only if MKIPFILTER is enabled</title>
    <description>/src/sys/modules/Makefile - 1.291</description>
    <pubDate>Thu Jul 18 04:28:55 UTC 2024</pubDate>
    <dc:creator>rin</dc:creator>
</item>

<item>
    <title>branches:  1.290.2;<br/>Oooppss remove some local change that was accidentally committed</title>
    <description>/src/sys/modules/Makefile - 1.290</description>
    <pubDate>Mon May 20 18:14:38 UTC 2024</pubDate>
    <dc:creator>pgoyette</dc:creator>
</item>

<item>
    <title>Don't build the compat_110 module yet - there's no release_110  with which<br/>we can be compatable.</title>
    <description>/src/sys/modules/Makefile - 1.289</description>
    <pubDate>Mon May 20 17:32:51 UTC 2024</pubDate>
    <dc:creator>pgoyette</dc:creator>
</item>

<item>
    <title>sys/modules: Don't make compat_110.<br/><br/>Eventually we'll need this but it doesn't make sense until 11.0 is<br/>released.</title>
    <description>/src/sys/modules/Makefile - 1.288</description>
    <pubDate>Mon May 20 13:34:12 UTC 2024</pubDate>
    <dc:creator>riastradh</dc:creator>
</item>

<item>
    <title>version dup3</title>
    <description>/src/sys/modules/Makefile - 1.287</description>
    <pubDate>Sun May 19 22:25:49 UTC 2024</pubDate>
    <dc:creator>christos</dc:creator>
</item>

<item>
    <title>port-arm/58194: Resurrect vmt(4) from bitrot<br/><br/>On this architecture vmt(4) used to search for a node "/hypervisor" in the<br/>FDT and probed the VMware hypervisor call only when the node was<br/>found. However, things appear to have changed and VMware no longer provides<br/>the FDT node.<br/><br/>Since vmt(4) doesn't actually need to read anything from FDT, and the<br/>hypervisor call logically resides in virtual CPUs themselves, it would be<br/>better to attach it directly to cpu, just like how it's probed on x86.</title>
    <description>/src/sys/modules/Makefile - 1.286</description>
    <pubDate>Thu May 09 00:09:59 UTC 2024</pubDate>
    <dc:creator>pho</dc:creator>
</item>

<item>
    <title>bsd.own.mk: Enable MKLSJIT on aarch64.<br/><br/>Make sure there's only one copy of the conditional, in bsd.own.mk;<br/>just make sys/modules/Makefile conditional on MKSLJIT so we don't<br/>have to keep these in sync.<br/><br/>As a workaround for PR 58106, tweak the conditional definition of<br/>SLJIT_CACHE_FLUSH to use cpu_icache_sync_range only in _HARDKERNEL,<br/>and use __builtin___clear_cache in userland and in rump kernels.<br/><br/>PR 58103: bpfjit.kmod is not built on aarch64</title>
    <description>/src/sys/modules/Makefile - 1.285</description>
    <pubDate>Tue Apr 02 22:37:34 UTC 2024</pubDate>
    <dc:creator>riastradh</dc:creator>
</item>

<item>
    <title>acpihed(4): New driver for PNP0C33 to notify apei(4).<br/><br/>PNP0C33 denotes the ACPI Hardware Error Device, which exists only to<br/>be a vector for event notifications.<br/><br/>PR kern/58046</title>
    <description>/src/sys/modules/Makefile - 1.284</description>
    <pubDate>Thu Mar 21 02:36:02 UTC 2024</pubDate>
    <dc:creator>riastradh</dc:creator>
</item>

<item>
    <title>apei(4): New driver for ACPI Platform Error Interfaces.<br/><br/>For now it is wired up only in x86 ALL kernels, and built as a module<br/>for x86 and Arm.  Once it gets a little more testing on machines with<br/>APEI, I would like to flip it on by default.<br/><br/>PR kern/58046</title>
    <description>/src/sys/modules/Makefile - 1.283</description>
    <pubDate>Wed Mar 20 17:11:44 UTC 2024</pubDate>
    <dc:creator>riastradh</dc:creator>
</item>

<item>
    <title>skip this subdir for "make includes".<br/><br/>it's excessively slow and does nothing (nor should it.)</title>
    <description>/src/sys/modules/Makefile - 1.282</description>
    <pubDate>Sat Mar 09 06:53:48 UTC 2024</pubDate>
    <dc:creator>mrg</dc:creator>
</item>
</channel></rss>

