u2f(4): Invert U2F_MAKE_UHID_ALIAS kernel build option

This makes non-GENERIC kernel configs easier to maintain.

Requested by: glebius
MFC after: 2 days

u2f(4): a HID driver for FIDO/U2F security keys

While FIDO/U2F keys were already supported by the generic uhid(4) and
hidraw(4) drivers, this driver adds some additional features an does
steps to ti

u2f(4): a HID driver for FIDO/U2F security keys

While FIDO/U2F keys were already supported by the generic uhid(4) and
hidraw(4) drivers, this driver adds some additional features an does
steps to tighten the security of FIDO/U2F access.

- It automatically loads through devd.
- Automatically enables HQ_NO_READAHEAD for FIDO/U2F devices.
- Implements only miminum set of features.
- Do not requires external devfs configuration to set character device
permissions.
- Names character device as u2f/# to make possible capsicum or any
other pledge()-style sandboxing.

PR: 265528
Differential Revision: https://reviews.freebsd.org/D51612

show more ...

arm64: turn on IEEE80211 debugging and IEEE80211_SUPPORT_MESH too

Like we do for other architectures, add IEEE80211_SUPPORT_MESH support
to the kernel config on arm64.

Like we do with, e.g., USB_DE

arm64: turn on IEEE80211 debugging and IEEE80211_SUPPORT_MESH too

Like we do for other architectures, add IEEE80211_SUPPORT_MESH support
to the kernel config on arm64.

Like we do with, e.g., USB_DEBUG, add IEEE80211_DEBUG too on main
(std.nodebug will turn this off).

Sponsored by: The FreeBSD Foundation
X-MFC: no
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D45817

show more ...

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

arm64: Add netmap(4) to default kernel config

Allows the development, testing and deployment of netmap(4)-based code
on arm64 without having to recompile the kernel. netmap(4) is already
in the amd

arm64: Add netmap(4) to default kernel config

Allows the development, testing and deployment of netmap(4)-based code
on arm64 without having to recompile the kernel. netmap(4) is already
in the amd64 and powerpc64 default configs, so it does not seem
unreasonable to also provide it on arm64 by default.

Note that netmap(4) is useful even on systems without NIC that fully
support it.

Reviewed by: vmaffione
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D43702

show more ...

Add an Armv8 rndr random number provider

Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy

Add an Armv8 rndr random number provider

Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy pool before reading a random number. Both registers
will set the condition flags to tell the caller they can't produce a
random number in a reasonable amount of time.

Without a signal to reseed the entropy pool use the latter register
to provide random numbers to the kernel pool. If at a later time we
had a way to tell the provider if it needs to reseed or not we could
use the former.

On an Amazon AWS Graviton3 VM this never failed, however this may not
be the case on low end CPUs so retry reading the random number 10 times
before returning an error.

Reviewed by: imp, delphij (csprng)
Sponsored by: The FreeBSD Foundation
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D35411

show more ...

Add a simple-framebuffer vt driver

This allows us to support this hardware and, in the future, use clocks
so they are enabled past the initial kernel boot process.

Reviewed by: ray
Differential Rev

Add a simple-framebuffer vt driver

This allows us to support this hardware and, in the future, use clocks
so they are enabled past the initial kernel boot process.

Reviewed by: ray
Differential Revision: https://reviews.freebsd.org/D30103

show more ...

arm64 kernel config: clean up whitespace

Most options in kernel config files use "options<space><tab>OPTION".
This allows the option to be commented out without shifting columns.
A few options had t

arm64 kernel config: clean up whitespace

Most options in kernel config files use "options<space><tab>OPTION".
This allows the option to be commented out without shifting columns.
A few options had two tabs, and some had spaces. Make them consistent.

show more ...

arm64: Move device scmi to std.arm

