On Sat, Apr 08, 2017 at 12:40:25PM +0200, Denis 'GNUtoo' Carikli wrote:
> I am working on it[1]. This commit has not been merged and is a work in
> progress. It is however available in coreboot's gerrit.
How did this work on any kernels if there was no PNP or ACPI entry?
FWIW, I wonder if
On Sat, Apr 08, 2017 at 12:40:25PM +0200, Denis 'GNUtoo' Carikli wrote:
> I am working on it[1]. This commit has not been merged and is a work in
> progress. It is however available in coreboot's gerrit.
How did this work on any kernels if there was no PNP or ACPI entry?
FWIW, I wonder if
Hi Paul,
On Thu, 6 Apr 2017 10:55:57 -0600
Jason Gunthorpe wrote:
> We added direct ACPI binding to the driver in addition to PNP, so if
> you have an ACPI table it goes down that path and does some additional
> validation of what is in the TPM. The BIOS must
Hi Paul,
On Thu, 6 Apr 2017 10:55:57 -0600
Jason Gunthorpe wrote:
> We added direct ACPI binding to the driver in addition to PNP, so if
> you have an ACPI table it goes down that path and does some additional
> validation of what is in the TPM. The BIOS must provide a
>
Dear Jarkko,
On 2017-04-07 22:13, Jarkko Sakkinen wrote:
On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> >We added direct ACPI binding to the driver in addition to PNP, so if
> >you have an ACPI table it goes down
Dear Jarkko,
On 2017-04-07 22:13, Jarkko Sakkinen wrote:
On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> >We added direct ACPI binding to the driver in addition to PNP, so if
> >you have an ACPI table it goes down
On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> > >We added direct ACPI binding to the driver in addition to PNP, so if
> > >you have an ACPI table it goes down that path and does some additional
> > >validation of
On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> > >We added direct ACPI binding to the driver in addition to PNP, so if
> > >you have an ACPI table it goes down that path and does some additional
> > >validation of
On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> >We added direct ACPI binding to the driver in addition to PNP, so if
> >you have an ACPI table it goes down that path and does some additional
> >validation of what is in the TPM. The BIOS must provide a
> >acpi_dev_resource_memory
On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> >We added direct ACPI binding to the driver in addition to PNP, so if
> >you have an ACPI table it goes down that path and does some additional
> >validation of what is in the TPM. The BIOS must provide a
> >acpi_dev_resource_memory
On Thu, Apr 06, 2017 at 10:55:57AM -0600, Jason Gunthorpe wrote:
> On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote:
>
> > Indeed, that improves the situation. I still need to pass `force=1` to the
> > module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9
> > yet.
>
On Thu, Apr 06, 2017 at 10:55:57AM -0600, Jason Gunthorpe wrote:
> On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote:
>
> > Indeed, that improves the situation. I still need to pass `force=1` to the
> > module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9
> > yet.
>
On 2017-04-06 18:55, Jason Gunthorpe wrote:
On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote:
Indeed, that improves the situation. I still need to pass `force=1` to
the
module to get `/dev/tpm0`. No idea, why it’s not in included in Linux
4.9
yet.
Fair point.. Jarkko - could you
On 2017-04-06 18:55, Jason Gunthorpe wrote:
On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote:
Indeed, that improves the situation. I still need to pass `force=1` to
the
module to get `/dev/tpm0`. No idea, why it’s not in included in Linux
4.9
yet.
Fair point.. Jarkko - could you
On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote:
> Indeed, that improves the situation. I still need to pass `force=1` to the
> module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9
> yet.
Fair point.. Jarkko - could you forward that patch to -stable?
> $
On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote:
> Indeed, that improves the situation. I still need to pass `force=1` to the
> module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9
> yet.
Fair point.. Jarkko - could you forward that patch to -stable?
> $
On 04/06/17 08:18, Paul Menzel wrote:
> Dear Maciej,
>
> On 2017-04-05 13:03, Maciej S. Szmigiero wrote:
>
>>> tpm tpm0: Unable to read burstcount
>>> tpm tpm0: tpm_transmit: tpm_send: error -16
>>> tpm_tis tpm_tis: Could not get TPM timeouts and durations
>>
>> This looks like a regression I
On 04/06/17 08:18, Paul Menzel wrote:
> Dear Maciej,
>
> On 2017-04-05 13:03, Maciej S. Szmigiero wrote:
>
>>> tpm tpm0: Unable to read burstcount
>>> tpm tpm0: tpm_transmit: tpm_send: error -16
>>> tpm_tis tpm_tis: Could not get TPM timeouts and durations
>>
>> This looks like a regression I
Dear Maciej,
On 2017-04-05 13:03, Maciej S. Szmigiero wrote:
tpm tpm0: Unable to read burstcount
tpm tpm0: tpm_transmit: tpm_send: error -16
tpm_tis tpm_tis: Could not get TPM timeouts and durations
This looks like a regression I had on ThinkPad X61S.
You can try with a patch from the
Dear Maciej,
On 2017-04-05 13:03, Maciej S. Szmigiero wrote:
tpm tpm0: Unable to read burstcount
tpm tpm0: tpm_transmit: tpm_send: error -16
tpm_tis tpm_tis: Could not get TPM timeouts and durations
This looks like a regression I had on ThinkPad X61S.
You can try with a patch from the
On Wed, Apr 05, 2017 at 01:03:42PM +0200, Maciej S. Szmigiero wrote:
> Hi Paul,
>
> > tpm tpm0: Unable to read burstcount
> > tpm tpm0: tpm_transmit: tpm_send: error -16
> > tpm_tis tpm_tis: Could not get TPM timeouts and durations
>
> This looks like a regression I had on ThinkPad X61S.
>
>
On Wed, Apr 05, 2017 at 01:03:42PM +0200, Maciej S. Szmigiero wrote:
> Hi Paul,
>
> > tpm tpm0: Unable to read burstcount
> > tpm tpm0: tpm_transmit: tpm_send: error -16
> > tpm_tis tpm_tis: Could not get TPM timeouts and durations
>
> This looks like a regression I had on ThinkPad X61S.
>
>
Hi Paul,
> tpm tpm0: Unable to read burstcount
> tpm tpm0: tpm_transmit: tpm_send: error -16
> tpm_tis tpm_tis: Could not get TPM timeouts and durations
This looks like a regression I had on ThinkPad X61S.
You can try with a patch from the following commit
which fixed it for me:
Hi Paul,
> tpm tpm0: Unable to read burstcount
> tpm tpm0: tpm_transmit: tpm_send: error -16
> tpm_tis tpm_tis: Could not get TPM timeouts and durations
This looks like a regression I had on ThinkPad X61S.
You can try with a patch from the following commit
which fixed it for me:
Dear Jason,
Thank you for your reply.
On 2017-04-04 19:15, Jason Gunthorpe wrote:
On Tue, Apr 04, 2017 at 06:29:06PM +0200, Paul Menzel wrote:
Unfortunately, there seems to have been a regression between Linux
3.16
and 4.8 and 4.9, so that the Linux kernel doesn’t create the TPM
device.
Dear Jason,
Thank you for your reply.
On 2017-04-04 19:15, Jason Gunthorpe wrote:
On Tue, Apr 04, 2017 at 06:29:06PM +0200, Paul Menzel wrote:
Unfortunately, there seems to have been a regression between Linux
3.16
and 4.8 and 4.9, so that the Linux kernel doesn’t create the TPM
device.
On Tue, Apr 04, 2017 at 06:29:06PM +0200, Paul Menzel wrote:
> Unfortunately, there seems to have been a regression between Linux 3.16
> and 4.8 and 4.9, so that the Linux kernel doesn’t create the TPM
> device.
That old kernel did not check error codes when reading burst count,
the new one
On Tue, Apr 04, 2017 at 06:29:06PM +0200, Paul Menzel wrote:
> Unfortunately, there seems to have been a regression between Linux 3.16
> and 4.8 and 4.9, so that the Linux kernel doesn’t create the TPM
> device.
That old kernel did not check error codes when reading burst count,
the new one
28 matches
Mail list logo