src/sys/arm, branch releng/14.2 FreeBSD source tree sys: Use the new arm_smccc_invoke macros 2024-10-21T15:03:27+00:00 Andrew Turner andrew@FreeBSD.org 2024-10-14T14:33:51+00:00 78b308e5a4a15f1dbf52c289b1f1ad4f4b980184 Simplify the calls into the SMCCC firmware with the new arm_smccc_invoke* macros. Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D46987 (cherry picked from commit b9cd72b06d795a8c7b39df1f520e866ad7f11aa8) 
Simplify the calls into the SMCCC firmware with the new
arm_smccc_invoke* macros.

Sponsored by:	Arm Ltd
Differential Revision:	https://reviews.freebsd.org/D46987

(cherry picked from commit b9cd72b06d795a8c7b39df1f520e866ad7f11aa8)
sys: add conf/std.debug, generic debugging options 2024-10-09T08:44:35+00:00 Kristof Provost kp@FreeBSD.org 2024-04-23T21:11:24+00:00 0d4081ed69147a2591dfc8b89cba42dc6a2ce757 The new sys/conf/std.debug contains the list of debugging options enabled by default in -CURRENT, so they don't need to be listed individually in every kernel config. Introduce *-DEBUG variants of the major kernel configs. (cherry picked and modified from commit 4f8f9d708e6a4143f3b178bfab10d0a9b75ba2fe) Reviewed by: markj, imp, olce (previous version) Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D46871 
The new sys/conf/std.debug contains the list of debugging options
enabled by default in -CURRENT, so they don't need to be listed
individually in every kernel config.

Introduce *-DEBUG variants of the major kernel configs.

(cherry picked and modified from commit 4f8f9d708e6a4143f3b178bfab10d0a9b75ba2fe)

Reviewed by:	markj, imp, olce (previous version)
Sponsored by:	Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D46871
arm ti: Stop checking for failures from malloc(M_WAITOK) 2024-09-30T04:44:18+00:00 Zhenlei Huang zlei@FreeBSD.org 2024-09-03T10:25:22+00:00 920288c32900da48136eafc41aa6d020552e36e5 MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D45852 (cherry picked from commit fe6985ef87e1aedf8e5c9b3b959c7dd54a03e2fe) 
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D45852

(cherry picked from commit fe6985ef87e1aedf8e5c9b3b959c7dd54a03e2fe)
kernel: Make some compile time constant variables const 2024-09-20T10:04:02+00:00 Zhenlei Huang zlei@FreeBSD.org 2024-08-30T10:26:30+00:00 497f577f460ba93dda38910bf49b390fa610480f Those variables are not going to be changed at runtime. Make them const to avoid potential overwriting. This will also help spotting accidental global variables shadowing, since the variable's name such as `version` is short and commonly used. This change was inspired by reviewing khng's work D44760. No functional change intended. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D45227 (cherry picked from commit 356be1348dac94ba0d2dc1f479bc1f8a2ebaa03a) 
Those variables are not going to be changed at runtime. Make them const
to avoid potential overwriting. This will also help spotting accidental
global variables shadowing, since the variable's name such as `version`
is short and commonly used.

This change was inspired by reviewing khng's work D44760.

No functional change intended.

MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D45227

(cherry picked from commit 356be1348dac94ba0d2dc1f479bc1f8a2ebaa03a)
arm: Set NEW_PCIB in DEFAULTS rather than a subset of kernel configs 2024-09-07T00:00:56+00:00 Jessica Clarke jrtc27@FreeBSD.org 2024-02-22T18:27:45+00:00 d861861462d2b9157a6b938c2b4832d6589264a0 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 (cherry picked from commit 121be555997b3d7727e50d15acabd0ffbf4a4247) 
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

(cherry picked from commit 121be555997b3d7727e50d15acabd0ffbf4a4247)
intrng: Allow alternative IPI PICs to be registered and used 2024-09-06T23:59:02+00:00 Jessica Clarke jrtc27@FreeBSD.org 2024-01-24T23:49:54+00:00 7604062517ec25ac0412f258b36f58774bd234ce On RISC-V, the root PIC (whether the PLIC or, as will be the case in future, the local interrupt controller) cannot send IPIs, relying on another means to trigger the necessary software interrupts (firmware calls), but there are upcoming standard devices that will be able to inject them, so we can't just put the firmware calls in the root PIC driver. Thus, split out a new intr_ipi_dev from intr_irq_root_dev to use for sending IPIs. New devices can be registered with a given priority up until the first IPI is set up, when the best device seen so far gets frozen as the IPI device to use. Reviewed by: mhorne MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D35899 (cherry picked from commit 103d39efe0c68cb2a808c306b14c3f473a02535d) 
On RISC-V, the root PIC (whether the PLIC or, as will be the case in
future, the local interrupt controller) cannot send IPIs, relying on
another means to trigger the necessary software interrupts (firmware
calls), but there are upcoming standard devices that will be able to
inject them, so we can't just put the firmware calls in the root PIC
driver.

Thus, split out a new intr_ipi_dev from intr_irq_root_dev to use for
sending IPIs. New devices can be registered with a given priority up
until the first IPI is set up, when the best device seen so far gets
frozen as the IPI device to use.

Reviewed by:	mhorne
MFC after:	1 month
Differential Revision:	https://reviews.freebsd.org/D35899

