I recently switched to 2.6.35-rcX-wl (wireless-testing) for development and discovered that only the first issued suspend/hibernate was successful, every subsequent suspend/hibernate failed with the following in dmesg:

legacy_suspend(): pnp_bus_suspend+0x0/0x6a returns 28
PM: Device 00:02 failed to suspend: error 28
PM: Some devices failed to suspend

Device 00:02 is owned by the tpm_tis driver. Unloading tpm_tis before suspend fixes this issue for me.

I didn't have such problems with kernels <2.6.35 and it seems the culprit is
the patch "TPM: workaround to enforce PCR updates across suspends" which
introduced a return value in tpm_pm_suspend if transmit_cmd fails:

[...]
-       tpm_transmit(chip, savestate, sizeof(savestate));
-       return 0;
+       /* for buggy tpm, flush pcrs with extend to selected dummy */
+       if (tpm_suspend_pcr) {
+               cmd.header.in = pcrextend_header;
+               cmd.params.pcrextend_in.pcr_idx = cpu_to_be32(tpm_suspend_pcr);
+               memcpy(cmd.params.pcrextend_in.hash, dummy_hash,
+                      TPM_DIGEST_SIZE);
+               rc = transmit_cmd(chip, &cmd, EXTEND_PCR_RESULT_SIZE,
+                                 "extending dummy pcr before suspend");
+       }
+
+       /* now do the actual savestate */
+       cmd.header.in = savestate_header;
+       rc = transmit_cmd(chip, &cmd, SAVESTATE_RESULT_SIZE,
+                         "sending savestate before suspend");
+       return rc;
[...]

In the meantime I was able to find a workaround for this issue and sent a PATCH to the tpmdd-devel list [1] but unfortunately got no reply yet. Since I have really _no_ knowledge at all about tpm stuff I'd like to get the patch reviewed first from somebody working on the tpm stuff. 

Thanks,
Helmut

[1] http://sourceforge.net/mailarchive/forum.php?thread_name=201006091511.09810.helmut.schaa%40googlemail.com&forum_name=tpmdd-devel