| #
8cbe0dd5
|
| 26-Nov-2025 |
ykla <yklaxds@gmail.com> |
sys: RealTek -> Realtek
Realtek changed how it styled its name 25 or so years ago, but the old style persisted in many places. These products use the new styling in their datasheets.
Signed-off-by:
sys: RealTek -> Realtek
Realtek changed how it styled its name 25 or so years ago, but the old style persisted in many places. These products use the new styling in their datasheets.
Signed-off-by: ykla yklaxds@gmail.com Sponsored by: Chinese FreeBSD Community Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1901
show more ...
|
| #
c1eff1d7
|
| 09-Sep-2025 |
Olivier Certner <olce@FreeBSD.org> |
sys: NOTES: Fix comment for wlan_* devices; GENERIC*: Re-order 'wlan_tkip'
Fix the comment introducing the 'wlan_*' devices (AES-CCMP is missing) after introducing AES-GCMP.
While here, re-order th
sys: NOTES: Fix comment for wlan_* devices; GENERIC*: Re-order 'wlan_tkip'
Fix the comment introducing the 'wlan_*' devices (AES-CCMP is missing) after introducing AES-GCMP.
While here, re-order the devices in order of appearance of the related technologies.
No functional change (intended).
Reviewed by: adrian, emaste Fixes: 7bf82ea4fdda ("sys: add wlan_gcmp to GENERIC kernels as appropriate") MFC after: 3 days MFC to: stable/15 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52444
show more ...
|
| #
7bf82ea4
|
| 13-Mar-2025 |
Adrian Chadd <adrian@FreeBSD.org> |
sys: add wlan_gcmp to GENERIC kernels as appropriate
Add wlan_gcmp wherever CCMP is defined in kernel configs.
Differential Revision: https://reviews.freebsd.org/D49343 Reviewed by: bz, cy
|
| #
d68d1248
|
| 11-Jul-2024 |
Mark Johnston <markj@FreeBSD.org> |
arm: Add evdev to the TEGRA124 config
This is required for the kernel to link after commit 13d00a43cba4.
Fixes: 13d00a43cba4 ("conf: Add usbhid and hidbus to GENERIC* kernel configs")
|
| #
13d00a43
|
| 20-Jun-2024 |
Emmanuel Vadot <manu@FreeBSD.org> |
conf: Add usbhid and hidbus to GENERIC* kernel configs
Include the new unified HID stack by default in generic. This will allow us to migrate to the multi-stack hkbd and hms instead of relying on th
conf: Add usbhid and hidbus to GENERIC* kernel configs
Include the new unified HID stack by default in generic. This will allow us to migrate to the multi-stack hkbd and hms instead of relying on the older ukbd and ums which only work with USB. To test those drivers just add hw.usb.usbhid.enable=1 in loader.conf
Differential Revision: https://reviews.freebsd.org/D45658 Reviewed by: emaste, imp, wulf (all older version) Sponsored by: Beckhoff Automation GmbH & Co. KG
show more ...
|
| #
121be555
|
| 22-Feb-2024 |
Jessica Clarke <jrtc27@FreeBSD.org> |
arm: Set NEW_PCIB in DEFAULTS rather than a subset of kernel configs
All other architectures set NEW_PCIB in DEFAULTS, with arm being the one remaining straggler that only sets it for GENERIC and TE
arm: Set NEW_PCIB in DEFAULTS rather than a subset of kernel configs
All other architectures set NEW_PCIB in DEFAULTS, with arm being the one remaining straggler that only sets it for GENERIC and TEGRA124. ARMADA38X and ARMADAXP contain device pci but don't set NEW_PCIB, however GENERIC claims to support them and as part of that NEW_PCIB support was added to mv_pci, so these configs are most likely just stale. Other than NOTES that just leaves ALPINE as the one kernel with PCI support not covered by GENERIC, but al_pci is supported by arm64 which enables NEW_PCIB, and it's just a generic_pcie_fdt_driver with some fixup code to deal with quirks so should support PCI_RES_BUS just fine. Therefore it is believed that all in-tree kernel configs support NEW_PCIB in reality, and so let's take a step towards removing all the non-NEW_PCIB code by having it always-on everywhere.
Reviewed by: emaste, jhb, manu MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D43806
show more ...
|
| #
031beb4e
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
| #
34223f74
|
| 11-Jan-2022 |
Emmanuel Vadot <manu@FreeBSD.org> |
arm: conf: Remove options EXT_RESOURCES
It is now unused in kernel code.
MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D33837
|
| #
c1a14887
|
| 20-May-2021 |
Ceri Davies <ceri@FreeBSD.org> |
sys/*/conf/*, docs: fix links to handbook
While here, fix all links to older en_US.ISO8859-1 documentation in the src/ tree.
PR: 255026 Reported by: Michael Büker <freebsd@michael-bu
sys/*/conf/*, docs: fix links to handbook
While here, fix all links to older en_US.ISO8859-1 documentation in the src/ tree.
PR: 255026 Reported by: Michael Büker <freebsd@michael-bueker.de> Reviewed by: dbaio Approved by: blackend (mentor), re (gjb) MFC after: 10 days Differential Revision: https://reviews.freebsd.org/D30265
show more ...
|
| #
67de2db2
|
| 04-Oct-2020 |
Vladimir Kondratyev <wulf@FreeBSD.org> |
Factor-out hardware-independent part of USB HID support to new module
It will be used by the upcoming HID-over-i2C implementation. Should be no-op, except hid.ko module dependency is to be added to
Factor-out hardware-independent part of USB HID support to new module
It will be used by the upcoming HID-over-i2C implementation. Should be no-op, except hid.ko module dependency is to be added to affected drivers.
Reviewed by: hselasky, manu Differential revision: https://reviews.freebsd.org/D27867
show more ...
|
| #
a63915c2
|
| 28-Jul-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @r350386
Sponsored by: The FreeBSD Foundation
|
| #
1f3392ed
|
| 27-Jul-2019 |
Emmanuel Vadot <manu@FreeBSD.org> |
arm: Fix TEGRA124 kernel
Since r350162 device syscon is needed for sdhci driver. Add it to the config file.
Reported by: dim
|
| #
7f49ce7a
|
| 27-Jun-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @349476
Sponsored by: The FreeBSD Foundation
|
| #
c363b16c
|
| 21-Jun-2019 |
Conrad Meyer <cem@FreeBSD.org> |
sys: Remove DEV_RANDOM device option
Remove 'device random' from kernel configurations that reference it (most). Replace perhaps mistaken 'nodevice random' in two MIPS configs with 'options RANDOM_L
sys: Remove DEV_RANDOM device option
Remove 'device random' from kernel configurations that reference it (most). Replace perhaps mistaken 'nodevice random' in two MIPS configs with 'options RANDOM_LOADABLE' instead. Document removal in UPDATING; update NOTES and random.4.
Reviewed by: delphij, markm (previous version) Approved by: secteam(delphij) Differential Revision: https://reviews.freebsd.org/D19918
show more ...
|
| #
7648bc9f
|
| 13-May-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @347527
Sponsored by: The FreeBSD Foundation
|
| #
251a32b5
|
| 08-May-2019 |
Kyle Evans <kevans@FreeBSD.org> |
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
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
show more ...
|
| #
8cbe0dd5
|
| 26-Nov-2025 |
ykla <yklaxds@gmail.com> |
sys: RealTek -> Realtek
Realtek changed how it styled its name 25 or so years ago, but the old style persisted in many places. These products use the new styling in their datasheets.
Signed-off-by:
sys: RealTek -> Realtek
Realtek changed how it styled its name 25 or so years ago, but the old style persisted in many places. These products use the new styling in their datasheets.
Signed-off-by: ykla yklaxds@gmail.com Sponsored by: Chinese FreeBSD Community Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1901
show more ...
|
| #
c1eff1d7
|
| 09-Sep-2025 |
Olivier Certner <olce@FreeBSD.org> |
sys: NOTES: Fix comment for wlan_* devices; GENERIC*: Re-order 'wlan_tkip'
Fix the comment introducing the 'wlan_*' devices (AES-CCMP is missing) after introducing AES-GCMP.
While here, re-order th
sys: NOTES: Fix comment for wlan_* devices; GENERIC*: Re-order 'wlan_tkip'
Fix the comment introducing the 'wlan_*' devices (AES-CCMP is missing) after introducing AES-GCMP.
While here, re-order the devices in order of appearance of the related technologies.
No functional change (intended).
Reviewed by: adrian, emaste Fixes: 7bf82ea4fdda ("sys: add wlan_gcmp to GENERIC kernels as appropriate") MFC after: 3 days MFC to: stable/15 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52444
show more ...
|
| #
7bf82ea4
|
| 13-Mar-2025 |
Adrian Chadd <adrian@FreeBSD.org> |
sys: add wlan_gcmp to GENERIC kernels as appropriate
Add wlan_gcmp wherever CCMP is defined in kernel configs.
Differential Revision: https://reviews.freebsd.org/D49343 Reviewed by: bz, cy
|
| #
d68d1248
|
| 11-Jul-2024 |
Mark Johnston <markj@FreeBSD.org> |
arm: Add evdev to the TEGRA124 config
This is required for the kernel to link after commit 13d00a43cba4.
Fixes: 13d00a43cba4 ("conf: Add usbhid and hidbus to GENERIC* kernel configs")
|
| #
13d00a43
|
| 20-Jun-2024 |
Emmanuel Vadot <manu@FreeBSD.org> |
conf: Add usbhid and hidbus to GENERIC* kernel configs
Include the new unified HID stack by default in generic. This will allow us to migrate to the multi-stack hkbd and hms instead of relying on th
conf: Add usbhid and hidbus to GENERIC* kernel configs
Include the new unified HID stack by default in generic. This will allow us to migrate to the multi-stack hkbd and hms instead of relying on the older ukbd and ums which only work with USB. To test those drivers just add hw.usb.usbhid.enable=1 in loader.conf
Differential Revision: https://reviews.freebsd.org/D45658 Reviewed by: emaste, imp, wulf (all older version) Sponsored by: Beckhoff Automation GmbH & Co. KG
show more ...
|
| #
121be555
|
| 22-Feb-2024 |
Jessica Clarke <jrtc27@FreeBSD.org> |
arm: Set NEW_PCIB in DEFAULTS rather than a subset of kernel configs
All other architectures set NEW_PCIB in DEFAULTS, with arm being the one remaining straggler that only sets it for GENERIC and TE
arm: Set NEW_PCIB in DEFAULTS rather than a subset of kernel configs
All other architectures set NEW_PCIB in DEFAULTS, with arm being the one remaining straggler that only sets it for GENERIC and TEGRA124. ARMADA38X and ARMADAXP contain device pci but don't set NEW_PCIB, however GENERIC claims to support them and as part of that NEW_PCIB support was added to mv_pci, so these configs are most likely just stale. Other than NOTES that just leaves ALPINE as the one kernel with PCI support not covered by GENERIC, but al_pci is supported by arm64 which enables NEW_PCIB, and it's just a generic_pcie_fdt_driver with some fixup code to deal with quirks so should support PCI_RES_BUS just fine. Therefore it is believed that all in-tree kernel configs support NEW_PCIB in reality, and so let's take a step towards removing all the non-NEW_PCIB code by having it always-on everywhere.
Reviewed by: emaste, jhb, manu MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D43806
show more ...
|
| #
031beb4e
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
| #
34223f74
|
| 11-Jan-2022 |
Emmanuel Vadot <manu@FreeBSD.org> |
arm: conf: Remove options EXT_RESOURCES
It is now unused in kernel code.
MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D33837
|
| #
c1a14887
|
| 20-May-2021 |
Ceri Davies <ceri@FreeBSD.org> |
sys/*/conf/*, docs: fix links to handbook
While here, fix all links to older en_US.ISO8859-1 documentation in the src/ tree.
PR: 255026 Reported by: Michael Büker <freebsd@michael-bu
sys/*/conf/*, docs: fix links to handbook
While here, fix all links to older en_US.ISO8859-1 documentation in the src/ tree.
PR: 255026 Reported by: Michael Büker <freebsd@michael-bueker.de> Reviewed by: dbaio Approved by: blackend (mentor), re (gjb) MFC after: 10 days Differential Revision: https://reviews.freebsd.org/D30265
show more ...
|