History log of /netbsd-src/sys/modules/Makefile (Results 1 – 25 of 295)
Revision Date Author Comments
# fea0c645 23-Jan-2025 brad <brad@NetBSD.org>

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

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

show more ...


# 8d3fa1ac 20-Jan-2025 maya <maya@NetBSD.org>

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

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


# 93180daf 04-Nov-2024 brad <brad@NetBSD.org>

Add a driver for the Maxim DS2482-100 and DS2482-800 I2C to 1-Wire
bridge.

This chip provides a I2C device that then has 1 or 8 1-Wire busses on
the other side. The 1-Wire buses show up as onewire(

Add a driver for the Maxim DS2482-100 and DS2482-800 I2C to 1-Wire
bridge.

This chip provides a I2C device that then has 1 or 8 1-Wire busses on
the other side. The 1-Wire buses show up as onewire(4) buses in the
NetBSD.

The chip can be used in situations where:

* You have a I2C bus extended a long distance, say with a LTC4311
active terminator / extender or one of the differential I2C
extenders and you would like to have a 1-Wire device on the far end
and it isn't possible to add wiring to get to the far end.

* You are either out of GPIO pins or the GPIO pins are not reliable
enough to use gpioow(4), but you do have working I2C.

The DS2482 does all of the 1-Wire signals in hardware and provides for
a couple of pullup options for the 1-Wire devices.

All of the functions of the DS2482-100 and -800 are supported except
for overdrive speed support. To do this will likely require some API
changes to onewire(4).

Breakout boards exist for the DS2482 for both variants, but they
appear to be more expensive than expected. The chip itself is quiet
cheap and wasn't all that hard to SMD solder to a board. No other
components are really needed.

There are other members in the same family, the DS2482-101, DS2484 and
DS2485. The DS2482-101 has a sleep pin, but from the datasheet
appears to program the same as the -100 variant. The DS2484 has a
slightly different way to set configuration information and probably
won't quite work with the driver, but isn't far off. The DS2485 is
very different and would require a new driver to function.

show more ...


# 375351f4 26-Aug-2024 riastradh <riastradh@NetBSD.org>

acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.

TBD: A

acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.

TBD: Add to all ACPI-supporting GENERIC kernels.

PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

show more ...


# 0a864b32 18-Jul-2024 rin <rin@NetBSD.org>

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


# 8f43f9fe 20-May-2024 pgoyette <pgoyette@NetBSD.org>

Oooppss remove some local change that was accidentally committed


# 210acb05 20-May-2024 pgoyette <pgoyette@NetBSD.org>

Don't build the compat_110 module yet - there's no release_110 with which
we can be compatable.


# 67daa9c8 20-May-2024 riastradh <riastradh@NetBSD.org>

sys/modules: Don't make compat_110.

Eventually we'll need this but it doesn't make sense until 11.0 is
released.


# 381b1356 19-May-2024 christos <christos@NetBSD.org>

version dup3


# 3dc92541 09-May-2024 pho <pho@NetBSD.org>

port-arm/58194: Resurrect vmt(4) from bitrot

On this architecture vmt(4) used to search for a node "/hypervisor" in the
FDT and probed the VMware hypervisor call only when the node was
found. Howeve

port-arm/58194: Resurrect vmt(4) from bitrot

On this architecture vmt(4) used to search for a node "/hypervisor" in the
FDT and probed the VMware hypervisor call only when the node was
found. However, things appear to have changed and VMware no longer provides
the FDT node.

Since vmt(4) doesn't actually need to read anything from FDT, and the
hypervisor call logically resides in virtual CPUs themselves, it would be
better to attach it directly to cpu, just like how it's probed on x86.

show more ...


# 2dda1941 02-Apr-2024 riastradh <riastradh@NetBSD.org>

bsd.own.mk: Enable MKLSJIT on aarch64.

Make sure there's only one copy of the conditional, in bsd.own.mk;
just make sys/modules/Makefile conditional on MKSLJIT so we don't
have to keep these in sync

bsd.own.mk: Enable MKLSJIT on aarch64.

Make sure there's only one copy of the conditional, in bsd.own.mk;
just make sys/modules/Makefile conditional on MKSLJIT so we don't
have to keep these in sync.

As a workaround for PR 58106, tweak the conditional definition of
SLJIT_CACHE_FLUSH to use cpu_icache_sync_range only in _HARDKERNEL,
and use __builtin___clear_cache in userland and in rump kernels.

PR 58103: bpfjit.kmod is not built on aarch64

show more ...


# 40cfbdd6 21-Mar-2024 riastradh <riastradh@NetBSD.org>

acpihed(4): New driver for PNP0C33 to notify apei(4).

PNP0C33 denotes the ACPI Hardware Error Device, which exists only to
be a vector for event notifications.

PR kern/58046


# 4b159fe5 20-Mar-2024 riastradh <riastradh@NetBSD.org>

apei(4): New driver for ACPI Platform Error Interfaces.

For now it is wired up only in x86 ALL kernels, and built as a module
for x86 and Arm. Once it gets a little more testing on machines with
AP

apei(4): New driver for ACPI Platform Error Interfaces.

For now it is wired up only in x86 ALL kernels, and built as a module
for x86 and Arm. Once it gets a little more testing on machines with
APEI, I would like to flip it on by default.

PR kern/58046

show more ...


# cec94d4f 09-Mar-2024 mrg <mrg@NetBSD.org>

skip this subdir for "make includes".

it's excessively slow and does nothing (nor should it.)


# dd048da8 26-Dec-2023 pgoyette <pgoyette@NetBSD.org>

Unhook radeondrm module from the build; it doesn't work, and
it's just tempting someone to try it. Leave the files around
in case someone wants to pursue making this work.

Should address kern/57793

Unhook radeondrm module from the build; it doesn't work, and
it's just tempting someone to try it. Leave the files around
in case someone wants to pursue making this work.

Should address kern/57793

XXX Related modules from the same legacy era should probably be
XXX removed, too, but so far only radeondrm has been reported
XXX as an issue. Kep an eye out for sisdrm, savagedrm, tdfxdrm,
XXX and r128drm.

show more ...


# 670e7745 27-Aug-2023 kardel <kardel@NetBSD.org>

make owtemp a module


# 2c4d4878 09-Aug-2023 andvar <andvar@NetBSD.org>

viadrmums(4): build legacy VIA DRM UMS driver module for amd64.

This driver is not built-in by default, thus loadable module can help (un)lucky
owners of 64-bit capable VIA (Nano/Eden) systems or ea

viadrmums(4): build legacy VIA DRM UMS driver module for amd64.

This driver is not built-in by default, thus loadable module can help (un)lucky
owners of 64-bit capable VIA (Nano/Eden) systems or early AMD/Intel systems
with some VIA chipsets, which include VIA integrated graphics.
I also boldly added product IDs for few later models from VX8xx/VX9xx chipsets
without 3D support (DX9_0) to "expand" the driver support to more systems.
Tested successfully basic functionality on VX800, and partially successfully
on VX900 (on VX900 Xorg failed to initialize due to openchrome related issues,
viadrmums attaches and it is by used the driver).
Didn't test on VX855, I don't have one.

Pull up to netbsd-10 is needed.

show more ...


# 75b842b8 07-May-2023 skrll <skrll@NetBSD.org>

RISC-V support that works on QEMU with a single hart.

Thanks for Simon Burge for plic(4).


# 7b522c96 13-Apr-2023 riastradh <riastradh@NetBSD.org>

sys/modules/Makefile: Use MACHINE_CPU, not MACHINE_ARCH, for aarch64.

This way it covers both little-endian and big-endian.


# d5970c6d 11-Apr-2023 riastradh <riastradh@NetBSD.org>

aarch64: Build drm modules.


# 189762b3 19-Dec-2022 pgoyette <pgoyette@NetBSD.org>

Create compat_100 module infrastructure now that we have branched
for NetBSD-10


# 50bb9ed1 03-Dec-2022 brad <brad@NetBSD.org>

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


# 068b504f 21-Nov-2022 brad <brad@NetBSD.org>

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

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.

show more ...


# 50bf6d2d 17-Nov-2022 brad <brad@NetBSD.org>

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 sup

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.

show more ...


# 6e81fb1e 07-Sep-2022 martin <martin@NetBSD.org>

Move emuxki from i386/amd64 specific modules to attachment specific
modules (effectively disabling it for the build for now, as it needs
setlist fixes and breaks the build).


12345678910>>...12