<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/s390/crypto/zcrypt_api.c, branch v5.0</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>s390/zcrypt: fix broken zcrypt_send_cprb in-kernel api function</title>
<updated>2018-10-15T10:16:57+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2018-10-12T06:35:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9434f5d3bef97c7212ef6d96d7783e3a3a6c1cb5'/>
<id>9434f5d3bef97c7212ef6d96d7783e3a3a6c1cb5</id>
<content type='text'>
With the new multi zcrypt device node support there came
in a code rework which broke the in-kernel api function
zcrypt_send_cprb(). This function is used by the pkey kernel
module and as an effect, transforming a secure key into a
protected key did not work any more.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With the new multi zcrypt device node support there came
in a code rework which broke the in-kernel api function
zcrypt_send_cprb(). This function is used by the pkey kernel
module and as an effect, transforming a secure key into a
protected key did not work any more.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/zcrypt: provide apfs failure code on type 86 error reply</title>
<updated>2018-10-09T09:21:36+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2018-10-04T13:37:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a17b92e0487f0bfbb1c5d0bdf26c64dddfc31ac4'/>
<id>a17b92e0487f0bfbb1c5d0bdf26c64dddfc31ac4</id>
<content type='text'>
The apfs field (AP final status) is set on transport
protocol failures (reply code 0x90) for type 86 replies.
For CCA cprbs this value is copied into the xcrb status
field which gives userspace a hint for the failure reason.
However, for EP11 cprbs there is no such status field
in the xcrb struct. So now regardless of the request
type, if a reply type 86 with transport protocol failure
is seen, the apfs value is printed as part of the debug
message. So the user has a chance to see the apfs value
without using a special build kernel.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The apfs field (AP final status) is set on transport
protocol failures (reply code 0x90) for type 86 replies.
For CCA cprbs this value is copied into the xcrb status
field which gives userspace a hint for the failure reason.
However, for EP11 cprbs there is no such status field
in the xcrb struct. So now regardless of the request
type, if a reply type 86 with transport protocol failure
is seen, the apfs value is printed as part of the debug
message. So the user has a chance to see the apfs value
without using a special build kernel.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/zcrypt: zcrypt device driver cleanup</title>
<updated>2018-10-09T09:21:35+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2018-10-04T13:30:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ee410de890cdf8fc94f6235dd9ef323a101511ab'/>
<id>ee410de890cdf8fc94f6235dd9ef323a101511ab</id>
<content type='text'>
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 &lt; 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 &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt; 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 &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/zcrypt: multiple zcrypt device nodes support</title>
<updated>2018-10-08T07:09:58+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2018-09-17T14:18:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=00fab2350e6b91e57b3cdcd5d9f01056775a921d'/>
<id>00fab2350e6b91e57b3cdcd5d9f01056775a921d</id>
<content type='text'>
This patch is an extension to the zcrypt device driver to provide,
support and maintain multiple zcrypt device nodes. The individual
zcrypt device nodes can be restricted in terms of crypto cards,
domains and available ioctls. Such a device node can be used as a
base for container solutions like docker to control and restrict
the access to crypto resources.

The handling is done with a new sysfs subdir /sys/class/zcrypt.
Echoing a name (or an empty sting) into the attribute "create" creates
a new zcrypt device node. In /sys/class/zcrypt a new link will appear
which points to the sysfs device tree of this new device. The
attribute files "ioctlmask", "apmask" and "aqmask" in this directory
are used to customize this new zcrypt device node instance. Finally
the zcrypt device node can be destroyed by echoing the name into
/sys/class/zcrypt/destroy. The internal structs holding the device
info are reference counted - so a destroy will not hard remove a
device but only marks it as removable when the reference counter drops
to zero.

The mask values are bitmaps in big endian order starting with bit 0.
So adapter number 0 is the leftmost bit, mask is 0x8000...  The sysfs
attributes accept 2 different formats:
* Absolute hex string starting with 0x like "0x12345678" does set
  the mask starting from left to right. If the given string is shorter
  than the mask it is padded with 0s on the right. If the string is
  longer than the mask an error comes back (EINVAL).
* Relative format - a concatenation (done with ',') of the
  terms +&lt;bitnr&gt;[-&lt;bitnr&gt;] or -&lt;bitnr&gt;[-&lt;bitnr&gt;]. &lt;bitnr&gt; may be any
  valid number (hex, decimal or octal) in the range 0...255. Here are
  some examples:
    "+0-15,+32,-128,-0xFF"
    "-0-255,+1-16,+0x128"
    "+1,+2,+3,+4,-5,-7-10"

