WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/arm/cortex?h=master 2021-03-25T04:12:00Z 2021-03-25T04:12:00Z jsg jsg@openbsd.org 2021-03-25T04:12:00Z urn:sha1:a4a50d9633ad5d32f291ac2e2a431b18d1120b73 based on include-what-you-use suggestions 2021-02-23T04:44:30Z cheloha cheloha@openbsd.org 2021-02-23T04:44:30Z urn:sha1:8611d3cdb295683ad47c33036b86b471b2d09741 The timecounter struct is large and I think it may change in the future. Changing it later will be easier if we use C99-style initialization for all timecounter structs. It also makes reading the code a bit easier. For reasons I cannot explain, switching to C99-style initialization sometimes changes the hash of the resulting object file, even though the resulting struct should be the same. So there is a binary change here, but only sometimes. No behavior should change in either case. I can't compile-test this everywhere but I have been staring at the diff for days now and I'm relatively confident this will not break compilation. Fingers crossed. ok gnezdo@ 2021-01-19T18:04:43Z kettenis kettenis@openbsd.org 2021-01-19T18:04:43Z urn:sha1:2252d02c98c50b91e4bcb2325ae12cccc27202c5 ok tb@, deraadt@ 2020-07-14T15:34:14Z patrick patrick@openbsd.org 2020-07-14T15:34:14Z urn:sha1:789e88a4f7019d5bbf49cfe092c6d4b9891ea3b0 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@ 2020-07-12T20:36:37Z naddy naddy@openbsd.org 2020-07-12T20:36:37Z urn:sha1:439fbd734b60ed38945a0337adc2cb2d4e121677 Checked against * ARM Architecture Reference Manual (agtimer) * ARM Cortex-A9 MPCore Technical Reference Manual (amptimer) * OMAP35x Applications Processor Technical Reference Manual (gptimer) Artturi Alm had independently suggested this in the past. 2020-07-06T13:33:05Z pirofti pirofti@openbsd.org 2020-07-06T13:33:05Z urn:sha1:d82e6535c6efd8305182f77041b2246ccfae1196 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@ 2020-04-29T15:25:07Z kettenis kettenis@openbsd.org 2020-04-29T15:25:07Z urn:sha1:37084e1e34e6eafe959b14d27c905d6c5ddf0888 DMA remapping in the same way as arm64. This relies on the dma-ranges property in the device tree and allows us to get rid of the hack for the Raspberry Pi in the dwctwo(4) driver. Note that this does not include the hack in simplebus(4) that we have on arm64 since firmware that has the dma-ranges is in widespread use now. ok patrick@ 2019-09-29T10:36:52Z kettenis kettenis@openbsd.org 2019-09-29T10:36:52Z urn:sha1:ad0d549be989c6f8d4daf91c86007e6a64fb3df1 ok patrick@ 2019-09-25T09:21:49Z kettenis kettenis@openbsd.org 2019-09-25T09:21:49Z urn:sha1:7e841682145c3ccad2c7efac3a2ff6dc7be7dadf ok patrick@, jsg@ 2019-09-22T19:13:45Z kettenis kettenis@openbsd.org 2019-09-22T19:13:45Z urn:sha1:738a7e0e6ad8ecae231afd53581a94cbfb112375 version. The divergence was probably an accident and the arm64 code makes more sense and is better tested. ok patrick@