mbox series

[0/6] Fix Atmel/Microchip TPMv1.2 issues

Message ID 20211104011253.4401-1-matt@traverse.com.au
Headers show
Series Fix Atmel/Microchip TPMv1.2 issues | expand

Message

Mathew McBride Nov. 4, 2021, 1:12 a.m. UTC
While doing bringup/rebase for the Ten64 I did some troubleshooting
for the tpm (v1.2, NOT tpm2) command which did not appear to function,
despite the Linux driver and tools (tcsd) working on the same board.

Evidently the Atmel TPM driver hasn't kept up with various step
changes in the I2C and TPM stacks, and while TPMv1.2 is quite
dated to TPMv2 it would be nice to make some use of the hardware
that is there.
(Admittedly I would love to replace our hardware TPM with an fTPM
but that is a project for another day)

There are also subcommands in tpm-v1 which also have been
missed in changes to the TPMv1 API and are fixed in this patchset.

I have checked that this set isn't impacted by Ilias' TPM cleanup
series[1] which only touches TPMv2.

[1] - http://patchwork.ozlabs.org/project/uboot/cover/20211103150910.69732-1-ilias.apalodimas@linaro.org/

Mathew McBride (6):
  cmd: tpm-v1: fix compile error in TPMv1 list resources command
  cmd: tpm-v1: fix load_key_by_sha1 compile errors
  drivers: tpm: atmel_twi: drop non-DM_I2C compatibility
  drivers: tpm: atmel_twi: do not use an offset byte
  drivers: tpm: atmel_twi: implement get_desc operation
  drivers: tpm: atmel_twi: fix printf specifier compile warning

 cmd/tpm-v1.c                | 17 +++++++++++------
 drivers/tpm/tpm_atmel_twi.c | 22 +++++++---------------
 lib/tpm-v1.c                |  4 ++--
 3 files changed, 20 insertions(+), 23 deletions(-)

Comments

Eugen Hristev Nov. 9, 2021, 8:42 a.m. UTC | #1
On 11/4/21 3:12 AM, Mathew McBride wrote:
> While doing bringup/rebase for the Ten64 I did some troubleshooting
> for the tpm (v1.2, NOT tpm2) command which did not appear to function,
> despite the Linux driver and tools (tcsd) working on the same board.
> 
> Evidently the Atmel TPM driver hasn't kept up with various step
> changes in the I2C and TPM stacks, and while TPMv1.2 is quite
> dated to TPMv2 it would be nice to make some use of the hardware
> that is there.
> (Admittedly I would love to replace our hardware TPM with an fTPM
> but that is a project for another day)
> 
> There are also subcommands in tpm-v1 which also have been
> missed in changes to the TPMv1 API and are fixed in this patchset.
> 
> I have checked that this set isn't impacted by Ilias' TPM cleanup
> series[1] which only touches TPMv2.
> 
> [1] - http://patchwork.ozlabs.org/project/uboot/cover/20211103150910.69732-1-ilias.apalodimas@linaro.org/
> 
> Mathew McBride (6):
>    cmd: tpm-v1: fix compile error in TPMv1 list resources command
>    cmd: tpm-v1: fix load_key_by_sha1 compile errors
>    drivers: tpm: atmel_twi: drop non-DM_I2C compatibility
>    drivers: tpm: atmel_twi: do not use an offset byte
>    drivers: tpm: atmel_twi: implement get_desc operation
>    drivers: tpm: atmel_twi: fix printf specifier compile warning
> 
>   cmd/tpm-v1.c                | 17 +++++++++++------
>   drivers/tpm/tpm_atmel_twi.c | 22 +++++++---------------
>   lib/tpm-v1.c                |  4 ++--
>   3 files changed, 20 insertions(+), 23 deletions(-)
> 
> --
> 2.30.1
> 

Hello Mathew, Ilias,

Even if this series touches a Microchip driver/part that is not part of 
the at91 architecture, the patches are in my queue.
I can take them through at91 tree if this is the way to go.
Is there another custodian tree that is dedicated for such kind of 
drivers? or more specific ?

Simon, your opinion on this ?

P.S. some of the patches look to be fixes most likely, so I guess it 
would be more likely to have them as fixes for 2022.01 release ?

