linux-kernel - Re: 2.6.23-rc1-mm1 - seems OK on Dell Latitude D820, except for tpm

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <17955.1185907709@turing-police.cc.vt.edu>
Date:	Tue, 31 Jul 2007 14:48:29 -0400
From:	Valdis.Kletnieks@...edu
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Kylene Hall <kjhall@...ibm.com>, tpm@...horst.net,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.23-rc1-mm1 - seems OK on Dell Latitude D820, except for tpm_tis

On Mon, 30 Jul 2007 19:53:19 EDT, Valdis.Kletnieks@...edu said:

> > > Just for the record, I see this in /sys:
> > > 
> > > % cat /sys/bus/pnp/devices/00:0e/id
> > > BCM0102
> > > PNP0c31
> > 
> > What's in /sys/bus/pnp/devices/00:0e/resources?
> 
> % cat /sys/bus/pnp/devices/00:0e/resources
> state = active
> io 0x378-0x37f
> io 0x778-0x77b
> irq 7
> dma 1

Scratch that.  When I wrote the first note, I was at home, and the TPM chip
did its PNP thing and became 00:0e.  I failed to notice that in my reply,
I was at work, and the printer port on the docking station became 00:0e and
the TPM became 00:0f.

% cat /sys/devices/pnp0/00:0f/id
BCM0102
PNP0c31
% cat /sys/devices/pnp0/00:0f/resources 
state = active
io 0xcb0-0xcbb
mem 0xfed40000-0xfed44fff

So there *isn't* an IRQ assigned.  When I tried the patch you sent,
I added a few debugging printk's, thusly:

        if (interrupts)
                chip->vendor.irq = irq;
printk(KERN_DEBUG "in tis_init, interrupts=%d irq=%d\n",interrupts,irq);
        if (interrupts && !chip->vendor.irq) {
                chip->vendor.irq =
                    ioread8(chip->vendor.iobase +
                            TPM_INT_VECTOR(chip->vendor.locality));
printk(KERN_DEBUG "after ioread8, interrupts=%d irq=%d\n",interrupts,chip->vendor.irq);

                for (i = 3; i < 16 && chip->vendor.irq == 0; i++) {

[ 1971.644193] in pnp_init, start=fed40000 len=5000 irq=-1
[ 1971.650907] tpm_tis 00:0f: 1.2 TPM (device-id 0x1001, rev-id 2)
[ 1971.650923] in tis_init, interrupts=1 irq=-1
[ 1971.650929] tpm_tis 00:0f: Unable to request irq: -1 for use

and it loads immediately.

I thought that !chip->vendor.irq looked like a wrong test, because if the
chip says '-1' meaning "no default assigned", and conversely, if the chip
had a positive number, we should be *using* that IRQ if we can, rather than
looping from 3 to 15 looking for one. So I tried it with (chip->vendor.irc < 0),
and this happened:

[ 2254.834377] in pnp_init, start=fed40000 len=5000 irq=-1
[ 2254.840422] tpm_tis 00:0f: 1.2 TPM (device-id 0x1001, rev-id 2)
[ 2254.840438] in tis_init, interrupts=1 irq=-1
[ 2254.840443] after ioread8, interrupts=1 irq=15
[ 2254.840457] tpm0 (IRQ 15) handled a spurious interrupt
[ 2256.839077] tpm_tis 00:0f: tpm_transmit: tpm_send: error -62
[ 2376.771347] tpm_tis 00:0f: tpm_transmit: tpm_send: error -62

Or am I wrong in thinking chip->vendor.irq == -1 means "Pick me an IRQ",
but instead means "I don't do that IRQ thing"? If so, maybe what we need
to be doing is something like:

	if (chip->vendor.irq == -1)
		interrupts = 0;

and force the use of interrupts off and do polling only?

Content of type "application/pgp-signature" skipped