From: Herbert Xu <herbert@gondor.apana.org.au>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Xiong Zhou <jencce.kernel@gmail.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Linux-Next <linux-next@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-crypto@vger.kernel.org,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: linux-next: Tree for May 15 (crypto /crct10dif)
Date: Tue, 21 May 2013 21:46:57 +0800 [thread overview]
Message-ID: <20130521134656.GA9594@gondor.apana.org.au> (raw)
In-Reply-To: <1369076985.27102.319.camel@schen9-DESK>
On Mon, May 20, 2013 at 12:09:45PM -0700, Tim Chen wrote:
> On Mon, 2013-05-20 at 19:47 +0800, Herbert Xu wrote:
>
> >
> > Nope this is still broken. We need to move the actual crct10dif
> > code into crypto/. I'll fix up the patch in the tree.
> >
> > Also I'm going to get rid of crc_t10dif_update_lib function. If you
> > still want to maintain the ordering you should do so using the
> > *_init constructs.
> >
>
> Herbert,
>
> I used the following constructs in the pclmulqdq version of t10dif
> to get the module loaded.
>
> static const struct x86_cpu_id crct10dif_cpu_id[] = {
> X86_FEATURE_MATCH(X86_FEATURE_PCLMULQDQ),
> {}
> };
> MODULE_DEVICE_TABLE(x86cpu, crct10dif_cpu_id);
>
> However, the default generic algorithm is used
> in the library function. The options CRC_T10DIF, CRYPTO_CRCT10DIF
> and CRYPTO_CRCT10DIF_PCLMUL are selected as modules (which
> is most likely usage scenario in distribution) on my
> test machine. The library module and generic crypto module was loaded
> before the pclmulqdq t10dif module during boot. How should
> things be changed to get this crypto module loaded earlier before the
> library? Should we add another init call level between fs and device
> init calls for loading the available crypto algorithms?
> The crc_t10dif_update_lib was originally used to side step this issue.
OK, the way it's meant to work is that the all versions generic
or otherwise do not call themselves by the name of the algorithm.
Instead every implementation links itself to the algorithm via
a module alias. That way the first user will cause modprobe
to load all available versions and then rank them by priority.
However, now that I've looked at it it appears that crc32c and
crct10dif have not done this properly. I'll fix that up.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2013-05-21 13:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-15 3:26 linux-next: Tree for May 15 Stephen Rothwell
2013-05-15 17:42 ` linux-next: Tree for May 15 (wireless/brcm) Randy Dunlap
2013-05-15 17:59 ` linux-next: Tree for May 15 (crypto /crct10dif) Randy Dunlap
2013-05-16 3:57 ` Xiong Zhou
2013-05-16 7:22 ` Geert Uytterhoeven
2013-05-16 16:09 ` Tim Chen
2013-05-16 16:59 ` Tim Chen
2013-05-16 18:03 ` Tim Chen
2013-05-17 3:09 ` Xiong Zhou
2013-05-20 11:47 ` Herbert Xu
2013-05-20 12:14 ` Herbert Xu
2013-05-20 19:09 ` Tim Chen
2013-05-21 13:46 ` Herbert Xu [this message]
2013-05-17 3:06 ` Xiong Zhou
2013-05-15 21:03 ` [PATCH -next] platform/x86: fix amilo-rfkill build errors Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130521134656.GA9594@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=geert@linux-m68k.org \
--cc=jencce.kernel@gmail.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=tim.c.chen@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox