- Change vm_page_reclaim_contig[_domain] to return an errno instead
of a boolean. 0 indicates a successful reclaim, ENOMEM indicates
lack of available memory to reclaim, with any other error (currently
only ERANGE) indicating that reclamation is impossible for the
specified address range. Change all callers to only follow
up with vm_page_wait* in the ENOMEM case.
- Introduce vm_domainset_iter_ignore(), which marks the specified
domain as unavailable for further use by the iterator. Use this
function to ignore domains that can't possibly satisfy a physical
allocation request. Since WAITOK allocations run the iterators
repeatedly, this avoids the possibility of infinitely spinning
in domain iteration if no available domain can satisfy the
allocation request.
PR: 274252
Reported by: kevans
Tested by: kevans
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D42706
(cherry picked from commit 2619c5ccfe1f7889f0241916bd17d06340142b05)
MFCed as a prerequisite for further MFC of VM domainset changes. Based
on analysis, it would not hurt, and I have been using it in productions
for months now.
Resolved the trivial conflict due to commit 718d1928f874 ("LinuxKPI:
make linux_alloc_pages() honor __GFP_NORETRY") having been MFCed before
this one.
Summary:
These came in the original DrvAPI commits in 2014, and are obsoleted by
bpf_mtap_if() and ether_bpf_mtap_if(). The `_if` suffix, rather than
prefix, conveys that it's operating on the bpf of the interface, instead
than the interface itself.
Reviewed by: glebius
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D41146
(cherry picked from commit 2a3716432d209c5fef1eb1a719f4c1914e7c8b5a)
Some drivers held regular mutexes across some new-bus calls; instead
depend on bus_topo_lock to protect the relevant softc members. This
also fixes the bus_topo_lock to be explicit in these drivers rather
than relying on the implicit Giant from taskqueue_swi_giant. It
avoids calling sleepable routines like device_probe_and_attach from an
swi context.
Differential Revision: https://reviews.freebsd.org/D49270
(cherry picked from commit c0bed9bd0bda2ca9239f5913cd2d5c1bd5d29bfa)
Implement basic clkdev methods required by the generic clk_gate device.
This should make it functional, and prevent panics when invoking the
clock's CLKNODE_GET_GATE method (e.g. with `sysctl -a`).
Additionally, we need to fill in other key fields of the clk_gate_def
structure before registering each clk.
PR: 278188
Reported by: solo_code@protonmail.com
Tested by: solo_code@protonmail.com
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48419
(cherry picked from commit 6f2775548278c76e7c33b15aaaaa759270a8dcd5)
These detach routines in these drivers all ended with 'return
(bus_generic_detach())' meaning that if any child device failed to
detach, the parent driver was left in a mostly destroyed state, but
still marked attached. Instead, bus drivers should detach child
drivers first and return errors before destroying driver state in the
parent.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47387
(cherry picked from commit d412c07617eb35435668b024bc2cecda05f57f1f)
- Implement bus_get_rman pulling bits from nexus_alloc_resource.
- Implement bus_map/unmap_resource pulling bits from
nexus_activate/deactivate_resource.
- Use bus_generic_rman_* for
bus_alloc/adjust/activate/deactivate/release_resource except for
custom interrupt activate/deactivate logic still in
nexus_activate/deactivate_resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43437
(cherry picked from commit faeb273e7a8ec57d87de8d4337598fb11ae305c3)
In order to match reality, allow using these functions with pointers on
const objects, and bring us closer to C11.
Remove the '+' modifier in the atomic_load_acq_64_i586()'s inline asm
statement's constraint for '*p' (the value to load). CMPXCHG8B always
writes back some value, even when the value exchange does not happen in
which case what was read is written back. atomic_load_acq_64_i586()
further takes care of the operation atomically writing back the same
value that was read in any case. All in all, this makes the inline
asm's write back undetectable by any other code, whether executing on
other CPUs or code on the same CPU before and after the call to
atomic_load_acq_64_i586(), except for the fact that CMPXCHG8B will
trigger a #GP(0) if the memory address is part of a read-only mapping.
This unfortunate property is however out of scope of the C abstract
machine, and in particular independent of whether the 'uint64_t' pointed
to is declared 'const' or not.
Approved by: markj (mentor)
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46887
(cherry picked from commit 5e9a82e898d55816c366cfa3ffbca84f02569fe5)
D37419 corrupts VFP context store on signal delivery and D38696 corrupts PCB
because it performs a binary copy between structures with different layouts.
Revert the problematic parts of these commits to have signals delivery
working. Unfortunately, there are more problems with these revisions and
more fixes need to be developed.
Fixes: 6926e2699a
Fixes: 4d2427f2c4
MFC after: 4 weeks
(cherry picked from commit 3abef90c325dc9badc51cc0e195db3fd5548ff53)
The BUSDMA buffer is treated as normal memory during compilation and compiler
is free to inline/optimize basic functions (i.e. memset, memcpy) accessing
buffers, including when an instruction is generated that performs a word
access to unaligned data. We support this, but only if the buffer in question
is mapped as normal memory (cached or not), but not to memory mapped as
strongly ordered or device type.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D47485
(cherry picked from commit 248109448f6afb3d093a522677aab2975a3e7a15)
For current architectures, these are just aliases for the existing
operation on the relevant scalar integer.
Reviewed by: imp, kib
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D47631
(cherry picked from commit a80b9ee15aa0f2da9f9f0c48e13324e0e5f2e840)
The pointer function types were missing for these functions, so add
them. Valuable for places where type sizes vary by architecture.
Differential Revision: https://reviews.freebsd.org/D37778
Reviewed by: imp, andrew
Pull Request: https://github.com/freebsd/freebsd-src/pull/1126
(cherry picked from commit 98c276811aece750cd93cec53cd6c8f926519da5)
Use a memory barrier after calling the existing atomic_testandset_long
rather than using the fcmpset-based fallback version from
<sys/_atomic_subword.h>.
Reviewed by: kib
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D47628
(cherry picked from commit 987c5a1944183cf82884fdb96b0432bd810aa8b9)
This is mostly to reduce the diff with CheriBSD which adds additional
constants to enum uio_rw, but also matches the normal style used for
uio_segflg.
Reviewed by: kib, emaste
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D45142
(cherry picked from commit 473c90ac04cec0abbb414978c53e9c259c9129e8)
The way a sound driver currently registers to sound(4) is using the
following sequence of function calls:
1. pcm_register() to initialize snddev_info.
2. pcm_addchan() calls to create the device's primary channels.
3. pcm_setstatus() to do the final setup.
While using 3 different functions in a specific order might not be very
elegant, this pattern cannot be easily avoided. However, pcm_register()
and pcm_setstatus() are especially confusing, since one would
intuitively expect:
1. pcm_register() to actually do the registration, as opposed to a basic
initialization.
2. pcm_setstatus() to, as the name suggests, set some kind of status, as
opposed to finalizing the registration.
This patch renames pcm_register() to pcm_init(), and pcm_setstatus() to
pcm_register(). Drivers are modified accordingly.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47325
(cherry picked from commit 516a9c0212b003e1da0c6f4476dbe4f3f431606c)
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)