A simple usage examples:

  # create new zcrypt device 'my_zcrypt':
  echo "my_zcrypt" &gt;/sys/class/zcrypt/create
  # go into the device dir of this new device
  echo "my_zcrypt" &gt;create
  cd my_zcrypt/
  ls -l
  total 0
  -rw-r--r-- 1 root root 4096 Jul 20 15:23 apmask
  -rw-r--r-- 1 root root 4096 Jul 20 15:23 aqmask
  -r--r--r-- 1 root root 4096 Jul 20 15:23 dev
  -rw-r--r-- 1 root root 4096 Jul 20 15:23 ioctlmask
  lrwxrwxrwx 1 root root    0 Jul 20 15:23 subsystem -&gt; ../../../../class/zcrypt
  ...
  # customize this zcrypt node clone
  # enable only adapter 0 and 2
  echo "0xa0" &gt;apmask
  # enable only domain 6
  echo "+6" &gt;aqmask
  # enable all 256 ioctls
  echo "+0-255" &gt;ioctls
  # now the /dev/my_zcrypt may be used
  # finally destroy it
  echo "my_zcrypt" &gt;/sys/class/zcrypt/destroy

Please note that a very similar 'filtering behavior' also applies to
the parent z90crypt device. The two mask attributes apmask and aqmask
in /sys/bus/ap act the very same for the z90crypt device node. However
the implementation here is totally different as the ap bus acts on
bind/unbind of queue devices and associated drivers but the effect is
still the same. So there are two filters active for each additional
zcrypt device node: The adapter/domain needs to be enabled on the ap
bus level and it needs to be active on the zcrypt device node level.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is an extension to the zcrypt device driver to provide,
support and maintain multiple zcrypt device nodes. The individual
zcrypt device nodes can be restricted in terms of crypto cards,
domains and available ioctls. Such a device node can be used as a
base for container solutions like docker to control and restrict
the access to crypto resources.

The handling is done with a new sysfs subdir /sys/class/zcrypt.
Echoing a name (or an empty sting) into the attribute "create" creates
a new zcrypt device node. In /sys/class/zcrypt a new link will appear
which points to the sysfs device tree of this new device. The
attribute files "ioctlmask", "apmask" and "aqmask" in this directory
are used to customize this new zcrypt device node instance. Finally
the zcrypt device node can be destroyed by echoing the name into
/sys/class/zcrypt/destroy. The internal structs holding the device
info are reference counted - so a destroy will not hard remove a
device but only marks it as removable when the reference counter drops
to zero.

The mask values are bitmaps in big endian order starting with bit 0.
So adapter number 0 is the leftmost bit, mask is 0x8000...  The sysfs
attributes accept 2 different formats:
* Absolute hex string starting with 0x like "0x12345678" does set
  the mask starting from left to right. If the given string is shorter
  than the mask it is padded with 0s on the right. If the string is
  longer than the mask an error comes back (EINVAL).
* Relative format - a concatenation (done with ',') of the
  terms +&lt;bitnr&gt;[-&lt;bitnr&gt;] or -&lt;bitnr&gt;[-&lt;bitnr&gt;]. &lt;bitnr&gt; may be any
  valid number (hex, decimal or octal) in the range 0...255. Here are
  some examples:
    "+0-15,+32,-128,-0xFF"
    "-0-255,+1-16,+0x128"
    "+1,+2,+3,+4,-5,-7-10"

A simple usage examples:

  # create new zcrypt device 'my_zcrypt':
  echo "my_zcrypt" &gt;/sys/class/zcrypt/create
  # go into the device dir of this new device
  echo "my_zcrypt" &gt;create
  cd my_zcrypt/
  ls -l
  total 0
  -rw-r--r-- 1 root root 4096 Jul 20 15:23 apmask
  -rw-r--r-- 1 root root 4096 Jul 20 15:23 aqmask
  -r--r--r-- 1 root root 4096 Jul 20 15:23 dev
  -rw-r--r-- 1 root root 4096 Jul 20 15:23 ioctlmask
  lrwxrwxrwx 1 root root    0 Jul 20 15:23 subsystem -&gt; ../../../../class/zcrypt
  ...
  # customize this zcrypt node clone
  # enable only adapter 0 and 2
  echo "0xa0" &gt;apmask
  # enable only domain 6
  echo "+6" &gt;aqmask
  # enable all 256 ioctls
  echo "+0-255" &gt;ioctls
  # now the /dev/my_zcrypt may be used
  # finally destroy it
  echo "my_zcrypt" &gt;/sys/class/zcrypt/destroy

