Allow user-space processes to use transactional execution (TX).
If the TX facility is available user space programs can use
transactions for fine-grained serialization based on the data
objects that are referenced during a transaction. This is
useful for lockless data structures and speculative compiler
optimizations.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Remove the file name from the comment at top of many files. In most
cases the file name was wrong anyway, so it's rather pointless.

Also unify the IBM copyright statement. We did have a lot of sightly
different statements and wanted to change them one after another
whenever a file gets touched. However that never happened. Instead
people start to take the old/"wrong" statements to use as a template
for new files.
So unify all of them in one go.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

Just saves a couple of instructions.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

The s390 idle accounting code uses a sequence counter which gets used
when the per cpu idle statistics get updated and read.

One assumption on read access is that only when the sequence counter is
even and did not change while reading all values the result is valid.
On cpu hotplug however the per cpu data structure gets initialized via
a cpu hotplug notifier on CPU_ONLINE.
CPU_ONLINE however is too late, since the onlined cpu is already running
and might access the per cpu data. Worst case is that the data structure
gets initialized while an idle thread is updating its idle statistics.
This will result in an uneven sequence counter after an update.

As a result user space tools like top, which access /proc/stat in order
to get idle stats, will busy loop waiting for the sequence counter to
become even again, which will never happen until the queried cpu will
update its idle statistics again. And even then the sequence counter
will only have an even value for a couple of cpu cycles.

Fix this by moving the initialization of the per cpu idle statistics
to cpu_init(). I prefer that solution in favor of changing the
notifier to CPU_UP_PREPARE, which would be a different solution to
the problem.

Cc: stable@vger.kernel.org
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

The .start function and indirectly the .next function of the show_cpuinfo
sequential operation uses NR_CPUS as limit instead of nr_cpu_ids.
This can cause warnings like this:

WARNING: at /usr/src/linux/include/linux/cpumask.h:107
Process lscpu (pid: 575, task: 000000007deb4338, ksp: 000000007794f588)
Krnl PSW : 0704000180000000 0000000000106db4 (show_cpuinfo+0x108/0x234)
           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0 EA:3
Krnl GPRS: 0000000000000003 0000000000791988 000000000071b478 0000000000000004
           0000000000000001 0000000000000000 000000007d139500 0000000000000400
           0000000000000000 000000000070e24c 000000007d48d600 0000000000000005
           000000007d48d600 00000000004dfa10 0000000000106cf8 000000007794fcc0
Krnl Code: 0000000000106da8: 95001000           cli     0(%r1),0
           0000000000106dac: a774ffac           brc     7,106d04
           0000000000106db0: a7f40001           brc     15,106db2
          >0000000000106db4: 92011000           mvi     0(%r1),1
           0000000000106db8: a7f4ffa6           brc     15,106d04
           0000000000106dbc: c0e5000065b4       brasl   %r14,113924
           0000000000106dc2: c09000303a45       larl    %r9,70e24c
           0000000000106dc8: c020001eefd4       larl    %r2,4e4d70

Replacing NR_CPUS with nr_cpu_ids fixes it.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

When the seqfile /proc/cpuinfo gets accesses for each possible cpu
loops_per_jiffy gets recalculated. However its value is only needed
on first access.
In addition loops_per_jiffy should be recalculated when the machine
reports a capability change.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Use get_online_cpus() instead of preempt_disable() to make sure cpus
don't go offline while accessing their per cpu data.
The preempt_disable() stuff is old code which was used before
get_online_cpus() was available.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Get rid of messages that indicate if a cpu went online or offline.
There is nothing special about this anymore and these messages might
flood the kernel log buffer which makes debugging harder since more
important messages might be overwritten.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Up to now print_cpu_info() uses the cpu address stored in it's local
lowcore to print a message to the console. The cpu address in the
lowcore is (in this case) however not the physical cpu address of the
local cpu. It's the address of the cpu that issued the sigp restart
which started the local cpu.
Fix this by using the store cpu address instruction instead.
It's not that anybody really cares since this is broken since more than
ten years...
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Remove cpu_id from lowcore and replace addr_t with __u64.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

This patch makes the hwcap bit for the high gprs feature to be visible
in /proc/cpuinfo.
Signed-off-by: NAndreas Krebbel <Andreas.Krebbel@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

The Extended Translation Facility 3 (ETF3) added instructions which
allow conversions between different unicode character maps (UTF-8,
UTF-32 ...).  These instructions got enhanced with a later version of
the ETF3 allowing malformed multibyte chars to be recognized and
reported correctly.  The attached patch reserves bit 8 in the elf
hwcaps vector for the enhanced version of ETF3. The bit corresponds to
the stfle bits 22 and 30 and will only be set if both of the stfle
bits are set.
Signed-off-by: NAndreas Krebbel <krebbel@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>