<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/arch/powerpc/include/asm/opal.h, branch linux-5.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.2.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.2.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-10-01T07:01:36Z</updated>
<entry>
<title>powerpc/xive: Fix bogus error code returned by OPAL</title>
<updated>2019-10-01T07:01:36Z</updated>
<author>
<name>Greg Kurz</name>
<email>groug@kaod.org</email>
</author>
<published>2019-09-11T15:52:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=be3b5f44206e05c06702de30e0d0565377e0eb40'/>
<id>urn:sha1:be3b5f44206e05c06702de30e0d0565377e0eb40</id>
<content type='text'>
commit 6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8 upstream.

There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call
to return the 32-bit value 0xffffffff when OPAL has run out of IRQs.
Unfortunatelty, OPAL return values are signed 64-bit entities and
errors are supposed to be negative. If that happens, the linux code
confusingly treats 0xffffffff as a valid IRQ number and panics at some
point.

A fix was recently merged in skiboot:

e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()")

but we need a workaround anyway to support older skiboots already
in the field.

Internally convert 0xffffffff to OPAL_RESOURCE which is the usual error
returned upon resource exhaustion.

Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Greg Kurz &lt;groug@kaod.org&gt;
Reviewed-by: Cédric Le Goater &lt;clg@kaod.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/156821713818.1985334.14123187368108582810.stgit@bahia.lan
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152</title>
<updated>2019-05-30T18:26:32Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-05-27T06:55:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2874c5fd284268364ece81a7bd936f3c8168e567'/>
<id>urn:sha1:2874c5fd284268364ece81a7bd936f3c8168e567</id>
<content type='text'>
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>powerpc/hmi: Fix kernel hang when TB is in error state.</title>
<updated>2019-05-02T16:54:57Z</updated>
<author>
<name>Mahesh Salgaonkar</name>
<email>mahesh@linux.vnet.ibm.com</email>
</author>
<published>2019-03-04T19:42:19Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=de269129a48a2d590ba1d20c719e19d86e3ddb3f'/>
<id>urn:sha1:de269129a48a2d590ba1d20c719e19d86e3ddb3f</id>
<content type='text'>
On TOD/TB errors timebase register stops/freezes until HMI error recovery
gets TOD/TB back into running state. On successful recovery, TB starts
running again and udelay() that relies on TB value continues to function
properly. But in case when HMI fails to recover from TOD/TB errors, the
TB register stay freezed. With TB not running the __delay() function
keeps looping and never return. If __delay() is called while in panic
path then system hangs and never reboots after panic.

Signed-off-by: Mahesh Salgaonkar &lt;mahesh@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/xive: add OPAL extensions for the XIVE native exploitation support</title>
<updated>2019-04-11T05:31:41Z</updated>
<author>
<name>Cédric Le Goater</name>
<email>clg@kaod.org</email>
</author>
<published>2019-04-10T17:04:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=88ec6b93c8e7d6d4ffaf6ad6395ceb3bf552de15'/>
<id>urn:sha1:88ec6b93c8e7d6d4ffaf6ad6395ceb3bf552de15</id>
<content type='text'>
The support for XIVE native exploitation mode in Linux/KVM needs a
couple more OPAL calls to get and set the state of the XIVE internal
structures being used by a sPAPR guest.

Signed-off-by: Cédric Le Goater &lt;clg@kaod.org&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/powernv: Move opal_power_control_init() call in opal_init().</title>
<updated>2018-12-21T00:32:49Z</updated>
<author>
<name>Mahesh Salgaonkar</name>
<email>mahesh@linux.vnet.ibm.com</email>
</author>
<published>2018-12-13T05:47:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=08fb726df13778a54592aaa1deea6a154637c868'/>
<id>urn:sha1:08fb726df13778a54592aaa1deea6a154637c868</id>
<content type='text'>
opal_power_control_init() depends on opal message notifier to be
initialized, which is done in opal_init()-&gt;opal_message_init(). But both
these initialization are called through machine initcalls and it all
depends on in which order they being called. So far these are called in
correct order (may be we got lucky) and never saw any issue. But it is
clearer to control initialization order explicitly by moving
opal_power_control_init() into opal_init().

