[lkml]   [2004]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [tpmdd-devel] Re: [PATCH 1/1] driver: Tpm hardware enablement
    On Fri, 2004-12-10 at 12:39 -0600, Kylene Hall wrote:
    > On Fri, 2004-12-10 at 09:41, Ian Campbell wrote:
    > > On Fri, 2004-12-10 at 09:28 -0600, Kylene Hall wrote:
    > > > Good point. Splitting this out (esp. because there will be more in the
    > > > future) is a good idea. What is the usual way to do this? For example,
    > > > what function in the chip specific file would call
    > > > register_tpm_hardware, how do I make sure that gets called etc.
    > >
    > > I guess you could have multiple modules, one providing the generic code
    > > and the dev interface etc (tpm.ko) and then one per hardware chip
    > > (tmp-nsc.ko, tpm-atmel.ko, tpm-atmel-i2c.ko).
    > >
    > > The hardware modules can then call tpm_register_hardware() in their
    > > module_init function.
    > >
    > I have begun to implement it this but the problem I have now is that
    > this setup makes tpm_atmel and tpm_nsc dependent on tpm. Since tpm
    > calls pci_register_driver in its init (which has to happen before
    > tpm_<specific> init) probe is called before the "interfaces" are
    > registered and thus the tpm_probe fails to find the device. Do I move
    > the pci_register? If so what is the proper place to register it? When
    > one interface registers? If so then I think devices for the second and
    > subsequent interfaces would never be discovered for the same reason as I
    > am currently experiencing. Do I need to move the current tpm probe
    > logic to the hw specific drivers?

    I'm not too sure about the relationship between the different types of
    TPM chip you seem to be coping with and the PCI id's associated with
    them. I think the normal way would be to have a separate self-contained
    driver encapsulating the complete hardware specific bits for each
    possible type of pci hardware device, or indeed i2c device rather than
    mixing support for multiple different chips in a single driver.

    I think often you would have tpm_atmel's module_init contain a call to
    pci_register_driver to register the device id's associated with the
    Atmel parts. Then the probe call does tpm_<specific>_init and registers
    the tpm h/w device with the hardware independent bit using

    I would then be able to support the i2c variant of the atmel part by
    registering an i2c part instead of a PCI one and calling
    tpm_register_hardware from the equivalent i2c probe function.


    Ian Campbell, Senior Design Engineer
    Arcom, Clifton Road, Direct: +44 (0)1223 403 465
    Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:08    [W:0.030 / U:23.820 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site