From: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org>,
Ashley Lai <ashley-fm2HMyfA2y6tG0bUXCXiUA@public.gmane.org>,
Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org>,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
josh.triplett-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org
Subject: Re: [PATCH v1 2/3] tpm: two-phase chip management functions
Date: Thu, 23 Oct 2014 10:22:52 +0300 [thread overview]
Message-ID: <20141023072252.GA5188@intel.com> (raw)
In-Reply-To: <20141022171603.GC12775-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Wed, Oct 22, 2014 at 11:16:03AM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 22, 2014 at 07:23:55PM +0300, Jarkko Sakkinen wrote:
> > tpm_register_hardware() and tpm_remove_hardware() are called often
> > before initializing the device. This is wrong order since it could
> > be that main TPM driver needs a fully initialized chip to be able to
> > do its job. For example, now it is impossible to move common startup
> > functions such as tpm_do_selftest() to tpm_register_hardware().
>
> > Added tpm_chip_alloc() and tpm_chip_register() where tpm_chip_alloc()
>
> It is called tpmm_chip_alloc() in this version..
>
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>
> Reviewed-By: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
>
> Looks fine, if you have to spin this again you can incorporate the
> nits.
Thanks for the review! I'll try to incorporate most (if not all of
them). I was going to comment some of the points you made but they
would have mostly been "ACK".
> > +
> > +static DECLARE_BITMAP(dev_mask, TPM_NUM_DEVICES);
>
> Not for this patch, but while this area of code is being looked at
> this should probably be an IDR/IDA like other subsytems?
Yes, it should use IDR. I'll put this into my backlog but don't
include into this patch set.
> > + if (try_module_get(pos->dev->driver->owner)) {
> > + chip = pos;
> > + break;
> > + }
>
> Not for this patch, this module stuff should be wiped in favor of chip->ops
> locking.
Definitely, horrible stuff, putting into my backlog (kref + mutex
should be a better solution).
> > +static void tpmm_chip_remove(void *data)
> > +{
> > + struct tpm_chip *chip = (struct tpm_chip *) data;
> > + dev_dbg(chip->dev, "%s\n", __func__);
>
> This print is silent in the default compile, right?
Forgotten clutter, removing it, thanks.
> > + chip->dev_num = find_first_zero_bit(dev_mask, TPM_NUM_DEVICES);
> [..]
> > + set_bit(chip->dev_num, dev_mask);
>
> Not for this patch but somehow there is no locking for dev_mask
> here. I guess it should use the driver_lock spinlock?
I'll add it anyway, thanks.
> > + chip->bios_dir = tpm_bios_log_setup(chip->devname);
>
> Not for this patch, but tpm_bios_log_setup can return NULL if
> securityfs setup fails.
Easy to fix so I'll just fix it.
> > diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
> > index 6069d13..8e2576a 100644
> > +++ b/drivers/char/tpm/tpm_atmel.c
> > @@ -138,11 +138,11 @@ static void atml_plat_remove(void)
> > struct tpm_chip *chip = dev_get_drvdata(&pdev->dev);
> >
> > if (chip) {
> > + tpm_chip_unregister(chip);
> > if (chip->vendor.have_region)
> > atmel_release_region(chip->vendor.base,
> > chip->vendor.region_size);
> > atmel_put_base_addr(chip->vendor.iobase);
> > - tpm_remove_hardware(chip->dev);
> > platform_device_unregister(pdev);
>
> Missed this before, the Atmel driver is the same as the TIS driver in
> force mode, ie it isn't going through the driver APIs, but instead
> force creating platform devices. Same comment as for TIS - I'm not
> sure devm works properly like this.
>
> I guess just add the same comment as for TIS?
Yup, makes sense.
> > diff --git a/drivers/char/tpm/tpm_i2c_infineon.c b/drivers/char/tpm/tpm_i2c_infineon.c
> > index 472af4b..6f00bc3 100644
> > +++ b/drivers/char/tpm/tpm_i2c_infineon.c
> > @@ -581,10 +581,9 @@ static int tpm_tis_i2c_init(struct device *dev)
> > int rc = 0;
> > struct tpm_chip *chip;
> >
> > - chip = tpm_register_hardware(dev, &tpm_tis_i2c);
> > - if (!chip) {
> > - dev_err(dev, "could not register hardware\n");
> > - rc = -ENODEV;
> > + chip = tpmm_chip_alloc(dev, &tpm_tis_i2c);
> > + if (IS_ERR(chip)) {
> > + rc = PTR_ERR(chip);
> > goto out_err;
>
> Nit: out_err is synonymous with 'return rc;', so all the goto out_err
> in this driver can just return;
>
> > + rc = tpm_chip_register(chip);
> > + if (rc)
> > + return rc;
> > + return 0;
>
> Nit: could just be return tpm_chip_register(chip);
>
> > @@ -619,10 +619,9 @@ tpm_st33_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id)
> > goto end;
> > }
> >
> > - chip = tpm_register_hardware(&client->dev, &st_i2c_tpm);
> > - if (!chip) {
> > - dev_info(&client->dev, "fail chip\n");
> > - err = -ENODEV;
> > + chip = tpmm_chip_alloc(&client->dev, &st_i2c_tpm);
> > + if (IS_ERR(chip)) {
> > + err = PTR_ERR(chip);
> > goto end;
> > }
>
> Nit: Same comment, 'goto end' can just be 'return rc'
>
> > - dev_info(chip->dev, "TPM I2C Initialized\n");
> > + err = tpm_chip_register(chip);
> > + if (err)
> > + goto _irq_set;
> > +
>
> Nit: Same comment
>
> > end:
> > pr_info("TPM I2C initialisation fail\n");
>
> This pr_info should be deleted
Agreed.
> > @@ -573,6 +580,8 @@ static void tpm_inf_pnp_remove(struct pnp_dev *dev)
> > struct tpm_chip *chip = pnp_get_drvdata(dev);
> >
> > if (chip) {
>
> Nit: This if in the remove callback is an anti-pattern and should be
> globally removed. If remove is being called then probe succeeded,
> there is no way for probe to succed and drvdata to be unset.
>
> > static void tpm_nsc_remove(struct device *dev)
> > {
> > struct tpm_chip *chip = dev_get_drvdata(dev);
> > - if ( chip ) {
> > + if (chip) {
>
> Same comment
>
> > @@ -836,7 +831,7 @@ MODULE_PARM_DESC(hid, "Set additional specific HID for this driver to probe");
> >
> > static struct platform_driver tis_drv = {
> > .driver = {
> > - .name = "tpm_tis",
> > + .name = "tpm_tis",
> > .owner = THIS_MODULE,
> > .pm = &tpm_tis_pm,
> > },
>
> There is no remove method here in this platform_driver, this ties into
> the question if force works or not. The tpm_tis_remove call in the
> cleanup_hardware should be done through the .remove method of this
> driver structure..
I'll try to get this tested.
> Jason
/Jarkko
next prev parent reply other threads:[~2014-10-23 7:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 16:23 [PATCH v1 0/3] tpm: prepare for TPM2 Jarkko Sakkinen
2014-10-22 16:23 ` [PATCH v1 2/3] tpm: two-phase chip management functions Jarkko Sakkinen
[not found] ` <1413995036-22497-3-git-send-email-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2014-10-22 17:16 ` Jason Gunthorpe
[not found] ` <20141022171603.GC12775-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2014-10-23 7:22 ` Jarkko Sakkinen [this message]
2014-10-22 16:23 ` [PATCH v1 3/3] tpm: fix multiple race conditions in tpm_ppi.c Jarkko Sakkinen
[not found] ` <1413995036-22497-4-git-send-email-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2014-10-22 17:26 ` Jason Gunthorpe
[not found] ` <20141022172646.GD12775-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2014-10-23 7:30 ` Jarkko Sakkinen
[not found] ` <1413995036-22497-1-git-send-email-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2014-10-22 16:23 ` [PATCH v1 1/3] tpm: merge duplicate transmit_cmd() functions Jarkko Sakkinen
[not found] ` <1413995036-22497-2-git-send-email-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2014-10-22 16:37 ` Jason Gunthorpe
2014-10-22 16:34 ` Aw: [PATCH v1 0/3] tpm: prepare for TPM2 Peter Huewe
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=20141023072252.GA5188@intel.com \
--to=jarkko.sakkinen-vuqaysv1563yd54fqh9/ca@public.gmane.org \
--cc=ashley-fm2HMyfA2y6tG0bUXCXiUA@public.gmane.org \
--cc=christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=jason.gunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
--cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
--cc=josh.triplett-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=peterhuewe-Mmb7MZpHnFY@public.gmane.org \
--cc=tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=tpmdd-yWjUBOtONefk1uMJSBkQmQ@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).