<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/s390/Makefile, branch master</title>
<subtitle>Linux Kernel</subtitle>
<id>https://git.etezian.org/cgit.cgi/linux.git/atom?h=master</id>
<link rel='self' href='https://git.etezian.org/cgit.cgi/linux.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/'/>
<updated>2016-09-06T09:00:04+00:00</updated>
<entry>
<title>s390: add assembler include path for vx-insn.h</title>
<updated>2016-09-06T09:00:04+00:00</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2016-09-06T08:46:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=c783b91ebdbab67e848889c29dd0611c2b2c9fea'/>
<id>urn:sha1:c783b91ebdbab67e848889c29dd0611c2b2c9fea</id>
<content type='text'>
With git commit 0eab11c7e0d30de14a15ccd8269eef238321a8e1
"s390/vx: allow to include vx-insn.h with .include"
and an older gcc we get errors like this:

{standard input}:6: Error: can't open asm/vx-insn.h for reading:
No such file or directory
arch/s390/kernel/fpu.c:57: Error: Unrecognized opcode: `vstm'

To solve this issue simply add the path to arch/s390/include to
all assembler runs.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/facilities: add helper tool to generate facility lists</title>
<updated>2015-12-18T13:59:20+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2015-02-02T06:08:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=c30f6828fed9d33c2d54dfaf3621717c56f9c779'/>
<id>urn:sha1:c30f6828fed9d33c2d54dfaf3621717c56f9c779</id>
<content type='text'>
Modifying the architecture level set facility lists was always very
error prone. Given the numbering of the facility bits within the
Principles of Operation, where the most significant bit number is 0,
it happened a lot of times that wrong bits were set or cleared.

Therefore this patch adds a tool "gen_facilities" which generates
include/generated/facilites.h.  The definition of the bits to be set
is contained within arch/s390/include/asm/facilities_src.h and can be
easily extended to e.g. also generate such lists for the KVM module.

The generated file looks like this:

 #define FACILITIES_ALS _AC(0xc1006450f0040000,UL)
 #define FACILITIES_ALS_DWORDS 1

The facility bits defined in this patch match 1:1 to the current masks
that can be found in head.S.

That is if the tool gets executed with -march=z990 then the generated
masks will equal the masks in head.S for CONFIG_MARCH_Z990.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: add 'install' target to 'make help'</title>
<updated>2015-11-27T08:24:17+00:00</updated>
<author>
<name>Michael Holzheu</name>
<email>holzheu@linux.vnet.ibm.com</email>
</author>
<published>2015-11-25T10:54:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=b8eecf36a47bc5e9569f513a3888d03d82985fbb'/>
<id>urn:sha1:b8eecf36a47bc5e9569f513a3888d03d82985fbb</id>
<content type='text'>
Signed-off-by: Michael Holzheu &lt;holzheu@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/sclp: convert early sclp console code to C</title>
<updated>2015-07-29T07:11:39+00:00</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2015-07-08T08:20:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=22362a0e23182d230527a5add690b4027860d7d3'/>
<id>urn:sha1:22362a0e23182d230527a5add690b4027860d7d3</id>
<content type='text'>
The 31-bit assembler code for the early sclp console is error
prone as git commit fde24b54d976cc123506695c17db01438a11b673
"s390/sclp: clear upper register halves in _sclp_print_early"
has shown.

Convert the assembler code to C.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: remove 31 bit support</title>
<updated>2015-03-25T10:49:33+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2015-02-12T12:08:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=5a79859ae0f35d25c67a03e82bf0c80592f16a39'/>
<id>urn:sha1:5a79859ae0f35d25c67a03e82bf0c80592f16a39</id>
<content type='text'>
Remove the 31 bit support in order to reduce maintenance cost and
effectively remove dead code. Since a couple of years there is no
distribution left that comes with a 31 bit kernel.

The 31 bit kernel also has been broken since more than a year before
anybody noticed. In addition I added a removal warning to the kernel
shown at ipl for 5 minutes: a960062e5826 ("s390: add 31 bit warning
message") which let everybody know about the plan to remove 31 bit
code. We didn't get any response.

Given that the last 31 bit only machine was introduced in 1999 let's
remove the code.
Anybody with 31 bit user space code can still use the compat mode.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/ftrace: hotpatch support for function tracing</title>
<updated>2015-01-29T08:19:25+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2015-01-09T12:08:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=e6d60b368b45b9be3aa068f8e5fa98c3487c9d4e'/>
<id>urn:sha1:e6d60b368b45b9be3aa068f8e5fa98c3487c9d4e</id>
<content type='text'>
Make use of gcc's hotpatch support to generate better code for ftrace
function tracing.
The generated code now contains only a six byte nop in each function
prologue instead of a 24 byte code block which will be runtime patched to
support function tracing.
With the new code generation the runtime overhead for supporting function
tracing is close to zero, while the original code did show a significant
performance impact.

Acked-by: Steven Rostedt &lt;rostedt@goodmis.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>
</entry>
<entry>
<title>s390: add z13 code generation support</title>
<updated>2015-01-22T11:15:57+00:00</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2015-01-14T16:50:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=f8b2dcbd9e6d1479b9b5a9e9e78bbaf783bde819'/>
<id>urn:sha1:f8b2dcbd9e6d1479b9b5a9e9e78bbaf783bde819</id>
<content type='text'>
Allow to generate code that only runs on z13 machines.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: pass march flag to assembly files as well</title>
<updated>2014-09-09T06:53:28+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2014-08-14T14:06:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=0f1b1ff54b386926ef1a524e60ef89ae7738bbd5'/>
<id>urn:sha1:0f1b1ff54b386926ef1a524e60ef89ae7738bbd5</id>
<content type='text'>
Currently the march flag gets only passed to C files, but not to
assembler files.
This means that we can't add new instructions like e.g. aghik to asm
files, since the assembler doesn't know of the new instructions if
the appropriate march flag isn't specified.

So also pass the march flag when compiling assembler files as well.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: allow to set gcc -mtune flag</title>
<updated>2013-10-31T08:54:01+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2013-10-30T11:12:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=1db9e0513d7478f6c80ca0bc4f58f53fe49e27f8'/>
<id>urn:sha1:1db9e0513d7478f6c80ca0bc4f58f53fe49e27f8</id>
<content type='text'>
Add a new Kconfig choice group which allows to configure how gcc should
tune the generated code (via -mtune option).
By default the -mtune parameter will match the -march parameter.

This is a rather large patch, but I wouldn't know how to make this shorter
unfortunately.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: always set -march compiler option</title>
<updated>2013-10-24T15:16:44+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2013-09-11T07:29:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.etezian.org/cgit.cgi/linux.git/commit/?id=faf499dfccfd88d842164078917e7b6aae9a3cdb'/>
<id>urn:sha1:faf499dfccfd88d842164078917e7b6aae9a3cdb</id>
<content type='text'>
Currently we only set the -march compiler option if the kbuild
system figured out that the compiler actually supports the selected
architecture (cc-option test).

In result this means that no -march compiler option is set when an
unsupported cpu architecture of the current compiler is selected.
The kernel compile will afterwards succeed but with the default
architecture instead of the (unsupported) selected one.

Change this behaviour, so compiles will fail if the compiler does
not support the selected cpu architecture.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
</feed>
