On 06.07.2015 [16:13:07 +0800], Herbert Xu wrote: > On Thu, Jul 02, 2015 at 03:42:26PM -0700, Nishanth Aravamudan wrote: > > Based off the CONFIG_SPU_FS_MODULE code, only attempt to load platform > > modules if the nx-842 pseries/powernv drivers are built as modules. > > > > Otherwise, if CONFIG_DEV_NX_COMPRESS=y, > > CONFIG_DEV_NX_COMPRESS_PSERIES=y, CONFIG_DEV_NX_POWERNV=y, the following > > message is emitted at boot: > > > > nx_compress: no nx842 driver found. > > > > even though the drivers successfully loads. > > > > This is because in the =y case, the module_init() calls get converted to > > initcalls and the nx842_init() runs before the platform driver > > nx842_pseries_init() or nx842_powernv_init() functions, which are what > > normally set the static platform driver. > > > > Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> > > Cc: Dan Streetman <ddstr...@us.ibm.com> > > Cc: Herbert Xu <herb...@gondor.apana.org.au> > > Cc: "David S. Miller" <da...@davemloft.net> > > Cc: linux-cry...@vger.kernel.org > > Cc: linuxppc-dev@lists.ozlabs.org > > Ugh, I think this whole thing is redundant. The whole point of > the crypto API is to allow the coexistence of multiple underlying > implementations.
Sure, that makes sense -- sorry, I was picking this up while Dan was on vacation. Will provide a better v2. > Please get rid of nx-842-platform.c completely and move the crypto > registration into the individual platform drivers. That is, powernv > and pseries should each register their own crypto driver. They can of > course share a common set of crypto code which can live in its own > module. There should be no need for mucking with module reference > counts at all. Will do, thanks! -Nish _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
