• Sascha Silbe's avatar
    s390/zcrypt: Fix initialisation when zcrypt is built-in · 121a868d
    Sascha Silbe authored
    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: default avatarSascha Silbe <silbe@linux.vnet.ibm.com>
    Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    121a868d
Makefile 335 Bytes