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:
> > +/**
> > + * 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@xxxxxxxxxx/
Satya, feel free to include that patch in v7 of your patchset.
- Eric
