All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
	Ashley Lai <ashley@ashleylai.com>,
	Marcel Selhorst <tpmdd@selhorst.net>,
	tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	josh.triplett@intel.com, christophe.ricard@gmail.com,
	jason.gunthorpe@obsidianresearch.com
Subject: Re: [PATCH v5 7/7] tpm: create TPM 2.0 devices using own device class
Date: Wed, 5 Nov 2014 09:40:29 +0200	[thread overview]
Message-ID: <20141105074029.GA16217@intel.com> (raw)
In-Reply-To: <20141104181433.GA28387@obsidianresearch.com>

On Tue, Nov 04, 2014 at 11:14:33AM -0700, Jason Gunthorpe wrote:
> On Tue, Nov 04, 2014 at 01:47:34PM +0200, Jarkko Sakkinen wrote:
> 
> > > > I used the class 'tpm' only for TPM 2.x because I didn't want to
> > > > break the binary compatibility for TPM 1.x anyway. In ideal situtation
> > > > both would be character devices inside the class 'tpm' and there would
> > > > be sysfs attribute such as 'family' to mark the protocol to be used.
> > > 
> > > You can create the class without moving away from miscdev...
> > > 
> > > Not having the device creates way to much difference that has to be
> > > supported, way too messy.
> > 
> > I have to admit that I'm not quite following here but I assume that
> > you restated this below in more verbose way and this is basically the
> > same argument :)
> 
> I mean, if we have a patch that does:
> 
> struct tpm_chip {
>    struct device cdev;  // the class device
>    struct device *pdev; // the 'platform' device chip is bound too
> 
>    struct device *dev = pdev; // Temporary Compatability
> [+ device_register/etc/etc]
> 
> Then both cdev and pdev should always be valid. We should not have cdev
> be valid for TPM2 and invalid for TPM1, that is just a big mess.

As a first patch I'll do a patch that does dev -> pdev rename and
nothing else. IMHO it's clean and easy to review if no other changes
are contained. One reason for this is obviously that I want to use
cdev for struct cdev not for the class device.

> Just this change is perfectly safe, it creates the /sys/class/tpm/tpm0
> directory, but doesn't change anything already existing
> 
> Then, a patch: go through and replace all uses of chip->dev with &chip->cdev in
> 90% of cases
> 
> Another patch: use chip->pdev for the handfull of the rest, and drop
> dev entirely
> 
> Then a patch: Drop misc_register entirely, no compat stuff. Explain
> clearly the resulting sysfs changes, CC the various people who monitor
> the sysfs API, act on any feedback. I'm hoping it is an OK change.
> [ If it is not OK then we can talk about using it only for TPM2 or
>   whatever ]
> 
> > I think the current variable name "dev" is miss-leading. The
> > use of "pdev" would document better the appropriate use for that
> > field (i.e. for the most cases DON'T use it).
> 
> Yes, see above :)
> 
> > I think that would be a mess. The way things are done in this v5
> > patch set is actually quite coherent and it does not break backwards
> > compatibility because the "proper" device hierarchy is only used for
> > TPM 2.0 devices.
> 
> I mean, just do something like this:
> 
> if (chip->id == 0)
>    chip->cdev.devt = MKDEV(MISC_MAJOR, TPM_MINOR)
> else
>    chip->cdev.devt = [.. dynamic alloc_chrddev_region ..]
> 
> Very simple, keeps the major/minor for TPM0, moves the 'dev' file to
> the new location in sysfs.
> 
> I can't find another example of this in the kernel, so I don't know
> what the thinking is..
> 
> Jason

  parent reply	other threads:[~2014-11-05  7:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-01  9:01 [PATCH v5 0/7] TPM 2.0 support Jarkko Sakkinen
2014-11-01  9:01 ` [PATCH v5 1/7] tpm: merge duplicate transmit_cmd() functions Jarkko Sakkinen
2014-11-01  9:01 ` [PATCH v5 2/7] tpm: two-phase chip management functions Jarkko Sakkinen
2014-11-01  9:01 ` [PATCH v5 3/7] tpm: fix multiple race conditions in tpm_ppi.c Jarkko Sakkinen
2014-11-01  9:01 ` [PATCH v5 4/7] tpm: TPM 2.0 baseline support Jarkko Sakkinen
2014-11-01  9:01 ` [PATCH v5 5/7] tpm: TPM 2.0 CRB Interface Jarkko Sakkinen
2014-11-01  9:01 ` [PATCH v5 6/7] tpm: TPM 2.0 FIFO Interface Jarkko Sakkinen
2014-11-01  9:01 ` [PATCH v5 7/7] tpm: create TPM 2.0 devices using own device class Jarkko Sakkinen
2014-11-02 21:33   ` Jason Gunthorpe
2014-11-03  5:41     ` Jarkko Sakkinen
2014-11-03 21:38       ` Jason Gunthorpe
2014-11-04 11:47         ` Jarkko Sakkinen
2014-11-04 12:05           ` Jarkko Sakkinen
2014-11-04 18:14           ` Jason Gunthorpe
2014-11-04 20:38             ` Jarkko Sakkinen
2014-11-04 20:49               ` Jason Gunthorpe
2014-11-04 23:00                 ` Jarkko Sakkinen
2014-11-05  7:40             ` Jarkko Sakkinen [this message]
2014-11-05 17:48               ` Jason Gunthorpe
2014-11-06  8:58                 ` Jarkko Sakkinen
2014-11-01  9:33 ` [PATCH v5 0/7] TPM 2.0 support Jarkko Sakkinen

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=20141105074029.GA16217@intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=ashley@ashleylai.com \
    --cc=christophe.ricard@gmail.com \
    --cc=jason.gunthorpe@obsidianresearch.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=josh.triplett@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=tpmdd-devel@lists.sourceforge.net \
    --cc=tpmdd@selhorst.net \
    /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.