Would it be possible to also support memory-mapped UART this way? Intel >=Skylake and all aarch64 systems use mmio.

In D18028#493129, @greg_unrelenting.technology wrote:

Is it just me or did setting epp break in the latest version?

Now calling from IOAPIC suspend/resume functions (if there's any better place "close to the nexus" I haven't found it.)

Is it just me or did setting epp break in the latest version?

Just installed libsigsegv on a machine and the pkg message was: "Note that the stackoverflow handling functions of this library need procfs mounted on /proc."

In D22275#486869, @emaste wrote:

Do we know what if any ports actually use procfs?

Rebased on top of the ASID changes

In D21564#485874, @hselasky wrote:

Who will submit this patch?

ping

Diff broken by rS354193 'Set the userspace execute never bit on kernel mappings' (looks like that sets UXN in the else case instead).

Rebased on top of the powerpc64 change

Maybe at some point they can even become PIE executables by default! :)

The pmap_change_attr() API is private on arm64

In D16698#478767, @imp wrote:

So with the suggested changes, I'm not able to get very far with the patches in this review. With wulf's code I'm able to get the device probed. With this code, I see the following

In D21863#477929, @hselasky wrote:

Likely this Google device is not USB certified

oh, i915 is reloadable, right. Everything works fine, can adjust brightness after reloading.

Yeah, I was wondering about devmatch in D21612

ping

Works fine on the Google Pixelbook (i7-7Y75) (where the old EST does not work because there aren't any acpi_perf devices).

Looks like this was merged as rS351480 but phabricator didn't count that for closing this review (full URL shouldn't be in "Differential Revision:"??)

In D20789#467032, @hselasky wrote:

Can you update my patch and test an again? Thank you!

panic: vm_fault_hold: fault on nofault entry, addr: 0xffff00006e1ff000 in gfx_v8_0_kiq_resume

ping

In D20974#462987, @emaste wrote:

Can you show a diff of the NetBSD version to this? i.e. what you had to change in the port?
(I assume that we don't want to treat this as contrib code and will just adopt it.)

In D21167#463001, @emaste wrote:

This is just another "upstream only considered Linux, we need to be included in the same way as Linux" case.

But I mean this was already the case for the presumably-working amd64/i386 cases?

Builds fine on aarch64 CURRENT, tested building ripgrep with it, fine.

I'm building on aarch64 right now, llvm is done, so I'm expecting success

btw, kms-drm patch: https://github.com/FreeBSDDesktop/kms-drm/pull/163

In D21168#460060, @imp wrote:

Have you run this and does it work?

Seems fine so far, thanks

bump

oh, also, msi_enabled is actually a public flag used by the i915 driver:

We need pdev->irq = rle->start still (and, for completeness, similarly in the disable function), otherwise it tries to request LINUX_IRQ_INVALID:

This causes panics in ZFS. Just doing an installkernel or cp -r /boot/kernel /boot/kernel.something results in:

In D20974#458088, @emaste wrote:

In D20974#457245, @greg_unrelenting.technology wrote:

Would be nice to test on ThunderX2 :)

Does not attach on ThunderX2 (no sbsawdt0 in dmesg).

Update: added pdev->msi_enabled flag that's used by i915kms.

In D20974#457235, @emaste wrote:

I can confirm this attaches on my eMAG but I cannot verify the watchdog functionality - were you able to test it?

In D20974#457221, @emaste wrote:

@greg_unrelenting.technology do you have a git repo available with your work in it? It'd be slightly easier for me to just add your repo and grab changes directly.

In D21018#456270, @ngie wrote:

Could you please test this change out on amd64?

We probably wouldn't want that on big armv8 boxes, maybe || defined(__aarch64__) should be added to if defined(__amd64__) in that case..

In D16698#455093, @nikola.lecic_anthesphoria.net wrote:

In D16698#454859, @greg_unrelenting.technology wrote:

In D16698#454202, @nikola.lecic_anthesphoria.net wrote:

1. I compiled this driver with EVDEV support (https://gist.github.com/johalun/3c67a678e740b82512cec52bfe926092). How can I make use of it? I see no difference with and without this patch.

If there's a new device in /dev/input, it is working. You can run libinput debug-events to see the input events. To consume evdev devices from xorg, use xf86-input-libinput. There were patches for autodetection (one adding evdev autodetection to the devd backend, another switching to the udev backend with libudev-devd). The devd one might have been merged?? (I don't follow Xorg, I use Wayland exclusively)

Thanks; I thought that kldload evdev was enough; but kernel with EVDEV_SUPPORT was needed.

In D16698#454202, @nikola.lecic_anthesphoria.net wrote:

1. I compiled this driver with EVDEV support (https://gist.github.com/johalun/3c67a678e740b82512cec52bfe926092). How can I make use of it? I see no difference with and without this patch.

please commit?

Sure. I've actually made a couple more changes recently btw. I hope PATCH_SITES is okay here

UPDATE: actually this miiiight have been preventing the GPU from working.

hm, just looked at linux — regular, _nocache and _wt are all PROT_DEVICE_nGnRE. Let's change them all then.

In D20765#449718, @bcran wrote:

I just tried booting with this patch applied and with EDK2 firmware built from master yesterday, and I still don't see any output - both with devicetree and acpi.

Tested on += Marvell MACCHIATObin (Armada8k) [upstream EDK2, atf-marvell, ECAM shift removed, ACPI mode]