Thanks,
Eugen
Ilias Apalodimas Nov. 9, 2021, 8:57 a.m. UTC | #2
On Tue, 9 Nov 2021 at 10:42, <Eugen.Hristev@microchip.com> wrote:
>
> On 11/4/21 3:12 AM, Mathew McBride wrote:
> > While doing bringup/rebase for the Ten64 I did some troubleshooting
> > for the tpm (v1.2, NOT tpm2) command which did not appear to function,
> > despite the Linux driver and tools (tcsd) working on the same board.
> >
> > Evidently the Atmel TPM driver hasn't kept up with various step
> > changes in the I2C and TPM stacks, and while TPMv1.2 is quite
> > dated to TPMv2 it would be nice to make some use of the hardware
> > that is there.
> > (Admittedly I would love to replace our hardware TPM with an fTPM
> > but that is a project for another day)
> >
> > There are also subcommands in tpm-v1 which also have been
> > missed in changes to the TPMv1 API and are fixed in this patchset.
> >
> > I have checked that this set isn't impacted by Ilias' TPM cleanup
> > series[1] which only touches TPMv2.
> >
> > [1] - http://patchwork.ozlabs.org/project/uboot/cover/20211103150910.69732-1-ilias.apalodimas@linaro.org/
> >
> > Mathew McBride (6):
> >    cmd: tpm-v1: fix compile error in TPMv1 list resources command
> >    cmd: tpm-v1: fix load_key_by_sha1 compile errors
> >    drivers: tpm: atmel_twi: drop non-DM_I2C compatibility
> >    drivers: tpm: atmel_twi: do not use an offset byte
> >    drivers: tpm: atmel_twi: implement get_desc operation
> >    drivers: tpm: atmel_twi: fix printf specifier compile warning
> >
> >   cmd/tpm-v1.c                | 17 +++++++++++------
> >   drivers/tpm/tpm_atmel_twi.c | 22 +++++++---------------
> >   lib/tpm-v1.c                |  4 ++--
> >   3 files changed, 20 insertions(+), 23 deletions(-)
> >
> > --
> > 2.30.1
> >
>
> Hello Mathew, Ilias,
>
> Even if this series touches a Microchip driver/part that is not part of
> the at91 architecture, the patches are in my queue.
> I can take them through at91 tree if this is the way to go.

I am fine with that

> Is there another custodian tree that is dedicated for such kind of
> drivers? or more specific ?

As far as I know there isn't.

>
> Simon, your opinion on this ?
>
> P.S. some of the patches look to be fixes most likely, so I guess it
> would be more likely to have them as fixes for 2022.01 release ?

Yes all of those look good.  I had a minor comment on one of those,
but we can always add more info on the TPM later.

Thanks
/Ilias
>
> Thanks,
> Eugen
Ilias Apalodimas Nov. 17, 2021, 10:35 a.m. UTC | #3
Eugen,

Will this go through your tree?  I recently picked up maintainership
of the TPM drivers, so I could send them through that.  Up to you.

Cheers
/Ilias

On Tue, 9 Nov 2021 at 10:57, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> On Tue, 9 Nov 2021 at 10:42, <Eugen.Hristev@microchip.com> wrote:
> >
> > On 11/4/21 3:12 AM, Mathew McBride wrote:
> > > While doing bringup/rebase for the Ten64 I did some troubleshooting
> > > for the tpm (v1.2, NOT tpm2) command which did not appear to function,
> > > despite the Linux driver and tools (tcsd) working on the same board.
> > >
> > > Evidently the Atmel TPM driver hasn't kept up with various step
> > > changes in the I2C and TPM stacks, and while TPMv1.2 is quite
> > > dated to TPMv2 it would be nice to make some use of the hardware
> > > that is there.
> > > (Admittedly I would love to replace our hardware TPM with an fTPM
> > > but that is a project for another day)
> > >
> > > There are also subcommands in tpm-v1 which also have been
> > > missed in changes to the TPMv1 API and are fixed in this patchset.
> > >
> > > I have checked that this set isn't impacted by Ilias' TPM cleanup
> > > series[1] which only touches TPMv2.
> > >
> > > [1] - http://patchwork.ozlabs.org/project/uboot/cover/20211103150910.69732-1-ilias.apalodimas@linaro.org/
> > >
> > > Mathew McBride (6):
> > >    cmd: tpm-v1: fix compile error in TPMv1 list resources command
> > >    cmd: tpm-v1: fix load_key_by_sha1 compile errors
> > >    drivers: tpm: atmel_twi: drop non-DM_I2C compatibility
> > >    drivers: tpm: atmel_twi: do not use an offset byte
> > >    drivers: tpm: atmel_twi: implement get_desc operation
> > >    drivers: tpm: atmel_twi: fix printf specifier compile warning
> > >
> > >   cmd/tpm-v1.c                | 17 +++++++++++------
> > >   drivers/tpm/tpm_atmel_twi.c | 22 +++++++---------------
> > >   lib/tpm-v1.c                |  4 ++--
> > >   3 files changed, 20 insertions(+), 23 deletions(-)
> > >
> > > --
> > > 2.30.1
> > >
> >
> > Hello Mathew, Ilias,
> >
> > Even if this series touches a Microchip driver/part that is not part of
> > the at91 architecture, the patches are in my queue.
> > I can take them through at91 tree if this is the way to go.
>
> I am fine with that
>
> > Is there another custodian tree that is dedicated for such kind of
> > drivers? or more specific ?
>
> As far as I know there isn't.
>
> >
> > Simon, your opinion on this ?
> >
> > P.S. some of the patches look to be fixes most likely, so I guess it
> > would be more likely to have them as fixes for 2022.01 release ?
>
> Yes all of those look good.  I had a minor comment on one of those,
> but we can always add more info on the TPM later.
>
> Thanks
> /Ilias
> >
> > Thanks,
> > Eugen
Eugen Hristev Nov. 17, 2021, 11:09 a.m. UTC | #4
On 11/17/21 12:35 PM, Ilias Apalodimas wrote:
> Eugen,
> 
> Will this go through your tree?  I recently picked up maintainership
> of the TPM drivers, so I could send them through that.  Up to you.
> 

