Re: [PATCH 00/12] New Crypto service commands

From: Dinh Nguyen
Date: Tue Jun 27 2023 - 11:17:34 EST




On 6/23/23 02:35, Ang, Tien Sung wrote:


-----Original Message-----
From: Dinh Nguyen <dinguyen@xxxxxxxxxx>
Sent: Friday, 23 June, 2023 3:32 PM
To: Ang, Tien Sung <tien.sung.ang@xxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 00/12] New Crypto service commands



On 6/23/23 01:53, Ang, Tien Sung wrote:


-----Original Message-----
From: Dinh Nguyen <dinguyen@xxxxxxxxxx>
Sent: Friday, 23 June, 2023 1:37 PM
To: Ang, Tien Sung <tien.sung.ang@xxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 00/12] New Crypto service commands



On 6/22/23 22:20, tien.sung.ang@xxxxxxxxx wrote:
From: Ang Tien Sung <tien.sung.ang@xxxxxxxxx>

hi,
This patch set comprises updates to the svc driver to add new crypto
services for AES encryption/decryption, SHA2 digest generation, SHA2
MAC verification, ECDSA hash signing, ECDSA SHA2 data signing, ECDSA
hash signature verification, ECDSA SHA2 data signature verification
crypto key management and lastly ECDSA public key retrieval.
The additions of the commands are all standard entries to svc driver
with minimal logic.


I guess I'll ask the same question, who's the consumer for these?


This commands will be used by the future and current downstream crypto
driver that is under redesign.
The svc driver is merely a firmware messenger that is used to send
Mailbox commands to the SDM firmware.
It is essential for us to begin doing this first. Thanks


I think what you're going to find out quickly when you upstream more is that
the community will not care about your downstream stuff. The problem I
have with this patch is that you're adding code that no-one is using at the
moment and with the crypto driver being redesigned, this code may or may
not get used, right? Let's focus on the getting the crypto driver first.

Dinh
I disagree. Our customers want the SVC driver to be updated. They will use a
combination of down-stream sources and upstream sources. The crypto driver
development is another matter. We should focus on ensuring the SVC driver is
fully upstream will all features. Hope you understand. Let us get there.


Sorry, but in good stewardship, I cannot accept code that is going to be unused in the kernel. If any other community members want to chime in, I'm open.

Dinh