soc/intel/skylake: Probe XHCI for wake source for Internal PME

If GPE_STS indicates that the wake source is internal PME, but none of
the controllers have the PME_STS bit set, then try probing individual
XHCI ports to see if one of those was a wake source. In some cases
e.g. gsmi logging with S0ix, pci_pm_resume_noirq runs before gsmi
callback and clears PME_STS_BIT in controller register. In such cases,
xhci port status might provide a better idea about the wake source.

BUG=b:67874513

Change-Id: I841bb2abccfa9bd6553c1513e88a6306b40315e4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/22089
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>

src/soc/intel/skylake/elog.c

@@ -226,6 +226,16 @@ static void pch_log_pme_internal_wake_source(void)
 		dev_found = true;
 	}
 
+	/*
+	 * If device is still not found, but the wake source is internal PME,
+	 * try probing XHCI ports to see if any of the USB2/3 ports indicate
+	 * that it was the wake source. This path would be taken in case of GSMI
+	 * logging with S0ix where the pci_pm_resume_noirq runs and clears the
+	 * PME_STS_BIT in controller register.
+	 */
+	if (!dev_found)
+		dev_found = pch_xhci_update_wake_event(PCH_DEV_XHCI);
+
 	if (!dev_found)
 		elog_add_event_wake(ELOG_WAKE_SOURCE_PME_INTERNAL, 0);
 }