Sascha Silbe 121a868d05 s390/zcrypt: Fix initialisation when zcrypt is built-in ... ap_bus and zcrypt_api assumed module information to always be present and initialisation to be done in module loading order (symbol dependencies). These assumptions don't hold if zcrypt is built-in; THIS_MODULE will be NULL in this case and init call order is linker order, i.e. Makefile order. Fix initialisation order by ordering the object files in the Makefile according to their dependencies, like the module loader would do. Fix message type registration by using a dedicated "name" field rather than piggy-backing on the module ("owner") information. There's no change to the requirement that module name and msgtype name are identical. The existing name macros are used. We don't need any special code for dealing with the drivers being built-in; the generic module support code already does the right thing. Test results: 1. CONFIG_MODULES=y, CONFIG_ZCRYPT=y KVM: boots, no /sys/bus/ap (expected) LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type present 2. CONFIG_MODULES=y, CONFIG_ZCRYPT=m=: KVM: boots, loading zcrypt_cex4 (and ap) fails (expected) LPAR with CEX5: boots, loading =zcrypt_cex4= succeeds, /sys/bus/ap/devices/card*/type present after explicit module loading 3. CONFIG_MODULES unset, CONFIG_ZCRYPT=y: KVM: boots, no /sys/bus/ap (expected) LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type present No further testing (user-space functionality) was done. Fixes: 3b6245fd303f ("s390/zcrypt: Separate msgtype implementation from card modules.") Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>		2015-11-11 13:56:34 +01:00
..
ap_bus.c
ap_bus.h
Makefile
zcrypt_api.c
zcrypt_api.h
zcrypt_cca_key.h
zcrypt_cex2a.c
zcrypt_cex2a.h
zcrypt_cex4.c
zcrypt_cex4.h
zcrypt_debug.h
zcrypt_error.h
zcrypt_msgtype6.c
zcrypt_msgtype6.h
zcrypt_msgtype50.c
zcrypt_msgtype50.h
zcrypt_pcixcc.c
zcrypt_pcixcc.h