7b5a5e4e replaced nexus_activate_resource() with the bus generic
equivalent, which uses bus_map_resource(). However, though not intended
to have a functional change, nexus_map_resource() uses the bus tag of
the build (BE vs LE), while nexus_activate_resource() always explicitly
set a big-endian tag, leading to failures on powerpc64le now. Using BE
unless otherwise explicitly specified with the RF_LITTLEENDIAN fixes LE
on bare metal, and doesn't hurt in a VM, which nexus_map_resource() was
added for.
Reported by: pkubaj
Tested by: pkubaj
Fixes: 7b5a5e4e("powerpc nexus: Use bus_generic_rman_*")
MFC after: 1 day
Approved by: re(cperciva)
(cherry picked from commit c4921a0faaf1683f39347dd066000d929c39c8b9)
(cherry picked from commit 45d585ab7f222ca36988c406df528128a17f9884)
In this case, the domain from which the memory to back the VM page array
is allocated does not matter, so just let vm_phys_early_alloc() choose
a suitable domain.
Reviewed by: jhibbits, markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48888
(cherry picked from commit 0ebd9cf85d3627e50e6a7330b67719fce4d1a5fe)
Thus far we've relied on the firmware setting HFSCR correctly, enabling
all facilities. However, it appears some recent firmwares do not.
Linux explicitly enables all facilities it supports (including
transactional memory, which new firmwares apparently do not enable), so
do the same here, explicitly enable all the facilities FreeBSD supports.
MFC after: 1 week
(cherry picked from commit fe73eb441f1c98fe350f4822c7d2abfeef046bf8)
Treat Hypervisor Facility Unavailable as an illegal instruction in user
space. This way programs that use facilities like transactional memory,
which will never be supported as it has been removed from the ISA, will
not crash the kernel.
Tested by: pkubaj
MFC after: 1 week
(cherry picked from commit 0b663e0cee89dedf5b070ff4e839d5ad95061535)
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)
Similar to 68a3ff041129208ea98a3bd5142061176ab4165e, the default case
needs to call bus_generic_* to pass the request up the tree, not bus_*
which will just call this method again.
Fixes: d7c16b333455 powerpc psim: Use bus_generic_rman_*
(cherry picked from commit 61d9bd21e9d6c3f876c4c8549fafaaaa4de75983)
Similar to 68a3ff041129208ea98a3bd5142061176ab4165e, the default case
needs to call bus_generic_* to pass the request up the tree, not bus_*
which will just call this method again.
Fixes: 5a7e717fb790 powerpc mpc85xx: Use bus_generic_rman_*
(cherry picked from commit cd9d26ed91c049dd60919c71badced89e18a882a)
The default case needs to call bus_generic_adjust_resource to pass the
request up the tree, not bus_adjust_resource which will just call this
method again.
Fixes: d7c16b333455 powerpc psim: Use bus_generic_rman_*
(cherry picked from commit ccb1b43e20f5a1a0795b14f3ef39d5c2e15b424d)
The default case needs to call bus_generic_adjust_resource to pass the
request up the tree, not bus_adjust_resource which will just call this
method again.
Fixes: 5a7e717fb790 powerpc mpc85xx: Use bus_generic_rman_*
(cherry picked from commit 68a3ff041129208ea98a3bd5142061176ab4165e)
If this powerpc-specific flag is set on a resource, then the
little-endian bus tag is always used when mapping that resource.
Make use of this flag in the mpc85xx/fsl_sata driver to avoid setting
the SATA BAR's bus tag after bus_alloc_resource.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D43553
(cherry picked from commit a82470212b7659afb7d3287e2ccae72d5e496b71)
Previously it failed to compile since the macro passed too many
arguments to the function. Fix by adding the bus handle to the
function and adding an implementation that calls pmap_unmapdev.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D43440
(cherry picked from commit a3d6e0de1c89c145b40ed80fe54c6bad1abbf416)
Implement bus_map/unmap_resource and add bus_get_rman for use by
bus_generic_rman_*.
Reviewed by: imp, jhibbits
Differential Revision: https://reviews.freebsd.org/D43435
(cherry picked from commit af081ec6f7cf4b764a1b417135440cf05cf1a174)
- Split out bits of iobus_activate/deactive_resource to implement
iobus_map/unmap_resource.
- Use bus_generic_rman_* methods in several bus methods to handle
memory and I/O port resources.
- Add an implementation of bus_adjust_resource.
Reviewed by: imp, jhibbits
Differential Revision: https://reviews.freebsd.org/D43433
(cherry picked from commit d7c16b333455faef4236d98bb6e671651e87a66d)
- Split out part of ps3bus_activate_resource into a
ps3bus_map_resource method.
- Implement ps3bus_unmap_resource via pmap_unmapdev.
- Use bus_generic_rman_* to add bus_adjust_resource,
bus_deactivate_resource, and bus_release_resource methods.
Reviewed by: imp, jhibbits
Differential Revision: https://reviews.freebsd.org/D43432
(cherry picked from commit 3dd55df98282293c41bb0d98fa54312a9cf2aba5)
Prior to change [1] this flag is useless but harmless. After the change
plat_name[] will be fetched from kernel environment after invoking the
platform probe function `platform_probe_and_attach()`. The probe function
runs at early boot stage prior to `mi_startup()` thus it is too late and
pointless to set plat_name[] after the probe.
Nathan mentioned that the logic to specify the platform pre-dates the
powerpc64 work, and is from the original pre-FDT Book-E bringup from
like 2008, so it's irrelevant these days. Instead of fixing setting the
sysctl knob hw.platform, let's clean it up now.
[1] 3da1cf1e88 Extend the meaning of the CTLFLAG_TUN flag to ...
Discussed with: nwhitehorn
Reviewed by: olce (previous version), jhibbits, #powerpc
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D48897
(cherry picked from commit b61fbbed73ea3bf0c84589b56cca160c46a3739d)
The kernel source contains several definitions of an ilog2 function;
some are slower than necessary, and one of them is incorrect.
Elimininate them all and define an ilog2 macro in libkern to replace
them, in a way that is fast, correct for all argument types, and, in a
GENERIC kernel, includes a check for an invalid zero parameter.
Folks at Microsoft have verified that having a correct ilog2
definition for their MANA driver doesn't break it.
Reviewed by: alc, markj, mhorne (older version), jhibbits (older version)
Differential Revision: https://reviews.freebsd.org/D45170
Differential Revision: https://reviews.freebsd.org/D45235
(cherry picked from commit b0056b31e90029553894d17c441cbb2c06d31412)
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)
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)
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)
ps3 are broken since we moved to clang/elfv2. Fix this by updating the
hypercall glue to the new ABI.
Signed-off-by: Chattrapat Sangmanee <aomsin27@hotmail.co.th>
Reviewed by: jhibbits
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/1413
(cherry picked from commit 50a03971d3327f3ca5c2a1a96ec83c77b6a669c8)
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)
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)
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)
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)
Newer firmware on POWER systems, including v2.10 of the Talos II and
Blackbird firmware can end up reserving more than 32 memory regions in
the device tree, which exceeded an assumption made by ofw_machdep.c's
excise_fdt_reserved(). Bump the maximum number of FDT reservations to
the next power of 2 in order to fix booting on newer firmware.
PR: 277097
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D44015
(cherry picked from commit b52dceb838116391996909ff50b49f950ee01f48)
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)
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)
A recent change made it possible for cpu_set_upcall() to return an
error. Do that here instead of ignoring an error from copyin().
Reviewed by: jhibbits
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43105
(cherry picked from commit bdf03b4bcc4a9aa0be503dbc64415e6b0b845fbc)
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)
RB_HALT does not mean poweroff, RB_POWEROFF does.
Reviewed by: jhibbits
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42339
(cherry picked from commit 41e26e8288f1743c8584e5f9c461d36dce1cccc6)
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
When support for fpu_kern_enter/fpu_kern_leave was added to powerpc,
set_mcontext was updated to handle Altivec state restoration in the same
way that the FPU state by lazily restoring the context on the first
trap. However the function was not correctly updated to unconditionally
clear the PCB_VEC and PSL_VEC bits from the pcb's flags and srr1
respectively which can sometimes result in a mismatch between a
process's MSR[VEC] state and its pcb_flags.
Fix this by simply clearing the VEC flags unconditionally in
set_mcontext, which is already done for FPU/VSX.
Fixes: a6662c37b6ffe ("powerpc: Implement fpu_kern_enter/fpu_kern_leave")
Reviewed by: alfredo
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D42417
(cherry picked from commit 270f75cf3433807d124cdf1f0072ab801532f425)
Summary:
Provide an implementation of fpu_kern_enter/fpu_kern_leave for PPC to
enable FPU, VSX, and Altivec usage in-kernel. The functions currently
only support FPU_KERN_NOCTX, but this is sufficient for ossl(1) and many
other users of the API.
This patchset has been tested on powerpc64le using a modified version of
the in-tree tools/tools/crypto/cryptocheck.c tool to check for FPU/Vec
register clobbering along with a follow-up patch to enable ossl(4) on
powerpc64*.
Reviewed by: jhibbits
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D41540
Relnotes: yes
(cherry picked from commit a6662c37b6ffee46e18be5f7570149edc64c1d0b)
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)
Commit 2d2bcba7ba changed radix trie
implementation and made it necessary that radix tries be initialized
with vm_radix_init. @dbaio reports that in some configurations, there
is a powerpc boot panic and that this commit introduced the
problem. In powerpc/aim/mmu_radix.c, the radix trie in kernel_pmap is
initialized by zeroing all its fields.
Add a call to vm_radix_init to properly initialize
kernel_pmap->pm_radix.
Reported by: dbaio
Reviewed by: alc, jhibbits
Fixes: 2d2bcba7ba drop NULL check from radix trie search
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41846
(cherry picked from commit 8763b9862f90dc3bdbbc5e3c2664890be7c1f0c4)
For amd64, i386, arm, and riscv, i.e. all architectures except arm64,
the custom implementation is provided since we maintain the bitmask of
active CPUs anyway.
Arm64 uses somewhat naive iteration over CPUs and match current vmspace'
pmap with the argument. It is not guaranteed that vmspace->pmap is the
same as the active pmap, but the inaccuracy should be toleratable.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32360