Please note that a very similar 'filtering behavior' also applies to
the parent z90crypt device. The two mask attributes apmask and aqmask
in /sys/bus/ap act the very same for the z90crypt device node. However
the implementation here is totally different as the ap bus acts on
bind/unbind of queue devices and associated drivers but the effect is
still the same. So there are two filters active for each additional
zcrypt device node: The adapter/domain needs to be enabled on the ap
bus level and it needs to be active on the zcrypt device node level.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/zcrypt: code beautify</title>
<updated>2018-08-20T14:02:11+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2018-08-17T10:36:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ac2b96f351d7d222c46e524feca03005f3fa8d75'/>
<id>ac2b96f351d7d222c46e524feca03005f3fa8d75</id>
<content type='text'>
Code beautify by following most of the checkpatch suggestions:
 - SPDX license identifier line complains by checkpatch
 - missing space or newline complains by checkpatch
 - octal numbers for permssions complains by checkpatch
 - renaming of static sysfs functions complains by checkpatch
 - fix of block comment complains by checkpatch
 - fix printf like calls where function name instead of %s __func__
   was used
 - __packed instead of __attribute__((packed))
 - init to zero for static variables removed
 - use of DEVICE_ATTR_RO and DEVICE_ATTR_RW macros

No functional code changes or API changes!

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Code beautify by following most of the checkpatch suggestions:
 - SPDX license identifier line complains by checkpatch
 - missing space or newline complains by checkpatch
 - octal numbers for permssions complains by checkpatch
 - renaming of static sysfs functions complains by checkpatch
 - fix of block comment complains by checkpatch
 - fix printf like calls where function name instead of %s __func__
   was used
 - __packed instead of __attribute__((packed))
 - init to zero for static variables removed
 - use of DEVICE_ATTR_RO and DEVICE_ATTR_RW macros

No functional code changes or API changes!

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/zcrypt: Fix CCA and EP11 CPRB processing failure memory leak.</title>
<updated>2018-05-30T09:18:05+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@de.ibm.com</email>
</author>
<published>2018-05-28T11:00:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=89a0c0ec0d2e3ce0ee9caa00f60c0c26ccf11c21'/>
<id>89a0c0ec0d2e3ce0ee9caa00f60c0c26ccf11c21</id>
<content type='text'>
Tests showed, that the zcrypt device driver produces memory
leaks when a valid CCA or EP11 CPRB can't get delivered or has
a failure during processing within the zcrypt device driver.

This happens when a invalid domain or adapter number is used
or the lower level software or hardware layers produce any
kind of failure during processing of the request.

Only CPRBs send to CCA or EP11 cards can produce this memory
leak. The accelerator and the CPRBs processed by this type
of crypto card is not affected.

The two fields message and private within the ap_message struct
are allocated with pulling the function code for the CPRB but
only freed when processing of the CPRB succeeds. So for example
an invalid domain or adapter field causes the processing to
fail, leaving these two memory areas allocated forever.

Signed-off-by: Harald Freudenberger &lt;freude@de.ibm.com&gt;
Reviewed-by: Ingo Franzki &lt;ifranzki@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Tests showed, that the zcrypt device driver produces memory
leaks when a valid CCA or EP11 CPRB can't get delivered or has
a failure during processing within the zcrypt device driver.

This happens when a invalid domain or adapter number is used
or the lower level software or hardware layers produce any
kind of failure during processing of the request.

Only CPRBs send to CCA or EP11 cards can produce this memory
leak. The accelerator and the CPRBs processed by this type
of crypto card is not affected.

The two fields message and private within the ap_message struct
are allocated with pulling the function code for the CPRB but
only freed when processing of the CPRB succeeds. So for example
an invalid domain or adapter field causes the processing to
fail, leaving these two memory areas allocated forever.

