On Thu, Jul 11, 2019 at 12:32 PM Safford, David (GE Global Research, US) <david.safford@xxxxxx> wrote: > As far as I can tell, some OEMs simply are putting bad data in the tables. > I have seen at least one report where a BIOS update did fix the problem. The issue is that the CRB region is mapped into a region marked as ACPI NVS. drivers/acpi/nvs.c claims this region and as a result a resource conflict is generated. Since Windows is clearly fine with other drivers using ACPI NVS regions, the correct fix involves figuring out a way to either share these resources or allow tpm_crb to reclaim the region from the NVS driver. Note that the NVS driver's behaviour is to save and restore NVS regions over suspend/resume, so simply forcibly allocating the resource will result in two separate codepaths touching the region on resume - this seems like a bad outcome. Ideally this could be solved generically, but practically (given we've only seen this around TPMs, as far as I can tell) adding a hook to nvs.c that allowed drivers aware of the issue to have the space handed off to them might be easier. Have you seen this on any non-AMD systems?
