freebsd-nq/sys/modules/Makefile

838 lines
13 KiB
Makefile
Raw Normal View History

1999-08-28 01:08:13 +00:00
# $FreeBSD$
SYSDIR?=${SRCTOP}/sys
.include "${SYSDIR}/conf/kern.opts.mk"
SUBDIR_PARALLEL=
# Modules that include binary-only blobs of microcode should be selectable by
# MK_SOURCELESS_UCODE option (see below).
.include "${SYSDIR}/conf/config.mk"
.if defined(MODULES_OVERRIDE) && !defined(ALL_MODULES)
SUBDIR=${MODULES_OVERRIDE}
.else
2012-06-05 17:44:54 +00:00
SUBDIR= \
${_3dfx} \
${_3dfx_linux} \
${_aac} \
${_aacraid} \
accf_data \
accf_dns \
accf_http \
acl_nfs4 \
acl_posix1e \
${_acpi} \
ae \
${_aesni} \
2008-05-19 01:53:47 +00:00
age \
${_agp} \
Separate the parallel scsi knowledge out of the core of the XPT, and modularize it so that new transports can be created. Add a transport for SATA Add a periph+protocol layer for ATA Add a driver for AHCI-compliant hardware. Add a maxio field to CAM so that drivers can advertise their max I/O capability. Modify various drivers so that they are insulated from the value of MAXPHYS. The new ATA/SATA code supports AHCI-compliant hardware, and will override the classic ATA driver if it is loaded as a module at boot time or compiled into the kernel. The stack now support NCQ (tagged queueing) for increased performance on modern SATA drives. It also supports port multipliers. ATA drives are accessed via 'ada' device nodes. ATAPI drives are accessed via 'cd' device nodes. They can all be enumerated and manipulated via camcontrol, just like SCSI drives. SCSI commands are not translated to their ATA equivalents; ATA native commands are used throughout the entire stack, including camcontrol. See the camcontrol manpage for further details. Testing this code may require that you update your fstab, and possibly modify your BIOS to enable AHCI functionality, if available. This code is very experimental at the moment. The userland ABI/API has changed, so applications will need to be recompiled. It may change further in the near future. The 'ada' device name may also change as more infrastructure is completed in this project. The goal is to eventually put all CAM busses and devices until newbus, allowing for interesting topology and management options. Few functional changes will be seen with existing SCSI/SAS/FC drivers, though the userland ABI has still changed. In the future, transports specific modules for SAS and FC may appear in order to better support the topologies and capabilities of these technologies. The modularization of CAM and the addition of the ATA/SATA modules is meant to break CAM out of the mold of being specific to SCSI, letting it grow to be a framework for arbitrary transports and protocols. It also allows drivers to be written to support discrete hardware without jeopardizing the stability of non-related hardware. While only an AHCI driver is provided now, a Silicon Image driver is also in the works. Drivers for ICH1-4, ICH5-6, PIIX, classic IDE, and any other hardware is possible and encouraged. Help with new transports is also encouraged. Submitted by: scottl, mav Approved by: re
2009-07-10 08:18:08 +00:00
ahci \
aic7xxx \
alc \
Add ale(4), a driver for Atheros AR8121/AR8113/AR8114 PCIe ethernet controller. The controller is also known as L1E(AR8121) and L2E(AR8113/AR8114). Unlike its predecessor Attansic L1, AR8121/AR8113/AR8114 uses completely different Rx logic such that it requires separate driver. Datasheet for AR81xx is not available to open source driver writers but it shares large part of Tx and PHY logic of L1. I still don't understand some part of register meaning and some MAC statistics counters but the driver seems to have no critical issues for performance and stability. The AR81xx requires copy operation to pass received frames to upper stack such that ale(4) consumes a lot of CPU cycles than that of other controller. A couple of silicon bugs also adds more CPU cycles to address the known hardware bug. However, if you have fast CPU you can still saturate the link. Currently ale(4) supports the following hardware features. - MSI. - TCP Segmentation offload. - Hardware VLAN tag insertion/stripping with checksum offload. - Tx TCP/UDP checksum offload and Rx IP/TCP/UDP checksum offload. - Tx/Rx interrupt moderation. - Hardware statistics counters. - Jumbo frame. - WOL. AR81xx PCIe ethernet controllers are mainly found on ASUS EeePC or P5Q series of ASUS motherboards. Special thanks to Jeremy Chadwick who sent the hardware to me. Without his donation writing a driver for AR81xx would never have been possible. Big thanks to all people who reported feedback or tested patches. HW donated by: koitsu Tested by: bsam, Joao Barros <joao.barros <> gmail DOT com > Jan Henrik Sylvester <me <> janh DOT de > Ivan Brawley < ivan <> brawley DOT id DOT au >, CURRENT ML
2008-11-12 09:52:06 +00:00
ale \
alq \
${_amd_ecc_inject} \
${_amdgpio} \
${_amdsbwd} \
${_amdsmn} \
${_amdtemp} \
amr \
${_an} \
${_aout} \
2005-03-31 20:21:43 +00:00
${_arcmsr} \
${_allwinner} \
${_armv8crypto} \
${_asmc} \
This is the much rumoured ATA mkIII update that I've been working on. o ATA is now fully newbus'd and split into modules. This means that on a modern system you just load "atapci and ata" to get the base support, and then one or more of the device subdrivers "atadisk atapicd atapifd atapist ataraid". All can be loaded/unloaded anytime, but for obvious reasons you dont want to unload atadisk when you have mounted filesystems. o The device identify part of the probe has been rewritten to fix the problems with odd devices the old had, and to try to remove so of the long delays some HW could provoke. Also probing is done without the need for interrupts, making earlier probing possible. o SATA devices can be hot inserted/removed and devices will be created/ removed in /dev accordingly. NOTE: only supported on controllers that has this feature: Promise and Silicon Image for now. On other controllers the usual atacontrol detach/attach dance is still needed. o Support for "atomic" composite ATA requests used for RAID. o ATA RAID support has been rewritten and and now supports these metadata formats: "Adaptec HostRAID" "Highpoint V2 RocketRAID" "Highpoint V3 RocketRAID" "Intel MatrixRAID" "Integrated Technology Express" "LSILogic V2 MegaRAID" "LSILogic V3 MegaRAID" "Promise FastTrak" "Silicon Image Medley" "FreeBSD PseudoRAID" o Update the ioctl API to match new RAID levels etc. o Update atacontrol to know about the new RAID levels etc NOTE: you need to recompile atacontrol with the new sys/ata.h, make world will take care of that. NOTE2: that rebuild is done differently from the old system as the rebuild is now done piggybacked on read requests to the array, so atacontrol simply starts a background "dd" to rebuild the array. o The reinit code has been worked over to be much more robust. o The timeout code has been overhauled for races. o Support of new chipsets. o Lots of fixes for bugs found while doing the modulerization and reviewing the old code. Missing or changed features from current ATA: o atapi-cd no longer has support for ATAPI changers. Todays its much cheaper and alot faster to copy those CD images to disk and serve them from there. Besides they dont seem to be made anymore, maybe for that exact reason. o ATA RAID can only read metadata from all the above metadata formats, not write all of them (Promise and Highpoint V2 so far). This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. There is more to it than just the missing write metadata support, those formats are not unique to a given controller like Promise and Highpoint formats, instead they exist for several types, and even worse, some controllers can have different formats and its impossible to tell which one. The outcome is that we cannot reliably create the metadata of those formats and be sure the controller BIOS will understand it. However write support is needed to update/fail/rebuild the arrays properly so it sits fairly high on the TODO list. o So far atapicam is not supported with these changes. When/if this will change is up to the maintainer of atapi-cam so go there for questions. HW donated by: Webveveriet AS HW donated by: Frode Nordahl HW donated by: Yahoo! HW donated by: Sentex Patience by: Vife and my boys (and even the cats)
2005-03-30 12:03:40 +00:00
ata \
ath \
[ath] [ath_hal] (etc, etc) - begin the task of re-modularising the HAL. In the deep past, when this code compiled as a binary module, ath_hal built as a module. This allowed custom, smaller HAL modules to be built. This was especially beneficial for small embedded platforms where you didn't require /everything/ just to run. However, sometime around the HAL opening fanfare, the HAL landed here as one big driver+HAL thing, and a lot of the (dirty) infrastructure (ie, #ifdef AH_SUPPORT_XXX) to build specific subsets of the HAL went away. This was retained in sys/conf/files as "ath_hal_XXX" but it wasn't really floated up to the modules themselves. I'm now in a position where for the reaaaaaly embedded boards (both the really old and the last couple generation of QCA MIPS boards) having a cut down HAL module and driver loaded at runtime is /actually/ beneficial. This reduces the kernel size down by quite a bit. The MIPS modules look like this: adrian@gertrude:~/work/freebsd/head-embedded/src % ls -l ../root/mips_ap/boot/kernel.CARAMBOLA2/ath*ko -r-xr-xr-x 1 adrian adrian 5076 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_dfs.ko -r-xr-xr-x 1 adrian adrian 100588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal.ko -r-xr-xr-x 1 adrian adrian 627324 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal_ar9300.ko -r-xr-xr-x 1 adrian adrian 314588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_main.ko -r-xr-xr-x 1 adrian adrian 23472 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_rate.ko And the x86 versions, like this: root@gertrude:/home/adrian # ls -l /boot/kernel/ath*ko -r-xr-xr-x 1 root wheel 36632 May 24 18:32 /boot/kernel/ath_dfs.ko -r-xr-xr-x 1 root wheel 134440 May 24 18:32 /boot/kernel/ath_hal.ko -r-xr-xr-x 1 root wheel 82320 May 24 18:32 /boot/kernel/ath_hal_ar5210.ko -r-xr-xr-x 1 root wheel 104976 May 24 18:32 /boot/kernel/ath_hal_ar5211.ko -r-xr-xr-x 1 root wheel 236144 May 24 18:32 /boot/kernel/ath_hal_ar5212.ko -r-xr-xr-x 1 root wheel 336104 May 24 18:32 /boot/kernel/ath_hal_ar5416.ko -r-xr-xr-x 1 root wheel 598336 May 24 18:32 /boot/kernel/ath_hal_ar9300.ko -r-xr-xr-x 1 root wheel 406144 May 24 18:32 /boot/kernel/ath_main.ko -r-xr-xr-x 1 root wheel 55352 May 24 18:32 /boot/kernel/ath_rate.ko .. so you can see, not building the whole HAL can save quite a bit. For example, if you don't need AR9300 support, you can actually avoid wasting half a megabyte of RAM. On embedded routers this is quite a big deal. The AR9300 HAL can be later further shrunk because, hilariously, it indeed supports AH_SUPPORT_<xxx> for optionally adding chipset support. (I'll chase that down later as it's quite a big savings if you're only building for a single embedded target.) So: * Create a very hackish way to load/unload HAL modules * Create module metadata for each HAL subtype - ah_osdep_arXXXX.c * Create module metadata for ath_rate and ath_dfs (bluetooth is currently just built as part of it) * .. yes, this means we could actually build multiple rate control modules and pick one at load time, but I'd rather just glue this into net80211's rate control code. Oh well, baby steps. * Main driver is now "ath_main" * Create an "if_ath" module that does what the ye olde one did - load PCI glue, main driver, HAL and all child modules. In this way, if you have "if_ath_load=YES" in /boot/modules.conf it will load everything the old way and stuff should still work. * For module autoloading purposes, I actually /did/ fix up the name of the modules in if_ath_pci and if_ath_ahb. If you want to selectively load things (eg on ye cheape ARM/MIPS platforms where RAM is at a premium) you should: * load ath_hal * load the chip modules in question * load ath_rate, ath_dfs * load ath_main * load if_ath_pci and/or if_ath_ahb depending upon your particular bus bind type - this is where probe/attach is done. TODO: * AR5312 module and associated pieces - yes, we have the SoC side support now so the wifi support would be good to "round things out"; * Just nuke AH_SUPPORT_AR5416 for now and always bloat the packet structures; this'll simplify other things. * Should add a simple refcnt thing to the HAL RF/chip modules so you can't unload them whilst you're using them. * Manpage updates, UPDATING if appropriate, etc.
2017-05-25 04:18:46 +00:00
ath_dfs \
ath_hal \
ath_hal_ar5210 \
ath_hal_ar5211 \
ath_hal_ar5212 \
ath_hal_ar5416 \
ath_hal_ar9300 \
ath_main \
ath_rate \
ath_pci \
${_autofs} \
axgbe \
backlight \
${_bce} \
${_bcm283x_clkman} \
${_bcm283x_pwm} \
bfe \
bge \
bhnd \
${_bxe} \
${_bios} \
${_blake2} \
bnxt \
2006-07-26 22:10:10 +00:00
bridgestp \
bwi \
bwn \
${_bytgpio} \
${_chvgpio} \
cam \
${_cardbus} \
${_carp} \
cas \
${_cbb} \
cc \
Add ccp(4): experimental driver for AMD Crypto Co-Processor * Registers TRNG source for random(4) * Finds available queues, LSBs; allocates static objects * Allocates a shared MSI-X for all queues. The hardware does not have separate interrupts per queue. Working interrupt mode driver. * Computes SHA hashes, HMAC. Passes cryptotest.py, cryptocheck tests. * Does AES-CBC, CTR mode, and XTS. cryptotest.py and cryptocheck pass. * Support for "authenc" (AES + HMAC). (SHA1 seems to result in "unaligned" cleartext inputs from cryptocheck -- which the engine cannot handle. SHA2 seems to work fine.) * GCM passes for block-multiple AAD, input lengths Largely based on ccr(4), part of cxgbe(4). Rough performance averages on AMD Ryzen 1950X (4kB buffer): aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s ccp: ~630 Mb/s SHA256: ~660 Mb/s SHA512: ~700 Mb/s cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s As you can see, performance is poor in comparison to aesni(4) and even cryptosoft (due to high setup cost). At a larger buffer size (128kB), throughput is a little better (but still worse than aesni(4)): aesni: SHA1:~10400 Mb/s SHA256: ~9950 Mb/s ccp: ~2200 Mb/s SHA256: ~2600 Mb/s SHA512: ~3800 Mb/s cryptosoft: ~1750 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s AES performance has a similar story: aesni: 4kB: ~11250 Mb/s 128kB: ~11250 Mb/s ccp: ~350 Mb/s 128kB: ~4600 Mb/s cryptosoft: ~1750 Mb/s 128kB: ~1700 Mb/s This driver is EXPERIMENTAL. You should verify cryptographic results on typical and corner case inputs from your application against a known- good implementation. Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12723
2018-01-18 22:01:30 +00:00
${_ccp} \
cd9660 \
cd9660_iconv \
${_ce} \
${_cfi} \
add iic interface to ig4 driver, move isl and cyapa to iicbus Summary: The hardware does not expose a classic SMBus interface. Instead it has a lower level interface that can express a far richer I2C protocol than what smbus offers. However, the interface does not provide a way to explicitly generate the I2C stop and start conditions. It's only possible to request that the stop condition is generated after transferring the next byte in either direction. So, at least one data byte must always be transferred. Thus, some I2C sequences are impossible to generate, e.g., an equivalent of smbus quick command (<start>-<slave addr>-<r/w bit>-<stop>). At the same time isl(4) and cyapa(4) are moved to iicbus and now they use iicbus_transfer for communication. Previously they used smbus_trans() interface that is not defined by the SMBus protocol and was implemented only by ig4(4). In fact, that interface was impossible to implement for the typical SMBus controllers like intpm(4) or ichsmb(4) where a type of the SMBus command must be programmed. The plan is to remove smbus_trans() and all its uses. As an aside, the smbus_trans() method deviates from the standard, but perhaps backwards, FreeBSD convention of using 8-bit slave addresses (shifted by 1 bit to the left). The method expects 7-bit addresses. There is a user facing consequence of this change. A user must now provide device hints for isl and cyapa that specify an iicbus to use and a slave address on it. On Chromebook hardware where isl and cyapa devices are commonly found it is also possible to use a new chromebook_platform(4) driver that automatically configures isl and cyapa devices. There is no need to provide the device hints in that case, Right now smbus(4) driver tries to discover all slaves on the bus. That is very dangerous. Fortunately, the probing code uses smbus_trans() to do its job, so it is really enabled for ig4 only. The plan is to remove that auto-probing code and smbus_trans(). Tested by: grembo, Matthias Apitz <guru@unixarea.de> (w/o chromebook_platform) Discussed with: grembo, imp Reviewed by: wblock (docs) MFC after: 1 month Relnotes: yes Differential Revision: https://reviews.freebsd.org/D8172
2016-10-30 12:15:33 +00:00
${_chromebook_platform} \
${_ciss} \
cloudabi \
${_cloudabi32} \
${_cloudabi64} \
${_coretemp} \
2004-05-17 14:24:52 +00:00
${_cp} \
${_cpsw} \
${_cpuctl} \
${_cpufreq} \
${_crypto} \
${_cryptodev} \
ctl \
${_cxgb} \
${_cxgbe} \
dc \
dcons \
dcons_crom \
${_dpms} \
dummynet \
Add kernel interfaces to call EFI Runtime Services. Runtime services require special execution environment for the call. Besides that, OS must inform firmware about runtime virtual memory map which will be active during the calls, with the SetVirtualAddressMap() runtime call, done while the 1:1 mapping is still used. There are two complication: the SetVirtualAddressMap() effectively must be done from loader, which needs to know kernel address map in advance. More, despite not explicitely mentioned in the specification, both 1:1 and the map passed to SetVirtualAddressMap() must be active during the SetVirtualAddressMap() call. Second, there are buggy BIOSes which require both mappings active during runtime calls as well, most likely because they fail to identify all relocations to perform. On amd64, we can get rid of both problems by providing 1:1 mapping for the duration of runtime calls, by temprorary remapping user addresses. As result, we avoid the need for loader to know about future kernel address map, and avoid bugs in BIOSes. Typically BIOS only maps something in low 4G. If not runtime bugs, we would take advantage of the DMAP, as previous versions of this patch did. Similar but more complicated trick can be used even for i386 and 32bit runtime, if and when the EFI boot on i386 is supported. We would need a trampoline page, since potentially whole 4G of VA would be switched on calls, instead of only userspace portion on amd64. Context switches are disabled for the duration of the call, FPU access is granted, and interrupts are not disabled. The later is possible because kernel is mapped during calls. To test, the sysctl mib debug.efi_time is provided, setting it to 1 makes one call to EFI get_time() runtime service, on success the efitm structure is printed to the control terminal. Load efirt.ko, or add EFIRT option to the kernel config, to enable code. Discussed with: emaste, imp Tested by: emaste (mac, qemu) Sponsored by: The FreeBSD Foundation MFC after: 2 weeks
2016-09-21 11:31:58 +00:00
${_efirt} \
${_em} \
Add support for Amazon Elastic Network Adapter (ENA) NIC ENA is a networking interface designed to make good use of modern CPU features and system architectures. The ENA device exposes a lightweight management interface with a minimal set of memory mapped registers and extendable command set through an Admin Queue. The driver supports a range of ENA devices, is link-speed independent (i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.), and has a negotiated and extendable feature set. Some ENA devices support SR-IOV. This driver is used for both the SR-IOV Physical Function (PF) and Virtual Function (VF) devices. ENA devices enable high speed and low overhead network traffic processing by providing multiple Tx/Rx queue pairs (the maximum number is advertised by the device via the Admin Queue), a dedicated MSI-X interrupt vector per Tx/Rx queue pair, and CPU cacheline optimized data placement. The ENA driver supports industry standard TCP/IP offload features such as checksum offload and TCP transmit segmentation offload (TSO). Receive-side scaling (RSS) is supported for multi-core scaling. The ENA driver and its corresponding devices implement health monitoring mechanisms such as watchdog, enabling the device and driver to recover in a manner transparent to the application, as well as debug logs. Some of the ENA devices support a working mode called Low-latency Queue (LLQ), which saves several more microseconds. This feature will be implemented for driver in future releases. Submitted by: Michal Krawczyk <mk@semihalf.com> Jakub Palider <jpa@semihalf.com> Jan Medala <jan@semihalf.com> Obtained from: Semihalf Sponsored by: Amazon.com Inc. Differential revision: https://reviews.freebsd.org/D10427
2017-05-22 14:46:13 +00:00
${_ena} \
esp \
${_et} \
evdev \
${_exca} \
ext2fs \
fdc \
2002-10-21 00:38:18 +00:00
fdescfs \
2017-06-10 23:45:26 +00:00
${_ffec} \
filemon \
2002-11-07 16:19:43 +00:00
firewire \
firmware \
${_ftwd} \
fusefs \
${_fxp} \
o Revert the part of if_gem.c rev. 1.35 which added a call to gem_stop() to gem_attach() as the former access softc members not yet initialized at that time and gem_reset() actually is enough to stop the chip. [1] o Revise the use of gem_bitwait(); add bus_barrier() calls before calling gem_bitwait() to ensure the respective bit has been written before we starting polling on it and poll for the right bits to change, f.e. even though we only reset RX we have to actually wait for both GEM_RESET_RX and GEM_RESET_TX to clear. Add some additional gem_bitwait() calls in places we've been missing them according to the GEM documentation. Along with this some excessive DELAYs, which probably only were added because of bugs in gem_bitwait() and its use in the first place, as well as as have of an gem_bitwait() reimplementation in gem_reset_tx() were removed. o Add gem_reset_rxdma() and use it to deal with GEM_MAC_RX_OVERFLOW errors more gracefully as unlike gem_init_locked() it resets the RX DMA engine only, causing no link loss and the FIFOs not to be cleared. Also use it deal with GEM_INTR_RX_TAG_ERR errors, with previously were unhandled. This was based on information obtained from the Linux GEM and OpenSolaris ERI drivers. o Turn on workarounds for silicon bugs in the Apple GMAC variants. This was based on information obtained from the Darwin GMAC and Linux GEM drivers. o Turn on "infinite" (i.e. maximum 31 * 64 bytes in length) DMA bursts. This greatly improves especially RX performance. o Optimize the RX path, this consists of: - kicking the receiver as soon as we've a spare descriptor in gem_rint() again instead of just once after all the ready ones have been handled; - kicking the receiver the right way, i.e. as outlined in the GEM documentation in batches of 4 and by pointing it to the descriptor after the last valid one; - calling gem_rint() before gem_tint() in gem_intr() as gem_tint() may take quite a while; - doubling the size of the RX ring to 256 descriptors. Overall the RX performance of a GEM in a 1GHz Sun Fire V210 was improved from ~100Mbit/s to ~850Mbit/s. o In gem_add_rxbuf() don't assign the newly allocated mbuf to rxs_mbuf before calling bus_dmamap_load_mbuf_sg(), if bus_dmamap_load_mbuf_sg() fails we'll free the newly allocated mbuf, unable to recycle the previous one but a NULL pointer dereference instead. o In gem_init_locked() honor the return value of gem_meminit(). o Simplify gem_ringsize() and dont' return garbage in the default case. Based on OpenBSD. o Don't turn on MAC control, MIF and PCS interrupts unless GEM_DEBUG is defined as we don't need/use these interrupts for operation. o In gem_start_locked() sync the DMA maps of the descriptor rings before every kick of the transmitter and not just once after enqueuing all packets as the NIC might instantly start transmitting after we kicked it the first time. o Keep state of the link state and use it to enable or disable the MAC in gem_mii_statchg() accordingly as well as to return early from gem_start_locked() in case the link is down. [3] o Initialize the maximum frame size to a sane value. o In gem_mii_statchg() enable carrier extension if appropriate. o Increment if_ierrors in case of an GEM_MAC_RX_OVERFLOW error and in gem_eint(). [3] o Handle IFF_ALLMULTI correctly; don't set it if we've turned promiscuous group mode on and don't clear the flag if we've disabled promiscuous group mode (these were mostly NOPs though). [2] o Let gem_eint() also report GEM_INTR_PERR errors. o Move setting sc_variant from gem_pci_probe() to gem_pci_attach() as device probe methods are not supposed to touch the softc. o Collapse sc_inited and sc_pci into bits for sc_flags. o Add CTASSERTs ensuring that GEM_NRXDESC and GEM_NTXDESC are set to legal values. o Correctly set up for 802.3x flow control, though #ifdef out the code that actually enables it as this needs more testing and mainly a proper framework to support it. o Correct and add some conversions from hard-coded functions names to __func__ which were borked or forgotten in if_gem.c rev. 1.42. o Use PCIR_BAR instead of a homegrown macro. o Replace sc_enaddr[6] with sc_enaddr[ETHER_ADDR_LEN]. o In gem_pci_attach() in case attaching fails release the resources in the opposite order they were allocated. o Make gem_reset() static to if_gem.c as it's not needed outside that module. o Remove the GEM_GIGABIT flag and the associated code; GEM_GIGABIT was never set and the associated code was in the wrong place. o Remove sc_mif_config; it was only used to cache the contents of the respective register within gem_attach(). o Remove the #ifdef'ed out NetBSD/OpenBSD code for establishing a suspend hook as it will never be used on FreeBSD. o Also probe Apple Intrepid 2 GMAC and Apple Shasta GMAC, add support for Apple K2 GMAC. Based on OpenBSD. o Add support for Sun GBE/P cards, or in other words actually add support for cards based on GEM to gem(4). This mainly consists of adding support for the TBI of these chips. Along with this the PHY selection code was rewritten to hardcode the PHY number for certain configurations as for example the PHY of the on-board ERI of Blade 1000 shows up twice causing no link as the second incarnation is isolated. These changes were ported from OpenBSD with some additional improvements and modulo some bugs. o Add code to if_gem_pci.c allowing to read the MAC-address from the VPD on systems without Open Firmware. This is an improved version of my variant of the respective code in if_hme_pci.c o Now that gem(4) is MI enable it for all archs. Pointed out by: yongari [1] Suggested by: rwatson [2], yongari [3] Tested on: i386 (GEM), powerpc (GMACs by marcel and yongari), sparc64 (ERI and GEM) Reviewed by: yongari Approved by: re (kensmith)
2007-09-26 21:14:18 +00:00
gem \
2003-05-31 18:36:41 +00:00
geom \
${_glxiic} \
${_glxsb} \
gpio \
hid \
hifn \
${_hpt27xx} \
${_hptiop} \
2004-10-24 08:53:40 +00:00
${_hptmv} \
${_hptnr} \
${_hptrr} \
hwpmc \
${_hwpmc_mips24k} \
${_hwpmc_mips74k} \
${_hyperv} \
i2c \
${_iavf} \
${_ibcore} \
${_ichwd} \
${_ice} \
${_ice_ddp} \
${_ida} \
if_bridge \
if_disc \
if_edsc \
${_if_enc} \
if_epair \
${_if_gif} \
${_if_gre} \
${_if_me} \
if_infiniband \
if_lagg \
Throw the switch on the new driver generation/loading mechanism. From here on in, if_ndis.ko will be pre-built as a module, and can be built into a static kernel (though it's not part of GENERIC). Drivers are created using the new ndisgen(8) script, which uses ndiscvt(8) under the covers, along with a few other tools. The result is a driver module that can be kldloaded into the kernel. A driver with foo.inf and foo.sys files will be converted into foo_sys.ko (and foo_sys.o, for those who want/need to make static kernels). This module contains all of the necessary info from the .INF file and the driver binary image, converted into an ELF module. You can kldload this module (or add it to /boot/loader.conf) to have it loaded automatically. Any required firmware files can be bundled into the module as well (or converted/loaded separately). Also, add a workaround for a problem in NdisMSleep(). During system bootstrap (cold == 1), msleep() always returns 0 without actually sleeping. The Intel 2200BG driver uses NdisMSleep() to wait for the NIC's firmware to come to life, and fails to load if NdisMSleep() doesn't actually delay. As a workaround, if msleep() (and hence ndis_thsuspend()) returns 0, use a hard DELAY() to sleep instead). This is not really the right thing to do, but we can't really do much else. At the very least, this makes the Intel driver happy. There are probably other drivers that fail in this way during bootstrap. Unfortunately, the only workaround for those is to avoid pre-loading them and kldload them once the system is running instead.
2005-04-24 20:21:22 +00:00
${_if_ndis} \
${_if_stf} \
tun/tap: merge and rename to `tuntap` tun(4) and tap(4) share the same general management interface and have a lot in common. Bugs exist in tap(4) that have been fixed in tun(4), and vice-versa. Let's reduce the maintenance requirements by merging them together and using flags to differentiate between the three interface types (tun, tap, vmnet). This fixes a couple of tap(4)/vmnet(4) issues right out of the gate: - tap devices may no longer be destroyed while they're open [0] - VIMAGE issues already addressed in tun by kp [0] emaste had removed an easy-panic-button in r240938 due to devdrn blocking. A naive glance over this leads me to believe that this isn't quite complete -- destroy_devl will only block while executing d_* functions, but doesn't block the device from being destroyed while a process has it open. The latter is the intent of the condvar in tun, so this is "fixed" (for certain definitions of the word -- it wasn't really broken in tap, it just wasn't quite ideal). ifconfig(8) also grew the ability to map an interface name to a kld, so that `ifconfig {tun,tap}0` can continue to autoload the correct module, and `ifconfig vmnet0 create` will now autoload the correct module. This is a low overhead addition. (MFC commentary) This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this, and how critical they are. Changes after this are likely easily MFC'd without taking this merge, but the merge will be easier. I have no plans to do this MFC as of now. Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill) Input also from: melifaro Relnotes: yes Differential Revision: https://reviews.freebsd.org/D20044
2019-05-08 02:32:11 +00:00
if_tuntap \
2001-09-05 23:47:46 +00:00
if_vlan \
if_vxlan \
if_wg \
iflib \
${_iir} \
imgact_binmisc \
${_intelspi} \
${_io} \
${_ioat} \
${_ipoib} \
${_ipdivert} \
${_ipfilter} \
${_ipfw} \
2008-02-29 22:28:18 +00:00
ipfw_nat \
Add ipfw_nat64 module that implements stateless and stateful NAT64. The module works together with ipfw(4) and implemented as its external action module. Stateless NAT64 registers external action with name nat64stl. This keyword should be used to create NAT64 instance and to address this instance in rules. Stateless NAT64 uses two lookup tables with mapped IPv4->IPv6 and IPv6->IPv4 addresses to perform translation. A configuration of instance should looks like this: 1. Create lookup tables: # ipfw table T46 create type addr valtype ipv6 # ipfw table T64 create type addr valtype ipv4 2. Fill T46 and T64 tables. 3. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 4. Create NAT64 instance: # ipfw nat64stl NAT create table4 T46 table6 T64 5. Add rules that matches the traffic: # ipfw add nat64stl NAT ip from any to table(T46) # ipfw add nat64stl NAT ip from table(T64) to 64:ff9b::/96 6. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host. Stateful NAT64 registers external action with name nat64lsn. The only one option required to create nat64lsn instance - prefix4. It defines the pool of IPv4 addresses used for translation. A configuration of instance should looks like this: 1. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 2. Create NAT64 instance: # ipfw nat64lsn NAT create prefix4 A.B.C.D/28 3. Add rules that matches the traffic: # ipfw add nat64lsn NAT ip from any to A.B.C.D/28 # ipfw add nat64lsn NAT ip6 from any to 64:ff9b::/96 4. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host. Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D6434
2016-08-13 16:09:49 +00:00
${_ipfw_nat64} \
${_ipfw_nptv6} \
${_ipfw_pmod} \
${_ipmi} \
ip6_mroute_mod \
2007-10-15 08:26:12 +00:00
ip_mroute_mod \
${_ips} \
Merge projects/ipsec into head/. Small summary ------------- o Almost all IPsec releated code was moved into sys/netipsec. o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel option IPSEC_SUPPORT added. It enables support for loading and unloading of ipsec.ko and tcpmd5.ko kernel modules. o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type support was removed. Added TCP/UDP checksum handling for inbound packets that were decapsulated by transport mode SAs. setkey(8) modified to show run-time NAT-T configuration of SA. o New network pseudo interface if_ipsec(4) added. For now it is build as part of ipsec.ko module (or with IPSEC kernel). It implements IPsec virtual tunnels to create route-based VPNs. o The network stack now invokes IPsec functions using special methods. The only one header file <netipsec/ipsec_support.h> should be included to declare all the needed things to work with IPsec. o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed. Now these protocols are handled directly via IPsec methods. o TCP_SIGNATURE support was reworked to be more close to RFC. o PF_KEY SADB was reworked: - now all security associations stored in the single SPI namespace, and all SAs MUST have unique SPI. - several hash tables added to speed up lookups in SADB. - SADB now uses rmlock to protect access, and concurrent threads can do SA lookups in the same time. - many PF_KEY message handlers were reworked to reflect changes in SADB. - SADB_UPDATE message was extended to support new PF_KEY headers: SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST. They can be used by IKE daemon to change SA addresses. o ipsecrequest and secpolicy structures were cardinally changed to avoid locking protection for ipsecrequest. Now we support only limited number (4) of bundled SAs, but they are supported for both INET and INET6. o INPCB security policy cache was introduced. Each PCB now caches used security policies to avoid SP lookup for each packet. o For inbound security policies added the mode, when the kernel does check for full history of applied IPsec transforms. o References counting rules for security policies and security associations were changed. The proper SA locking added into xform code. o xform code was also changed. Now it is possible to unregister xforms. tdb_xxx structures were changed and renamed to reflect changes in SADB/SPDB, and changed rules for locking and refcounting. Reviewed by: gnn, wblock Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D9352
2017-02-06 08:49:57 +00:00
${_ipsec} \
${_ipw} \
${_ipwfw} \
${_isci} \
${_iser} \
isp \
${_ispfw} \
${_itwd} \
${_iwi} \
${_iwifw} \
${_iwm} \
${_iwmfw} \
${_iwn} \
${_iwnfw} \
${_ix} \
${_ixv} \
${_ixl} \
2008-05-27 01:54:45 +00:00
jme \
kbdmux \
kgssapi \
kgssapi_krb5 \
khelp \
krpc \
ksyms \
Add kernel-side support for in-kernel TLS. KTLS adds support for in-kernel framing and encryption of Transport Layer Security (1.0-1.2) data on TCP sockets. KTLS only supports offload of TLS for transmitted data. Key negotation must still be performed in userland. Once completed, transmit session keys for a connection are provided to the kernel via a new TCP_TXTLS_ENABLE socket option. All subsequent data transmitted on the socket is placed into TLS frames and encrypted using the supplied keys. Any data written to a KTLS-enabled socket via write(2), aio_write(2), or sendfile(2) is assumed to be application data and is encoded in TLS frames with an application data type. Individual records can be sent with a custom type (e.g. handshake messages) via sendmsg(2) with a new control message (TLS_SET_RECORD_TYPE) specifying the record type. At present, rekeying is not supported though the in-kernel framework should support rekeying. KTLS makes use of the recently added unmapped mbufs to store TLS frames in the socket buffer. Each TLS frame is described by a single ext_pgs mbuf. The ext_pgs structure contains the header of the TLS record (and trailer for encrypted records) as well as references to the associated TLS session. KTLS supports two primary methods of encrypting TLS frames: software TLS and ifnet TLS. Software TLS marks mbufs holding socket data as not ready via M_NOTREADY similar to sendfile(2) when TLS framing information is added to an unmapped mbuf in ktls_frame(). ktls_enqueue() is then called to schedule TLS frames for encryption. In the case of sendfile_iodone() calls ktls_enqueue() instead of pru_ready() leaving the mbufs marked M_NOTREADY until encryption is completed. For other writes (vn_sendfile when pages are available, write(2), etc.), the PRUS_NOTREADY is set when invoking pru_send() along with invoking ktls_enqueue(). A pool of worker threads (the "KTLS" kernel process) encrypts TLS frames queued via ktls_enqueue(). Each TLS frame is temporarily mapped using the direct map and passed to a software encryption backend to perform the actual encryption. (Note: The use of PHYS_TO_DMAP could be replaced with sf_bufs if someone wished to make this work on architectures without a direct map.) KTLS supports pluggable software encryption backends. Internally, Netflix uses proprietary pure-software backends. This commit includes a simple backend in a new ktls_ocf.ko module that uses the kernel's OpenCrypto framework to provide AES-GCM encryption of TLS frames. As a result, software TLS is now a bit of a misnomer as it can make use of hardware crypto accelerators. Once software encryption has finished, the TLS frame mbufs are marked ready via pru_ready(). At this point, the encrypted data appears as regular payload to the TCP stack stored in unmapped mbufs. ifnet TLS permits a NIC to offload the TLS encryption and TCP segmentation. In this mode, a new send tag type (IF_SND_TAG_TYPE_TLS) is allocated on the interface a socket is routed over and associated with a TLS session. TLS records for a TLS session using ifnet TLS are not marked M_NOTREADY but are passed down the stack unencrypted. The ip_output_send() and ip6_output_send() helper functions that apply send tags to outbound IP packets verify that the send tag of the TLS record matches the outbound interface. If so, the packet is tagged with the TLS send tag and sent to the interface. The NIC device driver must recognize packets with the TLS send tag and schedule them for TLS encryption and TCP segmentation. If the the outbound interface does not match the interface in the TLS send tag, the packet is dropped. In addition, a task is scheduled to refresh the TLS send tag for the TLS session. If a new TLS send tag cannot be allocated, the connection is dropped. If a new TLS send tag is allocated, however, subsequent packets will be tagged with the correct TLS send tag. (This latter case has been tested by configuring both ports of a Chelsio T6 in a lagg and failing over from one port to another. As the connections migrated to the new port, new TLS send tags were allocated for the new port and connections resumed without being dropped.) ifnet TLS can be enabled and disabled on supported network interfaces via new '[-]txtls[46]' options to ifconfig(8). ifnet TLS is supported across both vlan devices and lagg interfaces using failover, lacp with flowid enabled, or lacp with flowid enabled. Applications may request the current KTLS mode of a connection via a new TCP_TXTLS_MODE socket option. They can also use this socket option to toggle between software and ifnet TLS modes. In addition, a testing tool is available in tools/tools/switch_tls. This is modeled on tcpdrop and uses similar syntax. However, instead of dropping connections, -s is used to force KTLS connections to switch to software TLS and -i is used to switch to ifnet TLS. Various sysctls and counters are available under the kern.ipc.tls sysctl node. The kern.ipc.tls.enable node must be set to true to enable KTLS (it is off by default). The use of unmapped mbufs must also be enabled via kern.ipc.mb_use_ext_pgs to enable KTLS. KTLS is enabled via the KERN_TLS kernel option. This patch is the culmination of years of work by several folks including Scott Long and Randall Stewart for the original design and implementation; Drew Gallatin for several optimizations including the use of ext_pgs mbufs, the M_NOTREADY mechanism for TLS records awaiting software encryption, and pluggable software crypto backends; and John Baldwin for modifications to support hardware TLS offload. Reviewed by: gallatin, hselasky, rrs Obtained from: Netflix Sponsored by: Netflix, Chelsio Communications Differential Revision: https://reviews.freebsd.org/D21277
2019-08-27 00:01:56 +00:00
${_ktls_ocf} \
le \
lge \
2005-05-06 14:47:54 +00:00
libalias \
libiconv \
libmchain \
lindebugfs \
linuxkpi \
${_lio} \
lpt \
mac_biba \
mac_bsdextended \
mac_ifoff \
mac_lomac \
mac_mls \
mac_none \
mac_ntpd \
mac_partition \
mac_portacl \
mac_seeotheruids \
mac_stub \
mac_test \
${_malo} \
md \
mdio \
2004-08-02 19:21:51 +00:00
mem \
mfi \
mii \
mlx \
mlxfw \
${_mlx4} \
${_mlx4ib} \
${_mlx4en} \
${_mlx5} \
${_mlx5en} \
${_mlx5ib} \
${_mly} \
mmc \
mmcsd \
${_mpr} \
${_mps} \
mpt \
2005-11-26 12:46:01 +00:00
mqueue \
mrsas \
msdosfs \
msdosfs_iconv \
2006-12-13 02:37:48 +00:00
msk \
${_mthca} \
mvs \
mwl \
${_mwlfw} \
mxge \
2003-02-27 14:49:56 +00:00
my \
${_nctgpio} \
${_ndis} \
${_netgraph} \
${_nfe} \
nfscl \
nfscommon \
nfsd \
nfslockd \
nfssvc \
nge \
nmdm \
nullfs \
${_ntb} \
${_nvd} \
${_nvdimm} \
${_nvme} \
${_nvram} \
oce \
${_ocs_fc} \
${_ossl} \
otus \
${_otusfw} \
ow \
${_padlock} \
This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random. This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources. The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people. The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway. Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to. My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise. My Nomex pants are on. Let the feedback commence! Reviewed by: trasz,des(partial),imp(partial?),rwatson(partial?) Approved by: so(des)
2014-10-30 21:21:53 +00:00
${_padlock_rng} \
${_pccard} \
${_pchtherm} \
${_pcfclock} \
${_pf} \
${_pflog} \
${_pfsync} \
plip \
2015-07-17 20:30:30 +00:00
${_pms} \
ppbus \
ppc \
ppi \
pps \
procfs \
proto \
pseudofs \
${_pst} \
pty \
puc \
2019-06-16 00:53:09 +00:00
pwm \
${_qat} \
${_qatfw} \
${_qlxge} \
${_qlxgb} \
${_qlxgbe} \
${_qlnx} \
ral \
${_ralfw} \
${_random_fortuna} \
${_random_other} \
rc4 \
2008-05-05 20:41:54 +00:00
${_rdma} \
This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random. This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources. The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people. The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway. Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to. My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise. My Nomex pants are on. Let the feedback commence! Reviewed by: trasz,des(partial),imp(partial?),rwatson(partial?) Approved by: so(des)
2014-10-30 21:21:53 +00:00
${_rdrand_rng} \
Take the support for the 8139C+/8169/8169S/8110S chips out of the rl(4) driver and put it in a new re(4) driver. The re(4) driver shares the if_rlreg.h file with rl(4) but is a separate module. (Ultimately I may change this. For now, it's convenient.) rl(4) has been modified so that it will never attach to an 8139C+ chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to match the 8169/8169S/8110S gigE chips. if_re.c contains the same basic code that was originally bolted onto if_rl.c, with the following updates: - Added support for jumbo frames. Currently, there seems to be a limit of approximately 6200 bytes for jumbo frames on transmit. (This was determined via experimentation.) The 8169S/8110S chips apparently are limited to 7.5K frames on transmit. This may require some more work, though the framework to handle jumbo frames on RX is in place: the re_rxeof() routine will gather up frames than span multiple 2K clusters into a single mbuf list. - Fixed bug in re_txeof(): if we reap some of the TX buffers, but there are still some pending, re-arm the timer before exiting re_txeof() so that another timeout interrupt will be generated, just in case re_start() doesn't do it for us. - Handle the 'link state changed' interrupt - Fix a detach bug. If re(4) is loaded as a module, and you do tcpdump -i re0, then you do 'kldunload if_re,' the system will panic after a few seconds. This happens because ether_ifdetach() ends up calling the BPF detach code, which notices the interface is in promiscuous mode and tries to switch promisc mode off while detaching the BPF listner. This ultimately results in a call to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init() to handle the IFF_PROMISC flag change. Unfortunately, calling re_init() here turns the chip back on and restarts the 1-second timeout loop that drives re_tick(). By the time the timeout fires, if_re.ko has been unloaded, which results in a call to invalid code and blows up the system. To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(), which stops the ioctl routine from trying to reset the chip. - Modified comments in re_rxeof() relating to the difference in RX descriptor status bit layout between the 8139C+ and the gigE chips. The layout is different because the frame length field was expanded from 12 bits to 13, and they got rid of one of the status bits to make room. - Add diagnostic code (re_diag()) to test for the case where a user has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some NICs have the REQ64# and ACK64# lines connected even though the board is 32-bit only (in this case, they should be pulled high). This fools the chip into doing 64-bit DMA transfers even though there is no 64-bit data path. To detect this, re_diag() puts the chip into digital loopback mode and sets the receiver to promiscuous mode, then initiates a single 64-byte packet transmission. The frame is echoed back to the host, and if the frame contents are intact, we know DMA is working correctly, otherwise we complain loudly on the console and abort the device attach. (At the moment, I don't know of any way to work around the problem other than physically modifying the board, so until/unless I can think of a software workaround, this will have do to.) - Created re(4) man page - Modified rlphy.c to allow re(4) to attach as well as rl(4). Note that this code works for the sample 8169/Marvell 88E1000 NIC that I have, but probably won't work for the 8169S/8110S chips. RealTek has sent me some sample NICs, but they haven't arrived yet. I will probably need to add an rlgphy driver to handle the on-board PHY in the 8169S/8110S (it needs special DSP initialization).
2003-09-08 02:11:25 +00:00
re \
rl \
${_rockchip} \
rtsx \
rtwn \
rtwn_pci \
rtwn_usb \
${_rtwnfw} \
${_s3} \
${_safe} \
safexcel \
${_sbni} \
scc \
${_sctp} \
sdhci \
${_sdhci_acpi} \
sdhci_pci \
sdio \
sem \
send \
${_sfxge} \
sge \
${_sgx} \
${_sgx_linux} \
siftr \
siis \
sis \
sk \
${_smartpqi} \
smbfs \
snp \
sound \
${_speaker} \
spi \
${_splash} \
${_sppp} \
ste \
2006-07-25 00:45:55 +00:00
stge \
${_sume} \
add superio driver The goal of this driver is consolidate information about SuperIO chips and to provide for peaceful coexistence of drivers that need to access SuperIO configuration registers. While SuperIO chips can host various functions most of them are discoverable and accessible without any knowledge of the SuperIO. Examples are: keyboard and mouse controllers, UARTs, floppy disk controllers. SuperIO-s also provide non-standard functions such as GPIO, watchdog timers and hardware monitoring. Such functions do require drivers with a knowledge of a specific SuperIO. At this time the driver supports a number of ITE and Nuvoton (fka Winbond) SuperIO chips. There is a single driver for all devices. So, I have not done the usual split between the hardware driver and the bus functionality. Although, superio does act as a bus for devices that represent known non-standard functions of a SuperIO chip. The bus provides enumeration of child devices based on the hardcoded knowledge of such functions. The knowledge as extracted from datasheets and other drivers. As there is a single driver, I have not defined a kobj interface for it. So, its interface is currently made of simple functions. I think that we can the flexibility (and complications) when we actually need it. I am planning to convert nctgpio and wbwd to superio bus very soon. Also, I am working on itwd driver (watchdog in ITE SuperIO-s). Additionally, there is ithwm driver based on the reverted sensors import, but I am not sure how to integrate it given that we still lack any sensors interface. Discussed with: imp, jhb MFC after: 7 weeks Differential Revision: https://reviews.freebsd.org/D8175
2019-07-01 17:05:41 +00:00
${_superio} \
${_sym} \
${_syscons} \
sysvipc \
tcp \
${_ti} \
tmpfs \
${_toecore} \
${_tpm} \
2004-04-27 17:57:45 +00:00
${_twa} \
2002-10-21 00:38:18 +00:00
twe \
tws \
uart \
udf \
udf_iconv \
ufs \
uinput \
unionfs \
2009-02-23 18:32:59 +00:00
usb \
${_vesa} \
${_virtio} \
vge \
${_viawd} \
videomode \
vkbd \
${_vmd} \
${_vmm} \
${_vmware} \
vr \
vte \
${_wbwd} \
wlan \
wlan_acl \
wlan_amrr \
wlan_ccmp \
wlan_rssadapt \
wlan_tkip \
wlan_wep \
wlan_xauth \
${_wpi} \
${_wpifw} \
${_x86bios} \
xdr \
xl \
xz \
zlib
.if ${MK_AUTOFS} != "no" || defined(ALL_MODULES)
_autofs= autofs
.endif
.if ${MK_CDDL} != "no" || defined(ALL_MODULES)
.if (${MACHINE_CPUARCH} != "arm" || ${MACHINE_ARCH:Marmv[67]*} != "") && \
${MACHINE_CPUARCH} != "mips"
.if ${KERN_OPTS:MKDTRACE_HOOKS}
SUBDIR+= dtrace
.endif
.endif
SUBDIR+= opensolaris
.endif
.if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
.if exists(${SRCTOP}/sys/opencrypto)
_crypto= crypto
_cryptodev= cryptodev
_random_fortuna=random_fortuna
_random_other= random_other
Add kernel-side support for in-kernel TLS. KTLS adds support for in-kernel framing and encryption of Transport Layer Security (1.0-1.2) data on TCP sockets. KTLS only supports offload of TLS for transmitted data. Key negotation must still be performed in userland. Once completed, transmit session keys for a connection are provided to the kernel via a new TCP_TXTLS_ENABLE socket option. All subsequent data transmitted on the socket is placed into TLS frames and encrypted using the supplied keys. Any data written to a KTLS-enabled socket via write(2), aio_write(2), or sendfile(2) is assumed to be application data and is encoded in TLS frames with an application data type. Individual records can be sent with a custom type (e.g. handshake messages) via sendmsg(2) with a new control message (TLS_SET_RECORD_TYPE) specifying the record type. At present, rekeying is not supported though the in-kernel framework should support rekeying. KTLS makes use of the recently added unmapped mbufs to store TLS frames in the socket buffer. Each TLS frame is described by a single ext_pgs mbuf. The ext_pgs structure contains the header of the TLS record (and trailer for encrypted records) as well as references to the associated TLS session. KTLS supports two primary methods of encrypting TLS frames: software TLS and ifnet TLS. Software TLS marks mbufs holding socket data as not ready via M_NOTREADY similar to sendfile(2) when TLS framing information is added to an unmapped mbuf in ktls_frame(). ktls_enqueue() is then called to schedule TLS frames for encryption. In the case of sendfile_iodone() calls ktls_enqueue() instead of pru_ready() leaving the mbufs marked M_NOTREADY until encryption is completed. For other writes (vn_sendfile when pages are available, write(2), etc.), the PRUS_NOTREADY is set when invoking pru_send() along with invoking ktls_enqueue(). A pool of worker threads (the "KTLS" kernel process) encrypts TLS frames queued via ktls_enqueue(). Each TLS frame is temporarily mapped using the direct map and passed to a software encryption backend to perform the actual encryption. (Note: The use of PHYS_TO_DMAP could be replaced with sf_bufs if someone wished to make this work on architectures without a direct map.) KTLS supports pluggable software encryption backends. Internally, Netflix uses proprietary pure-software backends. This commit includes a simple backend in a new ktls_ocf.ko module that uses the kernel's OpenCrypto framework to provide AES-GCM encryption of TLS frames. As a result, software TLS is now a bit of a misnomer as it can make use of hardware crypto accelerators. Once software encryption has finished, the TLS frame mbufs are marked ready via pru_ready(). At this point, the encrypted data appears as regular payload to the TCP stack stored in unmapped mbufs. ifnet TLS permits a NIC to offload the TLS encryption and TCP segmentation. In this mode, a new send tag type (IF_SND_TAG_TYPE_TLS) is allocated on the interface a socket is routed over and associated with a TLS session. TLS records for a TLS session using ifnet TLS are not marked M_NOTREADY but are passed down the stack unencrypted. The ip_output_send() and ip6_output_send() helper functions that apply send tags to outbound IP packets verify that the send tag of the TLS record matches the outbound interface. If so, the packet is tagged with the TLS send tag and sent to the interface. The NIC device driver must recognize packets with the TLS send tag and schedule them for TLS encryption and TCP segmentation. If the the outbound interface does not match the interface in the TLS send tag, the packet is dropped. In addition, a task is scheduled to refresh the TLS send tag for the TLS session. If a new TLS send tag cannot be allocated, the connection is dropped. If a new TLS send tag is allocated, however, subsequent packets will be tagged with the correct TLS send tag. (This latter case has been tested by configuring both ports of a Chelsio T6 in a lagg and failing over from one port to another. As the connections migrated to the new port, new TLS send tags were allocated for the new port and connections resumed without being dropped.) ifnet TLS can be enabled and disabled on supported network interfaces via new '[-]txtls[46]' options to ifconfig(8). ifnet TLS is supported across both vlan devices and lagg interfaces using failover, lacp with flowid enabled, or lacp with flowid enabled. Applications may request the current KTLS mode of a connection via a new TCP_TXTLS_MODE socket option. They can also use this socket option to toggle between software and ifnet TLS modes. In addition, a testing tool is available in tools/tools/switch_tls. This is modeled on tcpdrop and uses similar syntax. However, instead of dropping connections, -s is used to force KTLS connections to switch to software TLS and -i is used to switch to ifnet TLS. Various sysctls and counters are available under the kern.ipc.tls sysctl node. The kern.ipc.tls.enable node must be set to true to enable KTLS (it is off by default). The use of unmapped mbufs must also be enabled via kern.ipc.mb_use_ext_pgs to enable KTLS. KTLS is enabled via the KERN_TLS kernel option. This patch is the culmination of years of work by several folks including Scott Long and Randall Stewart for the original design and implementation; Drew Gallatin for several optimizations including the use of ext_pgs mbufs, the M_NOTREADY mechanism for TLS records awaiting software encryption, and pluggable software crypto backends; and John Baldwin for modifications to support hardware TLS offload. Reviewed by: gallatin, hselasky, rrs Obtained from: Netflix Sponsored by: Netflix, Chelsio Communications Differential Revision: https://reviews.freebsd.org/D21277
2019-08-27 00:01:56 +00:00
_ktls_ocf= ktls_ocf
.endif
.endif
.if ${MK_CUSE} != "no" || defined(ALL_MODULES)
SUBDIR+= cuse
.endif
.if ${MK_EFI} != "no"
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64"
_efirt= efirt
.endif
.endif
.if (${MK_INET_SUPPORT} != "no" || ${MK_INET6_SUPPORT} != "no") || \
defined(ALL_MODULES)
_carp= carp
_toecore= toecore
_if_enc= if_enc
_if_gif= if_gif
_if_gre= if_gre
_ipfw_pmod= ipfw_pmod
.if ${KERN_OPTS:MIPSEC_SUPPORT} && !${KERN_OPTS:MIPSEC}
Merge projects/ipsec into head/. Small summary ------------- o Almost all IPsec releated code was moved into sys/netipsec. o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel option IPSEC_SUPPORT added. It enables support for loading and unloading of ipsec.ko and tcpmd5.ko kernel modules. o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type support was removed. Added TCP/UDP checksum handling for inbound packets that were decapsulated by transport mode SAs. setkey(8) modified to show run-time NAT-T configuration of SA. o New network pseudo interface if_ipsec(4) added. For now it is build as part of ipsec.ko module (or with IPSEC kernel). It implements IPsec virtual tunnels to create route-based VPNs. o The network stack now invokes IPsec functions using special methods. The only one header file <netipsec/ipsec_support.h> should be included to declare all the needed things to work with IPsec. o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed. Now these protocols are handled directly via IPsec methods. o TCP_SIGNATURE support was reworked to be more close to RFC. o PF_KEY SADB was reworked: - now all security associations stored in the single SPI namespace, and all SAs MUST have unique SPI. - several hash tables added to speed up lookups in SADB. - SADB now uses rmlock to protect access, and concurrent threads can do SA lookups in the same time. - many PF_KEY message handlers were reworked to reflect changes in SADB. - SADB_UPDATE message was extended to support new PF_KEY headers: SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST. They can be used by IKE daemon to change SA addresses. o ipsecrequest and secpolicy structures were cardinally changed to avoid locking protection for ipsecrequest. Now we support only limited number (4) of bundled SAs, but they are supported for both INET and INET6. o INPCB security policy cache was introduced. Each PCB now caches used security policies to avoid SP lookup for each packet. o For inbound security policies added the mode, when the kernel does check for full history of applied IPsec transforms. o References counting rules for security policies and security associations were changed. The proper SA locking added into xform code. o xform code was also changed. Now it is possible to unregister xforms. tdb_xxx structures were changed and renamed to reflect changes in SADB/SPDB, and changed rules for locking and refcounting. Reviewed by: gnn, wblock Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D9352
2017-02-06 08:49:57 +00:00
_ipsec= ipsec
.endif
.if ${KERN_OPTS:MSCTP_SUPPORT} || ${KERN_OPTS:MSCTP}
_sctp= sctp
.endif
.endif
.if (${MK_INET_SUPPORT} != "no" && ${MK_INET6_SUPPORT} != "no") || \
defined(ALL_MODULES)
_if_stf= if_stf
.endif
.if ${MK_INET_SUPPORT} != "no" || defined(ALL_MODULES)
_if_me= if_me
_ipdivert= ipdivert
_ipfw= ipfw
Add ipfw_nat64 module that implements stateless and stateful NAT64. The module works together with ipfw(4) and implemented as its external action module. Stateless NAT64 registers external action with name nat64stl. This keyword should be used to create NAT64 instance and to address this instance in rules. Stateless NAT64 uses two lookup tables with mapped IPv4->IPv6 and IPv6->IPv4 addresses to perform translation. A configuration of instance should looks like this: 1. Create lookup tables: # ipfw table T46 create type addr valtype ipv6 # ipfw table T64 create type addr valtype ipv4 2. Fill T46 and T64 tables. 3. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 4. Create NAT64 instance: # ipfw nat64stl NAT create table4 T46 table6 T64 5. Add rules that matches the traffic: # ipfw add nat64stl NAT ip from any to table(T46) # ipfw add nat64stl NAT ip from table(T64) to 64:ff9b::/96 6. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host. Stateful NAT64 registers external action with name nat64lsn. The only one option required to create nat64lsn instance - prefix4. It defines the pool of IPv4 addresses used for translation. A configuration of instance should looks like this: 1. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 2. Create NAT64 instance: # ipfw nat64lsn NAT create prefix4 A.B.C.D/28 3. Add rules that matches the traffic: # ipfw add nat64lsn NAT ip from any to A.B.C.D/28 # ipfw add nat64lsn NAT ip6 from any to 64:ff9b::/96 4. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host. Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D6434
2016-08-13 16:09:49 +00:00
.if ${MK_INET6_SUPPORT} != "no" || defined(ALL_MODULES)
_ipfw_nat64= ipfw_nat64
.endif
.endif
.if ${MK_INET6_SUPPORT} != "no" || defined(ALL_MODULES)
_ipfw_nptv6= ipfw_nptv6
.endif
.if ${MK_IPFILTER} != "no" || defined(ALL_MODULES)
_ipfilter= ipfilter
2002-10-21 00:38:18 +00:00
.endif
.if ${MK_ISCSI} != "no" || defined(ALL_MODULES)
SUBDIR+= cfiscsi
SUBDIR+= iscsi
SUBDIR+= iscsi_initiator
.endif
.if !empty(OPT_FDT)
SUBDIR+= fdt
.endif
# Linuxulator
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64" || \
${MACHINE_CPUARCH} == "i386"
SUBDIR+= linprocfs
SUBDIR+= linsysfs
.endif
.if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386"
SUBDIR+= linux
.endif
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64"
SUBDIR+= linux64
SUBDIR+= linux_common
.endif
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64" || \
${MACHINE_CPUARCH} == "i386"
_ena= ena
.if ${MK_OFED} != "no" || defined(ALL_MODULES)
_ibcore= ibcore
_ipoib= ipoib
_iser= iser
.endif
_ipmi= ipmi
_mlx4= mlx4
_mlx5= mlx5
.if (${MK_INET_SUPPORT} != "no" && ${MK_INET6_SUPPORT} != "no") || \
defined(ALL_MODULES)
_mlx4en= mlx4en
_mlx5en= mlx5en
.endif
.if ${MK_OFED} != "no" || defined(ALL_MODULES)
_mthca= mthca
_mlx4ib= mlx4ib
_mlx5ib= mlx5ib
.endif
_ossl= ossl
_vmware= vmware
.endif
.if ${MK_NETGRAPH} != "no" || defined(ALL_MODULES)
_netgraph= netgraph
.endif
.if (${MK_PF} != "no" && (${MK_INET_SUPPORT} != "no" || \
${MK_INET6_SUPPORT} != "no")) || defined(ALL_MODULES)
_pf= pf
_pflog= pflog
.if ${MK_INET_SUPPORT} != "no"
_pfsync= pfsync
.endif
.endif
.if ${MK_SOURCELESS_UCODE} != "no"
_bce= bce
_fxp= fxp
_ispfw= ispfw
_ti= ti
.if ${MACHINE_CPUARCH} != "mips"
_mwlfw= mwlfw
_otusfw= otusfw
_ralfw= ralfw
_rtwnfw= rtwnfw
.endif
.endif
.if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \
${MACHINE_CPUARCH} != "mips" && \
Create a new MACHINE_ARCH for Freescale PowerPC e500v2 Summary: The Freescale e500v2 PowerPC core does not use a standard FPU. Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this. Additionaly, the SPE opcodes overlap with Altivec, so these are mutually exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was created with the same function set as in powerpc/powerpc/altivec.c, so it becomes effectively a drop-in replacement. setjmp/longjmp were modified to save the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by the SPE). Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not support double-precision floating point. Also, without a new MACHINE_ARCH it would be impossible to provide binary packages which utilize the SPE. Additionally, no work has been done to support ports, work is needed for this. This also means no newer gcc can yet be used. However, gcc's powerpc support has been refactored which would make adding a powerpcspe-freebsd target very easy. Test Plan: This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222 (P1022-based) board, compiled against the new ABI. Base system utilities (/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot multiuser. Reviewed By: bdrewery, imp Relnotes: yes Differential Revision: https://reviews.freebsd.org/D5683
2016-10-22 01:57:15 +00:00
${MACHINE_ARCH} != "powerpc" && ${MACHINE_ARCH} != "powerpcspe" && \
${MACHINE_CPUARCH} != "riscv"
_cxgbe= cxgbe
.endif
.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "arm64"
_ice= ice
.if ${MK_SOURCELESS_UCODE} != "no"
_ice_ddp= ice_ddp
.endif
.endif
# These rely on 64bit atomics
2018-12-09 21:53:45 +00:00
.if ${MACHINE_ARCH} != "powerpc" && ${MACHINE_ARCH} != "powerpcspe" && \
${MACHINE_CPUARCH} != "mips"
_mps= mps
_mpr= mpr
.endif
.if ${MK_TESTS} != "no" || defined(ALL_MODULES)
SUBDIR+= tests
.endif
.if ${MK_ZFS} != "no" || (defined(ALL_MODULES) && ${MACHINE_CPUARCH} != "powerpc")
SUBDIR+= zfs
.endif
.if (${MACHINE_CPUARCH} == "mips" && ${MACHINE_ARCH:Mmips64} == "")
2017-01-31 01:48:55 +00:00
_hwpmc_mips24k= hwpmc_mips24k
_hwpmc_mips74k= hwpmc_mips74k
.endif
.if ${MACHINE_CPUARCH} != "aarch64" && ${MACHINE_CPUARCH} != "arm" && \
${MACHINE_CPUARCH} != "mips" && ${MACHINE_CPUARCH} != "powerpc" && \
${MACHINE_CPUARCH} != "riscv"
_syscons= syscons
.endif
.if ${MACHINE_CPUARCH} != "mips"
# no BUS_SPACE_UNSPECIFIED
# No barrier instruction support (specific to this driver)
_sym= sym
# intr_disable() is a macro, causes problems
.if ${MK_SOURCELESS_UCODE} != "no"
_cxgb= cxgb
.endif
.endif
.if ${MACHINE_CPUARCH} == "aarch64"
_allwinner= allwinner
_armv8crypto= armv8crypto
_em= em
_rockchip= rockchip
.endif
.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
_agp= agp
_an= an
_aout= aout
_bios= bios
.if ${MK_SOURCELESS_UCODE} != "no"
_bxe= bxe
.endif
_cardbus= cardbus
_cbb= cbb
_cpuctl= cpuctl
_cpufreq= cpufreq
_dpms= dpms
_em= em
_et= et
_ftwd= ftwd
_exca= exca
Throw the switch on the new driver generation/loading mechanism. From here on in, if_ndis.ko will be pre-built as a module, and can be built into a static kernel (though it's not part of GENERIC). Drivers are created using the new ndisgen(8) script, which uses ndiscvt(8) under the covers, along with a few other tools. The result is a driver module that can be kldloaded into the kernel. A driver with foo.inf and foo.sys files will be converted into foo_sys.ko (and foo_sys.o, for those who want/need to make static kernels). This module contains all of the necessary info from the .INF file and the driver binary image, converted into an ELF module. You can kldload this module (or add it to /boot/loader.conf) to have it loaded automatically. Any required firmware files can be bundled into the module as well (or converted/loaded separately). Also, add a workaround for a problem in NdisMSleep(). During system bootstrap (cold == 1), msleep() always returns 0 without actually sleeping. The Intel 2200BG driver uses NdisMSleep() to wait for the NIC's firmware to come to life, and fails to load if NdisMSleep() doesn't actually delay. As a workaround, if msleep() (and hence ndis_thsuspend()) returns 0, use a hard DELAY() to sleep instead). This is not really the right thing to do, but we can't really do much else. At the very least, this makes the Intel driver happy. There are probably other drivers that fail in this way during bootstrap. Unfortunately, the only workaround for those is to avoid pre-loading them and kldload them once the system is running instead.
2005-04-24 20:21:22 +00:00
_if_ndis= if_ndis
_io= io
_itwd= itwd
_ix= ix
_ixv= ixv
.if ${MK_SOURCELESS_UCODE} != "no"
_lio= lio
.endif
_nctgpio= nctgpio
_ndis= ndis
_ntb= ntb
_ocs_fc= ocs_fc
_pccard= pccard
_qat= qat
_qatfw= qatfw
.if ${MK_OFED} != "no" || defined(ALL_MODULES)
2008-05-05 20:41:54 +00:00
_rdma= rdma
.endif
_safe= safe
_speaker= speaker
_splash= splash
_sppp= sppp
_wbwd= wbwd
_aac= aac
_aacraid= aacraid
_acpi= acpi
.if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
_aesni= aesni
.endif
_amd_ecc_inject=amd_ecc_inject
_amdsbwd= amdsbwd
_amdsmn= amdsmn
_amdtemp= amdtemp
_arcmsr= arcmsr
_asmc= asmc
.if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
_blake2= blake2
.endif
_bytgpio= bytgpio
_chvgpio= chvgpio
_ciss= ciss
add iic interface to ig4 driver, move isl and cyapa to iicbus Summary: The hardware does not expose a classic SMBus interface. Instead it has a lower level interface that can express a far richer I2C protocol than what smbus offers. However, the interface does not provide a way to explicitly generate the I2C stop and start conditions. It's only possible to request that the stop condition is generated after transferring the next byte in either direction. So, at least one data byte must always be transferred. Thus, some I2C sequences are impossible to generate, e.g., an equivalent of smbus quick command (<start>-<slave addr>-<r/w bit>-<stop>). At the same time isl(4) and cyapa(4) are moved to iicbus and now they use iicbus_transfer for communication. Previously they used smbus_trans() interface that is not defined by the SMBus protocol and was implemented only by ig4(4). In fact, that interface was impossible to implement for the typical SMBus controllers like intpm(4) or ichsmb(4) where a type of the SMBus command must be programmed. The plan is to remove smbus_trans() and all its uses. As an aside, the smbus_trans() method deviates from the standard, but perhaps backwards, FreeBSD convention of using 8-bit slave addresses (shifted by 1 bit to the left). The method expects 7-bit addresses. There is a user facing consequence of this change. A user must now provide device hints for isl and cyapa that specify an iicbus to use and a slave address on it. On Chromebook hardware where isl and cyapa devices are commonly found it is also possible to use a new chromebook_platform(4) driver that automatically configures isl and cyapa devices. There is no need to provide the device hints in that case, Right now smbus(4) driver tries to discover all slaves on the bus. That is very dangerous. Fortunately, the probing code uses smbus_trans() to do its job, so it is really enabled for ig4 only. The plan is to remove that auto-probing code and smbus_trans(). Tested by: grembo, Matthias Apitz <guru@unixarea.de> (w/o chromebook_platform) Discussed with: grembo, imp Reviewed by: wblock (docs) MFC after: 1 month Relnotes: yes Differential Revision: https://reviews.freebsd.org/D8172
2016-10-30 12:15:33 +00:00
_chromebook_platform= chromebook_platform
_coretemp= coretemp
.if ${MK_SOURCELESS_HOST} != "no" && empty(KCSAN_ENABLED)
_hpt27xx= hpt27xx
.endif
_hptiop= hptiop
.if ${MK_SOURCELESS_HOST} != "no" && empty(KCSAN_ENABLED)
2004-10-24 08:53:40 +00:00
_hptmv= hptmv
_hptnr= hptnr
_hptrr= hptrr
.endif
_hyperv= hyperv
2004-05-13 11:13:55 +00:00
_ichwd= ichwd
_ida= ida
_iir= iir
_intelspi= intelspi
_ips= ips
_isci= isci
_ipw= ipw
2006-03-17 13:06:19 +00:00
_iwi= iwi
_iwm= iwm
_iwn= iwn
.if ${MK_SOURCELESS_UCODE} != "no"
_ipwfw= ipwfw
_iwifw= iwifw
_iwmfw= iwmfw
_iwnfw= iwnfw
.endif
_mly= mly
_nfe= nfe
_nvd= nvd
_nvme= nvme
_nvram= nvram
.if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
_padlock= padlock
This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random. This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources. The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people. The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway. Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to. My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise. My Nomex pants are on. Let the feedback commence! Reviewed by: trasz,des(partial),imp(partial?),rwatson(partial?) Approved by: so(des)
2014-10-30 21:21:53 +00:00
_padlock_rng= padlock_rng
_rdrand_rng= rdrand_rng
.endif
_pchtherm = pchtherm
_s3= s3
_sdhci_acpi= sdhci_acpi
add superio driver The goal of this driver is consolidate information about SuperIO chips and to provide for peaceful coexistence of drivers that need to access SuperIO configuration registers. While SuperIO chips can host various functions most of them are discoverable and accessible without any knowledge of the SuperIO. Examples are: keyboard and mouse controllers, UARTs, floppy disk controllers. SuperIO-s also provide non-standard functions such as GPIO, watchdog timers and hardware monitoring. Such functions do require drivers with a knowledge of a specific SuperIO. At this time the driver supports a number of ITE and Nuvoton (fka Winbond) SuperIO chips. There is a single driver for all devices. So, I have not done the usual split between the hardware driver and the bus functionality. Although, superio does act as a bus for devices that represent known non-standard functions of a SuperIO chip. The bus provides enumeration of child devices based on the hardcoded knowledge of such functions. The knowledge as extracted from datasheets and other drivers. As there is a single driver, I have not defined a kobj interface for it. So, its interface is currently made of simple functions. I think that we can the flexibility (and complications) when we actually need it. I am planning to convert nctgpio and wbwd to superio bus very soon. Also, I am working on itwd driver (watchdog in ITE SuperIO-s). Additionally, there is ithwm driver based on the reverted sensors import, but I am not sure how to integrate it given that we still lack any sensors interface. Discussed with: imp, jhb MFC after: 7 weeks Differential Revision: https://reviews.freebsd.org/D8175
2019-07-01 17:05:41 +00:00
_superio= superio
_tpm= tpm
2004-04-27 17:57:45 +00:00
_twa= twa
_vesa= vesa
_viawd= viawd
_virtio= virtio
_wpi= wpi
.if ${MK_SOURCELESS_UCODE} != "no"
_wpifw= wpifw
.endif
_x86bios= x86bios
.endif
2002-09-16 08:32:48 +00:00
.if ${MACHINE_CPUARCH} == "amd64"
_amdgpio= amdgpio
_ccp= ccp
_iavf= iavf
_ioat= ioat
_ixl= ixl
_nvdimm= nvdimm
2015-07-17 20:30:30 +00:00
_pms= pms
_qlxge= qlxge
_qlxgb= qlxgb
_sume= sume
_vmd= vmd
.if ${MK_SOURCELESS_UCODE} != "no"
_qlxgbe= qlxgbe
_qlnx= qlnx
.endif
_sfxge= sfxge
_sgx= sgx
_sgx_linux= sgx_linux
_smartpqi= smartpqi
.if ${MK_BHYVE} != "no" || defined(ALL_MODULES)
.if ${KERN_OPTS:MSMP}
_vmm= vmm
.endif
.endif
.endif
.if ${MACHINE_CPUARCH} == "i386"
# XXX some of these can move to the general case when de-i386'ed
# XXX some of these can move now, but are untested on other architectures.
_3dfx= 3dfx
_3dfx_linux= 3dfx_linux
.if ${MK_SOURCELESS_HOST} != "no"
_ce= ce
.endif
.if ${MK_SOURCELESS_HOST} != "no"
_cp= cp
.endif
_glxiic= glxiic
_glxsb= glxsb
_pcfclock= pcfclock
_pst= pst
_sbni= sbni
.endif
.if ${MACHINE_ARCH} == "armv7"
_cfi= cfi
_cpsw= cpsw
.endif
.if ${MACHINE_CPUARCH} == "powerpc"
_aacraid= aacraid
_agp= agp
_an= an
_cardbus= cardbus
_cbb= cbb
_cfi= cfi
_cpufreq= cpufreq
_exca= exca
2017-06-10 23:45:26 +00:00
_ffec= ffec
_nvd= nvd
_nvme= nvme
_pccard= pccard
_virtio= virtio
.endif
2003-01-09 16:37:37 +00:00
.if ${MACHINE_ARCH:Mpowerpc64*} != ""
_ipmi= ipmi
_ixl= ixl
_nvram= opal_nvram
.endif
.if ${MACHINE_CPUARCH} == "powerpc" && ${MACHINE_ARCH} != "powerpcspe"
Create a new MACHINE_ARCH for Freescale PowerPC e500v2 Summary: The Freescale e500v2 PowerPC core does not use a standard FPU. Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this. Additionaly, the SPE opcodes overlap with Altivec, so these are mutually exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was created with the same function set as in powerpc/powerpc/altivec.c, so it becomes effectively a drop-in replacement. setjmp/longjmp were modified to save the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by the SPE). Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not support double-precision floating point. Also, without a new MACHINE_ARCH it would be impossible to provide binary packages which utilize the SPE. Additionally, no work has been done to support ports, work is needed for this. This also means no newer gcc can yet be used. However, gcc's powerpc support has been refactored which would make adding a powerpcspe-freebsd target very easy. Test Plan: This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222 (P1022-based) board, compiled against the new ABI. Base system utilities (/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot multiuser. Reviewed By: bdrewery, imp Relnotes: yes Differential Revision: https://reviews.freebsd.org/D5683
2016-10-22 01:57:15 +00:00
# Don't build powermac_nvram for powerpcspe, it's never supported.
_nvram+= powermac_nvram
Create a new MACHINE_ARCH for Freescale PowerPC e500v2 Summary: The Freescale e500v2 PowerPC core does not use a standard FPU. Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this. Additionaly, the SPE opcodes overlap with Altivec, so these are mutually exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was created with the same function set as in powerpc/powerpc/altivec.c, so it becomes effectively a drop-in replacement. setjmp/longjmp were modified to save the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by the SPE). Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not support double-precision floating point. Also, without a new MACHINE_ARCH it would be impossible to provide binary packages which utilize the SPE. Additionally, no work has been done to support ports, work is needed for this. This also means no newer gcc can yet be used. However, gcc's powerpc support has been refactored which would make adding a powerpcspe-freebsd target very easy. Test Plan: This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222 (P1022-based) board, compiled against the new ABI. Base system utilities (/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot multiuser. Reviewed By: bdrewery, imp Relnotes: yes Differential Revision: https://reviews.freebsd.org/D5683
2016-10-22 01:57:15 +00:00
.endif
.if (${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64" || \
${MACHINE_ARCH:Marmv[67]*} != "" || ${MACHINE_CPUARCH} == "i386")
_cloudabi32= cloudabi32
.endif
.if ${MACHINE_CPUARCH} == "aarch64" || ${MACHINE_CPUARCH} == "amd64"
_cloudabi64= cloudabi64
.endif
.endif
.if ${MACHINE_ARCH:Marmv[67]*} != "" || ${MACHINE_CPUARCH} == "aarch64"
_bcm283x_clkman= bcm283x_clkman
_bcm283x_pwm= bcm283x_pwm
.endif
.if !(${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} < 110000)
# LLVM 10 crashes when building if_malo_pci.c, fixed in LLVM11:
# https://bugs.llvm.org/show_bug.cgi?id=44351
_malo= malo
.endif
SUBDIR+=${MODULES_EXTRA}
.for reject in ${WITHOUT_MODULES}
SUBDIR:= ${SUBDIR:N${reject}}
.endfor
# Calling kldxref(8) for each module is expensive.
2003-01-21 05:52:48 +00:00
.if !defined(NO_XREF)
2003-03-12 14:32:46 +00:00
.MAKEFLAGS+= -DNO_XREF
afterinstall: .PHONY
@if type kldxref >/dev/null 2>&1; then \
${ECHO} ${KLDXREF_CMD} ${DESTDIR}${KMODDIR}; \
${KLDXREF_CMD} ${DESTDIR}${KMODDIR}; \
fi
.endif
SUBDIR:= ${SUBDIR:u:O}
.include <bsd.subdir.mk>