Signed-off-by: Harald Freudenberger &lt;freude@de.ibm.com&gt;
Reviewed-by: Ingo Franzki &lt;ifranzki@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/zcrypt: Support up to 256 crypto adapters.</title>
<updated>2018-04-11T08:36:27+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.vnet.ibm.com</email>
</author>
<published>2018-04-09T14:18:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=af4a72276d49da117dbc99799afee740a26f8f10'/>
<id>af4a72276d49da117dbc99799afee740a26f8f10</id>
<content type='text'>
There was an artificial restriction on the card/adapter id
to only 6 bits but all the AP commands do support adapter
ids with 8 bit. This patch removes this restriction to 64
adapters and now up to 256 adapter can get addressed.

Some of the ioctl calls work on the max number of cards
possible (which was 64). These ioctls are now deprecated
but still supported. All the defines, structs and ioctl
interface declarations have been kept for compabibility.
There are now new ioctls (and defines for these) with an
additional '2' appended which provide the extended versions
with 256 cards supported.

Signed-off-by: Harald Freudenberger &lt;freude@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There was an artificial restriction on the card/adapter id
to only 6 bits but all the AP commands do support adapter
ids with 8 bit. This patch removes this restriction to 64
adapters and now up to 256 adapter can get addressed.

Some of the ioctl calls work on the max number of cards
possible (which was 64). These ioctls are now deprecated
but still supported. All the defines, structs and ioctl
interface declarations have been kept for compabibility.
There are now new ioctls (and defines for these) with an
additional '2' appended which provide the extended versions
with 256 cards supported.

Signed-off-by: Harald Freudenberger &lt;freude@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/zcrypt: Remove deprecated zcrypt proc interface.</title>
<updated>2018-04-10T05:39:01+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.vnet.ibm.com</email>
</author>
<published>2018-04-04T12:01:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=71cbbff8c4fd1467b59b8c15a06093ac03cd11c7'/>
<id>71cbbff8c4fd1467b59b8c15a06093ac03cd11c7</id>
<content type='text'>
This patch removes the deprecated zcrypt proc interface.
It is outdated and deprecated and does not support the
latest 3 generations of CEX cards.

Signed-off-by: Harald Freudenberger &lt;freude@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch removes the deprecated zcrypt proc interface.
It is outdated and deprecated and does not support the
latest 3 generations of CEX cards.

Signed-off-by: Harald Freudenberger &lt;freude@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/zcrypt: Remove deprecated ioctls.</title>
<updated>2018-04-10T05:39:01+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.vnet.ibm.com</email>
</author>
<published>2018-04-04T11:25:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2a80786d477a3811c1a5410ddf08d0f981e53cf3'/>
<id>2a80786d477a3811c1a5410ddf08d0f981e53cf3</id>
<content type='text'>
This patch removes the old status calls which have been marked
as deprecated since at least 2 years now. There is no known
application or library relying on these ioctls any more.

Signed-off-by: Harald Freudenberger &lt;freude@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch removes the old status calls which have been marked
as deprecated since at least 2 years now. There is no known
application or library relying on these ioctls any more.

Signed-off-by: Harald Freudenberger &lt;freude@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390: crypto: Remove redundant license text</title>
<updated>2017-11-24T13:28:46+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2017-11-14T17:38:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0b622e60bc6c4eca75d517b10f15914ecd58e6b1'/>
<id>0b622e60bc6c4eca75d517b10f15914ecd58e6b1</id>
<content type='text'>
Now that the SPDX tag is in all drivers/s390/crypto/ files, that
identifies the license in a specific and legally-defined manner.  So the
extra GPL text wording can be removed as it is no longer needed at all.

This is done on a quest to remove the 700+ different ways that files in
the kernel describe the GPL license text.  And there's unneeded stuff
like the address (sometimes incorrect) for the FSF which is never
needed.

No copyright headers or other non-license-description text was removed.

Cc: Harald Freudenberger &lt;freude@de.ibm.com&gt;
Cc: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: "Paul E. McKenney" &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that the SPDX tag is in all drivers/s390/crypto/ files, that
identifies the license in a specific and legally-defined manner.  So the
extra GPL text wording can be removed as it is no longer needed at all.

This is done on a quest to remove the 700+ different ways that files in
the kernel describe the GPL license text.  And there's unneeded stuff
like the address (sometimes incorrect) for the FSF which is never
needed.

No copyright headers or other non-license-description text was removed.

Cc: Harald Freudenberger &lt;freude@de.ibm.com&gt;
Cc: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: "Paul E. McKenney" &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
