wireguard-openbsd/sys/arch/arm/include, branch master

spelling

2021-03-11T11:16:54Z

Add some infrastructure in the PCI chipset tag for pci_probe_device_hook()

2021-02-25T23:07:48Z

so that we can provide IOMMU-hooked bus DMA tags for each PCI device. ok kettenis@

Remove "for all XXX platforms" from comment. Fixes the issue pointed out

2020-08-14T16:51:09Z

by miod@ where the powerpc64 claimed to be "for all AArch64 platforms". ok patrick@

Implement pci_intr_establish_cpu() on arm64 and armv7. The function pointer

2020-07-14T15:42:19Z

in the chipset tag for establishing interrupts now takes a struct cpu_info *. The normal pci_intr_establish() macro passes NULL as ci, which indicates that the primary CPU is to be used. The PCI controller drivers can then simply pass the ci on to our arm64/armv7 interrupt establish "framework". Prompted by dlg@ ok kettenis@

Extend the interrupt API on arm64 and armv7 to be able to pass around

2020-07-14T15:34:14Z

a struct cpu_info *. From a driver point of view the fdt_intr_establish_* API now also exist same functions with a *_cpu suffix. Internally the "old" functions now call their *_cpu counterparts, passing NULL as ci. NULL will be interpreted as primary CPU in the interrupt controller code. The internal framework for interrupt controllers has been changed so that the establish methods provided by an interrupt controller function always takes a struct cpu_info *. Some drivers, like imxgpio(4) and rkgpio(4), only have a single interrupt line for multiple pins. On those we simply disallow trying to establish an interrupt on a non-primary CPU, returning NULL. Since we do not have MP yet on armv7, all armv7 interrupt controllers do return NULL if an attempt is made to establish an interrupt on a different CPU. That said, so far there's no way this can happen. If we ever gain MP support, this is a reminder that the interrupt controller drivers have to be adjusted. Prompted by dlg@ ok kettenis@

do not need these versions of timetc.h

2020-07-08T14:45:15Z

Add support for timeconting in userland.

2020-07-06T13:33:05Z

This diff exposes parts of clock_gettime(2) and gettimeofday(2) to userland via libc eliberating processes from the need for a context switch everytime they want to count the passage of time. If a timecounter clock can be exposed to userland than it needs to set its tc_user member to a non-zero value. Tested with one or multiple counters per architecture. The timing data is shared through a pointer found in the new ELF auxiliary vector AUX_openbsd_timekeep containing timehands information that is frequently updated by the kernel. Timing differences between the last kernel update and the current time are adjusted in userland by the tc_get_timecount() function inside the MD usertc.c file. This permits a much more responsive environment, quite visible in browsers, office programs and gaming (apparently one is are able to fly in Minecraft now). Tested by robert@, sthen@, naddy@, kmos@, phessler@, and many others! OK from at least kettenis@, cheloha@, naddy@, sthen@

Remove obsolete header. Nowadays the vararg

2020-06-30T15:41:55Z

functionality is provided by using compiler builtins. Tested in a ports bulk build on amd64 by naddy@ OK naddy@ mpi@

introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.

2020-05-31T06:23:56Z

rnd.c uses nanotime to get access to some bits that change quickly between events that it can mix into the entropy pool. it doesn't use nanotime to get a monotonically increasing set or ordered and accurate timestamps, it just wants something with bits that change. there's been discussions for years about letting rnd use a clock that's super fast to read, but not necessarily accurate, but it wasn't until recently that i figured out it wasn't interested in time at all, so things like keeping a fast clock coherent between cpu cores or correct according to ntp is unecessary. this means we can just let rnd read the cycle counters on cpus and things will be fine. cpus with cycle counters that vary in their speed and arent kept consistent between cores may even be desirable in this context. so this is the first step in converting rnd.c to reading cycle counter. it copies the nanotime backend to each arch, and they can replace it with something MD as a second step later on. djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits. thanks to visa for his eyes. ok deraadt@ visa@ deraadt@ says he will help handle any MD fallout that occurs.

Add machdep.compatible.

2020-05-17T15:36:50Z

ok jsg@