#
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 ...
|