On 25.01.2017 21:09, Jarkko Sakkinen wrote:
> On Tue, Jan 24, 2017 at 02:42:29PM +0100, Maciej S. Szmigiero wrote:
>> On 24.01.2017 13:01, Jarkko Sakkinen wrote:
>>> On Mon, Jan 23, 2017 at 06:23:55PM +0100, Maciej S. Szmigiero wrote:
>>>> On 16.01.2017 17:39, Jarkko Sakkinen wrote:
>>>>> On Mon, Jan 16, 2017 at 03:58:26PM +0100, Maciej S. Szmigiero wrote:
>>>>>> On 16.01.2017 14:55, Jarkko Sakkinen wrote:
>>>>>>> On Mon, Jan 16, 2017 at 03:46:12PM +0200, Jarkko Sakkinen wrote:
>>>>>>>> On Mon, Jan 16, 2017 at 11:42:02AM +0200, Jarkko Sakkinen wrote:
>>>>>>>>> On Fri, Jan 13, 2017 at 10:37:00PM +0100, Maciej S. Szmigiero wrote:
>>>>>>>>>> Since commit 1107d065fdf1 ("tpm_tis: Introduce intermediate layer 
>>>>>>>>>> for TPM
>>>>>>>>>> access") Atmel 3203 TPM on ThinkPad X61S (TPM firmware version 13.9) 
>>>>>>>>>> no
>>>>>>>>>> longer works.
>>>>>>>>>> The initialization proceeds fine until we get and start using 
>>>>>>>>>> chip-reported
>>>>>>>>>> timeouts - and the chip reports C and D timeouts of zero.
>>>>>>>>>>
>>>>>>>>>> It turns out that until commit 8e54caf407b98e ("tpm: Provide a 
>>>>>>>>>> generic
>>>>>>>>>> means to override the chip returned timeouts") we had actually let 
>>>>>>>>>> default
>>>>>>>>>> timeout values remain in this case, so let's bring back this 
>>>>>>>>>> behavior to
>>>>>>>>>> make chips like Atmel 3203 work again.
>>>>>>>>>>
>>>>>>>>>> Use a common code that was introduced by that commit so a warning is
>>>>>>>>>> printed in this case and /sys/class/tpm/tpm*/timeouts correctly says 
>>>>>>>>>> the
>>>>>>>>>> timeouts aren't chip-original.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
>>>>>>>>>>
>>>>>>>>>> Fixes: 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM 
>>>>>>>>>> access")
>>>>>>>>>> Cc: sta...@vger.kernel.org
>>>>>>>>>
>>>>>>>>> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com>
>>>>>>>>
>>>>>>>> It's now applied to my master branch so if someone wants to
>>>>>>>> test it, it should be fairly easy.
>>>>>>>
>>>>>>> And I decided to squash the rename commit to it.
>>>>>>
>>>>>> Wouldn't it be better to squash the rename commit into "fix iTPM probe 
>>>>>> via
>>>>>> probe_itpm() function" patch (if it isn't too late), since they touch the
>>>>>> same functionality?
>>>>>
>>>>> It can be renamed, modified and even dropped as long as it is in my
>>>>> master branch and I haven't sent pull request to James Morris.
>>>>
>>>> I see that "fix iTPM probe via probe_itpm() function" patch isn't present
>>>> in your pull request for 4.11.
>>>>
>>>> What I meant in previous message was that you squashed and "rename
>>>> TPM_TIS_ITPM_POSSIBLE to TPM_TIS_ITPM_WORKAROUND" patch into "use default 
>>>> timeout
>>>> value if chip reports it as zero" patch while it was logically connected 
>>>> with
>>>> "fix iTPM probe via probe_itpm() function" patch instead (which now isn't 
>>>> present
>>>> at all in the tree).
>>>> Sorry if it wasn't 100% clear.
>>>
>>> I see.
>>>
>>> I'll probably send later on pull request with fixes for release content
>>> I can include that commit into that pull request. Does that work for
>>> you?
>>
>> Yes, it would be fine, thanks.
> 
> It's now applied and pushed.

Almost there: it looks like the last hunk of the patch is missing from
the commit.

> /Jarkko

Maciej

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Reply via email to