Hi David,
> Gesendet: Mittwoch, 13. Januar 2016 um 05:39 Uhr
> Von: "David Howells"
> An: "Peter Huewe" , "Jarkko Sakkinen"
>
> Cc: dhowe...@redhat.com, dw...@infradead.org,
> tpmdd-devel@lists.sourceforge.net, keyri...@vger.kernel.org
> Bet
Hi Ken,
> Gesendet: Mittwoch, 13. Januar 2016 um 06:35 Uhr
> Von: "Ken Goldman"
> An: tpmdd-devel@lists.sourceforge.net
> Betreff: Re: [tpmdd-devel] TPM emulator driver status
> On 1/13/2016 8:39 AM, David Howells wrote:
> > Hi Peter, Jarkko,
> >
> > Is the TPM emulator likely to go upstream at a
> Gesendet: Donnerstag, 14. Januar 2016 um 06:58 Uhr
> Von: "Stefan Berger"
> An: "David Howells"
> Cc: dw...@infradead.org, "Jarkko Sakkinen" ,
> keyri...@vger.kernel.org, "Peter Huewe" ,
> tpmdd-devel@lists.sourceforge.net
>
Thanks for helping out on this one!!
This was exactly what I planned to do.
I will review and compare it to my patch sets
Peter
--
Sent from my mobile
--
Transform Data into Opportunity.
Accelerate data analysis in your a
Reviewed-by: Peter Huewe
--
Sent from my mobile
--
___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Hi
We can change the filename but keep the module name.
That's what I would propose.
Peter
--
Sent from my mobile
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provid
Thanks for all your efforts!!! I'm sorry I couldn't participate more. :(
So thanks a lot to all of you for taking care of this.
a quick testrun (x86) seemed okay and the patchset looks good to me
reviewed-by: Peter Huewe
tested-by: Peter Huewe
I'll try to give it a more detai
Am 6. Juni 2016 11:57:13 GMT-07:00, schrieb Matthew Garrett
:
>Hi,
>
>I'm looking into running a TPM microconference at the Linux Plubmers
>Conference in Santa Fe the first week of November. Right now we have a
>bunch of individual pieces of TPM-related technology, but little
>overall
>cohere
Faster suspend/resume is always appreciated.
--
Sent from my mobile
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols
Am 14. Juli 2016 19:20:16 GMT-07:00, schrieb Andrey Pronin
:
>This patchset adds a TCG TPM2.0 PTP FIFO compliant interface for
>Cr50 chip on SPI.
>
>Depends on the following patches by Andrey Pronin
>
>that add new members to phy_ops in tpm_tis_core:
> - tpm: support driver-specific sysfs attrs
Hi Andrey,
thanks for the update.
> This patchset adds support for H1 Secure Microcontroller running
> Cr50 firmware. It implements several functions, including TPM-like
> functionality, and communicates over SPI using the FIFO protocol
> described in the PTP Spec, section 6.
> H1 is a proprietar
Hi Ken,
I just checked and it seems that RHEL7.2 has backported some parts of the
TPM2.0 support to their 3.10 kernel.
For the tpm_tis part it is still lacking the acpi detection,
but loading the tpm_tis driver with force=1 should result in a working driver.
(either modprobe tpm_tis force=1 o
Am 29. August 2016 23:36:31 GMT-07:00, schrieb Jarkko Sakkinen
:
>On Tue, Aug 30, 2016 at 12:44:37AM -0400, Nayna Jain wrote:
>> This is documenting device tree binding for
>> I2C based TPM, similar concept which being used
>> for virtual TPM on POWER7 and POWER8 systems running PowerVM.
>>
>>
I agree - I always get stuck upon the sml thing.
>
>Also, enabled should be "enabled", not "okay".
No!
okay/ok is a dt keyword! (Or at least used in everything else)
It has nothing to do whether the TPM is enabled/disabled/activated whatever
See http://www.devicetree.org/specifications-pdf table
Am 30. August 2016 00:06:49 GMT-07:00, schrieb Jarkko Sakkinen
:
>On Mon, Aug 29, 2016 at 11:41:51PM -0700, Peter Huewe wrote:
>>
>>
>> Am 29. August 2016 23:36:31 GMT-07:00, schrieb Jarkko Sakkinen
>:
>> >On Tue, Aug 30, 2016 at 12:44:37AM -0400, Nayna Jain
Am 6. September 2016 12:47:37 GMT-07:00, schrieb Jason Gunthorpe
:
>On Thu, Sep 01, 2016 at 12:39:46AM +0530, Nayna wrote:
>> >>+int read_log_of(struct tpm_chip *chip);
>> >>+#else
>> >>+static inline int read_log_of(struct tpm_chip *chip)
>> >>+{
>> >>+ return -1;
>> >>+}
>> >>+#endif
>> >
>>
Jarkko,
what's the ack for?
As maintainer you usually apply and sign off or don't.
Ack is more if you are not touching the patch but still think it's good
(e.g.goes through another tree.
@Thomas:thanks for your contribution, but please spellcheck your descriptions,
please.
Am 11. September 2016
Am 12. September 2016 00:56:37 GMT-07:00, schrieb Jarkko Sakkinen
:
>On Sun, Sep 11, 2016 at 09:39:04PM -0700, Peter Huewe wrote:
>> Jarkko,
>> what's the ack for?
>> As maintainer you usually apply and sign off or don't.
>> Ack is more if you are not to
Hi
Am 11. Oktober 2016 19:13:13 MESZ, schrieb Jason Gunthorpe
:
>On Tue, Oct 11, 2016 at 03:01:01PM +0300, Jarkko Sakkinen wrote:
>> From: Peter Huewe
>>
>> In some weird cases it might be possible that the TPM does not set
>> STS.VALID within the given time
Am 7. November 2016 18:25:16 MEZ, schrieb Jason Gunthorpe
:
>On Mon, Nov 07, 2016 at 09:17:14AM -0800, Jarkko Sakkinen wrote:
>> Hi
>>
>> At LPC I remember some discussions about moving the ML to
>vger.kernel.org.
>> Do you think we should do that or not? Frankly, I do not have opinion
>on
>> t
Am 14. Februar 2017 03:33:36 MEZ schrieb Andrew Lunn :
>Hi Jason
>
>I'm hoping you can help me with an issue i have with an ATMEL I2C
>TPM. I have one connected to an DLN2 USB-I2C bus controller. Initial
>probe works, i can get the capabilites in /sys/class/tpm/tpm0,
>tpm_version etc:
>
>/sys/cla
Am 14. Februar 2017 14:05:11 MEZ schrieb Andrew Lunn :
>> Just limit the value which get_burstcount() returns to 256.
>>
>> This should do the trick - because that would be the mechanism the
>> tpm itself would use to fragment its response. Atleast for other
>> tpms like our infineon slb9645 i2c
ned-off-by: Peter Huewe
---
drivers/char/tpm/tpm_tis_core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index c0f296b5d413..fc0e9a2734ed 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/driver
Alexander Steffen
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_tis_spi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c
index 6e1a3c43f621..d782b9974c14 100644
--- a/drivers/char/tpm/tpm_tis_spi.c
+++ b/driver
e for other fixes in this series]
Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: Alexander Steffen
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_tis_spi.c | 87 --
1 file changed, 24 insertions(+), 63 deletions
Wait states are signaled in the last byte received from the TPM in
response to the header, not the first byte. Check rx_buf[3] instead of
rx_buf[0].
Cc:
Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: Alexander Steffen
Signed-off-by: Peter Huewe
--
write function was consolidated to one
transfer function, so we do not have to apply the same fix at two locations.
Maybe consider squashing it - we splitted it for easier review.
Affected Kernels: 4.8, 4.9, 4.10
Patchset was tested on Raspberry Pi2 with SLB9670 (TPM1.2 and TPM2.0)
Peter Hue
Limiting transfers to MAX_SPI_FRAMESIZE was not expected by the upper
layers, as tpm_tis has no such limitation. Add a loop to hide that
limitation.
Cc:
Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: Alexander Steffen
Signed-off-by: Peter Huewe
--
negligible performance penalty.
Cc:
Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: Alexander Steffen
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_tis_spi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/tpm/tpm_tis_spi.c b/driver
quash #1 and #3 - but reviewing it merged with #1 is quite hard since
it "obfuscates" the problem - since too much stuff moves around.
That's why I decided to split it - for easier review.
Peter
>
>
>On 16/02/2017 08:08, Peter Huewe wrote:
>> Wait states are signal
nce the splitting loop went missing during the merge.
At least with our tpms that's the case.
(I think we are signalling a higher burstcount value than 64, which is allowed)
>Or is this because of TIS vs PTP differences ?
>
>To be honest, this is a little behind me now :-)
>
&g
r now however the priority is to make the tpm_tis_spi driver work reliably
also on the rpi, and this is what this workaround does.
We can simply remove it once the rpi spi master is fixed.
Peter
>
>
>On 16/02/2017 08:09, Peter Huewe wrote:
>> Testing the implementation with a Raspbe
Am 21. Februar 2017 17:29:48 MEZ schrieb Andrew Lunn :
>On Tue, Feb 21, 2017 at 03:44:59PM +0100, Enric Balletbo i Serra wrote:
>> From: Bryan Freed
>>
>> When the I2C Infineon part is attached to an I2C adapter that imposes
>> a size limitation, large requests will fail -EINVAL.
>> Retry them
Am 22. Februar 2017 22:19:24 MEZ schrieb Jarkko Sakkinen
:
>On Thu, Feb 16, 2017 at 04:08:21PM +0000, Peter Huewe wrote:
>> During our testing it showed that unfortunately the whole native spi
>tpm driver
>> was more or less non-functional since it was merged, e.g. t
This adds another select to avoid the warning, consistent with other
>users
>of the crypto code.
>
>Fixes: c1f92b4b04ad ("tpm: enhance TPM 2.0 PCR extend to support
>multiple banks")
>Signed-off-by: Arnd Bergmann
Lgtm
Reviewed-by: Peter Huewe
>---
> drivers/char/tpm
Am 1. März 2017 12:51:16 MEZ schrieb Enric Balletbo i Serra
:
>From: Sonny Rao
>
>The suspend/resume behavior of the TPM can be controlled
>by setting "powered-while-suspended" in the DTS.
>
>Signed-off-by: Sonny Rao
>Signed-off-by: Enric Balletbo i Serra
>---
>Documentation/devicetree/bindin
kko's Comments
Peter Huewe (5):
tpm_tis_spi: Use single function to transfer data
tpm_tis_spi: Abort transfer when too many wait states are signaled
tpm_tis_spi: Check correct byte for wait state indicator
tpm_tis_spi: Remove limitation of transfers to MAX_SPI_FRAMESIZE bytes
tpm_tis_spi:
8 for the length.
Cc:
Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: Alexander Steffen
Signed-off-by: Peter Huewe
Reviewed-by: Jarkko Sakkinen
Tested-by: Benoit Houyere
---
drivers/char/tpm/tpm_tis_spi.c | 87 ---
Alexander Steffen
Signed-off-by: Peter Huewe
Reviewed-by: Jarkko Sakkinen
Tested-by: Benoit Houyere
---
drivers/char/tpm/tpm_tis_spi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c
index 062799e04f04..639614f2d415 100644
---
Wait states are signaled in the last byte received from the TPM in
response to the header, not the first byte. Check rx_buf[3] instead of
rx_buf[0].
Cc:
Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: Alexander Steffen
Signed-off-by: Peter Huewe
R
ned-off-by: Alexander Steffen
Signed-off-by: Peter Huewe
Reviewed-by: Jarkko Sakkinen
Tested-by: Benoit Houyere
---
drivers/char/tpm/tpm_tis_spi.c | 107 ++---
1 file changed, 58 insertions(+), 49 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis_spi.c b/dr
negligible performance penalty.
Cc:
Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy")
Signed-off-by: Alexander Steffen
Signed-off-by: Peter Huewe
Reviewed-by: Jarkko Sakkinen
Tested-by: Benoit Houyere
---
drivers/char/tpm/tpm_tis_spi.c | 1 +
1 file changed, 1 insertio
Am 27. Februar 2017 20:12:45 MEZ schrieb Wolfram Sang :
>Hi,
>
>> >> > Rather than trying small and smaller transfers, would it not be
>better
>> >> > to get the i2c core to expose the quirk info about transfer
>limits?
>> >> >
>> >>
>> >> Sounds a good idea to me, I guess the quirk info can be a
Am 2. März 2017 13:55:43 MEZ schrieb Jarkko Sakkinen
:
>On Wed, Mar 01, 2017 at 04:36:17PM +0100, Enric Balletbo i Serra wrote:
>> From: Bryan Freed
>>
>> When the I2C Infineon part is attached to an I2C adapter that imposes
>> a size limitation, large requests will fail with -EOPNOTSUPP. Retr
Hi,
Thanks for your patch.
Am 13. März 2017 06:21:57 MEZ schrieb meng...@windriver.com:
>From: Limeng
>
>So far, there is not a sysfs interface for user space code to
>check the TPM hardware version(TPM1.x or TPM2). So, add a
>file named description in /sys/class/tpm/tpmX/ to show it.
It's not re
Am 14. März 2017 19:18:15 MEZ schrieb Ken Goldman :
>On 3/13/2017 3:10 AM, Peter Huewe wrote:
>
>> And yes you are right there is currently no way, except for trial and
>> error, for the userspace to determine this. So an interface to get
>> this information makes sense
ed-off-by: Enric Balletbo i Serra
>> ---
>> This is a reworked version of the original patch based on the
>> suggestion made by Wolfram Sang to simply fall back to a sane minimum
>> when the maximum fails.
>>
>> Changes since v2:
>> - Do not remove faster
38=0x26= invalid post init, which means tpm did not receive tpm_startup command after reset.
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
--
Check out the vibrant tech community on one
> The memory copy from rodata to stack is useless.
>
> Signed-off-by: Jarkko Sakkinen
After review, yes that should work.
Reviewed-by: Peter Huewe
> ---
> drivers/char/tpm/tpm_infineon.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff
> Removed struct tpm_pcrextend_in as it is not used for anything anymore.
>
> Signed-off-by: Jarkko Sakkinen
LGTM.
Reviewed-by: Peter Huewe
> ---
> drivers/char/tpm/tpm.h | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm.h b/driver
sparse complains that tpmrm_write can be made static, and since it is
right we make it static.
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpmrm-dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpmrm-dev.c b/drivers/char/tpm/tpmrm-dev.c
index
Am 7. August 2017 13:46:32 MESZ schrieb Nayna Jain :
>The TPM burstcount status indicates the number of bytes that can
>be sent to the TPM without causing bus wait states. Effectively,
>it is the number of empty bytes in the command FIFO. Further,
>some TPMs have a static burstcount, when the va
Hi,
while skimming through my emails I noticed that sourceforge has flushed its
pending mail queues recently,
probably due to their internal re-structuring.
This is especially annoying since you recently had to re-confirm your
subscription to tpmdd-devel,
and if you did not click that link your
Hi Ken,
(speaking on behalf of myself here, not my employer :) )
> On Mon, Aug 07, 2017 at 01:52:34PM +0200, Peter Huewe wrote:
>> Imho: NACK from my side.
> After these viewpoints definitive NACK from my side too...
> I responded to the thread comments separately. However, ass
Hi Ken,
(again speaking only on my behalf, not my employer)
> Does anyone know of platforms where this occurs?
> I suspect (but not sure) that the days of SuperIO connecting floppy
> drives, printer ports, and PS/2 mouse ports on the LPC bus are over, and
> such legacy systems will not have a TPM.
Thabks Michal!
Am 29. August 2017 15:17:39 MESZ schrieb "Michal Suchánek" :
>Hello,
>
>On Tue, 29 Aug 2017 15:55:09 +0300
>Jarkko Sakkinen wrote:
>
>> On Mon, Aug 28, 2017 at 05:15:58PM +,
>> alexander.stef...@infineon.com wrote:
>> > But is that just because nobody bothered to implement the
Hi
Am 29. August 2017 18:35:26 MESZ schrieb Laurent Bigonville :
>Le 29/08/17 à 18:00, alexander.stef...@infineon.com a écrit :
>> Hi Laurent,
>
>Hello Alexander,
>
>>> Since the version 4.12 (I also tested with 4.13-rc5) of the kernel,
>the tpm
>>> device is not showing up in /dev/. In dmesg I ca
Am 30. August 2017 12:15:10 MESZ schrieb Jarkko Sakkinen
:
>On Tue, Aug 29, 2017 at 03:17:39PM +0200, Michal Suchánek wrote:
>> Hello,
>>
>> On Tue, 29 Aug 2017 15:55:09 +0300
>> Jarkko Sakkinen wrote:
>>
>> > On Mon, Aug 28, 2017 at 05:15:58PM +,
>> > alexander.stef...@infineon.com wrote
Am 12. September 2017 17:45:08 GMT-07:00 schrieb Jarkko Sakkinen
:
>On Wed, Sep 06, 2017 at 08:56:36AM -0400, Nayna Jain wrote:
>> The TPM burstcount status indicates the number of bytes that can
>> be sent to the TPM without causing bus wait states. Effectively,
>> it is the number of empty by
Am 13. September 2017 11:52:12 GMT-07:00 schrieb Ken Goldman
:
>On 9/6/2017 12:12 PM, Jason Gunthorpe wrote:
>>
>> The problem with this approach is that the TPM could totally block
>> the CPU for very long periods of time.
>>
>> It seems very risky to enable..
>>
>
>How would you characteriz
Hi Jarkko, Mimi, James, Jason, and everybody else,
it would be great if we could find a slot to discuss in person how we proceed
with the mailing lists, patch flows and review cycles.
I know there were some discussions, but atleast for my part I did not get the
final conclusion on how we procee
Am 13. September 2017 16:21:25 GMT-07:00 schrieb Jarkko Sakkinen
:
>On Wed, Sep 13, 2017 at 10:48:43PM +0200, Peter Huewe wrote:
>> Hi Jarkko, Mimi, James, Jason, and everybody else,
>>
>> it would be great if we could find a slot to discuss in person how we
>> pro
Am 15. September 2017 10:18:25 GMT-07:00 schrieb Jarkko Sakkinen
:
>Hi
>
>Many people were kicked out from the SourceForge mailing list in the
>July because SF required a resubscription, including non-human users,
>such as patchwork.
>
>We decided to create a new mailing list linux-integ...@vger
Am 15. September 2017 10:40:14 GMT-07:00 schrieb Joe Perches :
>On Fri, 2017-09-15 at 10:36 -0700, Jarkko Sakkinen wrote:
>> On Fri, Sep 15, 2017 at 10:25:36AM -0700, Joe Perches wrote:
>> > On Fri, 2017-09-15 at 10:18 -0700, Jarkko Sakkinen wrote:
>[]
>> > > We decided to create a new mailing li
Am 15. September 2017 13:07:58 GMT-07:00 schrieb Ken Goldman
:
>Newbie question: Do I have to subscribe, or are email addresses being
>migrated
You have to subscribe yourself.
Due to the new privacy regulations I do not have access to any member
information anymore on the old list.
Just se
Am 24. Oktober 2017 20:15:12 MESZ schrieb Jarkko Sakkinen
:
>On Tue, Oct 24, 2017 at 10:02:00AM -0700, Dmitry Torokhov wrote:
>> On Tue, Oct 24, 2017 at 9:11 AM, Jason Gunthorpe
>> wrote:
>> > On Tue, Oct 24, 2017 at 09:37:33PM +0530, PrasannaKumar
>Muralidharan wrote:
>> >> Hi Jason,
>> >>
>>
66 matches
Mail list logo
