summaryrefslogtreecommitdiffstats
path: root/drivers/s390/crypto/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* s390/zcrypt: Fix initialisation when zcrypt is built-inSascha Silbe2015-11-111-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* s390/zcrypt: remove support for PCICC and PCICA cardsMartin Schwidefsky2015-10-141-2/+2
| | | | | | | | Remove the code for really old crypt cards, PCICC and PCICA. These cards have been out of service for several years. Reviewd-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* s390/zcrypt: Add support for CEX4 crypto cardHolger Dengler2012-09-261-1/+1
| | | | | | | New zcrypt module supports IBM CryptoExpress 4 cards. Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* s390/zcrypt: Separate msgtype implementation from card modules.Holger Dengler2012-09-261-0/+1
| | | | | | | | | Msgtype implementations are now separated from card specific modules and can be dynamically registered. Existing msgtype implementations are restructured in modules. Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* [S390] Remove monolithic build option for zcrypt driver.Holger Dengler2012-03-111-10/+0
| | | | | | | | Remove the option to build a single module z90crypt that contains ap bus, request router and card drivers. Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* [S390] zcrypt driver Makefile, Kconfig and monolithic build.Martin Schwidefsky2006-09-201-0/+13
| | | | | | | | | The Makefile and Kconfig changes should be obvious. The monolithic build option is there to create an old-style z90crypt module for backward compatability to older distributions. Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* [S390] remove old z90crypt driver.Martin Schwidefsky2006-09-201-2/+0
| | | | | | | The z90crypt driver has served its term. It is replaced by the shiny new zcrypt device driver. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+6
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
OpenPOWER on IntegriCloud