PR/53135 CVS commit: src/sys/dev/acpi

["Taylor R Campbell" <riastradh%netbsd.org@localhost>]

The following reply was made to PR port-amd64/53135; it has been noted by GNATS.

From: "Taylor R Campbell" <riastradh%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/53135 CVS commit: src/sys/dev/acpi
Date: Tue, 18 Jul 2023 10:04:15 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Tue Jul 18 10:04:14 UTC 2023
 
 Modified Files:
 	src/sys/dev/acpi: acpi_ec.c
 
 Log Message:
 acpiec(4): Set sc_got_sci only when a transaction is over.
 
 Before, when the acpiec thread noticed an SCI had been requested and
 entered acpiec_gpe_state_machine to send the query command, it would
 see the SCI is still requested -- because it had yet to acknowledge
 it by setting the query command! -- and think the EC was asking for a
 _second_ SCI.
 
 So once the first SCI transaction was over, it would start a second
 one, even though the EC hadn't asked for another -- and this would
 wedge on some ECs.
 
 Now, acpiec_gpe_state_machine waits to see what state we transition
 to before taking the SCI bit to mean we need to notify the acpiec
 thread to handle another query.
 
 That way, when the acpiec thread enters acpiec_gpe_state_machine with
 EC_STATE_QUERY, it can send the query command first, with the side
 effect of clearing the SCI bit in subsequent reads of the status
 register, and it won't think another SCI has been requested until it
 returns to EC_STATE_FREE and sees the SCI bit set again in the status
 register.
 
 Possibly relevant PRs:
 
 PR kern/53135
 PR kern/52763
 PR kern/57162
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.91 -r1.92 src/sys/dev/acpi/acpi_ec.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.