linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).