Hi ,

The patch series by Mathew is now assigned to Tom Rini. You picked 
maintainership, that's fine, but you have a dedicated custodian tree ?

Tom, do you wish to handle these patches or you wish to reassign them to 
me and take them through at91 tree ?

Thanks,
Eugen

> Cheers
> /Ilias
> 
> On Tue, 9 Nov 2021 at 10:57, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
>>
>> On Tue, 9 Nov 2021 at 10:42, <Eugen.Hristev@microchip.com> wrote:
>>>
>>> On 11/4/21 3:12 AM, Mathew McBride wrote:
>>>> While doing bringup/rebase for the Ten64 I did some troubleshooting
>>>> for the tpm (v1.2, NOT tpm2) command which did not appear to function,
>>>> despite the Linux driver and tools (tcsd) working on the same board.
>>>>
>>>> Evidently the Atmel TPM driver hasn't kept up with various step
>>>> changes in the I2C and TPM stacks, and while TPMv1.2 is quite
>>>> dated to TPMv2 it would be nice to make some use of the hardware
>>>> that is there.
>>>> (Admittedly I would love to replace our hardware TPM with an fTPM
>>>> but that is a project for another day)
>>>>
>>>> There are also subcommands in tpm-v1 which also have been
>>>> missed in changes to the TPMv1 API and are fixed in this patchset.
>>>>
>>>> I have checked that this set isn't impacted by Ilias' TPM cleanup
>>>> series[1] which only touches TPMv2.
>>>>
>>>> [1] - http://patchwork.ozlabs.org/project/uboot/cover/20211103150910.69732-1-ilias.apalodimas@linaro.org/
>>>>
>>>> Mathew McBride (6):
>>>>     cmd: tpm-v1: fix compile error in TPMv1 list resources command
>>>>     cmd: tpm-v1: fix load_key_by_sha1 compile errors
>>>>     drivers: tpm: atmel_twi: drop non-DM_I2C compatibility
>>>>     drivers: tpm: atmel_twi: do not use an offset byte
>>>>     drivers: tpm: atmel_twi: implement get_desc operation
>>>>     drivers: tpm: atmel_twi: fix printf specifier compile warning
>>>>
>>>>    cmd/tpm-v1.c                | 17 +++++++++++------
>>>>    drivers/tpm/tpm_atmel_twi.c | 22 +++++++---------------
>>>>    lib/tpm-v1.c                |  4 ++--
>>>>    3 files changed, 20 insertions(+), 23 deletions(-)
>>>>
>>>> --
>>>> 2.30.1
>>>>
>>>
>>> Hello Mathew, Ilias,
>>>
>>> Even if this series touches a Microchip driver/part that is not part of
>>> the at91 architecture, the patches are in my queue.
>>> I can take them through at91 tree if this is the way to go.
>>
>> I am fine with that
>>
>>> Is there another custodian tree that is dedicated for such kind of
>>> drivers? or more specific ?
>>
>> As far as I know there isn't.
>>
>>>
>>> Simon, your opinion on this ?
>>>
>>> P.S. some of the patches look to be fixes most likely, so I guess it
>>> would be more likely to have them as fixes for 2022.01 release ?
>>
>> Yes all of those look good.  I had a minor comment on one of those,
>> but we can always add more info on the TPM later.
>>
>> Thanks
>> /Ilias
>>>
>>> Thanks,
>>> Eugen
Tom Rini Nov. 17, 2021, 11:27 a.m. UTC | #5
On Wed, Nov 17, 2021 at 11:09:05AM +0000, Eugen.Hristev@microchip.com wrote:
> On 11/17/21 12:35 PM, Ilias Apalodimas wrote:
> > Eugen,
> > 
> > Will this go through your tree?  I recently picked up maintainership
> > of the TPM drivers, so I could send them through that.  Up to you.
> > 
> 
> Hi ,
> 
> The patch series by Mathew is now assigned to Tom Rini. You picked 
> maintainership, that's fine, but you have a dedicated custodian tree ?
> 
> Tom, do you wish to handle these patches or you wish to reassign them to 
> me and take them through at91 tree ?

So, Ilias is getting set up with a tpm custodian tree now.  The question
I had was if you wanted these via the atmel tree, or would be OK with
them coming via the TPM tree.
Eugen Hristev Nov. 17, 2021, 11:34 a.m. UTC | #6
> So, Ilias is getting set up with a tpm custodian tree now.  The question
 >I had was if you wanted these via the atmel tree, or would be OK with
 >them coming via the TPM tree.


It's fine for me to take them through TPM tree. They are not in fact 
related to at91 architecture, it's another Atmel division that was 
creating these products.
I was willing to take them because there wasn't a better place for them, 
but if it's a TPM tree now, please go ahead with it.

Eugen


(P.S. when replying to your e-mails , thunderbird somehow deletes 
everything because it sees your e-mail as an attachment)