From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.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: Sun, 2 Nov 2014 14:33:05 -0700 [thread overview]
Message-ID: <20141102213305.GB28519@obsidianresearch.com> (raw)
In-Reply-To: <1414832495-23609-8-git-send-email-jarkko.sakkinen@linux.intel.com>
On Sat, Nov 01, 2014 at 11:01:35AM +0200, Jarkko Sakkinen wrote:
> Added own class for TPM devices that is used for TPM 2.0 and onwards.
> For TPM1 old device structure is kept for backwards compatibility.
>
> Each struct tpm_chip represents a character device that is associated
> to the tpm device class.
I think we should hang back on this untill we can answer a few
questions..
I certainly thing both TPM1 and TPM2 should create the class, at the
worst only tpm2 uses it for the chardev?
> @@ -63,7 +65,7 @@ static int tpm_open(struct inode *inode, struct file *file)
> * by the check of is_open variable, which is protected
> * by driver_lock. */
> if (test_and_set_bit(0, &chip->is_open)) {
> - dev_dbg(chip->dev, "Another process owns this TPM\n");
> + dev_dbg(chip->pdev, "Another process owns this TPM\n");
> return -EBUSY;
I actually think these are mostly wrong, and are part of why I think
tpm1 should create the class too.
Except for the probe and remove function everything should log using
the TPM device name (eg tpm0) and not the platform device name, so all
of these debug statements should stay chip->dev...
And considering the volume of changes it might be better to leave
'dev' as a pointer to the tpm class rather than try and tackle that in
this giant patch..
> +static void tpm_dev_release(struct device *dev)
> +{
> +}
And all of this is upside down, the devm interm stuff should hold a
get_device() on the struct device and the kfree should live here.
> + chip->cdev.owner = chip->pdev->driver->owner;
Is that right? the cdev fops is in this module, not the driver's
module..
> + rc = cdev_add(&chip->cdev, chip->dev.devt, 1);
Can we/should we re-use the misc dev minor number assigned to TPM for
tpm0?
To me altering the dev major:minor a far more visible change than
moving the 'dev' file in sysfs. udev will handle the latter
transparently, but the former will break non-udev systems..
Jason
next prev parent reply other threads:[~2014-11-02 21:33 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 [this message]
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
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=20141102213305.GB28519@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=ashley@ashleylai.com \
--cc=christophe.ricard@gmail.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jason.gunthorpe@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 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®