I still do not get how this is supposed to fully work but I assume the shortcut from before remains right. I'd say for me you can add:

A concurrent patch was committed two days ago; see D57444.

Individual reviews and a new removal of the KPI in a separate review.

In D58834#1357993, @jhb wrote:

I'm also working on merging changes to iw_cxgbe that should update it btw. For mthca we can find an upstream Linux commit to pull across. I think we should probably just move consumers to the newer KPI.

Try to track the correct branch; arc does not like me today. Take II.

Thanks to @kib for fixing mlx5 and ipoib:
fdcb52d03688 ofed/ipoib: convert to timer_setup linuxKPI
814cd919981e mlx5(4): convert to timer_setup() linuxKPI

Heads up: this change causes a regression in the InfiniBand/RoCE stack on main. Filed as PR <298485>: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298485.
Because FreeBSD's sysfs emulation is sysctl-backed and has no symlinks, parenting the kobject under dev->parent does not add a view alongside the class view the way the Linux symlink does - it replaces it.
ibcore sets dev.parent on both its devices (ib_sysfs.c:1340, ib_uverbs_main.c:1061), so sys.class.infiniband_verbs.uverbsN.ibdev and sys.class.infiniband.mlx5_N.* disappeared,
moving to sys.device.mlx5_coreN.*. libibverbs enumerates exclusively via the class view, so ibv_devices and ibv_devinfo now report no devices at all on a fully working adapter, with no error output.
Confirmed by reverting just this hunk and rebuilding.
Also note device_register() in the same header still class-parents unconditionally, so the two registration paths now behave differently for identical input.
Suggestions for a fix that preserves your DRM intent are in the PR.

Add missing lkpi_devres_release_free_list(&pdev->dev);

Anyone care to look at the parent in the stack which adds option LINUXKPI_DEBUG to the build system, etc.?

Otherwise I'll make those variables and tunables allowing us to turn them on or off or something more selectively.

I will hold back on this one for a bit until my WITNESS mystery posted on current (and hackers previously) is solved unless someone can assure me turning this on will not immediately kill drm-kmod (drivers).

I'll commit this with my next batch.

This seems reasonable to me

Address feedback from @bz.

I don’t have a better suggestion to make w.r.t. to the best location for this code.

I guess Phabricator ate the commit title because it does not mean much now :-)