tpmdd-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Christophe Ricard
	<christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org"
	<tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: tpm: Introduce TPM_CHIP_FLAG_VIRTUAL
Date: Thu, 31 Mar 2016 09:57:57 -0400	[thread overview]
Message-ID: <56FD2CE5.2080703@linux.vnet.ibm.com> (raw)
In-Reply-To: <CALD+uuy43FyxE_s7HR2mz6G=E4uwFh63oJLxJ8AF0i-0-AfT=Q@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2404 bytes --]

On 03/31/2016 09:06 AM, Christophe Ricard wrote:
> Hi Stefan,
>
> [Adding tpmdd mailing list].
> I agree that it would work when calling tpm_chip_alloc with NULL, my 
> only worry is that it is not chain the same way in other drivers.
> Currently we are not using chip->dev.drvdata to store chip but 
> platform data.
> chip is stored into the device platform data from the physical layer 
> (e.g: i2c, spi, pdev...).

Yes, aware of that.

>
> At the end, I think this would not cause any issue as 
> TPM_CHIP_FLAG_VIRTUAL will covert it. However in the current form i 
> believe
> It looks like priv field will be required only for the purpose of 
> vtpm_proxy.

Yes. And a priv field could be introduced in the chip structure to be 
used by the tpm_vtpm_proxy driver.

>
> After previous discussion with Jarkko and Jason, priv is currently on 
> its way to get removed... https://patchwork.kernel.org/patch/8705291/

Seen it.
>
> Would it be reasonable to use chip->dev.platform_data to store the 
> newly allocated proxy_dev instead of using a dedicated field (priv)?

That's a possibility we could look into.

       Stefan


>
> Best Regards
> Christophe
>
>
> 2016-03-31 13:43 GMT+02:00 Stefan Berger <stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org 
> <mailto:stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>>:
>
>     On 03/30/2016 05:56 AM, Christophe Ricard wrote:
>
>         Hi Stefan,
>
>         One question here:
>           int tpm_sysfs_add_device(struct tpm_chip *chip)
>           {
>         - int err;
>         - err = sysfs_create_group(&chip->dev.parent->kobj,
>         - &tpm_dev_group);
>         + int err = 0;
>         +
>         + if (!(chip->flags & TPM_CHIP_FLAG_VIRTUAL))
>         + err = sysfs_create_group(&chip->dev.parent->kobj,
>         + &tpm_dev_group);
>         + else {
>         + dev_set_drvdata(&chip->dev, chip);
>         What is the purpose of setting chip->dev.drvdata with chip ?
>         I don't see any place with a dev_get_drvdata. Can you explain ?
>
>
>     The subsequent patches implement a device driver that calls
>     tpm_chip_alloc() with NULL for the driver parameter and
>     dev_set_drvdata(), that typically gets called in
>     tpmm_chip_alloc(), is not called. There are dev_get_drvdata()
>     calls in tpm-sysfs.c that would not work without us calling
>     dev_set_drvdata() here.
>
>        Stefan
>
>


[-- Attachment #1.2: Type: text/html, Size: 5847 bytes --]

[-- Attachment #2: Type: text/plain, Size: 291 bytes --]

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

      reply	other threads:[~2016-03-31 13:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CALD+uuyndJkab4YxEaAJA1XX1Wsy9QqMRLAh7ewibpUYQiNPAg@mail.gmail.com>
     [not found] ` <56FD0D77.6090905@linux.vnet.ibm.com>
     [not found]   ` <56FD0D77.6090905-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2016-03-31 13:06     ` tpm: Introduce TPM_CHIP_FLAG_VIRTUAL Christophe Ricard
2016-03-31 13:57       ` Stefan Berger [this message]

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=56FD2CE5.2080703@linux.vnet.ibm.com \
    --to=stefanb-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
    --cc=christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /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;
as well as URLs for NNTP newsgroup(s).