I spotted another typo (see the attached comment). I approve it at the same time to not waste time in back and forth comments.

As I understand, HWEIGHT* are always supposed to be run on compile-time constants, so they could just be defined to this const_bitcount macro.

I can create a patch for this if this seems like a good solution to you all.

Handle negative return value from callback.

Rebase on top of main branch.

In D50848#1164156, @emaste wrote:

Hmm, OK. The struct is different and we might end up with a slightly puzzling build failure if things end up cross-threaded, but I suppose it's not really different than the status quo.

Thank you @emaste for the bugfix. I was not sure myself if the + 1 was intended.

Address comment from @bz: default the #if/#else logic to the latest version. A user has to define LINUXKPI_VERSION to request the older variant.

Address comment from @bz: move the definition of div64_ul() just after div64_u64().

Address comments from @wulf and @bz: don’t introduce a <uapi/linux/eventfd.h> header.

In D50863#1161012, @bz wrote:

In D50863#1161009, @wulf wrote:

General convention in at least drm-kmod is to not redefine ACPICA objects if it is possible. Porting of this code is mostly just a changing of symbol case and adding/removing of underscores. drm-kmod does not even guards these changes with #ifdefs

I picked a random file ( in v6.6 drivers/gpu/drm/radeon/radeon_acpi.c ) and it seems everything there got CamelCased without any #ifdefs. It's just an unnecessary diff to vendor and maintenance.

No idea how much of this was done in drm-kmod but I am not going to rewrite case in entire files because of this. I had not compiled files or #ifdef'ed out the entire logic. Not gong to fly anymore. Remove the #ifdefs from drm-kmod and reduce the diff to upstream and make maintenance easier by having one place to edit and not 117. That's what LinuxKPI is for.

Looks good to me!