On Friday 27 July 2007 07:28:09 am [EMAIL PROTECTED] wrote:
> Looks like the problematic code is in tpm_tis.c tpm_tis_init() near here:
>
> for (i = 3; i < 16 && chip->vendor.irq == 0; i++) {
> iowrite8(i, chip->vendor.iobase +
> TPM_INT_VECTOR(chip->vendor.locality));
> if (request_irq
> (i, tis_int_probe, IRQF_SHARED,
> chip->vendor.miscdev.name, chip) != 0) {
> dev_info(chip->dev,
> "Unable to request irq: %d for
> probe\n"
> ,
> i);
> continue;
> }
>
> This seems to be misbehaving differently for the two different DEBUG_SHIRQ
> cases.
>
> With DEBUG_SHIRQ=n, it starts at IRQ3, gets to at least 8 (where it complains
> it can't request it for probing), and possibly all the way to 15, without ever
> actually selecting and assigning an IRQ (to refresh memories, in that range
> /proc/interrupts only lists:
>
> 8: 0 0 IO-APIC-edge rtc
> 9: 3 0 IO-APIC-fasteoi acpi
> 12: 94 0 IO-APIC-edge i8042
> 14: 148166 0 IO-APIC-edge libata
> 15: 94 0 IO-APIC-edge libata
>
> So there's certainly IRQ's available. No idea why it doesn't choose one. But
> since it never chose one, it never gets into the "wait for the IRQ" protected
> by 'if (chip->vendor.irq)' at the end of tpm_tis_send.
>
> With DEBUG_SHIRQ=y, It starts at IRQ3, and assigns it (which seems a good
> thing).
> Unfortunately, this then hits the timeouts in tpm_tis_send.
>
> Anybody got an idea what *should* be happening here?
I don't know why tpm_tis_init() is messing around trying different
IRQs between 3 and 16. That looks suspiciously x86-dependent.
Maybe if you don't have PNP (though I doubt TPMs exist on any
pre-PNPBIOS machines) the "check-IRQ" loop would be necessary.
But you're using the PNP probe, and PNP should just tell you what
IRQ the device is configured for (and whether the IRQ can be
shared -- see 8250_pnp.c for an example).
The BIOS should have configured the TPM IRQ, and if we go and
mess with that IRQ setting without going through the PNP interface,
e.g., the ACPI _SRS method, we're liable to mess something up. The
TPM is often behind a few bridges, and if the bridge has any IRQ
routing configuration, only the BIOS knows how to keep that in
sync with the TPM IRQ configuration.
> 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?
Bjorn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