The scmi driver in its current form requires the arm_doorbell
driver to communicate with the firmware.
The arm_doorbell is only found in ARM Juno reference board (

arm64: Move device scmi to std.arm

The scmi driver in its current form requires the arm_doorbell
driver to communicate with the firmware.
The arm_doorbell is only found in ARM Juno reference board (and
apparently on Morello too).
If we want to use scmi on other platform (like some rockchip or imx
soc), the driver needs to be updated to support svc/shmem communication
with the firmware.
For now since it can be only used with arm_doorbell move the device to
std.arm otherwise kernel configs like ALLWINNER or ROCKCHIP fails to build.

Reviewed by: br, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37953

show more ...

Add support for ARM System Control and Management Interface (SCMI) v3.1.

The SCMI specification describes a set of standard interfaces for power,
performance and system management.

SCMI is extensib

Add support for ARM System Control and Management Interface (SCMI) v3.1.

The SCMI specification describes a set of standard interfaces for power,
performance and system management.

SCMI is extensible and provides interfaces to access functions which are
often implemented in firmwares in the System Control Processor (SCP).

This implements Shared Memory-based transfer, which is one of the ways on
how messages are exchanged between agents and the platform.

This includes a driver for ARM Message Handling Unit (MHU) Doorbell, which
is a mechanism that the caller can use to alert the callee of the presence
of a message.

The support implements clock management interface. For instance this allows
us to control HDMI pixel clock on ARM Morello Board.

Tested on ARM Morello Board.

Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D37316
Reviewed by: manu
Sponsored by: UKRI

show more ...

Remove the hyperv option from std.dev

It's already in std.hyperv and we don't need to repeat it here.

arm64: Hyper-V: enablement for ARM64 in Hyper-V (Part 3, final)

This is the last part for ARM64 Hyper-V enablement. This includes
commone files and make file changes to enable the ARM64 FreeBSD
gues

arm64: Hyper-V: enablement for ARM64 in Hyper-V (Part 3, final)

This is the last part for ARM64 Hyper-V enablement. This includes
commone files and make file changes to enable the ARM64 FreeBSD
guest on Hyper-V. With this patch, it should be able to build
the ARM64 image and install it on Hyper-V.

Reviewed by: emaste, andrew, whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D36744

show more ...

arm64: conf: Remove options EXT_RESOURCES

It is now unused in kernel code.

MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33836

arm64: Add per SoC family kernel config

There is multiple reason for this :
- This makes it easier to see which driver is needed for each SoC
- This makes it easier to create a custom config for one

arm64: Add per SoC family kernel config

There is multiple reason for this :
- This makes it easier to see which driver is needed for each SoC
- This makes it easier to create a custom config for one SoC
- This really reduce boot time (which some people might want)

Some explaination about the files :
- std.arm64 contains all standard kernel option
- std.dev contains all the standard kernel devices
- std.<soc> contains all drivers needed to boot on this SoC family
- <SOC> includes std.arm64, std.dev and std.<soc>
- GENERIC includes std.arm64, std.dev and all std.<soc>

Sponsored by: Diablotin Systems
MFC After: 2 months
Reviewed by: mmel, cognet, imp
Differential Revision: https://reviews.freebsd.org/D30474

show more ...

u2f(4): Invert U2F_MAKE_UHID_ALIAS kernel build option

This makes non-GENERIC kernel configs easier to maintain.

Requested by: glebius
MFC after: 2 days

u2f(4): a HID driver for FIDO/U2F security keys

While FIDO/U2F keys were already supported by the generic uhid(4) and
hidraw(4) drivers, this driver adds some additional features an does
steps to ti

u2f(4): a HID driver for FIDO/U2F security keys

While FIDO/U2F keys were already supported by the generic uhid(4) and
hidraw(4) drivers, this driver adds some additional features an does
steps to tighten the security of FIDO/U2F access.

- It automatically loads through devd.
- Automatically enables HQ_NO_READAHEAD for FIDO/U2F devices.
- Implements only miminum set of features.
- Do not requires external devfs configuration to set character device
permissions.
- Names character device as u2f/# to make possible capsicum or any
other pledge()-style sandboxing.

PR: 265528
Differential Revision: https://reviews.freebsd.org/D51612

show more ...

arm64: turn on IEEE80211 debugging and IEEE80211_SUPPORT_MESH too

Like we do for other architectures, add IEEE80211_SUPPORT_MESH support
to the kernel config on arm64.

Like we do with, e.g., USB_DE

arm64: turn on IEEE80211 debugging and IEEE80211_SUPPORT_MESH too

Like we do for other architectures, add IEEE80211_SUPPORT_MESH support
to the kernel config on arm64.

Like we do with, e.g., USB_DEBUG, add IEEE80211_DEBUG too on main
(std.nodebug will turn this off).

Sponsored by: The FreeBSD Foundation
X-MFC: no
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D45817

show more ...

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

arm64: Add netmap(4) to default kernel config

Allows the development, testing and deployment of netmap(4)-based code
on arm64 without having to recompile the kernel. netmap(4) is already
in the amd

arm64: Add netmap(4) to default kernel config

Allows the development, testing and deployment of netmap(4)-based code
on arm64 without having to recompile the kernel. netmap(4) is already
in the amd64 and powerpc64 default configs, so it does not seem
unreasonable to also provide it on arm64 by default.

Note that netmap(4) is useful even on systems without NIC that fully
support it.

Reviewed by: vmaffione
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D43702

show more ...

Add an Armv8 rndr random number provider

Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy

Add an Armv8 rndr random number provider

Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy pool before reading a random number. Both registers
will set the condition flags to tell the caller they can't produce a
random number in a reasonable amount of time.

Without a signal to reseed the entropy pool use the latter register
to provide random numbers to the kernel pool. If at a later time we
had a way to tell the provider if it needs to reseed or not we could
use the former.

On an Amazon AWS Graviton3 VM this never failed, however this may not
be the case on low end CPUs so retry reading the random number 10 times
before returning an error.

Reviewed by: imp, delphij (csprng)
Sponsored by: The FreeBSD Foundation
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D35411

show more ...

Add a simple-framebuffer vt driver

This allows us to support this hardware and, in the future, use clocks
so they are enabled past the initial kernel boot process.

Reviewed by: ray
Differential Rev

Add a simple-framebuffer vt driver

This allows us to support this hardware and, in the future, use clocks
so they are enabled past the initial kernel boot process.

Reviewed by: ray
Differential Revision: https://reviews.freebsd.org/D30103

show more ...

arm64 kernel config: clean up whitespace

Most options in kernel config files use "options<space><tab>OPTION".
This allows the option to be commented out without shifting columns.
A few options had t

arm64 kernel config: clean up whitespace

Most options in kernel config files use "options<space><tab>OPTION".
This allows the option to be commented out without shifting columns.
A few options had two tabs, and some had spaces. Make them consistent.

show more ...

arm64: Move device scmi to std.arm

The scmi driver in its current form requires the arm_doorbell
driver to communicate with the firmware.
The arm_doorbell is only found in ARM Juno reference board (

arm64: Move device scmi to std.arm

The scmi driver in its current form requires the arm_doorbell
driver to communicate with the firmware.
The arm_doorbell is only found in ARM Juno reference board (and
apparently on Morello too).
If we want to use scmi on other platform (like some rockchip or imx
soc), the driver needs to be updated to support svc/shmem communication
with the firmware.
For now since it can be only used with arm_doorbell move the device to
std.arm otherwise kernel configs like ALLWINNER or ROCKCHIP fails to build.

Reviewed by: br, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37953

show more ...

Add support for ARM System Control and Management Interface (SCMI) v3.1.

The SCMI specification describes a set of standard interfaces for power,
performance and system management.

SCMI is extensib

Add support for ARM System Control and Management Interface (SCMI) v3.1.

The SCMI specification describes a set of standard interfaces for power,
performance and system management.

SCMI is extensible and provides interfaces to access functions which are
often implemented in firmwares in the System Control Processor (SCP).

This implements Shared Memory-based transfer, which is one of the ways on
how messages are exchanged between agents and the platform.

This includes a driver for ARM Message Handling Unit (MHU) Doorbell, which
is a mechanism that the caller can use to alert the callee of the presence
of a message.

The support implements clock management interface. For instance this allows
us to control HDMI pixel clock on ARM Morello Board.

Tested on ARM Morello Board.

Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D37316
Reviewed by: manu
Sponsored by: UKRI

show more ...

Remove the hyperv option from std.dev

It's already in std.hyperv and we don't need to repeat it here.