Commit Graph

8 Commits

Author SHA1 Message Date
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
Martin Schwidefsky
b96a9e5140 s390/zcrypt: remove support for PCICC and PCICA cards
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>
2015-10-14 14:32:24 +02:00
Holger Dengler
1e2076f452 s390/zcrypt: Add support for CEX4 crypto card
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>
2012-09-26 15:44:56 +02:00
Holger Dengler
5e55a488c8 s390/zcrypt: Separate msgtype implementation from card modules.
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>
2012-09-26 15:44:55 +02:00
Holger Dengler
35424f636e [S390] Remove monolithic build option for zcrypt driver.
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>
2012-03-11 11:59:29 -04:00
Martin Schwidefsky
fe3a1be59c [S390] zcrypt driver Makefile, Kconfig and monolithic build.
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>
2006-09-20 15:58:34 +02:00
Martin Schwidefsky
7561b974e0 [S390] remove old z90crypt driver.
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>
2006-09-20 15:58:22 +02:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00