In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Herbert Xu
Cc: Jesper Nilsson
Cc: Lars Persson
Cc: Niklas Cassel
Cc: "David S. Miller"
Cc: Jamie Il
Device number (the character device index) is not a stable identifier
for a TPM chip. That is the reason why every call site passes
TPM_ANY_NUM to tpm_chip_find_get().
This commit changes the API in a way that instead a struct tpm_chip
instance is given and NULL means the default chip. In addition
Hi Jason,
Nice to see this patch. Some minor comments below.
On 25 October 2017 at 00:12, Jason Gunthorpe
wrote:
> The tpm-rng.c approach is completely inconsistent with how the kernel
> handles hotplug. Instead manage a hwrng device for each TPM. This will
> cause the kernel to read entropy fro
Hi Jarkko,
On 24 October 2017 at 23:52, Jarkko Sakkinen
wrote:
> On Tue, Oct 24, 2017 at 10:05:20PM +0530, PrasannaKumar Muralidharan wrote:
>> > 1. Every user in the kernel is using TPM_ANY_NUM, which means there are
>> >no other users.
>>
>> Completely agree that there is no in kernel users
Hi Jarkko,
On 25 October 2017 at 17:25, Jarkko Sakkinen
wrote:
> Device number (the character device index) is not a stable identifier
> for a TPM chip. That is the reason why every call site passes
> TPM_ANY_NUM to tpm_chip_find_get().
>
> This commit changes the API in a way that instead a stru
On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan
wrote:
> > +static int tpm_add_hwrng(struct tpm_chip *chip)
> > +{
> > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM))
> > + return 0;
>
> Can #ifndef CONFIG_HW_RANDOM_TPM be used instead? That way an if
> condition
On Wed, Oct 25, 2017 at 01:55:04PM +0200, Jarkko Sakkinen wrote:
> Device number (the character device index) is not a stable identifier
> for a TPM chip. That is the reason why every call site passes
> TPM_ANY_NUM to tpm_chip_find_get().
>
> This commit changes the API in a way that instead a str
Hi Jason,
On 25 October 2017 at 20:48, Jason Gunthorpe
wrote:
> On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan
> wrote:
>
>> > +static int tpm_add_hwrng(struct tpm_chip *chip)
>> > +{
>> > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM))
>> > + return 0;
>>
>> Ca
First patch change spaces to tabs, second adds HASH support for Exynos.
Changes:
version 8:
- fixes suggested by Vladimir Zapolskiy: drop first condition check in
s5p_hash_import, delete unused include delay.h, fix typo in commit
message, fix descriptions of struct s5p_hash_reqctx and functio
Hello,
While running the kcapi test suite on a SAMA5D2 Xplained board with a
v4.14-rc6 kernel, I encountered the following error:
# kcapi -x 9 -e -c "cbc(aes)" -i -k 000
0 -p 1b077a6af4b7f98229de786d7516b639
BUG: schedul
Change #define lines to use tabs consistently.
Acked-by: Vladimir Zapolskiy
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Kamil Konieczny
---
drivers/crypto/s5p-sss.c | 190 +++
1 file changed, 95 insertions(+), 95 deletions(-)
diff --git a/driver
Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW.
It uses the crypto framework asynchronous hash api.
It is based on omap-sham.c driver.
S5P has some HW differencies and is not implemented.
Modifications in s5p-sss:
- Add hash supporting structures and functions.
- Modify irq hand
Am Mittwoch, 25. Oktober 2017, 17:26:31 CEST schrieb Romain Izard:
Hi Romain, Herbert,
> Hello,
>
> While running the kcapi test suite on a SAMA5D2 Xplained board with a
> v4.14-rc6 kernel, I encountered the following error:
Thank you for the report.
>
> # kcapi -x 9 -e -c "cbc(aes)" -i 0
On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan wrote:
> > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM))
> > + return 0;
>
> Can #ifndef CONFIG_HW_RANDOM_TPM be used instead? That way an if
> condition can be avoided.
Nope. There is no reason to avoid the if-co
On Wed, Oct 25, 2017 at 08:21:16PM +0530, PrasannaKumar Muralidharan wrote:
> >> > 2. Moving struct tpm_rng to the TPM client is architecturally
> >> >uacceptable.
> >>
> >> As there was no response to the patch there is no way to know whether
> >> it is acceptable or not.
> >
> > I like the id
On Wed, Oct 25, 2017 at 08:40:26PM +0530, PrasannaKumar Muralidharan wrote:
> > -struct tpm_chip *tpm_chip_find_get(int chip_num)
> > +struct tpm_chip *tpm_chip_find_get(struct tpm_chip *chip)
> > {
> > - struct tpm_chip *chip, *res = NULL;
> > + struct tpm_chip *res = NULL;
> > +
On Wed, Oct 25, 2017 at 08:58:17PM +0200, Jarkko Sakkinen wrote:
> On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan wrote:
> > > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM))
> > > + return 0;
> >
> > Can #ifndef CONFIG_HW_RANDOM_TPM be used instead? That way an
> struct tpm_chip *tpm_chip_find_get(u64 id)
> {
> struct tpm_chup *chip;
> struct tpm_chip *res = NULL;
> int chip_num = 0;
> int chip_prev;
>
> mutex_lock(&idr_lock);
>
> do {
> chip_prev = chip_num;
>
> chip = idr_get_next(&dev_n
On Wed, Oct 25, 2017 at 01:37:07PM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 25, 2017 at 08:58:17PM +0200, Jarkko Sakkinen wrote:
> > On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan wrote:
> > > > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM))
> > > > + return 0
On Wed, Oct 25, 2017 at 10:00:30PM +0200, Jarkko Sakkinen wrote:
> A minor tidbit: could the tpm_ prefix removed from those fields?
Yes, in v2
I will send v2 when you land your rework patch as this will depend on it.
Jason
On Wed, Oct 25, 2017 at 01:46:33PM -0600, Jason Gunthorpe wrote:
> > struct tpm_chip *tpm_chip_find_get(u64 id)
> > {
> > struct tpm_chup *chip;
> > struct tpm_chip *res = NULL;
> > int chip_num = 0;
> > int chip_prev;
> >
> > mutex_lock(&idr_lock);
> >
> > do {
> >
On Wed, Oct 25, 2017 at 10:07:46PM +0200, Jarkko Sakkinen wrote:
> The id has a nice feature that it is unique for one boot cycle you can
> even try to get a chip that has been deleted. It has the most stable
> properties in the long run.
It isn't unique, we can re-use ids them via idr_alloc(). W
22 matches
Mail list logo