Re: [PATCH 6/6] nx-842-platform: if NX842 platform drivers are not modules, don't try to load them
From: Nishanth Aravamudan <hidden>
Date: 2015-07-06 17:07:45
Also in:
linuxppc-dev
On 06.07.2015 [16:13:07 +0800], Herbert Xu wrote:
On Thu, Jul 02, 2015 at 03:42:26PM -0700, Nishanth Aravamudan wrote:quoted
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 <redacted> Cc: Dan Streetman <redacted> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.orgUgh, 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