In D26215#582535, @kib wrote:

I suppose this was extracted from realloc(9) ?

Move main routine in to kern_malloc.c
Add pair of lines to malloc(9) manpage

LGTM from evdev point of view

In D25538#570725, @wulf wrote:

In D25538#570451, @lwhsu wrote:

is there a PR for this?

Really no. We have similar PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247787
I wrote to it's author to replace his patch with this one to not duplicate things.

I moved this patch to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247787

In D25538#570451, @lwhsu wrote:

is there a PR for this?

In D25538#570383, @miguel_gocobachi.dev wrote:

@wulf or @lwhsu can you merge this into the ports tree? thanks!

BTW I tagged current snapshot with 0.0.3. You can bump DISTVERSION to chase it.

LGTM

Following is Makefile I was going to submit to ports some time ago:

LGTM

Witness warnings are gone with your patch. Thank you.

In D24751#544726, @hselasky wrote:

This patch is not correct. Del timer sync means that when this function returns, the callout structure shall no longer be in use. The only way to guarantee that is to use callout_drain()!
It is not good enough to only block the timer callback!

In D24500#538927, @delphij wrote:

When INVARIANT is enabled, the prev and next pointers would be TRASHIT'ed (set to -1 or 0xffffffffffffffff).

Do you have some local modifications of cdev.c? Especially with relaxed locking in evdev_dtor()?

But the thread which is woken up locks evdev too. It should postpone all the free()s until FOREACH loop is completed.

Thanks.
List item is free()-ed asynchronously in other thread which is woken up in evdev_notify_event(). That is why this panic is rare.

LGTM (except EVDEV_RCPT_HW_KBD flag in powerpc case)

Looks mostly good to me. We should keep EVDEV_RCPT_KBDMUX for powerpc32 and EVDEV_SUPPORT #else branch is not needed.

Driver reworked to not depend on existing ACPI newbus device.
It deletes ACPI-hosted child and performs resource (IRQ) parsing and children power state (S0<->S3) management on his own.
No dummy driver required anymore.

In D23615#518762, @koobs wrote:

should we leave it open for any version/arch, or should we limit it. If limiting, I need a list of archs for ONLY_FOR_ARCHS and OSVERSIONS we shouldn't set IGNORE for

In D23615#518766, @koobs wrote:

Fails building in 11amd64 with the following, so will at least set OSVERSION > 12* unless its expected or desirable for iichid to be test on 11:

Only 12.1+ is supported.

I recommend to disable USB backend by default and leave it as build-time option as it is not completed yet and interferes with existing USB drivers.

In D23615#518316, @lwhsu wrote:

@wulf : Do you think it's time to put this into base or let's add this as a port first?

In D22901#501848, @jhb wrote:

So it would be helpful to see an acpidump of a system with these devices.

I don't think that Assistant key should be mapped to KEY_RIGHTMETA for following reasons:

1. It is not really a meta key as it does not affect other key meanings like Shift, Alt, Ctrl and Win keys do.
2. According to https://www.win.tue.nl/~aeb/linux/kbd/scancodes-6.html, scancode of 0x58 prefixed with 0xE0 is emitted by pressing of Fn+F12 keys on Logitech and Microsoft keyboards so the best matching evdev event would be KEY_FN_F12.

In D22515#492391, @emaste wrote:

Do you think we could add all of these test cases to the tree somewhere?