aboutsummaryrefslogtreecommitdiff
path: root/sys/modules/Makefile
Commit message (Collapse)AuthorAgeFilesLines
...
* mac_do: add a new MAC/do policy and mdo(1) utilityBaptiste Daroussin2024-05-221-0/+2
| | | | | | | | | | | | | | | | | | | This policy enables a user to become another user without having to be root (hence no setuid binary). it is configured via rules using sysctl security.mac.do.rules For example: security.mac.do.rules=uid=1001:80,gid=0:any The above rule means the user identifier by the uid 1001 is able to become user 80 Any user of the group 0 are allowed to become any user on the system. The mdo(1) utility expects the MAC/do policy to be installed and its rules defined. Reviewed by: des Differential Revision: https://reviews.freebsd.org/D45145
* sys/modules/dpdk_lpm4: do not build without INETLexi Winter2024-05-161-1/+1
| | | | | Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1236
* tpm: Refactor TIS and add a SPI attachmentJustin Hibbits2024-05-031-2/+1
| | | | | | | | | | | | | | | | Summary: Though mostly used in x86 devices, TPM can be used on others, with a direct SPI attachment. Refactor the TPM 2.0 driver set to use an attachment interface, and implement a SPI bus interface. Test Plan: Tested on a Raspberry Pi 4, with a GeeekPi TPM2.0 module (SLB9670 TPM) using security/tpm2-tools tpm2_getcaps for very light testing against the spibus attachment. Reviewed by: kd Obtained from: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D45069
* nvmf: Add infrastructure kernel module for NVMe over FabricsJohn Baldwin2024-05-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nvmf_transport.ko provides routines for managing NVMeoF queue pairs and capsules. It provides a glue layer between transports (such as TCP or RDMA) and an NVMeoF host (initiator) and controller (target). Unlike the synchronous API exposed to the host and controller by libnvmf, the kernel's transport layer uses an asynchronous API built on callbacks. Upper layers provide callbacks on queue pairs that are invoked for transport errors (error_cb) or anytime a capsule is received (receive_cb). Data transfers for a command are usually associated with a callback that is invoked once a transfer has finished either due to an error or successful completion. For an upper layer that is a host, command capsules are allocated and populated with an NVMe SQE by calling nvmf_allocate_command. A data buffer (described by a struct memdesc) can be associated with a command capsule before it is transmitted via nvmf_capsule_append_data. This function accepts a direction (send vs receive) as well as the data transfer callback. The host then transmits the command via nvmf_transmit_capsule. The host must ensure that the data buffer described by the 'struct memdesc' remains valid until the data transfer callback is called. The queue pair's receive_cb callback should match received response capsules up with previously transmitted commands. For the controller, incoming commands are received via the queue pair's receive_cb callback. nvmf_receive_controller_data is used to retrieve any data from a command (e.g. the data for a WRITE command). It can be called multiple times to split the data transfer into smaller sizes. This function accepts an I/O completion callback that is invoked once the data transfer has completed. nvmf_send_controller_data is used to send data to a remote host in response to a command. In this case a callback function is not used but the status is returned synchronously. Finally, the controller can allocate a response capsule via nvmf_allocate_response populated with a supplied CQE and send the response via nvmf_transmit_capsule. Reviewed by: imp Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D44711
* linuxkpi: Add linuxkpi_video moduleEmmanuel Vadot2024-04-301-0/+1
| | | | | | | | | This contain the hdmi code and the aperture code like in linux. Differential Revision: https://reviews.freebsd.org/D44925 Reviewed by: bz Obtained from: drm-kmod Sponsored by: Beckhoff Automation GmbH & Co. KG
* accf_tls: accept filter that waits for TLS handshake headerGleb Smirnoff2024-04-251-0/+1
|
* genet: add module (if_genet.ko)Lexi Winter2024-04-121-0/+6
| | | | | | | | | | | The driver already had the appropriate module macros, it just wasn't hooked into the build system. Since this device is specific to the Raspberry Pi 4, only build it for AArch64. Reviewed by: imp, emaste (earlier version) Pull Request: https://github.com/freebsd/freebsd-src/pull/1139
* sys: Enable NVMe drivers on all architecturesJohn Baldwin2024-04-091-6/+2
| | | | | | | | | The NVMe drivers are portable and are already included statically in GENERIC on other architectures such as aarch64 and riscv64. Reviewed by: imp Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D44690
* vf_i2c: split up and add ACPI attachments in addition to FDTPierre-Luc Drouin2024-03-291-0/+2
| | | | | | | | | | | Move the code from the arm specific to the iicbus controller directory. Split up between general logic and bus attachment code. Add support for ACPI attachment in addition to FDT. MFC after: 7 days Tested by: bz (LS1088a FDT), Pierre-Luc Drouin (Honeycomb, ACPI) Based on: D24917 by Val Packett (initial early version) Differential Revision: https://reviews.freebsd.org/D44020
* Import the kernel parts of bhyve/arm64Andrew Turner2024-02-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | To support virtual machines on arm64 add the vmm code. This is based on earlier work by Mihai Carabas and Alexandru Elisei at University Politehnica of Bucharest, with further work by myself and Mark Johnston. All AArch64 CPUs should work, however only the GICv3 interrupt controller is supported. There is initial support to allow the GICv2 to be supported in the future. Only pure Armv8.0 virtualisation is supported, the Virtualization Host Extensions are not currently used. With a separate userspace patch and U-Boot port FreeBSD guests are able to boot to multiuser mode, and the hypervisor can be tested with the kvm unit tests. Linux partially boots, but hangs before entering userspace. Other operating systems are untested. Sponsored by: Arm Ltd Sponsored by: Innovate UK Sponsored by: The FreeBSD Foundation Sponsored by: University Politehnica of Bucharest Differential Revision: https://reviews.freebsd.org/D37428
* pflow: import from OpenBSDKristof Provost2024-01-161-0/+2
| | | | | | | | | | | | | pflow is a pseudo device to export flow accounting data over UDP. It's compatible with netflow version 5 and IPFIX (10). The data is extracted from the pf state table. States are exported once they are removed. Reviewed by: melifaro Obtained from: OpenBSD Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D43106
* Revert "Don't try and run kldxref for arm kernels"Jessica Clarke2023-12-141-2/+1
| | | | | | Now that kldxref supports arm this should not be needed. This reverts commit 0840bdbf2a07b68e29267bc49057ca6df2351360.
* Don't try and run kldxref for arm kernelsJessica Clarke2023-12-141-1/+2
| | | | | | | | | | | | | | | Surprisingly, kldxref does not currently support arm, and unhelpfully this means it silently does nothing rather than give an error, so the linker.hints entry added to the METALOG for -DNO_ROOT builds (and pkgbase ones) refers to a file that doesn't exist. Ideally it would be supported (and ideally the METALOG handling would be less fragile, but without integrating it into kldxref the only real option would be to just run find(1) to get the list of linker.hints files, which feels a little backwards), but for now just paper over this by skipping the build step on arm. Reported by: bapt Fixes: ff7c12c1f17e ("Make kldxref a bootstrap tool and use unconditionally")
* Make kldxref a bootstrap tool and use unconditionallyJessica Clarke2023-12-131-4/+5
| | | | | | | | | | Now that kldxref is a generic cross tool and can be built on non-FreeBSD we can bootstrap it during the build and thus remove the condition for whether it exists. We also need to make sure to add it to the METALOG for -DNO_ROOT builds. Reviewed by: brooks, imp Differential Revision: https://reviews.freebsd.org/D43051
* ossl: Add support for armv7Mark Johnston2023-11-301-1/+5
| | | | | | | | | | | | | | | | | OpenSSL provides implementations of several AES modes which use bitslicing and can be accelerated on CPUs which support the NEON extension. This patch adds arm platform support to ossl(4) and provides an AES-CBC implementation, though bsaes_cbc_encrypt() only implements decryption. The real goal is to provide an accelerated AES-GCM implementation; this will be added in a subsequent patch. Initially derived from https://reviews.freebsd.org/D37420. Reviewed by: jhb Sponsored by: Klara, Inc. Sponsored by: Stormshield MFC after: 3 months Differential Revision: https://reviews.freebsd.org/D41304
* Add an Armv8 rndr random number providerAndrew Turner2023-11-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | Armv8.5 adds an optional random number generator. This is implemented as two special registers one to read a random number, the other to re-seed the entropy pool before reading a random number. Both registers will set the condition flags to tell the caller they can't produce a random number in a reasonable amount of time. Without a signal to reseed the entropy pool use the latter register to provide random numbers to the kernel pool. If at a later time we had a way to tell the provider if it needs to reseed or not we could use the former. On an Amazon AWS Graviton3 VM this never failed, however this may not be the case on low end CPUs so retry reading the random number 10 times before returning an error. Reviewed by: imp, delphij (csprng) Sponsored by: The FreeBSD Foundation Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D35411
* rtw88: re-connect to the buildBjoern A. Zeeb2023-10-061-1/+1
| | | | | | | | | | This adds the (updated) rtw88 driver back to the build. Functionality has not been tested (much) so might not currently work but people offered to test. Firmware is provided by the wifi-firmware-rtw88-kmod port/package. This reverts commit 712468443df1130db8f893a5e2ce5c6a8dbf5cde.
* iwlwifi: re-attach to build after updatesBjoern A. Zeeb2023-09-211-1/+1
| | | | | | | | | | | | While the build-breaking changes were only in the window of the two commits, 3e1f5cc9a81a..9af1bba44e1c, further updates restored some functionality as well. Now that we are done, add iwlwifi back to the build. This reverts commit b75d1ce6c10652fc4bfbf509deeae0e05c3d1356. Sponsored by: The FreeBSD Foundation MFC after: 3 days
* iwlwifi: temporary disable build for updatesBjoern A. Zeeb2023-09-211-1/+1
| | | | | | | | | Disconnect iwlwifi from the build for a few commits which, due to incompatible LinuxKPI 802.11 changes would break the build for a revision. It will be re-enabled "instantly". Sponsored by: The FreeBSD Foundation MFC after: 3 days
* rtw88: temporary disconnect from buildBjoern A. Zeeb2023-09-051-1/+1
| | | | | | | | | | | As announced on freebsd-wireless [1] disconnect rtw88 from the build. Add a note to the man page about the current state but leave the man page in place for now as this is supposed to be temporary. [1] https://lists.freebsd.org/archives/freebsd-wireless/2023-September/001377.html MFC after: 20 days X-MFC: will see about 14/13
* rtw88: detach firmware from buildBjoern A. Zeeb2023-09-051-4/+0
| | | | | | | | Firmware is kept in ports now and fwget will find the right one to install. MFC after: 20 days X-MFC: will see about 14/13
* sff: Add SFP driver (fdt-based draft)Dmitry Salychev2023-08-181-0/+2
| | | | | | | | | | | | | | This basic version of the driver obtains properties of the "sff,sfp" compatible devices and implements a simple interface to provide an I2C bus device for the rest of the drivers (e.g. to implement SIOCGI2C). Both of the interface and driver are subjects for a further generalization to be used in case of non-FDT and non-arm64 platforms. Reviewed by: bz, manu Approved by: bz (mentor) MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D41440
* sys: Remove $FreeBSD$: one-line sh patternWarner Losh2023-08-161-1/+0
| | | | Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
* ath(4): Remove MIPS AHB frontend and join PCI one w/ main support againMarius Strobl2023-08-081-1/+0
| | | | | | | | | | | | | | | | Following the removal of general MIPS support, there's no longer a need to have the AHB bus-frontend in place, which according to Linux sources also isn't used with any non-MIPS SoCs. For simplicity, PCI bus support is only made conditional on the main one again, i. e. device ath_pci is removed, and built into the main module, i. e. if_ath_pci.ko obsoleted, respectively. Effectively, this reverts the following commits and associated changes: dba9c8597747c6c9bf3d2ec68f7eb90552878dc7 e849bb3ecbb1963344a22ae77fc96f89fbebf40c Approved by: adrian Relnotes: yes Differential Revision: https://reviews.freebsd.org/D41354
* modules: Use MACHINE_CPUARCH moreWarner Losh2023-08-081-2/+3
| | | | | | | | Replace two cases of MACHINE_ARCH with MACHINE_CPUARCH and also use `aarch64` instead of the improper `arm64` for that test. Noticed by: Mark Millard Sponsored by: Netflix
* mac_ipacl: new MAC policy module to limit jail/vnet IP configurationShivank Garg2023-07-261-0/+2
| | | | | | | | | | | | | The mac_ipacl policy module enables fine-grained control over IP address configuration within VNET jails from the base system. It allows the root user to define rules governing IP addresses for jails and their interfaces using the sysctl interface. Requested by: multiple Sponsored by: Google, Inc. (GSoC 2019) MFC after: 2 months Reviewed by: bz, dch (both earlier versions) Differential Revision: https://reviews.freebsd.org/D20967
* superio+ncthwm: Add hardware monitoring supportStéphane Rochoy2023-07-011-0/+2
| | | | | | | | | Add support for the following chips: - Nuvoton NCT6779D - Nuvoton NCT6796D-E Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/719
* mpi3mr: 3rd Generation Tri-Mode NVMe/SAS/SATA MegaRaid / eHBASumit Saxena2023-06-151-0/+6
| | | | | | | | | | | | | | | | | | This is Broadcom's mpi3mr driver for FreeBSD version 8.6.0.2.0. The mpi3mr driver supports Broadcom SAS4116-based cards in the 9600 series: 9670W-16i, 9670-24i, 9660-16i, 9620-16i, 9600-24i, 9600-16i, 9600W-16e, 9600-16e, 9600-8i8e. Initially only available as a module and on amd64/arm64, since that's how it has been tested to date. Future commits will add it to the kernel build and may expand the architectures it is supported on. Co-authored-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com> Feedback-by: ken (prior versions) Reviewed-by: imp RelNotes: yes Differential-Revision: https://reviews.freebsd.org/D36771 Differential-Revision: https://reviews.freebsd.org/D36772
* qatfw: Don't build if WITH_SOURCELESS_UCODE is definedMark Johnston2023-06-121-0/+2
|
* qat: Stop building on i386Mark Johnston2023-06-121-2/+2
| | | | The driver isn't tested on i386, so don't spend effort compiling it.
* gve: Fix build on i386 and enable LINT builds.Xin LI2023-06-041-4/+1
| | | | | Reviewed-by: imp Differential Revision: https://reviews.freebsd.org/D40419
* Add gve, the driver for Google Virtual NIC (gVNIC)Shailend Chand2023-06-021-0/+5
| | | | | | | | | | | | | | | | | gVNIC is a virtual network interface designed specifically for Google Compute Engine (GCE). It is required to support per-VM Tier_1 networking performance, and for using certain VM shapes on GCE. The NIC supports TSO, Rx and Tx checksum offloads, and RSS. It does not currently do hardware LRO, and thus the software-LRO in the host is used instead. It also supports jumbo frames. For each queue, the driver negotiates a set of pages with the NIC to serve as a fixed bounce buffer, this precludes the use of iflib. Reviewed-by: markj MFC-after: 2 weeks Differential Revision: https://reviews.freebsd.org/D39873
* nlsysevent: add a genetlink(4) module to report kernel eventsBaptiste Daroussin2023-06-011-0/+1
| | | | | | | | Hooked to devctl_notify, this allows consumers to received events by subscribing to a system over a generic netlink protocol Reviewed by: imp, melifaro Differential Revision: https://reviews.freebsd.org/D37574
* twe: Remove driverWarner Losh2023-05-111-1/+0
| | | | Sponsored by: Netflix
* tests: add ktest modules to buildAlexander V. Chernikov2023-04-171-0/+1
| | | | MFC after: 2 weeks
* sys/modules/Makefile: conditionally add MAC/veriexec modulesStephen J. Kiernan2023-04-171-0/+2
| | | | | | | | | | Only build MAC/veriexec modules when MK_VERIEXEC is yes or we are building all modules. Add VERIEXEC knob to kernel __DEFAULT_NO_OPTIONS Reviewed by: sjg Obtained from: Juniper Networks, Inc.
* sys/modules/Makefile: add MAC/veriexec modules into the buildStephen J. Kiernan2023-04-161-0/+10
| | | | | | | Build the MAC/veriexec module and the SHA2, SHA256, SHA384, and SHA512 fingerprint modules. Obtained from: Juniper Networks, Inc.
* linuxkpi: Add hdmi helpersEmmanuel Vadot2023-03-281-0/+1
| | | | | | | | | | This is a direct port of the Linux code as the licence allows it, so style(9) isn't respected to allow applying directly the upstream commits. Do not add it to linuxkpi directly but add a new linuxkpi_hdmi module that drm modules will require later, no need to bloat linuxkpi more. Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D39122
* powerpc: enable ZFS on 32 bit powerpc/powerpcspeAlfredo Dal'Ava Junior2023-03-121-1/+1
| | | | | | | | Enable ZFS on powerpc 32 bit since it appears to build and work correctly. MFC after: 3 weeks Relnotes: yes
* sys/modules/Makefile: Add a section for arm64 + x86 + powerpc64.John Baldwin2023-03-081-15/+10
| | | | | | | | | This reduces some duplication between the existing arm64 + x86 section and the powerpc64 section. To make the diff simpler, enable mlx4 on powerpc64 since it compiles. Reviewed by: pkubaj, imp, emaste Differential Revision: https://reviews.freebsd.org/D38973
* Enable OFED on all platforms except for 32-bit arm.John Baldwin2023-03-081-11/+8
| | | | | | | | 32-bit arm triggers multiple -Wunaligned-access errors due to structure packing. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D38972
* superio,ftgpio: Add support for Fintek F81865 GPIOStéphane Rochoy2023-02-281-0/+2
| | | | | | Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/674 Differential Revision: https://reviews.freebsd.org/D37893
* powerpc64*: port mlx5, OFED, KTLS and krpingPiotr Kubaj2023-02-261-0/+13
| | | | | | | | | | | | | | | | Summary: This review ports mlx5 driver, kernel's OFED stack (userland is already enabled), KTLS and krping to powerpc64 and powerpc64le. krping requires a small change since it uses assembly for amd64 / i386. NOTE: On powerpc64le RDMA works fine in the userspace with libmlx5, but on powerpc64 it does not. The problem is that contrib/ofed/libmlx5/doorbell.h checks for SIZEOF_LONG but this macro exists on neither powerpc64* nor amd64. Thus, the file silently goes to the fallback function written for 32-bit architectures. It works fine on little-endian architectures, but causes a hard fail on big-endian. It's possible it may also cause some runtime issues on little-endian. Thus, on powerpc64 I verified that RDMA works with krping. Reviewers: #powerpc, hselasky Subscribers: bdrewery, imp, emaste, jhibbits Differential Revision: https://reviews.freebsd.org/D38786
* Revert "powerpc64*: port mlx5, OFED, KTLS and krping"Piotr Kubaj2023-02-251-13/+0
| | | | | | Wrong push, another commit was supposed to be pushed. This reverts commit 83d6d8877ef7dad4f4e8f409a01c9f28139cd026.
* powerpc64*: port mlx5, OFED, KTLS and krpingPiotr Kubaj2023-02-251-0/+13
| | | | | | | | | | | | | | | | Summary: This review ports mlx5 driver, kernel's OFED stack (userland is already enabled), KTLS and krping to powerpc64 and powerpc64le. krping requires a small change since it uses assembly for amd64 / i386. NOTE: On powerpc64le RDMA works fine in the userspace with libmlx5, but on powerpc64 it does not. The problem is that contrib/ofed/libmlx5/doorbell.h checks for SIZEOF_LONG but this macro exists on neither powerpc64* nor amd64. Thus, the file silently goes to the fallback function written for 32-bit architectures. It works fine on little-endian architectures, but causes a hard fail on big-endian. It's possible it may also cause some runtime issues on little-endian. Thus, on powerpc64 I verified that RDMA works with krping. Reviewers: #powerpc, hselasky Subscribers: bdrewery, imp, emaste, jhibbits Differential Revision: https://reviews.freebsd.org/D38786
* enic: Cisco VIC driverDoug Ambrisko2023-02-061-0/+2
| | | | | | This driver is based of the enic (Cisco VIC) DPDK driver. It provides basic ethernet functionality. Has been run with various VIC cards to do UEFI PXE boot with NFS root.
* Add tarfs, a filesystem backed by tarballs.Dag-Erling Smørgrav2023-02-021-0/+1
| | | | | | | Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Reviewed by: pauamma, imp Differential Revision: https://reviews.freebsd.org/D37753
* wdatwd: Add support for ACPI WDAT based watchdog timer.Takanori Watanabe2023-01-031-0/+2
| | | | | | | | | | | | | | | | | | | Simply said, WDAT is an abstraction for the real WDT hardware. For instance, to add a newer generation WDT to ichwd(4), one must know the detailed hardware registers, etc.. With WDAT, the necessary IO accesses to operate the WDT are comprehensively described in it and no hardware knowledge is required. With this driver, the WDT on Advantech ARK-1124C, Dell R210 and Dell R240 are detected and operated flawlessly. * While R210 is also supported by ichwd(4), others are not supported yet. The unfortunate thing is that not all systems have WDAT defined. Submitted by: t_uemura at macome.co.jp Reviewed by: hrs Differential Revision: https://reviews.freebsd.org/D37493
* retire cp(4) driverEd Maste2022-12-131-4/+0
| | | | | | | Sync serial (e.g. T1/T1/G.703) interfaces are obsolete, this driver includes obfuscated source, and has reported potential security issues. Differential Revision: https://reviews.freebsd.org/D33468
* retire ce(4) driverEd Maste2022-12-131-4/+0
| | | | | | | Sync serial (e.g. T1/T1/G.703) interfaces are obsolete, this driver includes obfuscated source, and has reported potential security issues. Differential Revision: https://reviews.freebsd.org/D33467