wireguard-openbsd/sys/arch/arm64/dev/simplebus.c, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/arm64/dev/simplebus.c?h=jd%2Fqueueboosts 2019-04-16T13:15:31Z Prevent attaching drivers to devices for which we attached a driver early. 2019-04-16T13:15:31Z kettenis kettenis@openbsd.org 2019-04-16T13:15:31Z urn:sha1:d45a5b64abd387cacc9c97a01693f44af4c4bc36 ok patrick@, dlg@, visa@ When accessing the child address cells make sure to use the size for 2019-03-07T07:58:26Z patrick patrick@openbsd.org 2019-03-07T07:58:26Z urn:sha1:229c19cd938575c2938ae232c6d2fe2fc3d0974d those instead of the size of the parent address cells. ok kettenis@ add a simplebus print function so unconfigured devices appear in dmesg. 2019-01-03T23:04:51Z dlg dlg@openbsd.org 2019-01-03T23:04:51Z urn:sha1:e3246555cbf9adcdec31893a9dd902402d5ca4c3 this was avoided previously because during the early stages of the port, there were mostly unsupported devices. the situation is a bit better now, so make the missing drivers more obvious so people can get interested. ok kettenis@ Pass the correct dma tag to the load buffer function. Passing t only 2017-06-01T21:19:07Z patrick patrick@openbsd.org 2017-06-01T21:19:07Z urn:sha1:35e955906efae14e6017afb833ca781a38ef0ad6 passes the tag where the pointer to the simplebus_dmamap_load_buffer() wrapper is stored in. We want to call the load buffer function that was passed from our parent device, so we have to pass the parent's tag. Otherwise we end up in a recursive and neverending loop. This only occurs when a simplebus attaches to a simplebus, which we apparently didn't have so far. Add code to identify the CPUs on arm64 systems. The primary CPU is attached 2017-04-27T10:23:19Z kettenis kettenis@openbsd.org 2017-04-27T10:23:19Z urn:sha1:3f1731310f2625bad45b67b7c7026a9ff2a4f1e1 and identified early on. For the secondary CPUs this happens late, such that the drivers we need to spin up CPUs, such as psci(4), will be available. This also fixes some code in simplebus(4) where the return value of OF_getprop() was not properly checked. Heavily based on an earlier diff from drahn@. ok drahn@, jsg@ The AMD Seattle SoC incorporates DMA coherent controllers, especially 2017-02-22T22:55:27Z patrick patrick@openbsd.org 2017-02-22T22:55:27Z urn:sha1:2d784deaae60ed682a085dc1d07e1151de3349ec AHCI, PCIe and Ethernet. Since these systems rely on cache snooping, we must not map pages that are supposed to be coherent as uncacheable. Instead if we have a cache coherent device, create a bus tag and mark that tag as coherent. For users of that tag we can simply use normal, cached memory. ok kettenis@ Add (temporary) workaround for the missing "dma-ranges" property in the 2017-01-23T10:47:53Z kettenis kettenis@openbsd.org 2017-01-23T10:47:53Z urn:sha1:c46d2c7f381055e25df4fdfbc0731c960cc72e78 device tree provided by the current Raspberry Pi firmware. ok jsg@ Parse and use "dma-ranges" property to do the appropriate dma address 2017-01-23T10:46:02Z kettenis kettenis@openbsd.org 2017-01-23T10:46:02Z urn:sha1:3e99d0b82503cf01f8f7b25288b454e353f89912 translations on machines like the Raspberry Pi. ok jsg@ No need to explicitly use config_activate_children in the cfattach struct. 2017-01-23T06:13:34Z kettenis kettenis@openbsd.org 2017-01-23T06:13:34Z urn:sha1:fc955b36c7dac13ebe51e9f80b3a42a83418e549 In comparison to armv7, our arm64 port passes the bus space tag as 2017-01-13T22:52:24Z patrick patrick@openbsd.org 2017-01-13T22:52:24Z urn:sha1:535110bcc4f295155883e76fd514a6ce12703180 first argument instead of the bus space cookie.