[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b287e2b7-08de-6fc8-4003-4609b1ba9378@roeck-us.net>
Date: Fri, 29 Jan 2021 15:32:38 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Lukasz Majczak <lma@...ihalf.com>, Peter Huewe <peterhuewe@....de>,
Jason Gunthorpe <jgg@...pe.ca>,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
Radoslaw Biernacki <rad@...ihalf.com>,
Marcin Wojtas <mw@...ihalf.com>,
Alex Levin <levinale@...gle.com>
Subject: Re: [PATCH] tpm_tis: Add missing start/stop_tpm_chip calls
On 1/29/21 2:49 PM, Jarkko Sakkinen wrote:
> On Mon, Jan 25, 2021 at 09:18:46AM -0800, Guenter Roeck wrote:
>> Hi Lukasz,
>>
>> On Sat, Jan 23, 2021 at 02:42:47AM +0100, Lukasz Majczak wrote:
>>> There is a missing call to start_tpm_chip before the call to
>>> the tpm_get_timeouts() and tpm_tis_probe_irq_single(). As the current
>>> approach maight work for tpm2, it fails for tpm1.x - in that case
>>> call to tpm_get_timeouts() or tpm_tis_probe_irq_single() tries to
>>> transmit TPM commands on a disabled chip what what doesn't succeed
>>
>> s/what what/what/
>
> s/maight/might/
>
> Also, would be nice to have the capatalization of acronyms correct
> and consistent. E.g. tpm1.x should be rather written as "TPM 1.x
> chips".
>
> It's also incorrect to state that something fails for TPM 1.x chips,
> unless you can somehow make a sense that every single TPM 1.x at wild
> fails, which probably is not true.
>
>>> and in turn causes tpm_tis_core_init() to fail.
>>> Tested on Samsung Chromebook Pro (Caroline).
>
> Anyone can tell me what does Caroline mean anyway?
>
"Caroline" is the code name for Samsung Chromebook Pro. The term
"Samsung Chromebook Pro (Caroline)" is quite widely used for this
system. Or, alternatively, "Caroline (Samsung Chromebook Pro)".
Guenter
Powered by blists - more mailing lists