On Wed, Mar 25, 2020 at 11:22:13PM -0700, Eric Biggers wrote:
quoted
+#ifdef CONFIG_BLK_INLINE_ENCRYPTION
+ /* Inline crypto capabilities */
+ struct blk_keyslot_manager *ksm;
+#endif
I do still wonder whether the concept of inline crypto support should be more
separated from keyslot management, to be better prepared for device-mapper
passthrough support and for hardware that accepts keys directly. (Such hardware
exists, though I'm not sure support for it will be upstreamed.) For example,
the crypto capabilities could be stored in a 'struct blk_crypto_capabilities'
rather than in 'struct blk_keyslot_manager', and the latter could be optional.
What you have now is fine for the functionality in the current patchset though,
so I'm not really complaining. Just something to think about.
I'd rather keep things simple (aka as-is) for now. If needed we can
change it. I doubt we'll even have a handful drivers with inline
crypto in the next years..