Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?

Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?

[Peter Hüwe]

Hi,

I was wondering if anyone here on this list still has a machine with an old=
=20
ATMEL TPM (trusted platform module) lying around?

=46rom the kconfig entry it becomes evident that it was only supported on p=
pc64=20
machines.

config TCG_ATMEL
	tristate "Atmel TPM Interface"
	depends on PPC64 || HAS_IOPORT
	---help---
	  If you have a TPM security chip from Atmel say Yes and it=20
	  will be accessible from within Linux.  To compile this driver=20
	  as a module, choose M here; the module will be called tpm_atmel.

The hardware/driver is pretty old and the driver might have contained a bug=
=20
that made it unusable for the last 6 years ;)

So if anyone still has this kind of hardware around, please reply.

Thanks,
Peter

Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?

[Joel Schopp]

On 10/27/2013 05:06 PM, Peter Hüwe wrote:
> Hi,
> 
> I was wondering if anyone here on this list still has a machine with an old 
> ATMEL TPM (trusted platform module) lying around?
> 
>>From the kconfig entry it becomes evident that it was only supported on ppc64 
> machines.
> 
> config TCG_ATMEL
> 	tristate "Atmel TPM Interface"
> 	depends on PPC64 || HAS_IOPORT
> 	---help---
> 	  If you have a TPM security chip from Atmel say Yes and it 
> 	  will be accessible from within Linux.  To compile this driver 
> 	  as a module, choose M here; the module will be called tpm_atmel.
> 
> The hardware/driver is pretty old and the driver might have contained a bug 
> that made it unusable for the last 6 years ;)
> 
> So if anyone still has this kind of hardware around, please reply.
> 

As near as I can tell this was on a single machine type (the js21 circa
2006).  The firmware on the machine didn't support establishing a root
of trust, so use of the TPM was as a practical matter effective only for
the other functions like random number generation and key management.
The number of users who used the TPM for this on this machine was likely
very small 7 years ago.  The number of those machines still in service
today is likely smaller still.  The cross section of those two small
numbers combined with those who want to run on a shiny new kernel has to
be quickly approaching zero.

I reccomend removing the driver.  If the stars align and a user actually
appears who wants to use one I'll clean up the driver and resubmit it
for inclusion.  I just don't think that will happen.

-Joel

Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?

[Jason Gunthorpe]

On Mon, Oct 28, 2013 at 01:03:43PM -0500, Joel Schopp wrote:
> On 10/27/2013 05:06 PM, Peter H?we wrote:
> > Hi,
> > 
> > I was wondering if anyone here on this list still has a machine with an old 
> > ATMEL TPM (trusted platform module) lying around?
> > 
> >>From the kconfig entry it becomes evident that it was only supported on ppc64 
> > machines.
> > 
> > config TCG_ATMEL
> > 	tristate "Atmel TPM Interface"
> > 	depends on PPC64 || HAS_IOPORT

Hurm, that is crazy, because tpm_atmel.h contains an #else block for
!CONFIG_PPC64. The single major source of complexity in this driver is
that else block.

The driver would be fine, and straightforward if it was a standard,
modern DT enabled driver, which is very easy if PPC64 is the only
supported implementation.

> I reccomend removing the driver.  If the stars align and a user actually
> appears who wants to use one I'll clean up the driver and resubmit it
> for inclusion.  I just don't think that will happen.

The needed clean up is really easy actually, replace everything below
'tpm_vendor_specific tpm_atmel' with approximately this:

static int atml_probe(struct platform_device *pdev)
{
	struct tpm_chip *chip;
	struct resrouce *res;

        res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
        if (!r)
                return -EIO;

	if (!(chip = tpm_register_hardware(dev, &tpm_atmel)))
               return -ENODEV;

	chip->iobase = devm_request_and_ioremap(&pdev->dev, res);
	if (!chip->iobase)
	       	return -ENOMEM;

	return 0;
}

static void atml_plat_remove(struct platform_device *pdev)
{
        struct tpm_chip *chip = dev_get_drvdata(&pdev->dev);
	tpm_remove_hardware(chip->dev);		
};

static const struct of_device_id platform_match[] = {
        {.compatible = "AT97SC3201"},
        {},
};
MODULE_DEVICE_TABLE(of, platform_match);

static SIMPLE_DEV_PM_OPS(tpm_atml_pm, tpm_pm_suspend, tpm_pm_resume);

static struct platform_driver atml_drv = {
        .probe = atml_probe,
        .remove = atml_plat_remove,
        .driver = {
                .name = "tpm_atmel",
                .owner          = THIS_MODULE,
                .pm             = &tpm_atml_pm,
		.of_match_table = of_match_ptr(platform_match),
        },
};

module_platform_driver(atml_drv);

MODULE_AUTHOR("Leendert van Doorn (leendert@watson.ibm.com)");
MODULE_DESCRIPTION("TPM Driver");
MODULE_VERSION("2.0");
MODULE_LICENSE("GPL");

If you guys can convice yourselves that doesn't obviously break anything I can
probably send a proper patch.

Jason

Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?

[Peter Hüwe]

Am Dienstag, 29. Oktober 2013, 00:47:45 schrieb Jason Gunthorpe:
> On Mon, Oct 28, 2013 at 01:03:43PM -0500, Joel Schopp wrote:
> > On 10/27/2013 05:06 PM, Peter H?we wrote:
> > > Hi,
> > > 
> > > I was wondering if anyone here on this list still has a machine with an
> > > old ATMEL TPM (trusted platform module) lying around?
> > > 
> > >>From the kconfig entry it becomes evident that it was only supported on
> > >>ppc64
> > >>
> > > machines.
> > > 
> > > config TCG_ATMEL
> > > 
> > > 	tristate "Atmel TPM Interface"
> > > 	depends on PPC64 || HAS_IOPORT
> 
> Hurm, that is crazy, because tpm_atmel.h contains an #else block for
> !CONFIG_PPC64. The single major source of complexity in this driver is
> that else block.
> 
Argh, sorry my bad.
Of course it's available on other archs as well, since it's
PPC64 _||_ HAS_IOPORT

d'oh - sorry.


Peter