Re: [PATCH] crypto: qce - Replace with stub driver

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2519 bytes --]

On 8/12/26 04:07, Bartosz Golaszewski wrote:
> On Wed, 12 Aug 2026 00:41:10 +0200, Eric Biggers <ebiggers@kernel.org> said:
>> On Tue, Aug 11, 2026 at 08:42:55AM -0500, Bartosz Golaszewski wrote:
>>
>>> No, the rationale has never been this. FWIW it can be that it's used for
>>> testing of the crypto module on a supported platform and that is already
>>> enough of a reason to keep it upstream.
>>>
>>> As I've said before: we don't just drop maintained drivers from linux.
>>
>> We definitely do if the drivers are not useful or appropriate for
>> inclusion in the kernel, though the policy varies by subsystem.  Even
>> just last month an entire filesystem got dropped despite someone wanting
>> to maintain it.
>>
> 
> I suppose you're talking about EFS? A thing that can't even be tested on real
> hardware? This is a much more extreme case. Here you have several people
> representing the vendor saying they want to keep and maintain it. I'm fine
> having my own tree and sending PRs to Herbert if he agrees and you are of
> course entirely free to disregard any patches targetting it.

Would you be okay with one of these options?

1. Make the stub driver as the default, with
   the real driver guarded by an off-by-default Kconfig option.

2. Keep the driver as is (with the power management issue fixed),
   but don't register any algorithm implementations with the crypto API.

3. Only register algorithm implementations with the crypto API if a
   non-default Kconfig option is selected.

4. Only register algorithm implementations with the crypto API if a
   non-default module parameter is selected.

5. Move the driver out of drivers/crypto, delete the algorithm
   registrations, and then add support for restricted media content
   decryption later.

The last option would be my preferred one.

Also, if Qualcomm has customers who use the QCE via the crypto API,
is Qualcomm aware of _why_ they made that choice?  From Eric's and
my perspective, that seems like a very strange decision, unless there
are factors that Eric and I are not aware of.

Finally, would you be willing to have a group call to discuss this
at some point?  That might be a more suitable venue for this kind of
discussion, and could potentially lead to a conclusion faster.  Also,
while at least I couldn't sign any NDAs, there might be information that
you could discuss there that you cannot post to a public mailing list.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]