Re: [tpmdd-devel] TPM atmel and nsc should use PNP

[Bjorn H. <bjo...@hp...>]

> Yes ideally that would be the case.  But many hardware vendors are not
> supporting ACPI BIOS entries for the TPM and this was not a requirement
> for 1.1 devices.

ACPI should describe all motherboard devices that consume resources
or need a driver.  Are you saying there's some exception to this for
TPM 1.1 devices?  Why would TPM be different from other motherboard
devices in this regard?

> As you will notice the tpm_tis driver now has away
> around the PNP stuff for machines that don't have the ACPI entry becaus=
e
> there are just too many cases that it doesn't work for.

Yes, I noticed this (and even mentioned it below).

> If you want to
> add similar support to atmel and nsc where the pnp is attempted first
> that might work (though for legacy reasons I don't want to make the non=
-
> PNP version for those drivers now require a module parameter as is the
> case in tis.

We can probably get away with blindly probing on x86.  But these
drivers shouldn't be x86-specific, and it's not safe to blindly
probe on some other architectures (ia64, for instance).

Do you know what PNP IDs the atmel and nsc devices would use?

> On Tue, 2006-07-25 at 16:49 -0600, Bjorn Helgaas wrote:
>> tpm_infineon.c and tpm_tis.c use pnp_register_driver() to bind to
>> devices with matching PNP IDs.  That seems like the right way to
>> do it.
>>
>> But tpm_atmel.c and tpm_nsc.c just blindly poke around looking for
>> their device.  That seems wrong.  Is there some reason they can't
>> use pnp_register_driver() also?  I'd be glad to send a patch to
>> fix this if somebody knows the appropriate list of PNP IDs that
>> these drivers should claim.
>>
>> I like the recent tpm_tis.c changes to give a hook for use when
>> ACPI doesn't correctly describe the TPM device.  That will give
>> manufacturers a hint that they're doing something wrong.
>>
>> Bjorn
>
>