https://bugzilla.kernel.org/show_bug.cgi?id=219055
--- Comment #12 from En-Wei Wu (en-wei...@canonical.com) ---
I found something suspicious in your ACPI table:
Method (UWFE, 0, Serialized) {
...
^^^^UBTC.CCI0 = CCI0 /* \_SB_.PCI0.SBRG.EC0_.CCI0 */
^^^^UBTC.CCI1 = CCI1 /* \_SB_.PCI0.SBRG.EC0_.CCI1 */
^^^^UBTC.CCI2 = CCI2 /* \_SB_.PCI0.SBRG.EC0_.CCI2 */
^^^^UBTC.CCI3 = CCI3 /* \_SB_.PCI0.SBRG.EC0_.CCI3 */
CCI0 = Zero
CCI3 = Zero
...
Notify (UBTC, 0x80) // Status Change
}
Method (_Q81, 0, Serialized) // _Qxx: EC Query, xx=0x00-0xFF
{
UWFE ()
}
_Q81 (further called UWFE()) is the method called when EC generates SCI (System
Control Interrupt) to notify OS (and ucsi_acpi_notify() will finally be called)
that the CCI (USB Type-C Command Status and Connector Change Indication) status
has changed by the USB-C controller.
Looking at UWFE(), CCI0 and CCI3 (are in System RAM) are zeroed after being
copied to EC RAM. Here is the point:
if OS tried to read this CCI event by only reading the system memory rather
than explicitly reading from EC RAM, OS might read the wrong value.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
