On Thu, Oct 23, 2008 at 02:28:32PM +0200, Christian Hohnstaedt wrote:
>
> atomic_set(&ctx->configuring, 0);
> + switch ((image_id>>16) & 0xff) {
> + case 3:
> + if (cipher_cfg_enc(tfm) & MOD_AES) {
> + printk(KERN_ERR "Firmware of %s lacks AES "
> + "support\n", npe_name(npe_c));
> + return -ENODEV;
> + }
> + case 4:
> + case 5:
> + break;
> + default:
> + printk(KERN_ERR "Firmware of %s lacks crypto support\n",
> + npe_name(npe_c));
> + return -ENODEV;
> + }
By the time you're in init_tfm, it's too late to decide that
your hardware doesn't support AES since the API cannot fall
back to another algorithm at this point.
You need to determine whether AES is supported before you register
your algorithm.
Indeed, if the objective was to avoid loading the firmware during
module initialisation, then this patch doesn't actually achieve
that because we now test the algorithm at registration time so
init_tfm will be called during module initialisation.
In any case, firmware loading during module initialisation happens
for all sorts of hardware so I don't see why you're trying to
avoid it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
