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)
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
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)
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)
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)
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 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 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)
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)
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
(cherry picked from commit 13d00a43cba4c35fcc9e0ab567baf530126a6348)
conf: hidmap is always needed for hms
So bring it in when hms is in the kernel config
Fixes: 13d00a43cba4 ("conf: Add usbhid and hidbus to GENERIC* kernel configs")
Sponsored by: Beckhoff Automation GmbH & Co. KG
(cherry picked from commit 5ed91e788f0b97c9e6c544671ffef71fad7cad27)
conf: powerpc: Add evdev to some kernel configs
Fixes: 13d00a43cba4 ("conf: Add usbhid and hidbus to GENERIC* kernel configs")
Sponsored by: Beckhoff Automation GmbH & Co. KG
(cherry picked from commit 43a62df0b464e60895084c7f9d9eddf70906fda3)
The ACPI generic timer attachment added 3 interrupts, but missed the
hypervisor physical interrupt. As the field is present in all versions
of the GTDT ACPI table and isn't an optional interrupts we can add it
to the interrupts provided to the driver.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43974
(cherry picked from commit f715e95461c9264913a65e2dc93c291b7e318d2e)
Change 4787572d05 made if_alloc_domain() never fail, then also do the
wrappers if_alloc(), if_alloc_dev(), and if_gethandle().
No functional change intended.
Reviewed by: kp, imp, glebius, stevek
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45740
(cherry picked from commit aa3860851b9f6a6002d135b1cac7736e0995eedc)
I cannot find a time where the function was not named this.
Reviewed by: kib, markj
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45383
(cherry picked from commit deab57178f0b06eab56d7811674176985a8ea98d)
Report syscalls that are not allowed in capability mode with
CAPFAIL_SYSCALL.
Reviewed by: markj
Approved by: markj (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D40678
(cherry picked from commit 05296a0ff615566d25c77c5e6619b08724d2eecb)
This is needed for gpiokeys driver that needs to read input state after
receiving an interrupt for either edge.
PR: 248138
(cherry picked from commit b98558e69b0aefbb99120a8a6ca7efbb8cafab5b)
For small segments (< PAGE_SIZE) there is a mismatch between how
required bounce pages are counted in _bus_dmamap_count_pages() and
bounce_bus_dmamap_load_buffer().
This problem has been observed on the RISC-V VisionFive v2 SoC (and
earlier revisions of the hardware) which has memory physically addressed
above 4GB. This requires some bouncing for the dwmmc driver, which has
has a maximum segment size of 2048 bytes. When attempting to load a
page-aligned 4-page buffer that requires bouncing, we can end up
counting 4 bounce pages for an 8-segment transfer. These pages will be
incorrectly configured to cover only the first half of the transfer (4 x
2048 bytes).
Fix the immediate issue by adding the maxsegsz check to
_bus_dmamap_count_pages(); this is what _bus_dmamap_count_phys() does
already. The result is that we will inefficiently allocate a separate
bounce page for each segment (8 pages for the example above), but the
transfer will proceed in its entirety.
The more complete fix is to address the shortcomings in how small
segments are assigned to bounce pages, so that we opportunistically
batch multiple segments to a page whenever they fit (e.g. two 2048 bytes
segments per 4096 page). This will be addressed more holistically in the
future. For now this change will prevent the (silent) incomplete
transfers that have been observed.
PR: 273694
Reported by: Jari Sihvola <jsihv@gmx.com>
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34118
(cherry picked from commit b134c10d658c3b350e04aa8dbd2628e955ddcce0)
These are bus addresses not CPU virtual addresses.
Reviewed by: andrew
Sponsored by: University of Cambridge, Google, Inc.
Differential Revision: https://reviews.freebsd.org/D44343
(cherry picked from commit 66658b0f2775824b2a80fb56ca15e6ceae2f8240)
Assume a PA of 0 indicates an invalid virtual address.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D43694
(cherry picked from commit afb1a3e30c05a0f69facff7df59547ec82e3531a)
Move the code from the arm specific to the iicbus controller directory.
Split up between general logic and bus attachment code.
Add support for ACPI attachment in addition to FDT.
Tested by: bz (LS1088a FDT), Pierre-Luc Drouin (Honeycomb, ACPI)
Based on: D24917 by Val Packett (initial early version)
(cherry picked from commit 5ca8e32633c4ffbbcd6762e5888b6a4ba0708c6c)
Enabling 11n for ath(4) so far was handled by a kernel option, which
was only enabled for certain kernel configurations.
In order to allow loading ath(4) as a module with 11n support on
all platforms, remove the kernel option and unconditionally enable
11n in ath(4).
Reported by: pkubaj
Reviewed by: adrian, imp
(cherry picked from commit 89c1e54a71cc4e04d4c575ee6df956a12e163cde)
In 9750d9e5, I brought the equivalent of the TS_BUSY flag back in a
mostly hardware-agnostic way in order to fix tty_drain() and, thus,
TIOCDRAIN for UARTs with TX FIFOs. This proved to be sufficient for
fixing the regression reported. So in light of the release cycle of
FreeBSD 10.3, I decided that this change was be good enough for the
time being and opted to go with the smallest possible yet generic
(for all UARTs driven by uart(4)) solution addressing the problem at
hand.
However, at least for the NS8250-class the above isn't a complete
fix as these UARTs only trigger an interrupt when the TX FIFO became
empty. At this point, there still can be an outstanding character
left in the transmit shift register as indicated via the LSR. Thus,
this change adds the 3rd (besides the tty(4) and generic uart(4) bits)
part I had in my tree ever since, adding a uart_txbusy method to be
queried in addition for tsw_busy and hooking it up as appropriate
for the NS8250-class.
As it turns out, the exact equivalent of this 3rd part later on was
implemented for uftdi(4) in 9ad221a5.
While at it, explain the rational behind the deliberately missing
locking in uart_tty_busy() (also applying to the generic sc_txbusy
testing already present).
(cherry picked from commit 353e4c5a068d06b0d6dcfa9eb736ecb16e9eae45)
On some platforms this static information can be derived directly from
the CPU, and there doesn't seem much use in restricting it.
Reviewed by: emaste, imp, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43281
(cherry picked from commit 0aba5dd2af57ea3ae90eb49d7745c4c5b6f0ab6b)
Some implementations copy data to userspace, an operation which can in
principle fail. In preparation for adding a __result_use_check
annotation to copyin() and related functions, let implementations of
cpu_set_upcall() return an error, and check for errors when copying data
to user memory.
Reviewed by: kib, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43100
(cherry picked from commit 7b68fb5ab2a276ccd081cc1a43cebf0fb315e952)
The VFP code expects the kernel to boot with VFP disabled, but some
boards will boot with it enabled. Make sure that vfp_init() disables
the VFP on each CPU during boot.
PR: 273752
Reviewed by: andrew
Diagnosed by: Thomas Skibo <thomas-bsd@skibo.net>
MFC after: 1 week
(cherry picked from commit ce2f34ade8b787b068085fa8a8ddd295b06c2737)
vfp_bounce() is called when handling an undefined instruction exception,
to see if we need to enable the VFP. Previously it would
unconditionally panic if the exception came from the kernel, which was
simply wrong, and it did not permit lazy initialization of VFP state in
the kernel. However, this functionality can be useful and is supported
by arm's fpu_kern_enter() implementation. Thus, relax assertions and
consume the exception if the thread was in an FPU section.
Based on a patch from Stormshield.
Reviewed by: andrew
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D42971
(cherry picked from commit 03a07de0d5ee7d58069152070c42d55f7ec32b7c)
Only panic if no undefined instruction handler matched the exception.
This can arise in practice if the VFP is enabled lazily.
While here, fix the panic string to not include a newline.
Reviewed by: andrew
Obtained from: Stormshield
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D42970
(cherry picked from commit ecc2e6deae71b69a30bf3b7e3354aba002a37d69)
This enables the use of some out-of-tree crypto libraries on arm.
No functional change intended, there are no callers of this function in
the tree currently.
Reviewed by: andrew
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D42969
(cherry picked from commit a6a481eaa2e0f02e24b874f1a08bb494a68972c0)
Filter functions are deprecated, and unused in the tree. If either of
the filter or filterarg arguments to bus_dma_tag_create() are non-NULL,
print a warning.
This is a direct commit to stable/14.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42897
In uma_set_align_mask(), ensure that the passed value doesn't have its
highest bit set, which would lead to problems since keg/zone alignment
is internally stored as signed integers. Such big values do not make
sense anyway and indicate some programming error. A future commit will
introduce checks for this case and other ones.
Reviewed by: kib, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42262
(cherry picked from commit 3d8f548b9e5772ff6890bdc01f7ba7b76203857d)
There's no point in setting 'arm_dcache_align_mask' before the
function's end.
Reviewed by: markj, kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42261
(cherry picked from commit 1bce6f951a902f03bfb354f5b11473a0d12b3d7d)
Create the uma_get_cache_align_mask() accessor and put it in a separate
private header so as to minimize namespace pollution in header/source
files that need only this function and not the whole 'uma.h' header.
Make sure the accessors have '_mask' as a suffix, so that callers are
aware that the real alignment is the power of two that is the mask plus
one. Rename the stem to something more explicit. Rename
uma_set_cache_align_mask()'s single parameter to 'mask'.
Hide 'uma_align_cache' to ensure that it cannot be set in any other way
then by a call to uma_set_cache_align_mask(), which will perform sanity
checks in a further commit. While here, rename it to
'uma_cache_align_mask'.
This is also in preparation for some further changes, such as improving
the sanity checks, eliminating internal resolving of UMA_ALIGN_CACHE and
changing the type of the 'uma_cache_align_mask' variable.
Reviewed by: markj, kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42258
(cherry picked from commit dc8f7692fd1de628814f4eaf4a233dccf4c92199)
Make sure that we don't try to copy with a negative resid.
Make sure that we don't walk off the end of the iovec array.
Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42098
(cherry picked from commit 8fd0ec53deaad34383d4b344714b74d67105b258)
The sysctl knob 'vm.pmap.pv_entry_max' becomes a loader tunable since
7ff48af704 (Allow a specific setting for pv entries) but is fetched
from system environment 'vm.pmap.pv_entries'. That is inconsistent and
obscure.
This reverts 36e1b9702e (Correct the tunable name in the message).
PR: 231577
Reviewed by: jhibbits, alc, kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D42274
(cherry picked from commit 02320f64209563e35fa371fc5eac94067f688f7f)
The folder is a mess so start moving stuff into sub-directories.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D41907
(cherry picked from commit 580d00f42fdd94ce43583cc45fe3f1d9fdff47d4)
madt_table_data contains an array of pointers for each CPU and was
allocated on the stack. If MAXCPU is raised to a sufficiently large
value this can overflow the kernel stack. Cap the stack growth by
using GIC_MAXCPU instead as for other parts of the gicv1/v2 driver in
commit a0e20c0ded.
Suggested by: andrew
Reviewed by: andrew, emaste
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41800
(cherry picked from commit d0af08c4ba3e400049d246d72401ce36d3bee98a)
