On Wed, Mar 25, 2020 at 11:22:13PM -0700, Eric Biggers wrote: > > +#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..
