On 03/31/2015 09:05 AM, Stefan Berger wrote: > Signed-off-by: Stefan Berger <stef...@linux.vnet.ibm.com> > --- > hw/tpm/tpm_tis.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Eric Blake <ebl...@redhat.com> However; > > diff --git a/hw/tpm/tpm_tis.c b/hw/tpm/tpm_tis.c > index 815c8ea..3f42982 100644 > --- a/hw/tpm/tpm_tis.c > +++ b/hw/tpm/tpm_tis.c > @@ -814,7 +814,7 @@ static void tpm_tis_mmio_write_intern(void *opaque, > hwaddr addr, > tis->loc[locty].state == TPM_TIS_STATE_COMPLETION) { > /* drop the byte */ > } else { > - DPRINTF("tpm_tis: Data to send to TPM: %08x (size=%d)\n", > + DPRINTF("tpm_tis: Data to send to TPM: 0x%08" PRIx64 " > (size=%d)\n", This caused me to do a double-take (usually, a variable named 'size' is size_t, in which case %d is wrong; but here it is 'unsigned size'). Also, there is another suspicious DPRINTF earlier in the function; maybe it's worth a v3? I'm talking about: DPRINTF("tpm_tis: write.%u(%08x) = %08x\n", size, (int)addr, (uint32_t)val); but there are some 32-bit platforms where uint32_t is a long, so %x will cause a compiler warning, as compared to PRIx32. And if you are just going to cast, why not cast directly to int; on the other hand, if what you are printing is truly 64-bit, then why not use %016x instead of %08x (that is, when printing a 64-bit number, having a minimum of 8 0-padded bytes doesn't make it easy to distinguish a 10-character from 11-character printout, while consistently padding all output to 16 characters makes alignment easier to spot). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature