Accessing DSDT entries within a kernel device driver

DISCUSSION Marcel Selhorst 4 participants 7 messages Aug 2, 2005 3 messages not in the archive ACPI

Share & tools

Marcel Selhorst

author

2005-08-02 19:29 UTC #0 lore raw

Dear ACPI-List,

I am pretty new to ACPI and I hope that my question is not offending, but I didn't find an answer in the mailing archive.
I am writing a device driver for a trusted platform module (TPM), which is connected to the mainboard via the LPC-bus. The corresponding ioports needed to communicate with the chip are written into the ACPI-table (DSDT) through the BIOS. So what I would like to do is simply read out the values stored inside the DSDT-table and gather the information I need to configure the TPM-chip with the correct ioports. The corresponding DSDT-entry looks like this:

Device (TPM)

        {
            Name (_HID, EisaId ("IFX0101"))
            Name (_UID, 0x01)
            Name (_CRS, ResourceTemplate ()
            {
                IO (Decode16, 0x004E, 0x004E, 0x01, 0x02)
                IO (Decode16, 0x4700, 0x4700, 0x01, 0x0C)
            })
        }

Is there a way to get the information (without userspace disassembling through iasl)?

Thanks a lot,

Marcel Selhorst

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

A message that is not in the archive (sent off-list or not yet received): [email protected]

Bjorn Helgaas

2005-08-02 20:18 UTC #2 lore raw

Quoted 7 lines · Marcel Selhorst

I am pretty new to ACPI and I hope that my question is not offending, but I didn't find an answer in the mailing archive.
I am writing a device driver for a trusted platform module (TPM), which is connected to the mainboard via the LPC-bus. The corresponding ioports needed to communicate with the chip are written into the ACPI-table (DSDT) through the BIOS. So what I would like to do is simply read out the values stored inside the DSDT-table and gather the information I need to configure the TPM-chip with the correct ioports.

Use 8250_pnp.c as a template, specifically serial_pnp_probe().

You should be able to claim the TPM device using a PNP driver that claims IFX0101 devices. Then the PNP subsystem will take care of extracting your IO port information from the ACPI namespace.

Quoted 13 lines

The corresponding DSDT-entry looks like this:

Device (TPM)

        {
            Name (_HID, EisaId ("IFX0101"))
            Name (_UID, 0x01)
            Name (_CRS, ResourceTemplate ()
            {
                IO (Decode16, 0x004E, 0x004E, 0x01, 0x02)
                IO (Decode16, 0x4700, 0x4700, 0x01, 0x0C)
            })
        }

Quoted 1 line

Is there a way to get the information (without userspace disassembling through iasl)?

A message that is not in the archive (sent off-list or not yet received): [email protected]

Marcel Selhorst

author

2005-08-02 21:00 UTC #4 lore raw

Hi Björn,

Quoted 3 lines

You should be able to claim the TPM device using a PNP driver that claims IFX0101 devices. Then the PNP subsystem will take care of extracting your IO port information from the ACPI namespace.

thanks for this hint, I will try this out immediately ;-)

Best regards,

Marcel Selhorst

Alex Williamson

2005-08-02 20:38 UTC #5 lore raw

In reply to a message not in the archive

Quoted 11 lines · Marcel Selhorst

Device (TPM)

        {
            Name (_HID, EisaId ("IFX0101"))
            Name (_UID, 0x01)
            Name (_CRS, ResourceTemplate ()
            {
                IO (Decode16, 0x004E, 0x004E, 0x01, 0x02)
                IO (Decode16, 0x4700, 0x4700, 0x01, 0x0C)
            })
        }

I was looking at this recently too. I believe IFX0101 is the HID
specifically for an Infineon TPM. There's a driver for it in -mm, but it uses hard coded address (blech) and doesn't work on my laptop. The code to find it and extract the resources through ACPI is pretty simple, but Bjorn's idea of using the ACPI PNP framework is probably the right way to do it. I got sidetracked from the problem after trying to figure out why the TPM drivers have such a strange attachment to a PCI device. There will be systems that have a TPM, but don't have an LPC bus exposed via a PCI device. Seems like the LPC stuff needs to be separated into it's own driver and TPM needs to be more independent. In any case, we definitely need to move these drivers over to ACPI discovery, I can't imagine they work for a very broad audience given their current discovery code.

Alex

Signature · 9 lines

Alex Williamson                             HP Linux & Open Source Lab



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Marcel Selhorst

author

2005-08-02 21:33 UTC #6 lore raw

Hi Alex,

Quoted 2 lines

I was looking at this recently too. I believe IFX0101 is the HID
specifically for an Infineon TPM.

Yes, thats exactly the TPM I am working with.

Quoted 1 line

There's a driver for it in -mm,

oh I know, I have written it ;-))

Quoted 1 line

but it uses hard coded address (blech) and doesn't work on my laptop.

Thats the point why I am trying to use the ACPI-functions in order to configure the TPM. Until now I assumed, that the ioports are correctly set into the configuration registers of the TPM through the BIOS (at least my prototypes did), but the feedback showed me, that it is not always the case. Currently I am revising the kernel source code to do this automatically and a new release will follow soon including support for Infineons new TPM 1.2 chips.

(But you can try the older device driver (version 1.3.2) from
<http://www.prosec.rub.de/tpm>
This version is more hacky and manually assigns (hardcoded) ioports to the TPM, if the configuration registers are zero. At least this version should work for your laptop.)

