[Solved] E7440: Instant wake with BCM94360CS2 card in WWAN slot

[gelomon]

Hello Everyone. It's me again. I have a lying BCM94360CS2 from my old hack Inspiron 5558 which reached it's end-of-life after 5ish years. Now I want to utilize it so I can minimize also using kexts on my hack. 

I manage to fit with an adapter and a MHF4 cable (e7440 uses U.FL connection on default mini pcie card) and use it flawlessly enjoying the benefits, perfect handoff, airdrop, unlock with apple watch and faster wifi speeds and no bluetooth stutters.

 

After sometime of enjoying, I closed the lid and the issue now appears. My laptop no has instant wake.

Digging in some logs, this is the only thing I found. Nothing helpful.

 

My hack sleep is working fine with Intel Wifi card

 

2022-12-10 20:59:56 +0800 DarkWake            	DarkWake from Normal Sleep [CDN] : due to RTC LID0/Maintenance Using BATT (Charge:100%) 32 secs   
2022-12-10 20:59:56 +0800 HibernateStats      	hibmode=0 standbydelaylow=10800 standbydelayhigh=86400                     	          48       
2022-12-10 20:59:56 +0800 WakeTime            	WakeTime: 2.084 sec                         
2022-12-11 13:28:22 +0800 DarkWake            	DarkWake from Normal Sleep [CDN] : due to LID0 PXSX/Network Using AC (Charge:100%) 15 secs   
2022-12-11 13:28:22 +0800 WakeDetails         	DriverReason:XHC - DriverDetails:                                          
2022-12-11 13:28:22 +0800 HibernateStats      	hibmode=0 standbydelaylow=10800 standbydelayhigh=86400                     	          182     
2022-12-11 13:28:22 +0800 WakeTime            	WakeTime: 2.322 sec 

 

 

Any help would be greatly appreciated

 

This is my hack with the BCM94360CS2

Another confusing log from pmsert -g assertions. Keyboard was working fine and not causing instant wake on intel wifi card

 

 

Assertion status system-wide:
   BackgroundTask                 0
   ApplePushServiceTask           0
   UserIsActive                   1
   PreventUserIdleDisplaySleep    0
   PreventSystemSleep             0
   ExternalMedia                  0
   PreventUserIdleSystemSleep     0
   NetworkClientActive            0
Listed by owning process:
   pid 170(WindowServer): [0x0000001e0009806c] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle serviceID:1000003c7 name:AppleUserHIDEventSe product:Keyboard eventType:3"  
	Timeout will fire in 10800 secs Action=TimeoutActionRelease
No kernel assertions.
Idle sleep preventers: IODisplayWrangler

 

[Hervé]

The slot in question is combo mSATA/WWAN and therefore supports USB on top of SATA + PCIe services.

 

Instant wake is often due to a device not going in sleep mode because it is not powered down; in your case, it would have to be the USB-based Bluetooth module of the card. I'd say you need to adjust power settings of your USB ACPI devices since I expect the WWAN slot was not initially taken into account given that there was no USB device attached to it. I encountered a similar issue when I replaced a (wifi-only) DW1510 card by a (combo Wifi/BT) BCM94360CS2 in my Vostro 200 desktop. See here for details (in my case, a patched DSDT is used; in your case, I expect you use a SSDT).

 

Don't understand what you say about your assertion log and the "Keyboard working fine and not causing instant wake on the Intel Wifi" statement. I fail to see the link between your keyboard and the Intel wireless cards. Anyway, your Intel Wifi may not be fitted with Bluetooth or, at least, a bluetooth module that was detected in macOS. Check your USB ports in SysInfo... So, as indicated above, identify the USB port used by your card and patch/adjust the associated UHC/EHC/XHC ACPI device accordingly.

[gelomon]

I have created a new USB port Mapping. Mapped the new Bluetooth device on its new location, but still I got instant wake. I’m already running out of ideas on how to fix this issue.

 

I was surprised, there was a USB device attached to the WWAN port. It was detected when I remapped the USB ports before posting my inquiry here.

 

About the keyboard, that was the last assertion log after instant wake. I don’t know why it’s there. I got your point, I also don’t see any connection. 
 

I will try digging into the port and see if I can find anything. Can you suggest other things I can check?

See below remapped USB ports:

Edited December 11, 2022 by gelomon
Additional Info and images

[Hervé]

As I said, you ned to adjust the power settings attached to the USB port supporting the Bluetooth module of your card. Check your IOReg + ACPI tables.

[Jake Lo]

