>> + notify_remote_via_evtchn(priv->evtchn); >> + >> + ordinal = be32_to_cpu(*((__be32 *) (buf + 6))); > > Um, + 6? Why? Is there an #define for that magic constant? > Should this value be read before you do the wait_for_tpm_stat stuff?
This is hardcoded to 6 even in tpm.c. Time for a #define... > Otherwise it looks OK to me. Should this go through me or Kent? > And if so, is Kent waiting for my feedback? My comments were minor -- I was expecting feedback on your earlier comments before merging. I think this should go through the tpmdd maintainer if its going to live in drivers/char/tpm though. Kent > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > tpmdd-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tpmdd-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
