On Fri, Jul 05, 2013 at 10:03:10AM -0400, Adam Langley wrote: > On Thu, Jul 4, 2013 at 9:07 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > >> This appears to be coming from acpi_evaluate_object_typed in > >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_ppi.c#n75, > >> so I added a printk to get the actual value of |status| when it fails > >> and it's 5 (aka AE_NOT_FOUND I believe). > > In hindsight, the error was somewhat obvious. The driver is locating > the TPM object in the ACPI tables by walking the tables with a > callback [1]. The callback is using strstr to look for the substring > "TPM" in the handle of the object and returns the first that it finds. > On my system, if I alter the callback to print each match and not > abort the walk I find three values: > > \_SB_.PCI0.TPMX > \_SB_.PCI0.LPCB.TPM_ > \_SB_.PCI0.ITPM > > Of these, the second is the right one. > > (I note that the callback also appears to have a memory leak in the > case that the string doesn't contain "TPM".) > > I'm sure that the strstr() worked on the computer that it was > developed on, but it's rather fragile. I can get it working for me by > using "LPCB.TPM" as the argument to strstr(), but who's to say that > doesn't break someone else? I wonder whether there is a real PNP Id associated with that device? I have one sample ASL code that looks like: Device (\_SB.PCI0.LPCB.TPM) { Name (_HID, EisaId ("PNP0C31")) Name (_CID, EisaId ("PNP0C31")) Name (_STR, Unicode ("TPM 1.2 Device")) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xFED40000, // Address Base 0x00005000, // Address Length ) }) Does your TPM_ device look similar? That PNP0C31 can be matched in the TPM driver instead of trusting some random device names that might change from vendor to vendor. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
