Re: [tpmdd-devel] Re: [PATCH 1/1] driver: Tpm hardware enablement

[Ian Campbell <icampbell@arcom.com>]

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

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.

-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road,                    Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom       Phone:  +44 (0)1223 411 200