History log of /freebsd/sys/modules/Makefile (Results 151 – 175 of 8759)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 97e25132 11-May-2020 John Baldwin <jhb@FreeBSD.org>

Remove ubsec(4).

This driver was previously marked for deprecation in r360710.

Approved by: csprng (cem, gordon, delphij)
Relnotes: yes
Sponsored by: Chelsio Communications
Differential Revision: h

Remove ubsec(4).

This driver was previously marked for deprecation in r360710.

Approved by: csprng (cem, gordon, delphij)
Relnotes: yes
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D24766

show more ...


# 732a02b4 17-Apr-2020 Gleb Smirnoff <glebius@FreeBSD.org>

Split XDR into separate kernel module. Make krpc depend on xdr.

Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D24408


# 8de97f39 09-Apr-2020 Rick Macklem <rmacklem@FreeBSD.org>

Remove the old NFS lock device driver that uses Giant.

This NFS lock device driver was replaced by the kernel NLM around FreeBSD7 and
has not normally been used since then.
To use it, the kernel had

Remove the old NFS lock device driver that uses Giant.

This NFS lock device driver was replaced by the kernel NLM around FreeBSD7 and
has not normally been used since then.
To use it, the kernel had to be built without "options NFSLOCKD" and
the nfslockd.ko had to be deleted as well.
Since it uses Giant and is no longer used, this patch removes it.

With this device driver removed, there is now a lot of unused code
in the userland rpc.lockd. That will be removed on a future commit.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D22933

show more ...


# c3079787 31-Mar-2020 Takanori Watanabe <takawata@FreeBSD.org>

Add Platform Controller Hub built-in thermal management device driver.

Differential Revision: https://reviews.freebsd.org/D24077


# 2733d8c9 20-Mar-2020 Ed Maste <emaste@FreeBSD.org>

retire cx,ctau drivers

The devices supported by these drivers are obsolete ISA cards, and the
sync serial protocols they supported are essentially obsolete too.

Sponsored by: The FreeBSD Foundation


# c5568ba0 12-Mar-2020 Leandro Lupori <luporl@FreeBSD.org>

Enable ixl device on PowerPC64

The ixl driver now works on PowerPC64 and may be compiled in-kernel and
as a module.

