Hi,
On 2020/7/27 15:10, Arnd Bergmann wrote:
> On Mon, Jul 27, 2020 at 4:54 AM Tianjia Zhang
> wrote:
>>
>> Obviously, the TPM version number in the help message is wrong, which
>> will cause confusion. This patch fixes it.
>
> How is this "obvious"? I tried finding the specification and could
Hi,
NACK
> % git --no-pager grep IFX0102 drivers/char/tpm
> drivers/char/tpm/tpm_infineon.c: {"IFX0102", 0},
> drivers/char/tpm/tpm_tis.c: {"IFX0102", 0}, /* Infineon */
> Obviously IFX0102 was added to the HID table for the TCG TIS driver by
> mistake.
The HID IFX0102 was NOT
>> +Q: https://patchwork.kernel.org/project/linux-integrity/list/
> Is there a way of viewing not just the posted patches, but the discussion as
> well? Do we need to set up an archive as well?
Spinics is archiving us at
https://www.spinics.net/lists/linux-integrity/
It would be good to add
>> +Q: https://patchwork.kernel.org/project/linux-integrity/list/
> Is there a way of viewing not just the posted patches, but the discussion as
> well? Do we need to set up an archive as well?
Spinics is archiving us at
https://www.spinics.net/lists/linux-integrity/
It would be good to add
> 1. I've got a TPM that implements vendor-specific command codes. Those
> cannot be send to the TPM anymore, but are rejected with EINVAL.
>
>> 2. When upgrading the firmware on my TPM, it switches to a
>> non-standard communication mode for the upgrade process and does not
>> communicate using
> 1. I've got a TPM that implements vendor-specific command codes. Those
> cannot be send to the TPM anymore, but are rejected with EINVAL.
>
>> 2. When upgrading the firmware on my TPM, it switches to a
>> non-standard communication mode for the upgrade process and does not
>> communicate using
Hi Aaron, Rajob, PeterA and everybody else,
(sorry for the late reply)
>On 03/27/2013 11:22 PM, Rajiv Andrade wrote:
>> Sorry for the delay. Can you send us the dmesg output after setting
>> loglevel=7 at boot time? Additionally, can you send us the TPM manufacturer
>> model/version
>>> On
Hi Aaron, Rajob, PeterA and everybody else,
(sorry for the late reply)
On 03/27/2013 11:22 PM, Rajiv Andrade wrote:
Sorry for the delay. Can you send us the dmesg output after setting
loglevel=7 at boot time? Additionally, can you send us the TPM manufacturer
model/version
On Thu, Mar 21,
Hi
> The TPM is too busy to respond to the command immediately, but the
> command could be resubmitted at a later time. The TPM MAY return
> TPM_RETRY for any command at any time.
> It can take several seconds before the TPM will respond again. I measured a
> typical time between 3 and 4
Hi
The TPM is too busy to respond to the command immediately, but the
command could be resubmitted at a later time. The TPM MAY return
TPM_RETRY for any command at any time.
It can take several seconds before the TPM will respond again. I measured a
typical time between 3 and 4
>> Yes, no problem.
>> I'll create a patch without it -
>> I'll make it this way that you can apply the conversion patch first
>> and then the change.
>Thanks!
>Kent
The new version of my patch was just sent - please apply this one first.
Thanks,
Peter
Yes, no problem.
I'll create a patch without it -
I'll make it this way that you can apply the conversion patch first
and then the change.
Thanks!
Kent
The new version of my patch was just sent - please apply this one first.
Thanks,
Peter
Hi Jason,
>Great, I'll send an updated version, thanks!
;) You're welcome.
>> >+struct tpm_startup_in {
>> >+ __be16 startup_type;
>> >+} __packed;
>>
>>
>> All the other user
>> __attribute__((packed));
>> Care to change to be consistent?
> I used to __packed to avoid a checkpatch
Hi Jason, Hi Kent,
>
>Discussion on this got a bit sidetracked talking about
>suspend/resume.. To be clear, this fixes a real, serious, problem on
>normal embedded cases where the kernel refuses to attach the TPM driver
>at all.
>
>Key, are you happy with this as-is for the next merge window?
>
Hi Jason, Hi Kent,
Discussion on this got a bit sidetracked talking about
suspend/resume.. To be clear, this fixes a real, serious, problem on
normal embedded cases where the kernel refuses to attach the TPM driver
at all.
Key, are you happy with this as-is for the next merge window?
This
Hi Jason,
Great, I'll send an updated version, thanks!
;) You're welcome.
+struct tpm_startup_in {
+ __be16 startup_type;
+} __packed;
All the other user
__attribute__((packed));
Care to change to be consistent?
I used to __packed to avoid a checkpatch warning, they should
Hi Kent,
> > > +What:/sys/class/misc/tpmX/device/active
> > > +Date:April 2006
> > > +KernelVersion: 2.6.17
> > > +Contact: tpmdd-de...@lists.sf.net
> > > +Description: The "active" property prints a '1' if the TPM chip is
> > > accepting
> > > + commands.
Hi Kent,
thanks a lot for this effort!
I really appreciate it.
> +What:/sys/class/misc/tpmX/device/active
> +Date:April 2006
> +KernelVersion: 2.6.17
> +Contact: tpmdd-de...@lists.sf.net
> +Description: The "active" property prints a '1' if the TPM chip
Hi Kent,
thanks a lot for this effort!
I really appreciate it.
+What:/sys/class/misc/tpmX/device/active
+Date:April 2006
+KernelVersion: 2.6.17
+Contact: tpmdd-de...@lists.sf.net
+Description: The active property prints a '1' if the TPM chip is
Hi Kent,
+What:/sys/class/misc/tpmX/device/active
+Date:April 2006
+KernelVersion: 2.6.17
+Contact: tpmdd-de...@lists.sf.net
+Description: The active property prints a '1' if the TPM chip is
accepting
+ commands. An inactive TPM chip
-Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Using open/close is an interesting idea, but it wouldn't work. open()
> is coded to return EBUSY if another process has it open, rather than
> block, and spinning on open would be unacceptable.
Hmm,
-Original Message-
From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
Using open/close is an interesting idea, but it wouldn't work. open()
is coded to return EBUSY if another process has it open, rather than
block, and spinning on open would be unacceptable.
Hmm, maybe
Hi Kent,
> Peter, you mentioned you have some embedded setups, would you be able
> to test?
I could probably test it on the beagleboard c4 with our Infineon SLB9635 TT1.2
I2C TPM,
but I'm currently not sure if I have the suspend/resume thing currently running
correctly.
Apart from that I
Hi Kent,
Peter, you mentioned you have some embedded setups, would you be able
to test?
I could probably test it on the beagleboard c4 with our Infineon SLB9635 TT1.2
I2C TPM,
but I'm currently not sure if I have the suspend/resume thing currently running
correctly.
Apart from that I also
>I welcome such functionality. Thanks for your efforts.
Me too ;)
Peter Huewe
Infineon Technologies AG
CCS TI SWT SW ESW
Tel:+49 821 25851-86
Fax:+49 821 25851-40
peter.hu...@infineon.com
VISIT US AT: www.infineon.com *
Infineon Technologies AG
Vorsitzender des
Hi Jason,
> The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
> TPM_STARTUP has not been issued. This will result in the TPM driver
> failing to load and no way to recover. Detect this and automatically
> issue TPM_STARTUP.
> This is for embedded applications where the kernel
Hi Jason,
one quick question:
- TPM_BUFSIZE = 4096,
[...]
+ u8 data_bufferx[2048];
Why do you half the buffer size?
Thanks,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi Jason,
one quick question:
- TPM_BUFSIZE = 4096,
[...]
+ u8 data_bufferx[2048];
Why do you half the buffer size?
Thanks,
Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi Jason,
The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
TPM_STARTUP has not been issued. This will result in the TPM driver
failing to load and no way to recover. Detect this and automatically
issue TPM_STARTUP.
This is for embedded applications where the kernel is
I welcome such functionality. Thanks for your efforts.
Me too ;)
Peter Huewe
Infineon Technologies AG
CCS TI SWT SW ESW
Tel:+49 821 25851-86
Fax:+49 821 25851-40
peter.hu...@infineon.com
VISIT US AT: www.infineon.com *
Infineon Technologies AG
Vorsitzender des Aufsichtsrats:
>> > Build using make -> no error.
>> I can't reproduce this either, James, can you send out your .config?
> See attached.
Hi James,
even with you config, I can't reproduce it here with 3.6-rc3 + mypatch.
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Build using make - no error.
I can't reproduce this either, James, can you send out your .config?
See attached.
Hi James,
even with you config, I can't reproduce it here with 3.6-rc3 + mypatch.
Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
>> From: James Morris [mailto:jmor...@namei.org]
>> I'm getting this error when building i2c as a module
>> WARNING: "__i2c_transfer" [drivers/char/tpm/tpm_i2c_infineon.ko] undefined!
> This is unconditionally (except I2C) available in Linus' master tree.
> And was introduced by b37d2a3a75cb in
> From: James Morris [mailto:jmor...@namei.org]
> I'm getting this error when building i2c as a module
> WARNING: "__i2c_transfer" [drivers/char/tpm/tpm_i2c_infineon.ko] undefined!
This is unconditionally (except I2C) available in Linus' master tree.
And was introduced by b37d2a3a75cb in June by
From: James Morris [mailto:jmor...@namei.org]
I'm getting this error when building i2c as a module
WARNING: __i2c_transfer [drivers/char/tpm/tpm_i2c_infineon.ko] undefined!
This is unconditionally (except I2C) available in Linus' master tree.
And was introduced by b37d2a3a75cb in June by Jean
From: James Morris [mailto:jmor...@namei.org]
I'm getting this error when building i2c as a module
WARNING: __i2c_transfer [drivers/char/tpm/tpm_i2c_infineon.ko] undefined!
This is unconditionally (except I2C) available in Linus' master tree.
And was introduced by b37d2a3a75cb in June by
Hi Kent,
> Thanks Peter. One more request - can you roll this fix into the driver
> patch itself and just add a note in the change log? Sorry I didn't
> mention this before.
Yes I'll do that.
And while at it I'll also replace our i2c_transfer_nolock with the new (in
3.6rc-1) __i2c_transfer
Hi Kent,
Thanks Peter. One more request - can you roll this fix into the driver
patch itself and just add a note in the change log? Sorry I didn't
mention this before.
Yes I'll do that.
And while at it I'll also replace our i2c_transfer_nolock with the new (in
3.6rc-1) __i2c_transfer
Hi James,
>Reverted:
> CC [M] drivers/char/tpm/tpm_i2c_infineon.o
>drivers/char/tpm/tpm_i2c_infineon.c:740: error: lvalue required as unary &
>operand
>make[1]: *** [drivers/char/tpm/tpm_i2c_infineon.o] Error 1
>Was this code tested?
Yes - quite extensively and also reviewed quite
Hi James,
Reverted:
CC [M] drivers/char/tpm/tpm_i2c_infineon.o
drivers/char/tpm/tpm_i2c_infineon.c:740: error: lvalue required as unary
operand
make[1]: *** [drivers/char/tpm/tpm_i2c_infineon.o] Error 1
Was this code tested?
Yes - quite extensively and also reviewed quite extensively.
> I've applied this patch to my tpmdd staging tree [1].
Thanks a lot, Kent.
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
I've applied this patch to my tpmdd staging tree [1].
Thanks a lot, Kent.
Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
42 matches
Mail list logo
