Hello Pankaj,
On 24.03.22 10:55, Pankaj Gupta wrote:
> Hi Ahmad,
>
> Please find the comments in-line.
Thanks for you review.
> Suggest to continue to use two separate descriptor-creation-function for 'encap' and 'decap'.
> This will help these API(s) to be maintained easily going forward.
We can still split them up in future once there is a real need.
But currently they are exactly the same, except for input/output length,
so I think it's correct to not introduce duplication unless needed.
>> - use append_seq_(in|out)_ptr_intlen for both encap/decap as a result
Case in point. The intlen omission was because the two functions are largely
identical and I only fixed up one of them. This is prone to repeat when
we go back to have identical code with minor differences.
> In continuation to the previous comment, there is another suggestion:
>
> Either:
> struct keyblob_info {
> void *key;
> size_t key_len;
>
> void *blob;
> size_t blob_len;
>
> size_t key_mod_len;
> const void *key_mod;
> };
I can do that.
Whats your opinion on the desc size computation? Comment the macro or add
the static inline helper?
Cheers,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi Ahmad,
Please find the comments in-line.
Regards
Pankaj
> -----Original Message-----
> From: Ahmad Fatoum <[email protected]>
> Sent: Thursday, March 24, 2022 3:40 PM
> To: Pankaj Gupta <[email protected]>; Horia Geanta
> <[email protected]>; Herbert Xu <[email protected]>;
> David S. Miller <[email protected]>
> Cc: [email protected]; Eric Biggers
> <[email protected]>; David Gstir <[email protected]>; Matthias
> Schiffer <[email protected]>; Sumit Garg
> <[email protected]>; Jan Luebbe <[email protected]>; Richard
> Weinberger <[email protected]>; [email protected]; Franck Lenormand
> <[email protected]>; James Morris <[email protected]>; Mimi
> Zohar <[email protected]>; [email protected]; David Howells
> <[email protected]>; Jarkko Sakkinen <[email protected]>;
> [email protected]; [email protected];
> [email protected]; [email protected]; James Bottomley
> <[email protected]>; Serge E. Hallyn <[email protected]>
> Subject: Re: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for
> blob generator
>
> Caution: EXT Email
>
> Hello Pankaj,
>
> On 24.03.22 10:55, Pankaj Gupta wrote:
> > Hi Ahmad,
> >
> > Please find the comments in-line.
>
> Thanks for you review.
>
> > Suggest to continue to use two separate descriptor-creation-function for
> 'encap' and 'decap'.
> > This will help these API(s) to be maintained easily going forward.
>
> We can still split them up in future once there is a real need.
> But currently they are exactly the same, except for input/output length, so I
> think it's correct to not introduce duplication unless needed.
>
> >> - use append_seq_(in|out)_ptr_intlen for both encap/decap as a
> >> result
>
> Case in point. The intlen omission was because the two functions are largely
> identical and I only fixed up one of them. This is prone to repeat when we go
> back to have identical code with minor differences.
>
> > In continuation to the previous comment, there is another suggestion:
> >
> > Either:
> > struct keyblob_info {
> > void *key;
> > size_t key_len;
> >
> > void *blob;
> > size_t blob_len;
> >
> > size_t key_mod_len;
> > const void *key_mod;
> > };
>
> I can do that.
>
Please do. Thanks.
Patch 4/4, needs to be re-worked to.
> Whats your opinion on the desc size computation? Comment the macro or
> add the static inline helper?
>
Comment the macro is fine.
> Cheers,
> Ahmad
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&data=04%7C01%7Cpankaj.gupta%40nxp.com%7C4
> d60f0d524a04b7cbd7b08da0d7e7d21%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C637837134158793951%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000&sdata=PetvZm8teusBwQ4BeZ1VLEOvBlCrZ2k2bNG3SJBEXPw%3D&
> amp;reserved=0 |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 28.03.22 11:29, Pankaj Gupta wrote:
>>> struct keyblob_info {
>>> void *key;
>>> size_t key_len;
>>>
>>> void *blob;
>>> size_t blob_len;
>>>
>>> size_t key_mod_len;
>>> const void *key_mod;
>>> };
>>
>> I can do that.
>>
>
> Please do. Thanks.
I went with your other suggestion instead: void *input and void *output.
This keeps the code simple and avoids having to do:
if (encap) {
in = info->key;
in_len = info->key_len;
out = info->blob_len;
out_len = info->key_len + CAAM_BLOB_OVERHEAD;
} else {
in = info->blob;
in_len = info->blob_len;
out = info->key_len;
out_len = info->blob_len - CAAM_BLOB_OVERHEAD;
}
> Patch 4/4, needs to be re-worked to.
>
>> Whats your opinion on the desc size computation? Comment the macro or
>> add the static inline helper?
>>
>
> Comment the macro is fine.
>
>> Cheers,
>> Ahmad
>>
>> --
>> Pengutronix e.K. | |
>> Steuerwalder Str. 21 |
>> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>> pengutronix.de%2F&data=04%7C01%7Cpankaj.gupta%40nxp.com%7C4
>> d60f0d524a04b7cbd7b08da0d7e7d21%7C686ea1d3bc2b4c6fa92cd99c5c30163
>> 5%7C0%7C0%7C637837134158793951%7CUnknown%7CTWFpbGZsb3d8eyJWI
>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>> 000&sdata=PetvZm8teusBwQ4BeZ1VLEOvBlCrZ2k2bNG3SJBEXPw%3D&
>> amp;reserved=0 |
>> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |