On 5/27/20 5:30 PM, Jarkko Sakkinen wrote:
>> This won't help if the message is read by an async tcti. If the problem lies
>> in the chip get locality code, perhaps this could help to debug the
>> root-cause
>> instead of masking it out in the upper layer code:
> What is TCTI and async TCTI? Not
On 5/26/20 1:00 PM, James Bottomley wrote:
> I don't think there is a root cause other than a TIS TPM is getting
> annoyed by us cycling localities too rapidly because we don't do an
> actual TPM operation between request and relinquish. Since the first
> request/relinquish seems unnecessary for
On 5/26/20 12:14 PM, James Bottomley wrote:
> + /* atomic tpm command send and result receive. We only hold the ops
> + * lock during this period so that the tpm can be unregistered even if
> + * the char dev is held open.
> + */
> + if (tpm_try_get_ops(priv->chip)) {
> +
devm_kcalloc() can fail and return NULL so we need to check for that.
Fixes: 58472f5cd4f6f ("tpm: validate TPM 2.0 commands")
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm2-cmd.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/char/tpm/tpm2-cmd.c b/driver
On 3/28/19 5:34 AM, Jarkko Sakkinen wrote:
> Thank you, it is applied.
Thank you Jarkko.
--
Tadeusz
: add support for partial reads")
Reported-by: Mantas Mikulėnas
Tested-by: Mantas Mikulėnas
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/t
Hi Jarkko,
On 3/25/19 7:09 AM, Jarkko Sakkinen wrote:
> It is still missing the comment I asked to add. Otherwise, it is good.
>
Sorry, I didn't see your email with the suggestion earlier.
To be honest I'm not sure if this comment adds much value, or if it is
even correct. The poll doesn't
: add support for partial reads")
Reported-by: Mantas Mikulėnas
Tested-by: Mantas Mikulėnas
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-de
reads")
Reported-by: Mantas Mikulėnas
Tested-by: Mantas Mikulėnas
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 5e
On 3/20/19 11:51 AM, Mantas Mikulėnas wrote:
> Thanks, this patch seems to work, and I apologize for not responding
> to test the patches earlier.
Thanks for testing.
>
> Any chance it'll be submitted for stable 5.0.x as well?
Yes, it's a regression. I included the "Fixes" tag so
it should be
On 3/20/19 7:30 AM, James Bottomley wrote:
> Just an observation on this: the mutex is now no-longer necessary
> because a read on a size_t quantity is always atomic.
True, that's why it wasn't there at the beginning, but
then things changed and I forgot to add it, so let's
put it there just in
reads")
Reported-by: Mantas Mikulėnas
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 5eecad233ea1..7312d3214381 100644
---
On 3/18/19 4:19 PM, James Bottomley wrote:
>> @@ -203,12 +203,14 @@ __poll_t tpm_common_poll(struct file *file,
>> poll_table *wait)
>> __poll_t mask = 0;
>>
>> poll_wait(file, >async_wait, wait);
>> +mutex_lock(>buffer_mutex);
>>
>> if (!priv->response_read ||
s
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 5eecad233ea1..61e458d6f652 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/cha
On 2/13/19 9:19 AM, Jarkko Sakkinen wrote:
> OK, great, thank you.
>
> They are in my master branch now.
Thanks Jarkko. Are you planning to push it also to 5.1?
random cmd, without
reading the first response - expect the second cmd to fail with -EBUSY
Signed-off-by: Tadeusz Struk
---
v3:
- Remove python docstrings
v2:
- Removed extra logging
- Changed subject tag to selftest/tpm2:
---
tools/testing/selftests/tpm2/tpm2.py |1
tools/testing
In order to have control over how many bytes are read or written
the device needs to be opened in unbuffered mode.
Signed-off-by: Tadeusz Struk
---
v2:
- Changed subject tags to selftests/tpm2:
---
tools/testing/selftests/tpm2/tpm2.py |4 ++--
1 file changed, 2 insertions(+), 2 deletions
On 2/13/19 7:13 AM, Jarkko Sakkinen wrote:
> On Tue, 2019-02-12 at 15:42 -0800, Tadeusz Struk wrote:
>> Three new tests added:
>> 1. Send get random cmd, read header in 1st read, read the rest in second
>>read - expect success
>> 2. Send get random cmd, read only
random cmd, without
reading the first response - expect the second cmd to fail with -EBUSY
Signed-off-by: Tadeusz Struk
---
v2:
- Removed extra logging
- Changed subject tag to selftest/tpm2:
---
tools/testing/selftests/tpm2/tpm2.py |1
tools/testing/selftests/tpm2/tpm2_tests.py
In order to have control over how many bytes are read or written
the device needs to be opened in unbuffered mode.
Signed-off-by: Tadeusz Struk
---
v2:
- Changed subject tags to selftests/tpm2:
---
tools/testing/selftests/tpm2/tpm2.py |4 ++--
1 file changed, 2 insertions(+), 2 deletions
On 2/11/19 8:48 AM, Jarkko Sakkinen wrote:
> You are missing a cover letter from this patch set. Please have it in
> v2. Also use tag "selftests/tpm2" instead of having two tags in the
> short summaries. Now they look a bit weird.
Since when is the cover letter mandatory?
I understand that is
random cmd, without
reading the first response - expect the second cmd to fail with -EBUSY
Signed-off-by: Tadeusz Struk
---
tools/testing/selftests/tpm2/tpm2.py |1
tools/testing/selftests/tpm2/tpm2_tests.py | 82
2 files changed, 83 insertions(+)
diff
In order to have control over how many bytes are read or written
the device needs to be opened in unbuffered mode.
Signed-off-by: Tadeusz Struk
---
tools/testing/selftests/tpm2/tpm2.py |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/tpm2/tpm2
On 11/27/18 2:10 PM, Jarkko Sakkinen wrote:
> Added the tests that I've been using for testing TPM 2.0 functionality
> for long time but have out-of-tree so far residing in
>
> https://github.com/jsakkine-intel/tpm2-scripts
>
> Cc: Tadeusz Struk
> Signed-off-by: Jarkko Sakk
On 11/27/18 2:10 PM, Jarkko Sakkinen wrote:
> Added the tests that I've been using for testing TPM 2.0 functionality
> for long time but have out-of-tree so far residing in
>
> https://github.com/jsakkine-intel/tpm2-scripts
>
> Cc: Tadeusz Struk
> Signed-off-by: Jarkko Sakk
, until the whole response is consumed.
The user can also read only part of the response and ignore
the rest by issuing a new write to send a new command.
Signed-off-by: Tadeusz Struk
---
The usecase is implemented in this TSS commit:
https://github.com/tpm2-software/tpm2-tss/commit
, until the whole response is consumed.
The user can also read only part of the response and ignore
the rest by issuing a new write to send a new command.
Signed-off-by: Tadeusz Struk
---
The usecase is implemented in this TSS commit:
https://github.com/tpm2-software/tpm2-tss/commit
On 11/20/18 3:07 PM, Jarkko Sakkinen wrote:
+ /* Holds the resul of the last successful call to tpm_transmit() */
>>> This comment is cruft.
>> Do you want me to remove it? This is the comment you proposed.
> As I explained before it made sense before you made the remark that
> it can only
On 11/20/18 3:07 PM, Jarkko Sakkinen wrote:
+ /* Holds the resul of the last successful call to tpm_transmit() */
>>> This comment is cruft.
>> Do you want me to remove it? This is the comment you proposed.
> As I explained before it made sense before you made the remark that
> it can only
On 11/20/18 4:48 AM, Jarkko Sakkinen wrote:
>> +/* Holds the resul of the last successful call to tpm_transmit() */
> This comment is cruft.
Do you want me to remove it? This is the comment you proposed.
>
>> +size_t response_length;
> data_pending would be now perfectly fine name now
On 11/20/18 4:48 AM, Jarkko Sakkinen wrote:
>> +/* Holds the resul of the last successful call to tpm_transmit() */
> This comment is cruft.
Do you want me to remove it? This is the comment you proposed.
>
>> +size_t response_length;
> data_pending would be now perfectly fine name now
On 11/20/18 4:48 AM, Jarkko Sakkinen wrote:
>> The usecase is implemented in this TSS commit:
>> https://github.com/tpm2-software/tpm2-tss/commit/ce982f67a67dc08e24683d30b05800648d8a264c
> Can you implement test for this to
>
> https://github.com/jsakkine-intel/tpm2-scripts
Just created a PR for
On 11/20/18 4:48 AM, Jarkko Sakkinen wrote:
>> The usecase is implemented in this TSS commit:
>> https://github.com/tpm2-software/tpm2-tss/commit/ce982f67a67dc08e24683d30b05800648d8a264c
> Can you implement test for this to
>
> https://github.com/jsakkine-intel/tpm2-scripts
Just created a PR for
, until the whole response is consumed.
The user can also read only part of the response and ignore
the rest by issuing a new write to send a new command.
Signed-off-by: Tadeusz Struk
---
The usecase is implemented in this TSS commit:
https://github.com/tpm2-software/tpm2-tss/commit
, until the whole response is consumed.
The user can also read only part of the response and ignore
the rest by issuing a new write to send a new command.
Signed-off-by: Tadeusz Struk
---
The usecase is implemented in this TSS commit:
https://github.com/tpm2-software/tpm2-tss/commit
On 11/19/18 9:28 AM, Jarkko Sakkinen wrote:
> Ah, you are correct.
>
> You should add a boolean flag instead of introducing a new variable for
> holding amount that has been read because obviously one read operation
> is enough for backwards compatibility.
>
> The code could read the code to
On 11/19/18 9:28 AM, Jarkko Sakkinen wrote:
> Ah, you are correct.
>
> You should add a boolean flag instead of introducing a new variable for
> holding amount that has been read because obviously one read operation
> is enough for backwards compatibility.
>
> The code could read the code to
On 11/19/18 5:58 AM, Jarkko Sakkinen wrote:
> Please explain a scenario where "!ret_size" would no work given that
> both size and partial_data have always positive value?
Right, I only looked at the one line above before responding.
I'll change it to !ret_size
>
> I don't understand. In order
On 11/19/18 5:58 AM, Jarkko Sakkinen wrote:
> Please explain a scenario where "!ret_size" would no work given that
> both size and partial_data have always positive value?
Right, I only looked at the one line above before responding.
I'll change it to !ret_size
>
> I don't understand. In order
On 11/17/18 11:48 PM, Jarkko Sakkinen wrote:
>> +if (priv->transmit_result || priv->partial_data) {
>> +if (*off == 0)
>> +priv->partial_data = priv->transmit_result;
>> +
>> +ret_size = min_t(ssize_t, size, priv->partial_data);
>> +if
On 11/17/18 11:48 PM, Jarkko Sakkinen wrote:
>> +if (priv->transmit_result || priv->partial_data) {
>> +if (*off == 0)
>> +priv->partial_data = priv->transmit_result;
>> +
>> +ret_size = min_t(ssize_t, size, priv->partial_data);
>> +if
, until the whole response is consumed.
The user can also read only part of the response and ignore
the rest by issuing a new write to send a new command.
Signed-off-by: Tadeusz Struk
---
The usecase is implemented in this TSS commit:
https://github.com/tpm2-software/tpm2-tss/commit
, until the whole response is consumed.
The user can also read only part of the response and ignore
the rest by issuing a new write to send a new command.
Signed-off-by: Tadeusz Struk
---
The usecase is implemented in this TSS commit:
https://github.com/tpm2-software/tpm2-tss/commit
off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 20 ++--
drivers/char/tpm/tpm-dev.h|4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 99b5133a9
off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 20 ++--
drivers/char/tpm/tpm-dev.h|4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 99b5133a9
On 11/15/18 3:31 PM, Jarkko Sakkinen wrote:
> You could drop these memset() calls and also one from
> tpm_timeout_work(). The call could be done once in the beginning of
> tpm_common_write() instead of having three different call sites.
>
Don't we want to clean the buffer as the response is
On 11/15/18 3:31 PM, Jarkko Sakkinen wrote:
> You could drop these memset() calls and also one from
> tpm_timeout_work(). The call could be done once in the beginning of
> tpm_common_write() instead of having three different call sites.
>
Don't we want to clean the buffer as the response is
, until the whole response is consumed.
The user can also read only part of the response and ignore
the rest by issuing a new write to send a new command.
Signed-off-by: Tadeusz Struk
---
The usecase is implemented in this TSS commit:
https://github.com/tpm2-software/tpm2-tss/commit
, until the whole response is consumed.
The user can also read only part of the response and ignore
the rest by issuing a new write to send a new command.
Signed-off-by: Tadeusz Struk
---
The usecase is implemented in this TSS commit:
https://github.com/tpm2-software/tpm2-tss/commit
On 11/5/18 5:44 AM, Jarkko Sakkinen wrote:
> You don't explain what the commit does at all.
>
>> The usecase is implemented in this TSS commit:
>> https://github.com/tpm2-software/tpm2-tss/commit/ce982f67a67dc08e24683d30b05800648d8a264c
> We do not want this as part of the commit message. You
On 11/5/18 5:44 AM, Jarkko Sakkinen wrote:
> You don't explain what the commit does at all.
>
>> The usecase is implemented in this TSS commit:
>> https://github.com/tpm2-software/tpm2-tss/commit/ce982f67a67dc08e24683d30b05800648d8a264c
> We do not want this as part of the commit message. You
Hi Jarkko,
On 11/5/18 5:39 AM, Jarkko Sakkinen wrote:
>> Changes in v2:
>> - Allow writes after only partial response is consumed to maintain
>>backwords compatibility.
> I do not understand what this bullet means. Do you deny writes somehow?
No I don't. This comment was wrt the first
Hi Jarkko,
On 11/5/18 5:39 AM, Jarkko Sakkinen wrote:
>> Changes in v2:
>> - Allow writes after only partial response is consumed to maintain
>>backwords compatibility.
> I do not understand what this bullet means. Do you deny writes somehow?
No I don't. This comment was wrt the first
-by: Tadeusz Struk
---
Changes in v2:
- Allow writes after only partial response is consumed to maintain
backwords compatibility.
---
drivers/char/tpm/tpm-dev-common.c | 38 -
drivers/char/tpm/tpm-dev.h|2 ++
2 files changed, 31 insertions
-by: Tadeusz Struk
---
Changes in v2:
- Allow writes after only partial response is consumed to maintain
backwords compatibility.
---
drivers/char/tpm/tpm-dev-common.c | 38 -
drivers/char/tpm/tpm-dev.h|2 ++
2 files changed, 31 insertions
On 9/16/18 5:03 AM, Jarkko Sakkinen wrote:
> I tried to test this but I get 404 from
> https://github.com/tstruk/tpm2-tss/tree/async
This has been already merged to tss upstream
https://github.com/tpm2-software/tpm2-tss
To enable it you need to configure tss with --enable-tcti-device-async=yes
On 9/16/18 5:03 AM, Jarkko Sakkinen wrote:
> I tried to test this but I get 404 from
> https://github.com/tstruk/tpm2-tss/tree/async
This has been already merged to tss upstream
https://github.com/tpm2-software/tpm2-tss
To enable it you need to configure tss with --enable-tcti-device-async=yes
On 08/31/2018 01:58 AM, Jarkko Sakkinen wrote:
> Just the change to the commit message. Mislooked patchwork, the typo was
> in my response :-) I'll do recheck for 2/2. Check those comments before
> v6 if there is anything else.
Hi,
I have done the changes you requested and ran the "checkpatch.pl
On 08/31/2018 01:58 AM, Jarkko Sakkinen wrote:
> Just the change to the commit message. Mislooked patchwork, the typo was
> in my response :-) I'll do recheck for 2/2. Check those comments before
> v6 if there is anything else.
Hi,
I have done the changes you requested and ran the "checkpatch.pl
Add a ptr to struct tpm_space to the file_priv and consolidate
of the write operations for the two interfaces.
Tested-by: Philip Tricca
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c |8 +---
drivers/char/tpm/tpm-dev.c| 10 ++
drivers/char/tpm/tpm
hing
what's needed is in the file_priv struct.
- Renamed the 'work' member of the timer to avoid confusion.
Now there are 'timeout_work' and 'async_work'.
- Removed the global wait queue and moved it to file_priv.
- Only creating the work queue when the first file is opened.
Tadeusz Struk (2):
tpm: add
Add a ptr to struct tpm_space to the file_priv and consolidate
of the write operations for the two interfaces.
Tested-by: Philip Tricca
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c |8 +---
drivers/char/tpm/tpm-dev.c| 10 ++
drivers/char/tpm/tpm
hing
what's needed is in the file_priv struct.
- Renamed the 'work' member of the timer to avoid confusion.
Now there are 'timeout_work' and 'async_work'.
- Removed the global wait queue and moved it to file_priv.
- Only creating the work queue when the first file is opened.
Tadeusz Struk (2):
tpm: add
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 141 -
drivers/char/tpm/tpm-dev.c|1
drivers/char/tpm/tpm-dev.h| 13 ++-
drivers/char/tpm/tpm-interface.c | 24 +-
drivers/char/tpm/tpm.h|2
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 141 -
drivers/char/tpm/tpm-dev.c|1
drivers/char/tpm/tpm-dev.h| 13 ++-
drivers/char/tpm/tpm-interface.c | 24 +-
drivers/char/tpm/tpm.h|2
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 142 -
drivers/char/tpm/tpm-dev.c|1
drivers/char/tpm/tpm-dev.h| 13 ++-
drivers/char/tpm/tpm-interface.c | 24 +-
drivers/char/tpm/tpm.h|2
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 142 -
drivers/char/tpm/tpm-dev.c|1
drivers/char/tpm/tpm-dev.h| 13 ++-
drivers/char/tpm/tpm-interface.c | 24 +-
drivers/char/tpm/tpm.h|2
ork' and 'async_work'.
- Removed the global wait queue and moved it to file_priv.
- Only creating the work queue when the first file is opened.
Tadeusz Struk (2):
tpm: add ptr to the tpm_space struct to file_priv
tpm: add support for nonblocking operation
drivers/char/tpm/tpm
Add a ptr to struct tpm_space to the file_priv to have an easy
access to it in the async job without the need to allocate memory.
This also allows to consolidate of the write operations for
the two interfaces.
Tested-by: Philip Tricca
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev
ork' and 'async_work'.
- Removed the global wait queue and moved it to file_priv.
- Only creating the work queue when the first file is opened.
Tadeusz Struk (2):
tpm: add ptr to the tpm_space struct to file_priv
tpm: add support for nonblocking operation
drivers/char/tpm/tpm
Add a ptr to struct tpm_space to the file_priv to have an easy
access to it in the async job without the need to allocate memory.
This also allows to consolidate of the write operations for
the two interfaces.
Tested-by: Philip Tricca
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev
On 08/10/2018 12:00 PM, James Bottomley wrote:
> On Fri, 2018-08-10 at 11:56 -0700, Tadeusz Struk wrote:
>> On 08/10/2018 11:48 AM, James Bottomley wrote:
>>> On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
>>>> and the feedback I got from Jason was:
>
On 08/10/2018 12:00 PM, James Bottomley wrote:
> On Fri, 2018-08-10 at 11:56 -0700, Tadeusz Struk wrote:
>> On 08/10/2018 11:48 AM, James Bottomley wrote:
>>> On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
>>>> and the feedback I got from Jason was:
>
On 08/10/2018 11:48 AM, James Bottomley wrote:
> On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
>> and the feedback I got from Jason was:
>>
>> "I wonder if it is worth creating this when the first file is
>> opened.. Lots of systems have TPMs but few
On 08/10/2018 11:48 AM, James Bottomley wrote:
> On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
>> and the feedback I got from Jason was:
>>
>> "I wonder if it is worth creating this when the first file is
>> opened.. Lots of systems have TPMs but few
On 08/10/2018 10:43 AM, Jarkko Sakkinen wrote:
>> +static struct workqueue_struct *tpm_dev_wq;
> A naming contradiction with tpm_common_read() and tpm_common_write(). To
> sort that up I would suggest adding a commit to the patch set that
> renames these functions as tpm_dev_common_read() and
>
On 08/10/2018 10:43 AM, Jarkko Sakkinen wrote:
>> +static struct workqueue_struct *tpm_dev_wq;
> A naming contradiction with tpm_common_read() and tpm_common_write(). To
> sort that up I would suggest adding a commit to the patch set that
> renames these functions as tpm_dev_common_read() and
>
On 08/10/2018 10:27 AM, Jarkko Sakkinen wrote:
> On Tue, Aug 07, 2018 at 01:27:44PM -0700, Tadeusz Struk wrote:
>> Add a ptr to struct tpm_space to the file_priv to have an easy
>> access to it in the async job without the need to allocate memory.
>> This also allows to con
On 08/10/2018 10:27 AM, Jarkko Sakkinen wrote:
> On Tue, Aug 07, 2018 at 01:27:44PM -0700, Tadeusz Struk wrote:
>> Add a ptr to struct tpm_space to the file_priv to have an easy
>> access to it in the async job without the need to allocate memory.
>> This also allows to con
Add a ptr to struct tpm_space to the file_priv to have an easy
access to it in the async job without the need to allocate memory.
This also allows to consolidate of the write operations for
the two interfaces.
Tested-by: Philip Tricca
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 149 -
drivers/char/tpm/tpm-dev.c| 16 +++-
drivers/char/tpm/tpm-dev.h| 17 +++-
drivers/char/tpm/tpm-interface.c |1
drivers/char/tpm/tpm.h|1
Add a ptr to struct tpm_space to the file_priv to have an easy
access to it in the async job without the need to allocate memory.
This also allows to consolidate of the write operations for
the two interfaces.
Tested-by: Philip Tricca
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 149 -
drivers/char/tpm/tpm-dev.c| 16 +++-
drivers/char/tpm/tpm-dev.h| 17 +++-
drivers/char/tpm/tpm-interface.c |1
drivers/char/tpm/tpm.h|1
when the first file is opened.
Tadeusz Struk (2):
tpm: add ptr to the tpm_space struct to file_priv
tpm: add support for nonblocking operation
drivers/char/tpm/tpm-dev-common.c | 150 +++--
drivers/char/tpm/tpm-dev.c| 22 +++--
driver
when the first file is opened.
Tadeusz Struk (2):
tpm: add ptr to the tpm_space struct to file_priv
tpm: add support for nonblocking operation
drivers/char/tpm/tpm-dev-common.c | 150 +++--
drivers/char/tpm/tpm-dev.c| 22 +++--
driver
On 08/07/2018 11:20 AM, Jason Gunthorpe wrote:
> Doesn't lockdep complain when locks are left held after returning to
> user space? Even if it doesn't, that is a pretty ugly thing to do.
I didn't notice anything from lockdep during my testing,
but I will change it to release the lock before
On 08/07/2018 11:20 AM, Jason Gunthorpe wrote:
> Doesn't lockdep complain when locks are left held after returning to
> user space? Even if it doesn't, that is a pretty ugly thing to do.
I didn't notice anything from lockdep during my testing,
but I will change it to release the lock before
On 08/06/2018 05:35 PM, James Bottomley wrote:
> On Mon, 2018-08-06 at 17:09 -0700, Tadeusz Struk wrote:
>> On 08/06/2018 04:05 PM, James Bottomley wrote:
>>> For an async interface, shouldn't I be able to queue an
>>> arbitrary number of commands without blocking?
On 08/06/2018 05:35 PM, James Bottomley wrote:
> On Mon, 2018-08-06 at 17:09 -0700, Tadeusz Struk wrote:
>> On 08/06/2018 04:05 PM, James Bottomley wrote:
>>> For an async interface, shouldn't I be able to queue an
>>> arbitrary number of commands without blocking?
On 08/06/2018 04:05 PM, James Bottomley wrote:
> For an async interface, shouldn't I be able to queue an
> arbitrary number of commands without blocking?
That was the approach in the v1 version of this patch, but
Jason requested this to be changed so that only one command
at a time can be
On 08/06/2018 04:05 PM, James Bottomley wrote:
> For an async interface, shouldn't I be able to queue an
> arbitrary number of commands without blocking?
That was the approach in the v1 version of this patch, but
Jason requested this to be changed so that only one command
at a time can be
Add a ptr to struct tpm_space to the file_priv to have an easy
access to it in the async job without the need to allocate memory.
This also allows to consolidate of the write operations for
the two interfaces.
Tested-by: Philip Tricca
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev
Add a ptr to struct tpm_space to the file_priv to have an easy
access to it in the async job without the need to allocate memory.
This also allows to consolidate of the write operations for
the two interfaces.
Tested-by: Philip Tricca
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 145 +++--
drivers/char/tpm/tpm-dev.c| 16 +++-
drivers/char/tpm/tpm-dev.h| 16 +++-
drivers/char/tpm/tpm-interface.c |1
drivers/char/tpm/tpm.h|1
Signed-off-by: Tadeusz Struk
---
drivers/char/tpm/tpm-dev-common.c | 145 +++--
drivers/char/tpm/tpm-dev.c| 16 +++-
drivers/char/tpm/tpm-dev.h| 16 +++-
drivers/char/tpm/tpm-interface.c |1
drivers/char/tpm/tpm.h|1
r to avoid confusion.
Now there are 'timeout_work' and 'async_work'.
- Removed the global wait queue and moved it to file_priv.
- Only creating the work queue when the first file is opened.
Tadeusz Struk (2):
tpm: add ptr to the tpm_space struct to file_priv
tpm: add support for n
r to avoid confusion.
Now there are 'timeout_work' and 'async_work'.
- Removed the global wait queue and moved it to file_priv.
- Only creating the work queue when the first file is opened.
Tadeusz Struk (2):
tpm: add ptr to the tpm_space struct to file_priv
tpm: add support for n
On 07/23/2018 03:08 PM, Jason Gunthorpe wrote:
> On Mon, Jul 23, 2018 at 03:00:20PM -0700, Tadeusz Struk wrote:
>> On 07/23/2018 02:56 PM, Jason Gunthorpe wrote:
>>> The proposed patch doesn't clear the data_pending if the entire buffer
>>> is not consumed, so o
On 07/23/2018 03:08 PM, Jason Gunthorpe wrote:
> On Mon, Jul 23, 2018 at 03:00:20PM -0700, Tadeusz Struk wrote:
>> On 07/23/2018 02:56 PM, Jason Gunthorpe wrote:
>>> The proposed patch doesn't clear the data_pending if the entire buffer
>>> is not consumed, so o
On 07/23/2018 02:56 PM, Jason Gunthorpe wrote:
> The proposed patch doesn't clear the data_pending if the entire buffer
> is not consumed, so of course it is ABI breaking, that really isn't OK.
The data_pending will be cleared by the timeout handler if the user doesn't
read the response fully
1 - 100 of 611 matches
Mail list logo
