s390/pkey: Add new pkey handler module pkey-uv

This new pkey handler module supports the conversion of
Ultravisor retrievable secrets to protected keys.
The new module pkey-uv.ko is able to retrieve

s390/pkey: Add new pkey handler module pkey-uv

This new pkey handler module supports the conversion of
Ultravisor retrievable secrets to protected keys.
The new module pkey-uv.ko is able to retrieve and verify
protected keys backed up by the Ultravisor layer which is
only available within protected execution environment.

The module is only automatically loaded if there is the
UV CPU feature flagged as available. Additionally on module
init there is a check for protected execution environment
and for UV supporting retrievable secrets. Also if the kernel
is not running as a protected execution guest, the module
unloads itself with errno ENODEV.

The pkey UV module currently supports these Ultravisor
secrets and is able to retrieve a protected key for these
UV secret types:
- UV_SECRET_AES_128
- UV_SECRET_AES_192
- UV_SECRET_AES_256
- UV_SECRET_AES_XTS_128
- UV_SECRET_AES_XTS_256
- UV_SECRET_HMAC_SHA_256
- UV_SECRET_HMAC_SHA_512
- UV_SECRET_ECDSA_P256
- UV_SECRET_ECDSA_P384
- UV_SECRET_ECDSA_P521
- UV_SECRET_ECDSA_ED25519
- UV_SECRET_ECDSA_ED448

Signed-off-by: Harald Freudenberger <[email protected]>
Reviewed-by: Holger Dengler <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>

show more ...

s390/pkey: Introduce pkey base with handler registry and handler modules

Introduce pkey base kernel code with a simple pkey handler registry.
Regroup the pkey code into these kernel modules:
- pkey

s390/pkey: Introduce pkey base with handler registry and handler modules

Introduce pkey base kernel code with a simple pkey handler registry.
Regroup the pkey code into these kernel modules:
- pkey is the pkey api supporting the ioctls, sysfs and in-kernel api.
Also the pkey base code which offers the handler registry and
handler wrapping invocation functions is integrated there. This
module is automatically loaded in via CPU feature if the MSA feature
is available.
- pkey-cca is the CCA related handler code kernel module a offering
CCA specific implementation for pkey. This module is loaded in
via MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available.
- pkey-ep11 is the EP11 related handler code kernel module offering an
EP11 specific implementation for pkey. This module is loaded in via
MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available.
- pkey-pckmo is the PCKMO related handler code kernel module. This
module is loaded in via CPU feature if the MSA feature is available,
but on init a check for availability of the pckmo instruction is
performed.