try replacing with this USB Port kext. Added port 07

USBPorts_E7440.kext.zip

[gelomon]

Thanks @Jake Lo for the USBPorts, It's the same with my newly generated in which the Bluetooth was on port 07.

 

Hi @Hervé, Thanks for some insights. I have solved the instant wake issue after multiple hours of debugging and checking what went wrong I finally found the issue and fixed it with just an SSDT Modification. I found out that it's not the USB port not supporting the bluetooth but the WiFi device itself. I also found that the SDCard Reader might also cause instant wake due to unhandled call.

 

See below for the fix:

 

Going back to the logs I got from pmset -g log we can see that it is reporting DarkWake cause is due to LID0 PXSX/Network

 

2022-12-11 13:28:22 +0800 DarkWake            	DarkWake from Normal Sleep [CDN] : due to LID0 PXSX/Network Using AC (Charge:100%) 15 secs

 

When checking IOReg and querying what device is on PXSX,

 

ioreg -l | grep -i PXSX | grep -i acpi-path
    | |   |     |   "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/RP05@1c0004/PXSX@0"
    | |   |     |   "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/RP06@1c0005/PXSX@0"

 

I checked hackintool to verify what device really is and found out that it is the Card Reader and the new BCM94360CS2 WiFi device.

 

 

Drilling more further to ACPI searching for this two devices, I found out that these devices are calling the _PRW Method 

We can see below that both RP05.PXSX and RP06.PXSX calls the GPRW Method which we implemented via SSDT-E7440.aml

 

RP05.PXSX

 

RP06.PXSX

 

By inspecting the devices, I found out that these GPRW calls are passing 0x69 and 0x09 respectively.

I checked the SSDT-E7440.aml and found that these arguments are not handled by the SSDT.

 

 

I created more granular SSDTs for everything implemented on the SSDT-E7440.aml more easy debugging.

I created SSDT-GPRW.aml which implements the the missing 0x69 and 0x09 I also included the original 0x6D and I removed the 0x0D (this is not called / passed anywhere on the DSDT).

 

Edited December 12, 2022 by gelomon
Removed duplicate post that merged into one

[Hervé]

Interesting... No such additional patches required on my E7270 which is fitted with a BCM94360CS2. The card also attached to RP05.PXSX and _PRW method does call on GPRW with (0x69,0x4D) arguments; same applies to SD card reader attached to RP11.PXSX. Add-on patched table SSDT-GPRW.aml does not care for Arg0 being set to 0x69, yet sleep works perfectly well.

 

On the PCIe side, it's kinda weird that wake was working when you had an Intel card in that slot but not when the BCM94360CS2 was installed. Hence why I assumed it would be the USB-based Bluetooth module that caused instant wake.

 

Well done on your fix.

[gelomon]

Do you also use the WWAN port used on your e7270? I think we have a confusion, my intel wifi card is working but it is on the original wifi/bt mini-pcie port.

I also don't know why is this the case on my end. Maybe due to updated bios? I am on the latest a28 which was released on 2019.

 

Thanks again for the inputs about how you fix the DSDT on your other hack. At first I planned to just rename on DSDT via Opencore but that would only be trivial when I can just edit the GPRW and add the new handling for other arguments present on my DSDT.

 

 

 

[Hervé]

Yes, sorry I indeed made a confusion thinking you had the Intel card in that WWAN slot when it's clearly a half-size mini-PCIe card you had in the WLAN slot.

 

E7270's WWAN slot is M.2 Key B so unsuitable for Key A/E Wifi/BT cards. What I meant was that, in the case of my E7270, there is no instant wake issue due to replacement GPRW method not caring for values provided in the GPRW (0x69, 0x04) call programmed under the WLAN ACPI device. It'd be interesting to see what call is made in your DSDT under the RP0x.PXSX device used by the WLAN card/slot.

[gelomon]

Seems like the WWAN port has it's own Args passed. it is the only one passing the GPRW (0x09, 0x04)

 

It's the only one passing the 0x09. I don't know why is this happening, but handling it on the SSDT-GPRW  fixed it. maybe it's the default thing on combo WWAN/mSATA port.

I also tried disabling the default WiFi/BT mini-pcie port on BIOS but still instant wake happens.

 

I am just happy now that this is the fix. I was worried and can't concentrate last time as the fans ramping up fast on instantwake lol

 

                Device (PXSX)
                {
                    Name (_ADR, Zero)  // _ADR: Address
                    Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                    {
                        Return (GPRW (0x09, 0x04))
                    }
                }