Re: [PATCH] crypto: ccree - avoid implicit enum conversion

[Nick Desaulniers]

On Thu, Oct 11, 2018 at 12:47 AM Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote:
>
> Hi Nick,
>
> On Thu, Oct 11, 2018 at 2:49 AM Nick Desaulniers
> <ndesaulniers@xxxxxxxxxx> wrote:
> >
> > $ grep -r set_cipher_config0 -n
> >
> > shows a healthy mix of DESC_DIRECTION_ENCRYPT_ENCRYPT,
> > HASH_DIGEST_RESULT_LITTLE_ENDIAN, and DRV_CRYPTO_DIRECTION_ENCRYPT
> > (all enumeration values of different enums).
> >
> > >
> > > drivers/crypto/ccree/cc_aead.c:1643:30: warning: implicit conversion
> > > from enumeration type 'enum drv_hash_hw_mode' to different enumeration
> > > type 'enum drv_cipher_mode' [-Wenum-conversion]
> > >         set_cipher_mode(&desc[idx], DRV_HASH_HW_GHASH);
> >
> > Looks like a lot fewer call sites using DRV_HASH_HW_GHASH; same value
> > as DRV_CIPHER_OFB (different enum), but can a block cipher mode and a
> > hash be valid values for pdesc->word[4]?
> >
> > >
> > > Since this fundamentally isn't a problem because these values just
> > > represent simple integers for a shift operation, make it clear to Clang
> > > that this is okay by making the mode parameter in both functions an int.
> >
> > This also looks like the simplest fix to me, assuming the values of
> > all of these enums are valid for whatever pdesc->word[4] is.  Can the
> > maintainers explain what is CC7x-DESC what the comment makes reference
> > to?
>
> They indeed are. CC7x-DESC is a shorthand for "CryptoCell 7xx
> Descriptor" used in the hardware documents.
> These descriptors are comprised of fields with context sensitive
> meaning, hence this "overloading".
>
> Given this overloading of meaning an  "int" type is indeed a better
> suited type here.

Sounds like they're valid values then.  Thanks for the info.
Reviewed-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx>

>
> Thanks,
> Gilad
> --
> Gilad Ben-Yossef
> Chief Coffee Drinker
>
> values of Î will give rise to dom!



-- 
Thanks,
~Nick Desaulniers