In D51107#1166799, @takawata wrote:

In D51107#1166682, @wulf wrote:

There are more ArrowLake I2C device ids: 7750 and 7751. At least in share/misc/pci_vendors

According to the Datasheet, I2C#4(7750),I2C#5(7751) only supports PIO mode, and I'm not sure the PIO mode only device will work or not.

https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/core-ultra-200h-and-200u-series-processors-datasheet-volume-1-of-2/intel-serial-i-o-inter-integrated-circuit-i2c-controllers/

There are more ArrowLake I2C device ids: 7750 and 7751. At least in share/misc/pci_vendors

LGTM

LGTM

As number of object types we handle in LKPI does not exceed 10 it may counts as not a rewrite of ACPICA

In D50863#1161018, @imp wrote:

In D50863#1161017, @wulf wrote:

In D50863#1161016, @imp wrote:

Proper compat symbols will also make future ports easier

It is not about of proper symbols. It is about of adding of LKPI objects which differs only in character case in the name

Which is just as trivial to paper over with #defines so you don't have to change it next time which makes future ports faster since you don't have to detour around already solved trivial problems. When I've done it for other things in the tree, it's helped prevent death of a thousand cuts...

In D50863#1161016, @imp wrote:

Proper compat symbols will also make future ports easier

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.

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 even guards these changes with #ifdefs

@dumbbell FYI. Take a look at https://github.com/lutzbichler/drm-kmod/tree/pr/6.15. It seems that lutzbichler has advanced to drm-kmod v6.15

In D50315#1158083, @arrowd wrote:

Yep, I messed up and it was still using libinotify's libinotify.h. I've redone the test properly and found that the program starts behaving differently if linked to libinotify.

The test I'm running is

./inotify-test .
touch a
rm a

When not linked with libinotify, I get

a created in watched directory
a was opened
a opened for writing was closed
a delete from watched directory

When linked to libinotify, I only get

a created in watched directory
a deleted from watched directory

I don't think it is worth fixing, because this mess can only arise for 15-CURRENT users that do not recompile their ports after this change hits the tree.

In D50315#1156202, @markj wrote:

In D50315#1155735, @wulf wrote:

As I see, libinotify event values were just copied from Linux, so it may have sense to change system ones to make linuxolator support simpler

This is fine for most of the flags, I will change it. libinotify has this weird thing:

37 /* Flags for the parameter of inotify_init1. */                                                                                                                                                                                                                                                                           
38 #define IN_CLOEXEC      02000000        /* Linux x86 O_CLOEXEC */                                                                                                                                                                                                                                                         
39 #define IN_NONBLOCK     00004000        /* Linux x86 O_NONBLOCK */

Some applications will call inotify_init1(O_CLOEXEC) instead of specifying IN_CLOEXEC. In my inotify.h I just defined those flags to be equal, but to preserve compatibility with libinotify we have to support both values. I guess this is best handled in libc.

As I see, libinotify event values were just copied from Linux, so it may have sense to change system ones to make linuxolator support simpler

Current ABI is not compatible. libinotify events have different values compared with system provided ones.
You must use libinotify header to link with libinotify or change system one to be ABI-compatible.

LGTM

LGTM

In D50498#1153913, @aokblast wrote:

@wulf Are you still have concern on the read_kbd_data? If not, I plan to create the patch for merging.

Should we cache read_kbd_data() rather than reread it?

In D50315#1150660, @markj wrote:

In D50315#1150102, @wulf wrote:

In D50315#1149915, @markj wrote:

In D50315#1149724, @arrowd wrote:

In test "Bugfix tests":

failed: receive IN_ATTRIB for bugst-workdir/1 on hardlink delete
failed: Not receive IN_DELETE_SELF for bugst-workdir/1 on hardlink delete

This one is tricky to fix, I need to think about it.

IIRC IN_DELETE_SELF is generated when the file link number goes from 1 to 0

Some laptops powers radio module even they are switched off. You may try to reinsert wireless card or discharge battery.

In D50066#1141903, @aokblast wrote:

1. You have 1 patch for v2 header so I can abandon this patch?

It broke bt adaptor for me at first early version run too due to bug in rtlbt_load_fwfile() which is fixed in my version now

I am about to commit V2 firmware support. It worked for me with at least one 8852CE adaptor. just test it.

LGTM
Please add 2 more I2C device:

4dc5  Jasper Lake Serial IO I2C Host Controller #4
4dc6  Jasper Lake Serial IO I2C Host Controller #5

I was not able to read nor RGB mode nor Thermal policy from BIOS

In D48983#1117257, @mav wrote:

I have no objections, but I wonder whether maximum of 3 vs 7 might be model-specific?

Fix manpage and braces