Reviewed by: alfredo, erj
Sponsored by: Eldorado Research Institute (eldorado.org

Enable ixl device on PowerPC64

The ixl driver now works on PowerPC64 and may be compiled in-kernel and
as a module.

Reviewed by: alfredo, erj
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D23974

show more ...


# d8c51c6f 05-Mar-2020 Leandro Lupori <luporl@FreeBSD.org>

[aacraid] Port driver to big-endian

Port aacraid driver to big-endian (BE) hosts.

The immediate goal of this change is to make it possible to use the
aacraid driver on PowerPC64 machines that have

[aacraid] Port driver to big-endian

Port aacraid driver to big-endian (BE) hosts.

The immediate goal of this change is to make it possible to use the
aacraid driver on PowerPC64 machines that have Adaptec Series 8 SAS
controllers.

Adapters supported by this driver expect FIB contents in little-endian
(LE) byte order. All FIBs have a fixed header part as well as a data
part that depends on the command being issued to the controller.

In this way, on BE hosts, the FIB header and all FIB data structures
used in aacraid.c and aacraid_cam.c need to be converted to LE before
being sent to the adapter and converted to BE when coming from it.

The functions to convert each struct are on aacraid_endian.c.
For little-endian (LE) targets, they are macros that expand
to nothing.
In some cases, when only a few fields of a large structure are used,
the fields are converted inline, by the code using them.

PR: 237463
Reviewed by: jhibbits
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D23887

show more ...


# 79514055 01-Mar-2020 Warner Losh <imp@FreeBSD.org>

Remove bktr(4)

Remove the brooktree driver as discussed on arch@. Bump FreeBSD version to
1300082, though I doubt anything will care.

Relnote: yes


# 2ec8d574 16-Feb-2020 Konstantin Belousov <kib@FreeBSD.org>

Fix build of some modules for some kernel configs.

Namely, vmm.ko cannot be compiled without 'option SMP', the code uses
IPIs and LAPIC.
Recently systrace was forced over any configs, check for KDTR

Fix build of some modules for some kernel configs.

Namely, vmm.ko cannot be compiled without 'option SMP', the code uses
IPIs and LAPIC.
Recently systrace was forced over any configs, check for KDTRACE_HOOK
before compiling the dtrace/ modules.

Reviewed by: markj
Discussed with: mjg
Tested by: se (previous version)
Sponsored by: The FreeBSD Foundation (kib)
Differential revision: https://reviews.freebsd.org/D23699

show more ...


# 58aa35d4 03-Feb-2020 Warner Losh <imp@FreeBSD.org>

Remove sparc64 kernel support

Remove all sparc64 specific files
Remove all sparc64 ifdefs
Removee indireeect sparc64 ifdefs


# 43c2dac0 02-Feb-2020 Ed Maste <emaste@FreeBSD.org>

Move ce enable to SOURCELESS_HOST

ce contains obfuscated code that runs on the host's processor


# 51691e26 02-Feb-2020 Warner Losh <imp@FreeBSD.org>

Remove vpo.4

The Parallel Port SCSI adapter was interesting for 100MB ZIP drives, but is no
longer used or maintained. Remove it from the tree.

The Parallel Port microsequencer (microseq.9) is now

Remove vpo.4

The Parallel Port SCSI adapter was interesting for 100MB ZIP drives, but is no
longer used or maintained. Remove it from the tree.

The Parallel Port microsequencer (microseq.9) is now mostly unused in the tree,
but remains. PPI still refrences it, but doesn't use its full functionality.

Relnotes: Yes
Reviewed by: rgrimes@, Ihor Antonov
Discussed on: arch@
Differential Revision: https://reviews.freebsd.org/D23389

show more ...


Revision tags: vendor/sqlite3/sqlite-3310000, vendor/Juniper/libxo/1.4.0, vendor/llvm-project/llvmorg-10-init-17538-gd11abddb32f, vendor/llvm-project/llvmorg-10-init-17468-gc4a134a5107, vendor/llvm-project/llvmorg-10-init-17466-ge26a78e7085
# d4633a9e 16-Jan-2020 Leandro Lupori <luporl@FreeBSD.org>

[PowerPC64] Enable virtio drivers

This enables virtio modules on PowerPC* target.
On PowerPC64, drivers are also kernel builtin.

QEMU currently needs to be patched to in order to work on LE hosts d

[PowerPC64] Enable virtio drivers

This enables virtio modules on PowerPC* target.
On PowerPC64, drivers are also kernel builtin.

QEMU currently needs to be patched to in order to work on LE hosts due to known
issue affecting pre-1.0 (legacy) virtio drivers.

The patch was submitted to QEMU mail list by @afscoelho_gmail.com, available at
https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg01496.html

Submitted by: Alfredo Dal'Ava Junior <alfredo.junior@eldorado.org.br>
Reviewed by: luporl
Differential Revision: https://reviews.freebsd.org/D22833

show more ...


Revision tags: vendor/acpica/20200110, vendor/openssl/1.0.2u, vendor/libarchive/3.4.1, vendor/unbound/1.9.6, vendor/llvm-project/llvmorg-9.0.1, vendor/llvm-project/llvmorg-10-init-8157-g186155b89c2, vendor/llvm-project/trunk-r375505, vendor/acpica/20191213, vendor/device-tree/5.4
# 33ce28d1 28-Nov-2019 Scott Long <scottl@FreeBSD.org>

Remove the trm(4) driver

Differential Revision: https://reviews.freebsd.org/D22575


# 849aef49 21-Nov-2019 Andrew Turner <andrew@FreeBSD.org>

Port the NetBSD KCSAN runtime to FreeBSD.

Update the NetBSD Kernel Concurrency Sanitizer (KCSAN) runtime to work in
the FreeBSD kernel. It is a useful tool for finding data races between
threads exe

Port the NetBSD KCSAN runtime to FreeBSD.

Update the NetBSD Kernel Concurrency Sanitizer (KCSAN) runtime to work in
the FreeBSD kernel. It is a useful tool for finding data races between
threads executing on different CPUs.

This can be enabled by enabling KCSAN in the kernel config, or by using the
GENERIC-KCSAN amd64 kernel. It works on amd64 and arm64, however the later
needs a compiler change to allow -fsanitize=thread that KCSAN uses.

Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22315

show more ...


Revision tags: vendor/openresolv/3.9.2, vendor/file/5.37, vendor/Juniper/libxo/1.3.1, vendor/Juniper/libxo/1.3.0, vendor/NetBSD/blacklist/20191106, vendor/zstd/1.4.4, vendor/sqlite3/sqlite-3300100, release/12.1.0, upstream/12.1.0, vendor/llvm-openmp/openmp-trunk-r375505, vendor/lldb/lldb-trunk-r375505, vendor/lld/lld-trunk-r375505, vendor/llvm-libunwind/libunwind-trunk-r375505, vendor/libc++/libc++-trunk-r375505, vendor/compiler-rt/compiler-rt-trunk-r375505, vendor/clang/clang-trunk-r375505, vendor/llvm/llvm-trunk-r375505, vendor/tcsh/6.21.00-83c5be0, vendor/acpica/20191018
# 88f8e098 16-Oct-2019 Andriy Gapon <avg@FreeBSD.org>

attach itwd to the module build on x86

MFC after: 19 days
X-MFC with: r353647


Revision tags: vendor/opencsd/a1961c91b02a92f3c6ed8b145c636ac4c5565aca, vendor/processor-trace/892e12c5a27bda5806d1e63269986bb4171b5a8b
# f2521a76 10-Oct-2019 Doug Ambrisko <ambrisko@FreeBSD.org>

This driver attaches to the Intel VMD drive and connects a new PCI domain
starting at the max. domain, and then work down. Then existing FreeBSD
drivers will attach. Interrupt routing from the VMD

This driver attaches to the Intel VMD drive and connects a new PCI domain
starting at the max. domain, and then work down. Then existing FreeBSD
drivers will attach. Interrupt routing from the VMD MSI-X to the NVME
drive is not well known, so any interrupt is sent to all children that
register.

VROC used Intel meta data so graid(8) works with it. However, graid(8)
supports RAID 0,1,10 for read and write. I have some early code to
support writes with RAID 5. Note that RAID 5 can have life issues
with SSDs since it can cause write amplification from updating the parity
data.

Hot plug support needs a change to skip the following check to work:
if (pcib_request_feature(dev, PCI_FEATURE_HP) != 0) {
in sys/dev/pci/pci_pci.c.

Looked at by: imp, rpokala, bcr
Differential Revision: https://reviews.freebsd.org/D21383

show more ...


Revision tags: vendor/tcsh/6.21.00, vendor/tcpdump/4.9.3, vendor/libpcap/1.9.1, vendor/device-tree/5.3, vendor/device-tree/5.2, vendor/lldb/lldb-release_900-r372316, vendor/clang/clang-release_900-r372316, vendor/llvm/llvm-release_900-r372316
# 1c56203b 14-Sep-2019 Justin Hibbits <jhibbits@FreeBSD.org>

powerpc64/powernv: Add opal NVRAM driver for PowerNV systems

Add a very basic NVRAM driver for OPAL which can be used by the IBM
powerpc-utils nvram utility, not to be confused with the base nvram u

powerpc64/powernv: Add opal NVRAM driver for PowerNV systems

Add a very basic NVRAM driver for OPAL which can be used by the IBM
powerpc-utils nvram utility, not to be confused with the base nvram utility,
which only operates on powermac_nvram.

The IBM utility handles all partitions itself, treating the nvram device as
a plain store.

An alternative would be to manage partitions in the kernel, and augment the
base nvram utility to deal with different backing stores, but that
complicates the driver significantly. Instead, present the same interface
IBM's utlity expects, and we get the usage for free.

Tested by: bdragon

show more ...


# 6659d8e7 12-Sep-2019 Ed Maste <emaste@FreeBSD.org>

arm64: connect Linuxulator to the build

More work needs to be done, but it is capable of running basic
statically or dynamically linked Linux/arm64 binaries.

Relnotes: Yes
Sponsored by: The FreeBSD

arm64: connect Linuxulator to the build

More work needs to be done, but it is capable of running basic
statically or dynamically linked Linux/arm64 binaries.

Relnotes: Yes
Sponsored by: The FreeBSD Foundation

show more ...


Revision tags: vendor/tzdata/tzdata2019c, vendor/openssl/1.0.2t, vendor/openssl/1.1.1d, vendor/NetBSD/libedit/2019-09-10, vendor/lld/lld-release_90-r371301, vendor/lld/lld-release_900-r372316, vendor/clang/clang-release_90-r371301, vendor/llvm/llvm-release_90-r371301, vendor/lld/lld-release_90-r370514, vendor/libc++/libc++-release_90-r370514, vendor/libc++/libc++-release_90-r371301, vendor/libc++/libc++-release_900-r372316, vendor/compiler-rt/compiler-rt-release_90-r370514, vendor/compiler-rt/compiler-rt-release_90-r371301, vendor/compiler-rt/compiler-rt-release_900-r372316, vendor/clang/clang-release_90-r370514, vendor/llvm/llvm-release_90-r370514
# b2e60773 27-Aug-2019 John Baldwin <jhb@FreeBSD.org>

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 tr

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

show more ...


Revision tags: vendor/lldb/lldb-trunk-r366426, vendor/wpa/2.9, vendor/lldb/lldb-release_90-r369369, vendor/lldb/lldb-release_90-r370514, vendor/lldb/lldb-release_90-r371301, vendor/lld/lld-release_90-r369369, vendor/libc++/libc++-release_90-r369369, vendor/compiler-rt/compiler-rt-release_90-r369369, vendor/clang/clang-release_90-r369369, vendor/llvm/llvm-release_90-r369369, vendor/llvm-openmp/openmp-release_90-r369369, vendor/llvm-openmp/openmp-release_90-r370514, vendor/llvm-openmp/openmp-release_90-r371301, vendor/llvm-openmp/openmp-release_900-r372316, vendor/llvm-openmp/openmp-trunk-r366426, vendor/lld/lld-trunk-r366426, vendor/llvm-libunwind/libunwind-release_90-r369369, vendor/llvm-libunwind/libunwind-release_90-r370514, vendor/llvm-libunwind/libunwind-release_90-r371301, vendor/llvm-libunwind/libunwind-release_900-r372316, vendor/llvm-libunwind/libunwind-trunk-r366426, vendor/libc++/libc++-trunk-r366426, vendor/compiler-rt/compiler-rt-trunk-r366426, vendor/clang/clang-trunk-r366426, vendor/llvm/llvm-trunk-r366426, vendor/acpica/20190816
# 63ac15ab 15-Aug-2019 Alexander Motin <mav@FreeBSD.org>

Add NTB modules to i386 build.

There is no reason why NTB should not be usable on i386 if memory windows
are small enough.


Revision tags: vendor/bzip2/1.0.8, vendor/zstd/1.4.2, vendor/zstd/1.4.1, vendor/mandoc/20190723, vendor/libcxxrt/2019-07-26-f96846efbfd508f66d91fcbbef5dd808947c7f6d, vendor/llvm-libunwind/libunwind-release_801-r366581, vendor/clang/clang-release_801-r366581, vendor/sqlite3/sqlite-3290000, vendor/acpica/20190703, vendor/llvm-openmp/openmp-release_80-r364487, vendor/llvm-openmp/openmp-release_801-r366581, vendor/lldb/lldb-release_80-r364487, vendor/lldb/lldb-release_801-r366581, vendor/lld/lld-release_80-r364487, vendor/lld/lld-release_801-r366581, vendor/llvm-libunwind/libunwind-release_80-r364487, vendor/clang/clang-release_80-r364487, release/11.3.0, upstream/11.3.0, vendor/tzdata/tzdata2019b
# e3722b78 01-Jul-2019 Andriy Gapon <avg@FreeBSD.org>

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.

Whi

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

show more ...


Revision tags: vendor/unbound/1.9.2, vendor/unbound/1.9.1, vendor/elftoolchain/elftoolchain-r3769, vendor/less/v551, vendor/bzip2/1.0.7
# f5a95d9a 25-Jun-2019 Warner Losh <imp@FreeBSD.org>

Remove NAND and NANDFS support

NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance

Remove NAND and NANDFS support

NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance and just for ancient arm
hardware. NAND parts have evolved significantly from this early work
and little to none of it would be relevant should someone need to
update to support raw nand. This code has been off by default for
years and has violated the vnode protocol leading to panics since it
was committed.

Numerous posts to arch@ and other locations have found no actual users
for this software.

Relnotes: Yes
No Objection From: arch@
Differential Revision: https://reviews.freebsd.org/D20745

show more ...


# e108c3df 16-Jun-2019 Ian Lepore <ian@FreeBSD.org>

Add module makefiles for pwm.


Revision tags: vendor/libarchive/3.4.0, vendor/lldb/lldb-release_80-r363030, vendor/lld/lld-release_80-r363030, vendor/llvm-libunwind/libunwind-release_80-r363030, vendor/libc++/libc++-release_80-r363030, vendor/libc++/libc++-release_80-r364487, vendor/libc++/libc++-release_801-r366581, vendor/compiler-rt/compiler-rt-release_80-r363030, vendor/compiler-rt/compiler-rt-release_80-r364487, vendor/compiler-rt/compiler-rt-release_801-r366581, vendor/clang/clang-release_80-r363030, vendor/llvm/llvm-release_80-r363030, vendor/llvm/llvm-release_80-r364487, vendor/llvm/llvm-release_801-r366581
# 67ca7330 08-Jun-2019 Bjoern A. Zeeb <bz@FreeBSD.org>

Add SDIO support.

Add a CAM-Newbus SDIO support module. This works provides a newbus
infrastructure for device drivers wanting to use SDIO. On the lower end
while it is connected by newbus to SDHC

Add SDIO support.

Add a CAM-Newbus SDIO support module. This works provides a newbus
infrastructure for device drivers wanting to use SDIO. On the lower end
while it is connected by newbus to SDHCI, it talks CAM using the MMCCAM
framework to get to it.

This also duplicates the usbdevs framework to equally create sdiodev
header files with #defines for "vendors" and "products".

Submitted by: kibab (initial work, see https://reviews.freebsd.org/D12467)
Reviewed by: kibab, imp (comments on earlier version)
MFC after: 6 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19749

show more ...


12345678910>>...351