[SLOF] [PATCH v2 01/20] Add a TPM driver implementation
Alexey Kardashevskiy
aik at ozlabs.ru
Thu Nov 26 16:39:31 AEDT 2015
On 11/19/2015 10:58 PM, Thomas Huth wrote:
> On 19/11/15 12:50, Stefan Berger wrote:
>> On 11/18/2015 08:07 AM, Thomas Huth wrote:
>>> On 17/11/15 18:02, Stefan Berger wrote:
>>>> From: Stefan Berger <stefanb at linux.vnet.ibm.com>
>>>>
>>>> This patch adds a TPM driver for the CRQ interface as used by
>>>> the QEMU PAPR implementation.
>>>>
>>>> Signed-off-by: Stefan Berger <stefanb at linux.vnet.ibm.com>
> [...]
>>>> +/**** driver structures ****/
>>>> +
>>>> +struct tpm_driver tpm_drivers[TPM_NUM_DRIVERS] = {
>>>> + [PAPR_DRIVER_IDX] = {
>>>> + .setdurations = spapr_vtpm_set_durations,
>>>> + .probe = spapr_vtpm_probe,
>>>> + .init = spapr_vtpm_init,
>>>> + .activate = spapr_vtpm_activate,
>>>> + .ready = spapr_vtpm_endcycle,
>>>> + .senddata = spapr_vtpm_senddata,
>>>> + .transfer = spapr_vtpm_transfer,
>>>> + .waitresponseready = spapr_vtpm_waitresponseready,
>>>> + .readresponse = spapr_vtpm_readresponse,
>>>> + .sha1threshold = 100 * 1024,
>>>> + .getbuffersize = spapr_vtpm_get_buffersize,
>>>> + .getstate = spapr_vtpm_get_state,
>>>> + .geterror = spapr_vtpm_get_error,
>>>> + },
>>>> +};
>>> Do you plan other TPM drivers in the near future? If not, this struct
>>> tpm_driver interface with all those function pointers sounds a little
>>> bit over-engineered to me right now.
>>
>> I think it's a nice separation and allows for other drivers if it ever
>> became necessary.
>
> Well, function pointers are always more difficult to read, and to debug
> later!
> And since I don't see any other TPM driver implementation coming around
> in the near future, I really don't think that this is necessary here.
The very first version of this did have 2 TPM drivers so it is possible, I
just do not know how actual it is for pseries guests.
--
Alexey
More information about the SLOF
mailing list