From: "Jan Beulich" <JBeulich@suse.com>
To: "Matthew Fioravante" <matthew.fioravante@jhuapl.edu>
Cc: "jeremy@goop.org" <jeremy@goop.org>,
"Kent Yoder" <key@linux.vnet.ibm.com>,
"tpmdd-devel@lists.sourceforge.net"
<tpmdd-devel@lists.sourceforge.net>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
"mail@srajiv.net" <mail@srajiv.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] add tpm_xenu.ko: Xen Virtual TPM frontend driver
Date: Thu, 08 Nov 2012 08:17:32 +0000 [thread overview]
Message-ID: <509B78AC02000078000A723C@nat28.tlf.novell.com> (raw)
In-Reply-To: <509AA501.1090701@jhuapl.edu>
>>> On 07.11.12 at 19:14, Matthew Fioravante <matthew.fioravante@jhuapl.edu> wrote:
> On 11/07/2012 09:46 AM, Kent Yoder wrote:
>>> --- a/drivers/char/tpm/tpm.h
>>> +++ b/drivers/char/tpm/tpm.h
>>> @@ -130,6 +130,9 @@ struct tpm_chip {
>>>
>>> struct list_head list;
>>> void (*release) (struct device *);
>>> +#if CONFIG_XEN
>>> + void *priv;
>>> +#endif
>> Can you use the chip->vendor.data pointer here instead? tpm_ibmvtpm is
>> already using that as a priv pointer. I should probably change that name
>> to make it more obvious what that's used for.
> That makes more sense. I'm guessing your data pointer didn't exist
> during the 2.6.18 kernel which is why they added their own priv pointer.
It got introduced with 3.7-rc.
>>> @@ -310,6 +313,18 @@ struct tpm_cmd_t {
>>>
>>> ssize_t tpm_getcap(struct device *, __be32, cap_t *, const char *);
>>>
>>> +#ifdef CONFIG_XEN
>>> +static inline void *chip_get_private(const struct tpm_chip *chip)
>>> +{
>>> + return chip->priv;
>>> +}
>>> +
>>> +static inline void chip_set_private(struct tpm_chip *chip, void *priv)
>>> +{
>>> + chip->priv = priv;
>>> +}
>>> +#endif
>> Can you put these in tpm_vtpm.c please? One less #define. :-)
> Agreed, I'd rather not have to modify your shared tpm.h interface at all.
Either such accessors should be defined here, for everyone to
use (and tpm_ibmvtpm.c get changed accordingly), or the Xen
code should access the field without wrappers too (for consistency).
Jan
next prev parent reply other threads:[~2012-11-08 8:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-05 15:09 Matthew Fioravante
2012-11-06 19:39 ` Konrad Rzeszutek Wilk
2012-11-07 14:05 ` Matthew Fioravante
2012-11-07 14:48 ` Kent Yoder
2012-11-07 16:07 ` Konrad Rzeszutek Wilk
2012-11-08 15:40 ` Fioravante, Matthew E.
2012-11-07 14:46 ` Kent Yoder
2012-11-07 18:14 ` Matthew Fioravante
2012-11-08 1:10 ` Konrad Rzeszutek Wilk
2012-11-08 8:46 ` [Xen-devel] " Ian Campbell
2012-11-08 13:31 ` Konrad Rzeszutek Wilk
2012-11-08 8:17 ` Jan Beulich [this message]
2012-11-08 15:28 ` Kent Yoder
2012-11-08 15:36 ` Fioravante, Matthew E.
2012-11-08 22:06 ` [tpmdd-devel] " Kent Yoder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=509B78AC02000078000A723C@nat28.tlf.novell.com \
--to=jbeulich@suse.com \
--cc=jeremy@goop.org \
--cc=key@linux.vnet.ibm.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@srajiv.net \
--cc=matthew.fioravante@jhuapl.edu \
--cc=tpmdd-devel@lists.sourceforge.net \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®