System boots in sleep after PNLF patch (m3-7y30 mix plus)

[RehabMan]

Kextcache have these kexts, but I didn't see any message about these two kexts in kernel.log

They are listed only in the second kextcache output (after KernelCache ID)... I think this means they are not placed in cache.
It probably will require some fiddling with the VoodooI2C kexts Info.plist (IOProbeScore/etc).

 

[missile0407]

They are listed only in the second kextcache output (after KernelCache ID)... I think this means they are not placed in cache.
It probably will require some fiddling with the VoodooI2C kexts Info.plist (IOProbeScore/etc).

So...is there any method to test about this? Like add IOProbeScore variable manually or something?

 

[RehabMan]

So...is there any method to test about this? Like add IOProbeScore variable manually or something?

The IOProbeScore can be set in the kext Info.plist.

 

[missile0407]

The IOProbeScore can be set in the kext Info.plist.

Roger that.
Does IOProbeScore means priority that kernel going to load? Just like the priority variable settings on Ubuntu repository.
If so, do you know or is there any reference that explain which data is higher priority than disabler?

 

[RehabMan]

Roger that.
Does IOProbeScore means priority that kernel going to load? Just like the priority variable settings on Ubuntu repository.
If so, do you know or is there any reference that explain which data is higher priority than disabler?

It affects which kext is started amongst competing kexts for the same IOKit match.
You should probably read about IOProbeScore in Apple's kernel extension developer documentation.

 

[missile0407]

It affects which kext is started amongst competing kexts for the same IOKit match.
You should probably read about IOProbeScore in Apple's kernel extension developer documentation.

Initially investigated these kexts. Seems like we should have a scenario to solve it.

VoodooI2C has set IOProbeScore to 9999, so I think is other causes.
My guess is that both AppleIntelLpssI2C and disabler are based on IOPCIDevice as IO Provider.
And VoodooI2C is based on IOService.
Maybe IOPCIDevice had higher priority than IOService.

Just my 2 cents.

 

[RehabMan]

Initially investigated these kexts. Seems like we should have a scenario to solve it.

VoodooI2C has set IOProbeScore to 9999, so I think is other causes.
My guess is that both AppleIntelLpssI2C and disabler are based on IOPCIDevice as IO Provider.
And VoodooI2C is based on IOService.
Maybe IOPCIDevice had higher priority than IOService.

Just my 2 cents.

Class hierarchy does not determine priority.
I think it has to do with matching criteria. One uses IOPCIMatch and the other uses IONameMatch.

 

[missile0407]

Class hierarchy does not determine priority.
I think it has to do with matching criteria. One uses IOPCIMatch and the other uses IONameMatch.

Hmm, that make sense.
According from author's guide, I2C become as PCI-E device since Skylake.
I'll try modify VoodooI2CPCIDriver to match device from IOPCIDevice class.

 

[RehabMan]

Hmm, that make sense.
According from author's guide, I2C become as PCI-E device since Skylake.
I'll try modify VoodooI2CPCIDriver to match device from IOPCIDevice class.

Yeah, some experimentation on the matching criteria would be a good thing to work on...
The idea would be to insure that VoodooI2C matches better (higher IOProbeScore) than the Apple I2C kexts.
Disabler may or may not be required to accomplish that.

 

[missile0407]

Yeah, some experimentation on the matching criteria would be a good thing to work on...
The idea would be to insure that VoodooI2C matches better (higher IOProbeScore) than the Apple I2C kexts.
Disabler may or may not be required to accomplish that.

Morning!

I tried set IOProviderClass to IOPCIDevice, rename IONameMatch to IOPCIMatch and set a value from disabler in VoodooI2CPCIController.
Unfortunately the situation still a same, AppleIntelLpssI2C occupied the device first when removed disabler.
The good news is if I remove AppleIntelLpssI2C* but keep IOPCIDevice settings in VoodooI2CPCIController, the kext loads and trackpad back to work. Seems like IOPCIDevice match method is work on this kext.

Here's PR file included modified VoodooI2C.