Signed-off-by: Mahesh Salgaonkar &lt;mahesh@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/powernv: provide a console flush operation for opal hvc driver</title>
<updated>2018-08-20T10:19:54Z</updated>
<author>
<name>Nicholas Piggin</name>
<email>npiggin@gmail.com</email>
</author>
<published>2018-04-30T14:55:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=95b861a76c1ded3e89d33a3d9f4552dce22e9875'/>
<id>urn:sha1:95b861a76c1ded3e89d33a3d9f4552dce22e9875</id>
<content type='text'>
Provide the flush hv_op for the opal hvc driver. This will flush the
firmware console buffers without spinning with interrupts disabled.

Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>crypto/nx: Initialize 842 high and normal RxFIFO control registers</title>
<updated>2018-08-07T14:32:34Z</updated>
<author>
<name>Haren Myneni</name>
<email>haren@linux.vnet.ibm.com</email>
</author>
<published>2018-06-13T07:32:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=656ecc16e8fc2ab44b3d70e3fcc197a7020d0ca5'/>
<id>urn:sha1:656ecc16e8fc2ab44b3d70e3fcc197a7020d0ca5</id>
<content type='text'>
NX increments readOffset by FIFO size in receive FIFO control register
when CRB is read. But the index in RxFIFO has to match with the
corresponding entry in FIFO maintained by VAS in kernel. Otherwise NX
may be processing incorrect CRBs and can cause CRB timeout.

VAS FIFO offset is 0 when the receive window is opened during
initialization. When the module is reloaded or in kexec boot, readOffset
in FIFO control register may not match with VAS entry. This patch adds
nx_coproc_init OPAL call to reset readOffset and queued entries in FIFO
control register for both high and normal FIFOs.

Signed-off-by: Haren Myneni &lt;haren@us.ibm.com&gt;
[mpe: Fixup uninitialized variable warning]
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/powernv: Add support to enable sensor groups</title>
<updated>2018-07-31T09:56:45Z</updated>
<author>
<name>Shilpasri G Bhat</name>
<email>shilpa.bhat@linux.vnet.ibm.com</email>
</author>
<published>2018-07-24T09:13:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=04baaf28f40c68c35a413cd9d0db7139c67e6caf'/>
<id>urn:sha1:04baaf28f40c68c35a413cd9d0db7139c67e6caf</id>
<content type='text'>
Adds support to enable/disable a sensor group at runtime. This
can be used to select the sensor groups that needs to be copied to
main memory by OCC. Sensor groups like power, temperature, current,
voltage, frequency, utilization can be enabled/disabled at runtime.

Signed-off-by: Shilpasri G Bhat &lt;shilpa.bhat@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/powernv: implement opal_put_chars_atomic</title>
<updated>2018-07-24T12:09:57Z</updated>
<author>
<name>Nicholas Piggin</name>
<email>npiggin@gmail.com</email>
</author>
<published>2018-04-30T14:55:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=17cc1dd4924391b54fb179d0868b89dc96f2ee80'/>
<id>urn:sha1:17cc1dd4924391b54fb179d0868b89dc96f2ee80</id>
<content type='text'>
The RAW console does not need writes to be atomic, so relax
opal_put_chars to be able to do partial writes, and implement an
_atomic variant which does not take a spinlock. This API is used
in xmon, so the less locking that is used, the better chance there
is that a crash can be debugged.

Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/powernv: Implement and use opal_flush_console</title>
<updated>2018-07-24T12:09:56Z</updated>
<author>
<name>Nicholas Piggin</name>
<email>npiggin@gmail.com</email>
</author>
<published>2018-04-30T14:55:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d2a2262e686ce7a27776add27751f925ceda856f'/>
<id>urn:sha1:d2a2262e686ce7a27776add27751f925ceda856f</id>
<content type='text'>
A new console flushing firmware API was introduced to replace event
polling loops, and implemented in opal-kmsg with affddff69c55e
("powerpc/powernv: Add a kmsg_dumper that flushes console output on
panic"), to flush the console in the panic path.

The OPAL console driver has other situations where interrupts are off
and it needs to flush the console synchronously. These still use a
polling loop.

So move the opal-kmsg flush code to opal_flush_console, and use the
new function in opal-kmsg and opal_put_chars.

Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Reviewed-by: Russell Currey &lt;ruscur@russell.cc&gt;
Signed-off-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
</feed>
