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

[Dinh Nguyen <dinguyen@kernel.org>]

On 6/23/23 02:35, Ang, Tien Sung wrote:
> 
> 
>> -----Original Message-----
>> From: Dinh Nguyen <dinguyen@kernel.org>
>> Sent: Friday, 23 June, 2023 3:32 PM
>> To: Ang, Tien Sung <tien.sung.ang@intel.com>
>> Cc: linux-kernel@vger.kernel.org
>> 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@kernel.org>
>>>> Sent: Friday, 23 June, 2023 1:37 PM
>>>> To: Ang, Tien Sung <tien.sung.ang@intel.com>
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Subject: Re: [PATCH 00/12] New Crypto service commands
>>>>
>>>>
>>>>
>>>> On 6/22/23 22:20, tien.sung.ang@intel.com wrote:
>>>>> From: Ang Tien Sung <tien.sung.ang@intel.com>
>>>>>
>>>>> 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