> > On Fri, Aug 30, 2019 at 06:56:39PM +0900, Seunghun Han wrote: > > I got an AMD system which had a Ryzen Threadripper 1950X and MSI > > mainboard, and I had a problem with AMD's fTPM. My machine showed an error > > message below, and the fTPM didn't work because of it. > > > > [ 5.732084] tpm_crb MSFT0101:00: can't request region for resource > > [mem 0x79b4f000-0x79b4ffff] > > [ 5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16 > > > > When I saw the iomem, I found two fTPM regions were in the ACPI NVS area. > > The regions are below. > > > > 79a39000-79b6afff : ACPI Non-volatile Storage > > 79b4b000-79b4bfff : MSFT0101:00 > > 79b4f000-79b4ffff : MSFT0101:00 > > > > After analyzing this issue, I found that crb_map_io() function called > > devm_ioremap_resource() and it failed. The ACPI NVS didn't allow the TPM > > CRB driver to assign a resource in it because a busy bit was set to > > the ACPI NVS area. > > > > To support AMD's fTPM, I added a function to check intersects between > > the TPM region and ACPI NVS before it mapped the region. If some > > intersects are detected, the function just calls devm_ioremap() for > > a workaround. If there is no intersect, it calls devm_ioremap_resource(). > > > > Signed-off-by: Seunghun Han <kkamagui@xxxxxxxxx> > > --- > > drivers/char/tpm/tpm_crb.c | 25 +++++++++++++++++++++++-- > > 1 file changed, 23 insertions(+), 2 deletions(-) > > This still seems to result in two drivers controlling the same > memory. Does this create bugs and races during resume? > > Jason When I tested this patch in my machine, it seemed that ACPI NVS was saved after TPM CRB driver sent "TPM2_Shutdown(STATE)" to the fTPM while suspending. Then, ACPI NVS was restored while resuming. After resuming, PCRs didn't change and TPM2 tools such as tpm2_pcrlist, tpm2_extend, tpm2_getrandoms worked well. So, according to my test result, it seems that the patch doesn't create bugs and race during resume. Seunghun
