On Thu, Dec 19, 2019 at 08:48:38PM -0800, Eric Biggers wrote:

On Wed, Dec 18, 2019 at 06:51:32AM -0800, Satya Tangirala wrote:

quoted

+/**
+ * ufshcd_hba_init_crypto - Read crypto capabilities, init crypto fields in hba
+ * @hba: Per adapter instance
+ *
+ * Return: 0 if crypto was initialized or is not supported, else a -errno value.
+ */
+int ufshcd_hba_init_crypto(struct ufs_hba *hba)
+{
+	int cap_idx = 0;
+	int err = 0;
+	unsigned int crypto_modes_supported[BLK_ENCRYPTION_MODE_MAX];
+	enum blk_crypto_mode_num blk_mode_num;
+
+	/* Default to disabling crypto */
+	hba->caps &= ~UFSHCD_CAP_CRYPTO;
+
+	/* Return 0 if crypto support isn't present */
+	if (!(hba->capabilities & MASK_CRYPTO_SUPPORT))
+		goto out;
+

Note that unfortunately, this patch doesn't work yet on some UFS host
controllers that claim to support the UFS standard crypto, due to issues like
deviations from the UFS standard and missing device tree changes -- and this can
even cause boot-time crashes.

So if we can't fix everything right away (which can be really hard without help
from the relevant vendor) I think we have to define a bit
UFSHCD_QUIRK_BROKEN_CRYPTO in ufs_hba::quirks which can be set on host
controllers where the proper tricks to get the crypto working correctly haven't
been figured out yet.  The crypto support would be ignored if that bit is set.

I included a patch defining UFSHCD_QUIRK_BROKEN_CRYPTO in my RFC patchset that
wires up inline crypto support on Dragonboard 845c:
https://lkml.kernel.org/linux-scsi/20200110061634.46742-4-ebiggers@kernel.org/

Satya, feel free to include that patch in v7 of your patchset.

- Eric