(cherry picked from commit 103d39efe0c68cb2a808c306b14c3f473a02535d)
intrng: Extract arm/arm64 IPI->PIC glue code 2024-09-06T23:58:28+00:00 Jessica Clarke jrtc27@FreeBSD.org 2024-01-24T23:49:53+00:00 5e822432f03014c4fec03d6234886febf5fb5ce8 The arm and arm64 implementations of dispatching IPIs via PIC_IPI_SEND are almost identical, and entirely MI with the lone exception of a single store barrier on arm64 (that is likely either redundant or needed on arm too). Thus, de-duplicate this code by moving it to INTRNG as a generic IPI glue framework. The ipi_* functions remain declared in MD smp.h headers and implemented in MD code, but are trivial wrappers around intr_ipi_send that could be made MI, at least for INTRNG ports, at a later date. Note that, whilst both arm and arm64 had an ii_send member in intr_ipi to abstract over how to send interrupts,, they were always ultimately using PIC_IPI_SEND, and so this complexity has been removed. A follow-up commit will re-introduce the same flexibility by instead allowing a device other than the root PIC to be registered as the IPI sender. As part of this, strengthen a MAXCPU assertion that was missed in commit 2f0b059eeafc ("intrng: switch from MAXCPU to mp_ncpus") (which itself is mis-titled). Reviewed by: mmel, mhorne MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D35898 (cherry picked from commit fae8755f16ff5b9bdc32df046e0f16c0cbb48a29) 
The arm and arm64 implementations of dispatching IPIs via PIC_IPI_SEND
are almost identical, and entirely MI with the lone exception of a
single store barrier on arm64 (that is likely either redundant or needed
on arm too). Thus, de-duplicate this code by moving it to INTRNG as a
generic IPI glue framework. The ipi_* functions remain declared in MD
smp.h headers and implemented in MD code, but are trivial wrappers
around intr_ipi_send that could be made MI, at least for INTRNG ports,
at a later date.

Note that, whilst both arm and arm64 had an ii_send member in intr_ipi
to abstract over how to send interrupts,, they were always ultimately
using PIC_IPI_SEND, and so this complexity has been removed. A follow-up
commit will re-introduce the same flexibility by instead allowing a
device other than the root PIC to be registered as the IPI sender.

As part of this, strengthen a MAXCPU assertion that was missed in commit
2f0b059eeafc ("intrng: switch from MAXCPU to mp_ncpus") (which itself is
mis-titled).

Reviewed by:	mmel, mhorne
MFC after:	1 month
Differential Revision:	https://reviews.freebsd.org/D35898

(cherry picked from commit fae8755f16ff5b9bdc32df046e0f16c0cbb48a29)
intrng: Remove irq_root_ipicount and corresponding intr_pic_claim_root arg 2024-09-06T23:52:47+00:00 Jessica Clarke jrtc27@FreeBSD.org 2024-01-24T23:49:53+00:00 a73592e0d013275bd97d09d9cf168279688f7238 The static irq_root_ipicount variable is only ever written to (with the value passed to irq_root_ipicount), never read. Moreover, the bcm2836 driver, as used by the Raspberry Pi 2B and 3A/B (but not 4, which uses a GIC-400, though does have the legacy interrupt controller present too) passes 0 as ipicount, despite implementing IPIs. It's thus inaccurate and serves no purpose, so should be removed. Reviewed by: mmel, imp, mhorne MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D35897 (cherry picked from commit e06afdb2856944d6db4e33d4bbe0e2dbbd057eb4) 
The static irq_root_ipicount variable is only ever written to (with the
value passed to irq_root_ipicount), never read. Moreover, the bcm2836
driver, as used by the Raspberry Pi 2B and 3A/B (but not 4, which uses a
GIC-400, though does have the legacy interrupt controller present too)
passes 0 as ipicount, despite implementing IPIs. It's thus inaccurate
and serves no purpose, so should be removed.

Reviewed by:	mmel, imp, mhorne
MFC after:	1 month
Differential Revision:	https://reviews.freebsd.org/D35897

(cherry picked from commit e06afdb2856944d6db4e33d4bbe0e2dbbd057eb4)
arm/mpic: remove empty pic_init_secondary() hook 2024-09-06T23:52:27+00:00 Elliott Mitchell ehem+freebsd@m5p.com 2024-01-23T02:52:37+00:00 6f242c69b6049f4c319c1948da99472a53500c3f The default hook does nothing, so having an empty handler is pointless. Simple cleanup. Reviewed by: markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D40475 (cherry picked from commit a8b2189c90c52e43e27614b2cca6b753a70da0ca) 
The default hook does nothing, so having an empty handler is pointless.
Simple cleanup.

Reviewed by:	markj
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D40475

(cherry picked from commit a8b2189c90c52e43e27614b2cca6b753a70da0ca)
arm: Add evdev to the TEGRA124 config 2024-08-01T08:06:08+00:00 Mark Johnston markj@FreeBSD.org 2024-07-11T19:19:42+00:00 72a1920e73d11bd73b85e8e13caa1d838f9dbd91 This is required for the kernel to link after commit 13d00a43cba4. Fixes: 13d00a43cba4 ("conf: Add usbhid and hidbus to GENERIC* kernel configs") (cherry picked from commit d68d124817780db5f98f65ae02a7ce286cd426eb) 
This is required for the kernel to link after commit 13d00a43cba4.

Fixes:	13d00a43cba4 ("conf: Add usbhid and hidbus to GENERIC* kernel configs")
(cherry picked from commit d68d124817780db5f98f65ae02a7ce286cd426eb)