Re: [PATCH] crypto: talitos - fix rename first/last to first_desc/last_desc

Re: [PATCH] crypto: talitos - fix rename first/last to first_desc/last_desc

[Paul Louvel]

On Wed May 20, 2026 at 6:58 PM CEST, Goetz Goerisch wrote:
> Hi,
>
> Commit a1b80018b8cec27fc06a8b04a7f8b5f6cfe86eae
> was backported to 6.6.y with a866e2b1c65edaee2e1bb1024ee2c761ced335f8
> It renames last to last_desc but misses one occurrence which leads to compile errors on mpc85xx

Hi Goetz,

Thank you for the patch. I did not catch that since I worked on a mainline tree,
and that specific line was removed in 9826d1d6ed5f ("crypto: talitos - stop
using crypto_ahash::init"), which was not backported into the stable tree.

> drivers/crypto/talitos.c: In function 'ahash_digest':
> drivers/crypto/talitos.c:2204:16: error: 'struct talitos_ahash_req_ctx' has no member named 'last'
>  2204 | req_ctx->last = 1;
>       |        ^~4
>
> Fixes: a866e2b1c65e ("crypto: talitos - rename first/last to first_desc/last_desc")
> Signed-off-by: Goetz Goerisch <ggoerisch@gmail.com>
> ---
>  drivers/crypto/talitos.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index 347483f6fc5d..ed160c591346 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -2201,7 +2201,7 @@ static int ahash_digest(struct ahash_request *areq)
>  	struct crypto_ahash *ahash = crypto_ahash_reqtfm(areq);
>  
>  	ahash->init(areq);
> -	req_ctx->last = 1;
> +	req_ctx->last_desc = 1;

Instead of renaming req_ctx->last, commit 9826d1d6ed5f8 ("crypto: talitos - stop
using crypto_ahash::init") should be applied. Ideally before commit
655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation") to
avoid any compilation breakage and ensure correctness of the code.

>  
>  	return ahash_process_req(areq, areq->nbytes);
>  }

Paul.

-- 
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] crypto: talitos - fix rename first/last to first_desc/last_desc

[Paul Louvel]

On Thu May 21, 2026 at 12:16 PM CEST, Paul Louvel wrote:
> On Wed May 20, 2026 at 6:58 PM CEST, Goetz Goerisch wrote:
>> Hi,
>>
>> Commit a1b80018b8cec27fc06a8b04a7f8b5f6cfe86eae
>> was backported to 6.6.y with a866e2b1c65edaee2e1bb1024ee2c761ced335f8
>> It renames last to last_desc but misses one occurrence which leads to compile errors on mpc85xx
>
> Hi Goetz,
>
> Thank you for the patch. I did not catch that since I worked on a mainline tree,
> and that specific line was removed in 9826d1d6ed5f ("crypto: talitos - stop
> using crypto_ahash::init"), which was not backported into the stable tree.
>
>> drivers/crypto/talitos.c: In function 'ahash_digest':
>> drivers/crypto/talitos.c:2204:16: error: 'struct talitos_ahash_req_ctx' has no member named 'last'
>>  2204 | req_ctx->last = 1;
>>       |        ^~4
>>
>> Fixes: a866e2b1c65e ("crypto: talitos - rename first/last to first_desc/last_desc")
>> Signed-off-by: Goetz Goerisch <ggoerisch@gmail.com>
>> ---
>>  drivers/crypto/talitos.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
>> index 347483f6fc5d..ed160c591346 100644
>> --- a/drivers/crypto/talitos.c
>> +++ b/drivers/crypto/talitos.c
>> @@ -2201,7 +2201,7 @@ static int ahash_digest(struct ahash_request *areq)
>>  	struct crypto_ahash *ahash = crypto_ahash_reqtfm(areq);
>>  
>>  	ahash->init(areq);
>> -	req_ctx->last = 1;
>> +	req_ctx->last_desc = 1;
>
> Instead of renaming req_ctx->last, commit 9826d1d6ed5f8 ("crypto: talitos - stop
> using crypto_ahash::init") should be applied. Ideally before commit
> 655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation") to
> avoid any compilation breakage and ensure correctness of the code.

Small correction:

Ideally before commit 00463d5f864a ("crypto: talitos - fix SEC1 32k ahash
request limitation") to avoid any compilation breakage and ensure correctness of
the code.

>
>>  
>>  	return ahash_process_req(areq, areq->nbytes);
>>  }
>
> Paul.




-- 
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] crypto: talitos - fix rename first/last to first_desc/last_desc

[Goetz Goerisch]

Dear Paul,

Thank you for this review and feedback.

> > Instead of renaming req_ctx->last, commit 9826d1d6ed5f8 ("crypto: talitos - stop
> > using crypto_ahash::init") should be applied. Ideally before commit
> > 655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation") to
> > avoid any compilation breakage and ensure correctness of the code.
> 
> Small correction:
> 
> Ideally before commit 00463d5f864a ("crypto: talitos - fix SEC1 32k ahash
> request limitation") to avoid any compilation breakage and ensure correctness of
> the code.

I can confirm your recommendation. Appyling this commit before, fixes the problem. Please disregard my patch.

Greg could you please backport the mentioned commit to 6.6.y in the correct order for the next update?

I have fixed it for our downstream users for now.

Thank you,
Goetz

Re: [PATCH] crypto: talitos - fix rename first/last to first_desc/last_desc

[Greg Kroah-Hartman]

On Thu, May 21, 2026 at 05:25:18PM +0200, Goetz Goerisch wrote:
> Dear Paul,
> 
> Thank you for this review and feedback.
> 
> > > Instead of renaming req_ctx->last, commit 9826d1d6ed5f8 ("crypto: talitos - stop
> > > using crypto_ahash::init") should be applied. Ideally before commit
> > > 655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation") to
> > > avoid any compilation breakage and ensure correctness of the code.
> > 
> > Small correction:
> > 
> > Ideally before commit 00463d5f864a ("crypto: talitos - fix SEC1 32k ahash
> > request limitation") to avoid any compilation breakage and ensure correctness of
> > the code.
> 
> I can confirm your recommendation. Appyling this commit before, fixes the problem. Please disregard my patch.
> 
> Greg could you please backport the mentioned commit to 6.6.y in the correct order for the next update?

Can you send a series of backported patches in the correct order for us
to apply, so we know to get them correct?  Trying to dig out from an
email like this is usually quite easy to get wrong :)

thanks,

greg k-h