kernel/git/stable/linux-stable.git/drivers/s390/char, branch linux-4.3.y

s390/sclp_vt220: support magic sysrequests

2015-08-26T15:20:45+00:00

Implement magic sysrequest handling for the VT220 terminal (also known as the Integrated ASCII console on the HMC/SE). To invoke a "magic sysrequest" function, press "Ctrl+o" followed by a second character that designates the debugging function. The handling of the sysrq is scheduled away from the SCLP IRQ context; because large amounts of sysrq output might fill up the console buffers. The console might deadlock because it cannot empty the buffers while still in the receiving IRQ context. This behavior is the same as for the SCLP console. Reported-by: Horst Weber Signed-off-by: Hendrik Brueckner Reviewed-by: Peter Oberparleiter Signed-off-by: Martin Schwidefsky

s390/ctrlchar: improve handling of magic sysrequests

2015-08-26T15:20:44+00:00

Extract the sysrq handling from the ctrlchar_handle() into a separate function that can be directly used by other users. Introduce a new sysrq_work structure to embed the work_struct and to specify the magic sysrq function to be invoked. Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky

s390/3270: redraw screen on unsolicited device end

2015-08-26T15:19:49+00:00

If a 3270 terminal is disconnected and later reconnected again, it gets an unsolicited device end. This is currently ignored and you have to hit the clear key to get the screen redrawn. Add an automatic full redraw of the screen for this case. Signed-off-by: Martin Schwidefsky

s390/hmcdrv: fix interrupt registration

2015-08-19T08:40:17+00:00

The z/VM driver sets bit "63-22" in control register zero to one in order to enable the CP Service interrupt (0x2603). However the irq subclass mask that normally corresponds to the CP Service interrupt is "63-54" (== "63-22-32"). So it looks like the author read the documentation with the 32 bit sized cr0 register bit positions (== 22), but didn't realize that bit numbers change, if applied to a 64 bit register (== 54) due to the numbering scheme. Also use irq_subclass_register() instead if ctl_set_bit() since multiple services depend on the service signal subclass mask, which is the correct bit. This also explains why nobody noticed the bug, since the bit is always enabled anyway (e.g. pfault). Signed-off-by: Heiko Carstens Reviewed-by: Hendrik Brueckner Acked-by: Martin Schwidefsky Signed-off-by: Martin Schwidefsky

s390: remove unneeded semicolon

2015-08-07T07:57:00+00:00

Remove unneeded semicolon. The semantic patch that detects this change is available at scripts/coccinelle/misc/semicolon.cocci. Signed-off-by: Peter Senna Tschudin Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390/numa: add emulation support

2015-08-04T12:06:53+00:00

NUMA emulation (aka fake NUMA) distributes the available memory to nodes without using real topology information about the physical memory of the machine. Splitting the system memory into nodes replicates the memory management structures for each node. Particularly each node has its own "mm locks" and its own "kswapd" task. For large systems, under certain conditions, this results in improved system performance and/or latency based on reduced pressure on the mm locks and the kswapd tasks. NUMA emulation distributes CPUs to nodes while respecting the original machine topology information. This is done by trying to avoid to separate CPUs which reside on the same book or even on the same MC. Because the current Linux scheduler code requires a stable cpu to node mapping, cores are pinned to nodes when the first CPU thread is set online. This patch is based on the initial implementation from Philipp Hachtmann. Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky

s390/sclp: Change SCLP console default buffer-full behavior

2015-07-22T07:58:05+00:00

Dropping kernel messages during a console-buffer-full condition is preferable to halting the system until console messages are delivered, especially for production systems. Update default for sclp_console_drop kernel parameter accordingly. Signed-off-by: Peter Oberparleiter Acked-by: Martin Schwidefsky Signed-off-by: Martin Schwidefsky

s390/sclp: fix compile error

2015-07-01T07:34:38+00:00

Fix this error when compiling with CONFIG_SMP=n and CONFIG_DYNAMIC_DEBUG=y: drivers/s390/char/sclp_early.c: In function 'sclp_read_info_early': drivers/s390/char/sclp_early.c:87:19: error: 'EBUSY' undeclared (first use in this function) } while (rc == -EBUSY); ^ Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky

s390/kdump: fix nosmt kernel parameter

2015-06-25T07:39:26+00:00

It turned out that SIGP set-multi-threading can only be done once. Therefore switching to a different MT level after switching to sclp.mtid_prev in the dump case fails. As a symptom specifying the "nosmt" parameter currently fails for the kdump kernel and the kernel starts with multi-threading enabled. So fix this and issue diag 308 subcode 1 call after collecting the CPU states for the dump. Also enhance the diag308_reset() function to be usable also with enabled lowcore protection and prefix register != 0. After the reset it is possible to switch the MT level again. We have to do the reset very early in order not to kill the already initialized console. Therefore instead of kmalloc() the corresponding memblock functions have to be used. To avoid copying the sclp cpu code into sclp_early, we now use the simple sigp loop method for CPU detection. Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky

s390/smp: cleanup core vs. cpu in the SCLP interface

2015-06-25T07:39:24+00:00

The SCLP interface to query, configure and deconfigure CPUs actually operates on cores. For a machine without the multi-threading faciltiy a CPU and a core are equivalent but starting with System z13 a core can have multiple hardware threads, also referred to as logical CPUs. To avoid confusion replace the word 'cpu' with 'core' in the SCLP interface. Also replace MAX_CPU_ADDRESS with SCLP_MAX_CORES. The core-id is an 8-bit field, the maximum thread id is in the range 0-31. The theoretical limit for the CPU address is therefore 8191. Signed-off-by: Martin Schwidefsky