Lines Matching full:also

30 Inline encryption hardware is also very different from "self-encrypting drives",
41 also want support for falling back to the kernel crypto API when actual inline
42 encryption hardware is absent.  We also want inline encryption to work with
53   Encryption contexts also introduce constraints on bio merging; the block layer
70   layers to also evict keys from any keyslots they are present in.
94 We also introduce ``struct blk_crypto_profile`` to contain all generic inline
102 The blk_crypto_profile also manages the hardware's keyslots, when applicable.
118 ``struct request`` also contains a pointer to the original bio_crypt_ctx.
137 likewise for the block layer's keyslot management logic.  It is also desirable
141 Therefore, we also introduce *blk-crypto-fallback*, which is an implementation
166 blk-crypto-fallback also defines its own blk_crypto_profile and has its own
249 unsupported requests.  Also, if a nonzero number of keyslots was declared in the
251 also have a keyslot which was already programmed with the appropriate key.
254 while the device is runtime-suspended, then the driver must also set the ``dev``
319 However, there is an increasing desire to also protect users' data from other
378 Somewhat less importantly, it is also desirable that the raw keys are never
401 the hardware also includes a level of indirection; it doesn't use the unwrapped
431   purposes, and it's also assumed to have at least a 256-bit security strength.
504   ``lt_key_ptr``, which is of maximum size ``lt_key_size``.  It also updates
520   ``eph_key_ptr``, which is of maximum size ``eph_key_size``.  It also updates