Quoted 3 lines

The code to find it and extract the resources through ACPI is pretty simple, but Bjorn's idea of using the ACPI PNP framework is probably the right way to do it.

I was looking in the acpi-sourcecode trying to get the "acpi_evaluate_object"- things working, but wasn't succesful :(
Nevertheless, could you give a hint how to extract the resources through ACPI?

Quoted 2 lines

There will be systems that have a TPM, but don't have an LPC bus exposed via a PCI device.

Right. If you look at newer approaches, some manufacturers like BroadCom are including their TPMs into their network chips and others are including the TPM functionality directly into the super-io-controller.

Quoted 2 lines

Seems like the LPC stuff needs to be separated into it's own driver and TPM needs to be more independent.

In the current release of IBMs generic tpm interface (tpm.c/h), the lpc-stuff has been replaced through pci_enable_device-calls exactly for this reason to make the interface more flexible and LPC-bus-independent. But enhancing it with ACPI-functionality would really be great.

Thanks and best regards!

Marcel Selhorst

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alex Williamson

2005-08-02 21:50 UTC #8 lore raw

Quoted 3 lines · Marcel Selhorst

Quoted 1 line
There's a driver for it in -mm,
oh I know, I have written it ;-))

Heh, I should pay better attention to who I'm talking to ;^)

Quoted 9 lines

Quoted 1 line
but it uses hard coded address (blech) and doesn't work on my laptop.
Thats the point why I am trying to use the ACPI-functions in order to configure the TPM. Until now I assumed, that the ioports are correctly set into the configuration registers of the TPM through the BIOS (at least my prototypes did), but the feedback showed me, that it is not always the case. Currently I am revising the kernel source code to do this automatically and a new release will follow soon including support for Infineons new TPM 1.2 chips.

Very cool. While you're at it, I think we're going to end up having
TPMs that live in MMIO space instead of I/O port space. I assume the access semantics are pretty similar, readb/writeb vs inb/outb, but it's probably a good time to add that too.

Quoted 4 lines

I was looking in the acpi-sourcecode trying to get the "acpi_evaluate_object"- things working, but wasn't succesful :(
Nevertheless, could you give a hint how to extract the resources through ACPI?

Completely untested, but based on 8250_pnp, I think you'd need
something like this:

static int __devinit tpm_inf_probe(struct pnp_dev *dev,
const struct pnp_device_id *dev_id)
{
...
if (pnp_port_valid(dev, 0) && pnp_port_valid(dev, 1)) {
io_control = pnp_port_start(dev, 0)
io_address = pnp_port_start(dev, 1)
} else if (pnp_mem_valid(dev, 0) && pnp_mem_valid(dev, 1)) {
mem_control = pnp_mem_start(dev, 0)
mem_address = pnp_mem_start(dev, 1)
}
...
}

static const struct pnp_device_id tpm_pnp_tbl[] = {
        /* Infineon TPM */
        {"IFX0101", 0},
        {"", 0}
};

MODULE_DEVICE_TABLE(pnp, tpm_pnp_tbl);

static struct pnp_driver inf_pnp_driver = {
.name = "tpm_inf_pnp",
.id_table = tpm_pnp_tbl,
.probe = tpm_inf_probe,
.remove = __devexit_p(tpm_remove),
};

static int __init init_inf(void)

{
        return pnp_register_driver(&inf_pnp_driver);
}

static void __exit cleanup_inf(void)

{
        pnp_unregister_driver(&inf_pnp_driver);
}

If you want to use ACPI directly, have a look at 8250_acpi. The PNP stuff does seem easier since all of the complicated ACPI callback stuff to fill in resources is handled for you. I probably have some scrap code around from when I was trying that approach if you'd like it.

Quoted 4 lines

In the current release of IBMs generic tpm interface (tpm.c/h), the lpc-stuff has been replaced through pci_enable_device-calls exactly for this reason to make the interface more flexible and LPC-bus-independent. But enhancing it with ACPI-functionality would really be great.

Cool, sounds like things are on the right track. Let me know if I
can help further. Thanks,

Alex

Signature · 9 lines

Alex Williamson                             HP Linux & Open Source Lab



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Marcel Selhorst

2005-08-02 22:05 UTC #9 lore raw

Quoted 1 line

Heh, I should pay better attention to who I'm talking to ;^)

lol, sounds a little like the godfather:
<italian sound on>
you better pay attention whom you're talking to
<italian sound off>

:-))

Quoted 4 lines

Very cool. While you're at it, I think we're going to end up having
TPMs that live in MMIO space instead of I/O port space. I assume the access semantics are pretty similar, readb/writeb vs inb/outb, but it's probably a good time to add that too.

great idea, I will think about that :)

Quoted 2 lines

Completely untested, but based on 8250_pnp, I think you'd need
something like this: [...]

wow, that was quick, thanks for the fast reply and the detailled examples! I will try them out now (hmm, hope this is not going to be an insomnian night).

Quoted 2 lines

I probably have some scrap
code around from when I was trying that approach if you'd like it.

For the moment I should have enough :)

Quoted 2 lines

Cool, sounds like things are on the right track. Let me know if I
can help further.

Yes, thanks, you can test the new code, when its done :-)

Bye,

Marcel Selhorst