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]

In D20720#448402, @trasz wrote:

In D20720#448101, @greg_unrelenting.technology wrote:

Many many many Linux binaries are ELFOSABI_NONE.

The Elf64_Brandinfo definitions directly above the added lines allow executables with ELFOSABI_NONE to run when interp_path matches. You can see one was added for musl libc, before that one was added, Alpine Linux did not work.
But that's for normal executables.

But the musl entry still says ELFOSABI_LINUX, doesn't it?

Many many many Linux binaries are ELFOSABI_NONE.

Well, someone could chroot into a *FreeBSD* installation with the compat/linux packages installed in it..

Works fine on aarch64, please add it to the list

Rebased for rS348195 (D20357)

I wonder if this is what we need on aarch64 for the Ampere eMAG server to not panic in ACPI: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237055#c40

update: what's hanging is the WRITE4 for putting the PLL into normal mode!

Kernel with this patch boots fine on Amazon EC2 (which btw you can use too, freebsd-snapshots posts have aarch64 AMIs)

new emmc patch is D20156

In D19335#433606, @manu wrote:

In D19335#433397, @manu wrote:

In D19335#433249, @greg_unrelenting.technology wrote:

rebased, depends on D19986

not tested yet — for some reason my rockpro64 can't boot: clknode_register hangs when registering the first PLL on rk3399_cru0 :(

Could you test reverting r344626 ? ganbold@ have problem with this revision on the NanoPi T4. I personally don't have problems booting it (tried yesterday).

Mhm no, I've unplugged my eMMC module from my RockPro64 for a long time now so it's not that.
Could you try with the latest dtb ? It's installed now but on the wrong path until @kevans commit his fix. (so it's in /boot/dtb/ directly right now)

rebased, depends on D19986

Added fdt detach corresponding to the current attach code (usb-phy)

I don't think anyone really worked on the tests. I never tried to run them.

Done. btw, the original version was confirmed working on the Ampere system.

In D19986#430964, @emaste wrote:

In D19986#430466, @manu wrote:

Something like D19389 would be better.

Ah, yes. GregV would you rework it using that approach?

Done. Checked that mlx5ib loads.

In D19983#429595, @hselasky wrote:

Can you verify that the LINT kernel passes with this change on aarch64?

Sure, split to D19987

Update: the GPU hangs are *not* caused by IOMMU remapping. Possibly a bug in drm-v5.0… I'll try the updated version of this patch with stable drm later

In D19845#428854, @tychon wrote:

Looks like a symptom of non-translatable physical address. I've encountered drivers which need additional work outside of the scope of this effort. Perhaps this is the case there as I can't any more cases in the Linux KPI where a physical address is substituted for a DMA one.

Also, I assume this is in remap mode. Does it work in identify map mode hw.busdma.default="bounce"? Unless there is an API which escaped, if it works in hw.dmar.enable="0" it's not a regression from before :-/

Some more i915 GPU testing (w/o the latest update here): after using Firefox (opengl layers, xwayland) for some time, GPU resets start happening

works very well, will this be committed soon?

Also tested on an AMD Ryzen + Vega system, no regressions. (No IOMMU there because no one wrote a dmar equivalent for AMD IOMMU…)

Tested on my Haswell laptop with drm-v5.0, everything works (both with DMAR on and off), this line is new in dmesg:

okay, PCI is now https://reviews.freebsd.org/D19896

done

The quirk is a much more elegant way, thanks for the suggestion!

Landed as r345407.

In D19507#423995, @imp wrote:

I wouldn't be opposed to that either. I dislike special cases, but this may be a good case for an exception.

In D19507#423825, @imp wrote:

IIRC, this violates the ACPI definition for these fields.

Dammit. The Ampere eMAG (which uses the pl011 SBSR UART) represents *shiftp = 2; as

In D19438#416304, @ae wrote:

I have no objection. AFAIR, the main goal of this change was the adding ability to extend number of entries for some tables, that have very little number of partition entries, e.g. 1 or 2.
I think if you revert this change, then you will not able to add new partitions for these tables, even if there are enough space to keep them.

I can confirm that mtu changes on ena work fine with this patch, nice

Merged into D19507

btw, would it be better to integrate all my uart patches into this, or post them separately?

In D19507#417521, @andrew wrote:

Could you use spcr->SerialPort.AccessWidth to find this? It's set to 1 in the copy of the spcr table I have indicating byte access.

In D19330#414453, @markj wrote:

I still think that the change should apply only to shm descriptors

In D19354#414690, @jbeich wrote:

Greg, can you help fix stdsimd on aarch64?