The handler modules register via a pkey_handler struct at the pkey
base code and the pkey customer (that is currently the pkey api code
fetches a handler via pkey handler registry functions and calls the
unified handler functions via the pkey base handler functions.

As a result the pkey-cca, pkey-ep11 and pkey-pckmo modules get
independent from each other and it becomes possible to write new
handlers which offer another kind of implementation without implicit
dependencies to other handler implementations and/or kernel device
drivers.

For each of these 4 kernel modules there is an individual Kconfig
entry: CONFIG_PKEY for the base and api, CONFIG_PKEY_CCA for the PKEY
CCA support handler, CONFIG_PKEY_EP11 for the EP11 support handler and
CONFIG_PKEY_PCKMO for the pckmo support. The both CEX related handler
modules (PKEY CCA and PKEY EP11) have a dependency to the zcrypt api
of the zcrypt device driver.

Signed-off-by: Harald Freudenberger <[email protected]>
Reviewed-by: Holger Dengler <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>

show more ...

s390/pkey: Rework and split PKEY kernel module code

This is a huge rework of all the pkey kernel module code.
The goal is to split the code into individual parts with
a dedicated calling interface:

s390/pkey: Rework and split PKEY kernel module code

This is a huge rework of all the pkey kernel module code.
The goal is to split the code into individual parts with
a dedicated calling interface:
- move all the sysfs related code into pkey_sysfs.c
- all the CCA related code goes to pkey_cca.c
- the EP11 stuff has been moved to pkey_ep11.c
- the PCKMO related code is now in pkey_pckmo.c

The CCA, EP11 and PCKMO code may be seen as "handlers" with
a similar calling interface. The new header file pkey_base.h
declares this calling interface. The remaining code in
pkey_api.c handles the ioctl, the pkey module things and the
"handler" independent code on top of the calling interface
invoking the handlers.

This regrouping of the code will be the base for a real
pkey kernel module split into a pkey base module which acts
as a dispatcher and handler modules providing their service.

Signed-off-by: Harald Freudenberger <[email protected]>
Reviewed-by: Holger Dengler <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>

show more ...

s390/ap: modularize ap bus

There is no hard requirement to have the ap bus statically in the
kernel, so add an option to compile it as module.

Cc: Tony Krowiak <[email protected]>
Cc: Halil Pa

s390/ap: modularize ap bus

There is no hard requirement to have the ap bus statically in the
kernel, so add an option to compile it as module.

Cc: Tony Krowiak <[email protected]>
Cc: Halil Pasic <[email protected]>
Signed-off-by: Holger Dengler <[email protected]>
Reviewed-by: Harald Freudenberger <[email protected]>
Reviewed-by: Anthony Krowiak <[email protected]>
Signed-off-by: Alexander Gordeev <[email protected]>

show more ...

s390/zcrypt: remove CEX2 and CEX3 device drivers

Remove the legacy device driver code for CEX2 and CEX3 cards.

The last machines which are able to handle CEX2 crypto cards
are z10 EC first availabl

s390/zcrypt: remove CEX2 and CEX3 device drivers

Remove the legacy device driver code for CEX2 and CEX3 cards.

The last machines which are able to handle CEX2 crypto cards
are z10 EC first available 2008 and z10 BC first available 2009.
The last machines able to handle a CEX3 crypto card are
z196 first available 2010 and z114 first available 2011.

Please note that this does not imply to drop CEX2 and CEX3
support in general. With older kernels on hardware up to the
aforementioned machine models these crypto cards will get
support by IBM.

The removal of the CEX2 and CEX3 device drivers code opens up
some simplifications, for example support for crypto cards
without rng support can be removed also.

Signed-off-by: Harald Freudenberger <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>

show more ...

s390/zcrypt: add new low level ep11 functions support file

This patch introduces two new files which provide some
low level functions to interact with EP11 crypto cards:

ep11_get_card_info() sends

s390/zcrypt: add new low level ep11 functions support file

This patch introduces two new files which provide some
low level functions to interact with EP11 crypto cards:

ep11_get_card_info() sends an EP11 query module info CPRB to the
addressed card, processes the returning reply and exposes some of
the information returned in the new ep11_card_info struct.

ep11_get_domain_info() sends an EP11 query domain info CPRB to the
addressed card/queue, processes the returning reply and exposes some
of the information returned in the new ep11_domain_info struct.

Signed-off-by: Harald Freudenberger <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>

show more ...

s390/zcrypt: move cca misc functions to new code file

Rework of the pkey code. Moved all the cca generic code
away from pkey_api.c into a new file zcrypt_ccamisc.c.
This new file is now part of the

s390/zcrypt: move cca misc functions to new code file

Rework of the pkey code. Moved all the cca generic code
away from pkey_api.c into a new file zcrypt_ccamisc.c.
This new file is now part of the zcrypt device driver
and exports a bunch of cca functions to pkey and may
be called from other kernel modules as well.

The pkey ioctl API is unchanged.

Signed-off-by: Harald Freudenberger <[email protected]>
Reviewed-by: Ingo Franzki <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>

show more ...

s390/zcrypt: zcrypt device driver cleanup

Some cleanup in the s390 zcrypt device driver:
- Removed fragments of pcixx crypto card code. This code
can't be reached anymore because the hardware dete

s390/zcrypt: zcrypt device driver cleanup

Some cleanup in the s390 zcrypt device driver:
- Removed fragments of pcixx crypto card code. This code
can't be reached anymore because the hardware detection
function does not recognize crypto cards < CEX2 since
commit f56545430736 ("s390/zcrypt: Introduce QACT support
for AP bus devices.")
- Rename of some files and driver names which where still
reflecting pcixx support to cex2a/cex2c.
- Removed all the zcrypt version strings in the file headers.
There is only one place left - the zcrypt.h header file is
now the only place for zcrypt device driver version info.
- Zcrypt version pump up from 2.2.0 to 2.2.1.

Signed-off-by: Harald Freudenberger <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390: vfio-ap: register matrix device with VFIO mdev framework

Registers the matrix device created by the VFIO AP device
driver with the VFIO mediated device framework.
Registering the matrix device

s390: vfio-ap: register matrix device with VFIO mdev framework

Registers the matrix device created by the VFIO AP device
driver with the VFIO mediated device framework.
Registering the matrix device will create the sysfs
structures needed to create mediated matrix devices
each of which will be used to configure the AP matrix
for a guest and connect it to the VFIO AP device driver.

Registering the matrix device with the VFIO mediated device
framework will create the following sysfs structures:

/sys/devices/vfio_ap/matrix/
...... [mdev_supported_types]
......... [vfio_ap-passthrough]
............ create

To create a mediated device for the AP matrix device, write a UUID
to the create file:

uuidgen > create

A symbolic link to the mediated device's directory will be created in the
devices subdirectory named after the generated $uuid:

/sys/devices/vfio_ap/matrix/
...... [mdev_supported_types]
......... [vfio_ap-passthrough]
............ [devices]
............... [$uuid]

A symbolic link to the mediated device will also be created
in the vfio_ap matrix's directory:

/sys/devices/vfio_ap/matrix/[$uuid]

Signed-off-by: Tony Krowiak <[email protected]>
Reviewed-by: Halil Pasic <[email protected]>
Reviewed-by: Cornelia Huck <[email protected]>
Tested-by: Michael Mueller <[email protected]>
Tested-by: Farhan Ali <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Christian Borntraeger <[email protected]>

show more ...

s390: vfio-ap: base implementation of VFIO AP device driver

Introduces a new AP device driver. This device driver
is built on the VFIO mediated device framework. The framework
provides sysfs interfa

s390: vfio-ap: base implementation of VFIO AP device driver

Introduces a new AP device driver. This device driver
is built on the VFIO mediated device framework. The framework
provides sysfs interfaces that facilitate passthrough
access by guests to devices installed on the linux host.

The VFIO AP device driver will serve two purposes:

1. Provide the interfaces to reserve AP devices for exclusive
use by KVM guests. This is accomplished by unbinding the
devices to be reserved for guest usage from the zcrypt
device driver and binding them to the VFIO AP device driver.

2. Implements the functions, callbacks and sysfs attribute
interfaces required to create one or more VFIO mediated
devices each of which will be used to configure the AP
matrix for a guest and serve as a file descriptor
for facilitating communication between QEMU and the
VFIO AP device driver.

When the VFIO AP device driver is initialized:

* It registers with the AP bus for control of type 10 (CEX4
and newer) AP queue devices. This limitation was imposed
due to:

1. A desire to keep the code as simple as possible;

2. Some older models are no longer supported by the kernel
and others are getting close to end of service.

3. A lack of older systems on which to test older devices.

The probe and remove callbacks will be provided to support
the binding/unbinding of AP queue devices to/from the VFIO
AP device driver.

* Creates a matrix device, /sys/devices/vfio_ap/matrix,
to serve as the parent of the mediated devices created, one
for each guest, and to hold the APQNs of the AP devices bound to
the VFIO AP device driver.

Signed-off-by: Tony Krowiak <[email protected]>
Reviewed-by: Halil Pasic <[email protected]>
Tested-by: Michael Mueller <[email protected]>
Tested-by: Farhan Ali <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Reviewed-by: Cornelia Huck <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Christian Borntraeger <[email protected]>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

s390/pkey: Introduce pkey kernel module

This patch introcudes a new kernel module pkey which is providing
protected key handling and management functions. The pkey API is
available within the kernel

s390/pkey: Introduce pkey kernel module

This patch introcudes a new kernel module pkey which is providing
protected key handling and management functions. The pkey API is
available within the kernel for other s390 specific code to create
and manage protected keys. Additionally the functions are exported
to user space via IOCTL calls. The implementation makes extensive
use of functions provided by the zcrypt device driver. For
generating protected keys from secure keys there is also a CEX
coprocessor card needed.

Signed-off-by: Harald Freudenberger <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/zcrypt: add multi domain support

Currently the ap infrastructure only supports one domain at a time.
This feature extends the generic cryptographic device driver to
support multiple cryptograph

s390/zcrypt: add multi domain support

Currently the ap infrastructure only supports one domain at a time.
This feature extends the generic cryptographic device driver to
support multiple cryptographic domains simultaneously.

There are now card and queue devices on the AP bus with independent
card and queue drivers. The new /sys layout is as follows:

/sys/bus/ap
devices
<xx>.<yyyy> -> ../../../devices/ap/card<xx>/<xx>.<yyyy>
...
card<xx> -> ../../../devices/ap/card<xx>
...
drivers
<drv>card
card<xx> -> ../../../../devices/ap/card<xx>
<drv>queue
<xx>.<yyyy> -> ../../../../devices/ap/card<xx>/<xx>.<yyyy>
...

/sys/devices/ap
card<xx>
<xx>.<yyyy>
driver -> ../../../../bus/ap/drivers/<zzz>queue
...
driver -> ../../../bus/ap/drivers/<drv>card
...

The two digit <xx> field is the card number, the four digit <yyyy>
field is the queue number and <drv> is the name of the device driver,
e.g. "cex4".

For compatability /sys/bus/ap/card<xx> for the old layout has to exist,
including the attributes that used to reside there.

With additional contributions from Harald Freudenberger and
Martin Schwidefsky.

Signed-off-by: Ingo Tuchscherer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/zcrypt: Move the ap bus into kernel

Move the ap bus into the kernel and make it general available.
Additionally include the message types and the API layer as a
preparation for the workload man

s390/zcrypt: Move the ap bus into kernel

Move the ap bus into the kernel and make it general available.
Additionally include the message types and the API layer as a
preparation for the workload management facility.

Signed-off-by: Ingo Tuchscherer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

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
dependenci

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 <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

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 Tuchscher

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 <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/zcrypt: Add support for CEX4 crypto card

New zcrypt module supports IBM CryptoExpress 4 cards.

Signed-off-by: Holger Dengler <[email protected]>
Signed-off-by: Martin Schwidefsky <schwidef

s390/zcrypt: Add support for CEX4 crypto card

New zcrypt module supports IBM CryptoExpress 4 cards.

Signed-off-by: Holger Dengler <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

s390/zcrypt: Separate msgtype implementation from card modules.

Msgtype implementations are now separated from card specific modules
and can be dynamically registered. Existing msgtype implementatio

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 <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

[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

[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 <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

[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
backw

[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 <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>

show more ...

[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 <[email protected]>

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

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!

show more ...