All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.