lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 2 Nov 2014 14:33:05 -0700
From:	Jason Gunthorpe <>
To:	Jarkko Sakkinen <>
Cc:	Peter Huewe <>, Ashley Lai <>,
	Marcel Selhorst <>,,,,,
Subject: Re: [PATCH v5 7/7] tpm: create TPM 2.0 devices using own device class

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

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

> +	rc = cdev_add(&chip->cdev, chip->dev.devt, 1);

Can we/should we re-use the misc dev minor number assigned to TPM for

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists