Accessing DSDT entries within a kernel device driver

Accessing DSDT entries within a kernel device driver

[Marcel Selhorst]

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

Re: Accessing DSDT entries within a kernel device driver

[Bjorn Helgaas]

On Tuesday 02 August 2005 1:29 pm, Marcel Selhorst wrote:
> 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.

> 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)?


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

Re: Accessing DSDT entries within a kernel device driver

[Marcel Selhorst]

Hi Björn,

> 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



-------------------------------------------------------
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_idt77&alloc_id\x16492&op=click

Re: Accessing DSDT entries within a kernel device driver

[Alex Williamson]

On Tue, 2005-08-02 at 21:29 +0200, Marcel Selhorst wrote:

> 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

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

Re: Accessing DSDT entries within a kernel device driver

[Marcel Selhorst]

Hi Alex,

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

> There's a driver for it in -mm, 

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

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

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

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

> 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



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

Re: Accessing DSDT entries within a kernel device driver

[Alex Williamson]

On Tue, 2005-08-02 at 23:33 +0200, Marcel Selhorst wrote:

> > 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 ;^)

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

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

> 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

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

Re: Accessing DSDT entries within a kernel device driver

[Marcel Selhorst]

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

:-))

>    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 :)

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

> 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 :)

>    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


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