Messages in this thread |  | | | Subject | Re: [tpmdd-devel] Re: [PATCH 1/1] driver: Tpm hardware enablement | | From | Ian Campbell <> | | Date | Tue, 14 Dec 2004 09:59:53 +0000 |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |