Based on the x86 commit doing the same.
See commit 304ec1b050 ("x86/uaccess: Use __uaccess_begin_nospec()
and uaccess_try_nospec") and b3bbfb3fb5 ("x86: Introduce
__uaccess_begin_nospec() and uaccess_try_nospec") for more detail.
In all cases we are ordering the load from the potentially
user-controlled pointer vs a previous branch based on an access_ok()
check or similar.
Base on a patch from Michal Suchanek.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Check what firmware told us and enable/disable the barrier_nospec as
appropriate.
We err on the side of enabling the barrier, as it's no-op on older
systems, see the comment for more detail.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Note that unlike RFI which is patched only in kernel the nospec state
reflects settings at the time the module was loaded.
Iterating all modules and re-patching every time the settings change
is not implemented.
Based on lwsync patching.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Based on the RFI patching. This is required to be able to disable the
speculation barrier.
Only one barrier type is supported and it does nothing when the
firmware does not enable it. Also re-patching modules is not supported
So the only meaningful thing that can be done is patching out the
speculation barrier at boot when the user says it is not wanted.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
A no-op form of ori (or immediate of 0 into r31 and the result stored
in r31) has been re-tasked as a speculation barrier. The instruction
only acts as a barrier on newer machines with appropriate firmware
support. On older CPUs it remains a harmless no-op.
Implement barrier_nospec using this instruction.
mpe: The semantics of the instruction are believed to be that it
prevents execution of subsequent instructions until preceding branches
have been fully resolved and are no longer executing speculatively.
There is no further documentation available at this time.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
This now has new code in it written by Nick and I, and switch to a
SPDX tag.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
This allows eg. the RCU stall detector, or the soft/hardlockup
detectors to trigger a backtrace on all CPUs.
We implement this by sending a "safe" NMI, which will actually only
send an IPI. Unfortunately the generic code prints "NMI", so that's a
little confusing but we can probably live with it.
If one of the CPUs doesn't respond to the IPI, we then print some info
from it's paca and do a backtrace based on its saved_r1.
Example output:
INFO: rcu_sched detected stalls on CPUs/tasks:
2-...0: (0 ticks this GP) idle=1be/1/4611686018427387904 softirq=1055/1055 fqs=25735
(detected by 4, t=58847 jiffies, g=58, c=57, q=1258)
Sending NMI from CPU 4 to CPUs 2:
CPU 2 didn't respond to backtrace IPI, inspecting paca.
irq_soft_mask: 0x01 in_mce: 0 in_nmi: 0 current: 3623 (bash)
Back trace of paca->saved_r1 (0xc0000000e1c83ba0) (possibly stale):
Call Trace:
[c0000000e1c83ba0] [0000000000000014] 0x14 (unreliable)
[c0000000e1c83bc0] [c000000000765798] lkdtm_do_action+0x48/0x80
[c0000000e1c83bf0] [c000000000765a40] direct_entry+0x110/0x1b0
[c0000000e1c83c90] [c00000000058e650] full_proxy_write+0x90/0xe0
[c0000000e1c83ce0] [c0000000003aae3c] __vfs_write+0x6c/0x1f0
[c0000000e1c83d80] [c0000000003ab214] vfs_write+0xd4/0x240
[c0000000e1c83dd0] [c0000000003ab5cc] ksys_write+0x6c/0x110
[c0000000e1c83e30] [c00000000000b860] system_call+0x58/0x6c
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Currently the options we have for sending NMIs are not necessarily
safe, that is they can potentially interrupt a CPU in a
non-recoverable region of code, meaning the kernel must then panic().
But we'd like to use smp_send_nmi_ipi() to do cross-CPU calls in
situations where we don't want to risk a panic(), because it doesn't
have the requirement that interrupts must be enabled like
smp_call_function().
So add an API for the caller to indicate that it wants to use the NMI
infrastructure, but doesn't want to do anything "unsafe".
Currently that is implemented by not actually calling cause_nmi_ipi(),
instead falling back to an IPI. In future we can pass the safe
parameter down to cause_nmi_ipi() and the individual backends can
potentially take it into account before deciding what to do.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
A CPU that gets stuck with interrupts hard disable can be difficult to
debug, as on some platforms we have no way to interrupt the CPU to
find out what it's doing.
A stop-gap is to have the CPU save it's stack pointer (r1) in its paca
when it hard disables interrupts. That way if we can't interrupt it,
we can at least trace the stack based on where it last disabled
interrupts.
In some cases that will be total junk, but the stack trace code should
handle that. In the simple case of a CPU that disable interrupts and
then gets stuck in a loop, the stack trace should be informative.
We could clear the saved stack pointer when we enable interrupts, but
that loses information which could be useful if we have nothing else
to go on.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
set_fs() sets the addr_limit, which is used in access_ok() to
determine if an address is a user or kernel address.
Some code paths use set_fs() to temporarily elevate the addr_limit so
that kernel code can read/write kernel memory as if it were user
memory. That is fine as long as the code can't ever return to
userspace with the addr_limit still elevated.
If that did happen, then userspace can read/write kernel memory as if
it were user memory, eg. just with write(2). In case it's not clear,
that is very bad. It has also happened in the past due to bugs.
Commit 5ea0727b16 ("x86/syscalls: Check address limit on user-mode
return") added a mechanism to check the addr_limit value before
returning to userspace. Any call to set_fs() sets a thread flag,
TIF_FSCHECK, and if we see that on the return to userspace we go out
of line to check that the addr_limit value is not elevated.
For further info see the above commit, as well as:
https://lwn.net/Articles/722267/https://bugs.chromium.org/p/project-zero/issues/detail?id=990
Verified to work on 64-bit Book3S using a POC that objdumps the system
call handler, and a modified lkdtm_CORRUPT_USER_DS() that doesn't kill
the caller.
Before:
$ sudo ./test-tif-fscheck
...
0000000000000000 <.data>:
0: e1 f7 8a 79 rldicl. r10,r12,30,63
4: 80 03 82 40 bne 0x384
8: 00 40 8a 71 andi. r10,r12,16384
c: 78 0b 2a 7c mr r10,r1
10: 10 fd 21 38 addi r1,r1,-752
14: 08 00 c2 41 beq- 0x1c
18: 58 09 2d e8 ld r1,2392(r13)
1c: 00 00 41 f9 std r10,0(r1)
20: 70 01 61 f9 std r11,368(r1)
24: 78 01 81 f9 std r12,376(r1)
28: 70 00 01 f8 std r0,112(r1)
2c: 78 00 41 f9 std r10,120(r1)
30: 20 00 82 41 beq 0x50
34: a6 42 4c 7d mftb r10
After:
$ sudo ./test-tif-fscheck
Killed
And in dmesg:
Invalid address limit on user-mode return
WARNING: CPU: 1 PID: 3689 at ../include/linux/syscalls.h:260 do_notify_resume+0x140/0x170
...
NIP [c00000000001ee50] do_notify_resume+0x140/0x170
LR [c00000000001ee4c] do_notify_resume+0x13c/0x170
Call Trace:
do_notify_resume+0x13c/0x170 (unreliable)
ret_from_except_lite+0x70/0x74
Performance overhead is essentially zero in the usual case, because
the bit is checked as part of the existing _TIF_USER_WORK_MASK check.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
It's called 'fs' for historical reasons, it's named after the x86 'FS'
register. But we don't have to use that name for the member of
thread_struct, and in fact arch/x86 doesn't even call it 'fs' anymore.
So rename it to 'addr_limit', which better reflects what it's used
for, and is also the name used on other arches.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
In PPC_PTRACE_GETHWDBGINFO and PPC_PTRACE_SETHWDEBUG we do an
access_ok() check and then __copy_{from,to}_user().
Instead we should just use copy_{from,to}_user() which does all that
for us and is less error prone.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The EEH report functions now share a fair bit of code around the start
and end of each function.
So factor out as much as possible, and move the traversal into a
custom function. This also allows accurate debug to be generated more
easily.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
[mpe: Format with clang-format]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
If a device without a driver is recovered via EEH, the flag
EEH_DEV_NO_HANDLER is incorrectly left set on the device after
recovery, because the test in eeh_report_resume() for the existence of
a bound driver is done before the flag is cleared. If a driver is
later bound, and EEH experienced again, some of the drivers EEH
handers are not called.
To correct this, clear the flag unconditionally after EEH processing
is complete.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
To ease future refactoring, extract calls to eeh_enable_irq() and
eeh_disable_irq() from the various report functions. This makes
the report functions initial sequences more similar, as well as making
the IRQ changes visible when reading eeh_handle_normal_event().
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
To ease future refactoring, extract setting of the channel state
from the report functions out into their own functions. This increases
the amount of code that is identical across all of the report
functions.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The same test is done in every EEH report function, so factor it out.
Since eeh_dev_removed() needs to be moved higher up in the file,
simplify it a little while we're at it.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Add a for_each-style macro for iterating through PEs without the
boilerplate required by a traversal function. eeh_pe_next() is now
exported, as it is now used directly in place.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
As EEH event handling progresses, a cumulative result of type
pci_ers_result is built up by (some of) the eeh_report_*() functions
using either:
if (rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
if (*res == PCI_ERS_RESULT_NONE) *res = rc;
or:
if ((*res == PCI_ERS_RESULT_NONE) ||
(*res == PCI_ERS_RESULT_RECOVERED)) *res = rc;
if (*res == PCI_ERS_RESULT_DISCONNECT &&
rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
(Where *res is the accumulator.)
However, the intent is not immediately clear and the result in some
situations is order dependent.
Address this by assigning a priority to each result value, and always
merging to the highest priority. This renders the intent clear, and
provides a stable value for all orderings.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
[mpe: Minor formatting (clang-format)]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
To aid debugging, add a message to show when EEH processing for a PE
will be done at the device's parent, rather than directly at the
device.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The traversal functions eeh_pe_traverse() and eeh_pe_dev_traverse()
both provide their first argument as void * but every single user casts
it to the expected type.
Change the type of the first parameter from void * to the appropriate
type, and clean up all uses.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Correct two cases where eeh_pcid_get() is used to reference the driver's
module but the reference is dropped before the driver pointer is used.
In eeh_rmv_device() also refactor a little so that only two calls to
eeh_pcid_put() are needed, rather than three and the reference isn't
taken at all if it wasn't needed.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Add a single log line at the end of successful EEH recovery, so that
it's clear that event processing has finished.
Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Since thread-imc internally use the core-imc hardware infrastructure
and is depended on it, having thread-imc in the kernel in the
absence of core-imc is trivial. Patch disables thread-imc, if
core-imc is not registered.
Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Replace the direct return statement in imc_mem_init() with goto, to adhere
to the kernel coding style.
Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When any of the IMC (In-Memory Collection counter) devices fail
to initialize, imc_common_mem_free() frees set of memory. In doing so,
pmu_ptr pointer is also freed. But pmu_ptr pointer is used in subsequent
function (imc_common_cpuhp_mem_free()) which is wrong. Patch here reorders
the code to avoid such access.
Also free the memory which is dynamically allocated during imc
initialization, wherever required.
Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The device node obtained with of_find_compatible_node() should be
released by calling of_node_put(). But it was not released when
of_get_property() failed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
[mpe: Invert the sense of the if so we only need one return path]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Structure platform_driver does not need to set the owner field, as this
will be populated by the driver core.
Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The GETFIELD and SETFIELD macros in xive-regs.h aren't used except for
a single instance of GETFIELD, so replace that and remove them.
These macros are also defined in vas.h, so either those should be
eventually replaced or the macros moved into bitops.h.
Signed-off-by: Russell Currey <ruscur@russell.cc>
[mpe: Rewrite the assignment to 'he' to avoid ffs() etc.]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
to_tm() is now completely unused, the only reference being in the
_dump_time() helper that is also unused. This removes both, leaving
the rest of the powerpc RTC code y2038 safe to as far as the hardware
supports.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
update_persistent_clock() is deprecated because it suffers from overflow
in 2038 on 32-bit architectures. This changes powerpc to use the
update_persistent_clock64() replacement, and to pass down 64-bit
timestamps consistently.
This is now simpler, as we no longer have to worry about the offset
numbers in tm_year and tm_mon that are different between the Linux
conventions and RTAS.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Looking through the remaining users of the deprecated mktime()
function, I found the powerpc rtc handlers, which use it in
place of rtc_tm_to_time64().
To clean this up, I'm changing over the read_persistent_clock()
function to the read_persistent_clock64() variant, and change
all the platform specific handlers along with it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The to_tm() helper function operates on a signed integer for the time,
so it will suffer from overflow in 2038, even on 64-bit kernels.
Rather than fix that function, this replaces its use in the rtas
procfs implementation with the standard rtc_time64_to_tm() helper
that is very similar but is not affected by the overflow.
In order to actually support long times, the parser function gets
changed to 64-bit user input and output as well. Note that the tm_mon
and tm_year representation is slightly different, so we have to manually
add an offset here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
In order to use the rtc_tm_to_time64() and rtc_time64_to_tm()
helper functions in later patches, we have to ensure that
CONFIG_RTC_LIB is always built-in.
Note that this symbol only controls a couple of helper functions,
not the actual RTC subsystem, which remains optional and is
enabled with CONFIG_RTC_CLASS.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Needed on Amiga X1000 with SB600.
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When inserting SLB entries for EA above 512TB, we need to hard disable irq.
This will make sure we don't take a PMU interrupt that can possibly touch
user space address via a stack dump. To prevent this, we need to hard disable
the interrupt.
Also add a comment explaining why we don't need context synchronizing isync
with slbmte.
Fixes: f384796c4 ("powerpc/mm: Add support for handling > 512TB address in SLB miss")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
With split pmd page table lock enabled, we don't use mm->page_table_lock when
updating pmd entries. This patch update hugetlb path to use the right lock
when inserting huge page directory entries into page table.
ex: if we are using hugepd and inserting hugepd entry at the pmd level, we
use pmd_lockptr, which based on config can be split pmd lock.
For update huge page directory entries itself we use mm->page_table_lock. We
do have a helper huge_pte_lockptr() for that.
Fixes: 675d99529 ("powerpc/book3s64: Enable split pmd ptlock")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Currently we do not have an isync, or any other context synchronizing
instruction prior to the slbie/slbmte in _switch() that updates the
SLB entry for the kernel stack.
However that is not correct as outlined in the ISA.
From Power ISA Version 3.0B, Book III, Chapter 11, page 1133:
"Changing the contents of ... the contents of SLB entries ... can
have the side effect of altering the context in which data
addresses and instruction addresses are interpreted, and in which
instructions are executed and data accesses are performed.
...
These side effects need not occur in program order, and therefore
may require explicit synchronization by software.
...
The synchronizing instruction before the context-altering
instruction ensures that all instructions up to and including that
synchronizing instruction are fetched and executed in the context
that existed before the alteration."
And page 1136:
"For data accesses, the context synchronizing instruction before the
slbie, slbieg, slbia, slbmte, tlbie, or tlbiel instruction ensures
that all preceding instructions that access data storage have
completed to a point at which they have reported all exceptions
they will cause."
We're not aware of any bugs caused by this, but it should be fixed
regardless.
Add the missing isync when updating kernel stack SLB entry.
Cc: stable@vger.kernel.org
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
[mpe: Flesh out change log with more ISA text & explanation]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The stores to update the SLB shadow area must be made as they appear
in the C code, so that the hypervisor does not see an entry with
mismatched vsid and esid. Use WRITE_ONCE for this.
GCC has been observed to elide the first store to esid in the update,
which means that if the hypervisor interrupts the guest after storing
to vsid, it could see an entry with old esid and new vsid, which may
possibly result in memory corruption.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Implementing pte_update with pte_xchg (which uses cmpxchg) is
inefficient. A single larx/stcx. works fine, no need for the less
efficient cmpxchg sequence.
Then remove the memory barriers from the operation. There is a
requirement for TLB flushing to load mm_cpumask after the store
that reduces pte permissions, which is moved into the TLB flush
code.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The ISA suggests ptesync after setting a pte, to prevent a table walk
initiated by a subsequent access from missing that store and causing a
spurious fault. This is an architectual allowance that allows an
implementation's page table walker to be incoherent with the store
queue.
However there is no correctness problem in taking a spurious fault in
userspace -- the kernel copes with these at any time, so the updated
pte will be found eventually. Spurious kernel faults on vmap memory
must be avoided, so a ptesync is put into flush_cache_vmap.
On POWER9 so far I have not found a measurable window where this can
result in more minor faults, so as an optimisation, remove the costly
ptesync from pte updates. If an implementation benefits from ptesync,
it would be better to add it back in update_mmu_cache, so it's not
done for things like fork(2).
fork --fork --exec benchmark improved 5.2% (12400->13100).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Prefetch the faulting address in update_mmu_cache to give the page
table walker perhaps 100 cycles head start as locks are dropped and
the interrupt completed.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
This matches other architectures, when we know there will be no
further accesses to the address (e.g., for teardown), page table
entries can be cleared non-atomically.
The comments about NMMU are bogus: all MMU notifiers (including NMMU)
are released at this point, with their TLBs flushed. An NMMU access at
this point would be a bug.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
In the case of a spurious fault (which can happen due to a race with
another thread that changes the page table), the default Linux mm code
calls flush_tlb_page for that address. This is not required because
the pte will be re-fetched. Hash does not wire this up to a hardware
TLB flush for this reason. This patch avoids the flush for radix.
>From Power ISA v3.0B, p.1090:
Setting a Reference or Change Bit or Upgrading Access Authority
(PTE Subject to Atomic Hardware Updates)
If the only change being made to a valid PTE that is subject to
atomic hardware updates is to set the Refer- ence or Change bit to
1 or to add access authorities, a simpler sequence suffices
because the translation hardware will refetch the PTE if an access
is attempted for which the only problems were reference and/or
change bits needing to be set or insufficient access authority.
The nest MMU on POWER9 does not re-fetch the PTE after such an access
attempt before faulting, so address spaces with a coprocessor
attached will continue to flush in these cases.
This reduces tlbies for a kernel compile workload from 0.95M to 0.90M.
fork --fork --exec benchmark improved 0.5% (12300->12400).
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Radix flushes the TLB when updating ptes to increase permissiveness
of protection (increase access authority). Book3S does not require
TLB flushing in this case, and it is not done on hash. This patch
avoids the flush for radix.
>From Power ISA v3.0B, p.1090:
Setting a Reference or Change Bit or Upgrading Access Authority
(PTE Subject to Atomic Hardware Updates)
If the only change being made to a valid PTE that is subject to
atomic hardware updates is to set the Reference or Change bit to 1
or to add access authorities, a simpler sequence suffices because
the translation hardware will refetch the PTE if an access is
attempted for which the only problems were reference and/or change
bits needing to be set or insufficient access authority.
The nest MMU on POWER9 does not re-fetch the PTE after such an access
attempt before faulting, so address spaces with a coprocessor
attached will continue to flush in these cases.
This reduces tlbies for a kernel compile workload from 1.28M to 0.95M,
tlbiels from 20.17M 19.68M.
fork --fork --exec benchmark improved 2.77% (12000->12300).
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When relaxing access (read -> read_write update), pte needs to be marked invalid
to handle a nest MMU bug. We also need to do a tlb flush after the pte is
marked invalid before updating the pte with new access bits.
We also move tlb flush to platform specific __ptep_set_access_flags. This will
help us to gerid of unnecessary tlb flush on BOOK3S 64 later. We don't do that
in this patch. This also helps in avoiding multiple tlbies with coprocessor
attached.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
In later patch, we use the vma and psize to do tlb flush. Do the prototype
update in separate patch to make the review easy.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
In later patch we will update them which require them to be moved
to pgtable-radix.c. Keeping the function in radix.h results in
compile warning as below.
./arch/powerpc/include/asm/book3s/64/radix.h: In function ‘radix__ptep_set_access_flags’:
./arch/powerpc/include/asm/book3s/64/radix.h:196:28: error: dereferencing pointer to incomplete type ‘struct vm_area_struct’
struct mm_struct *mm = vma->vm_mm;
^~
./arch/powerpc/include/asm/book3s/64/radix.h:204:6: error: implicit declaration of function ‘atomic_read’; did you mean ‘__atomic_load’? [-Werror=implicit-function-declaration]
atomic_read(&mm->context.copros) > 0) {
^~~~~~~~~~~
__atomic_load
./arch/powerpc/include/asm/book3s/64/radix.h:204:21: error: dereferencing pointer to incomplete type ‘struct mm_struct’
atomic_read(&mm->context.copros) > 0) {
Instead of fixing header dependencies, we move the function to pgtable-radix.c
Also the function is now large to be a static inline . Doing the
move in separate patch helps in review.
No functional change in this patch. Only code movement.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
In a later patch, we want to update __ptep_set_access_flags take page size
arg. This makes ptep_set_access_flags only work with mmu_virtual_psize.
To simplify the code make huge_ptep_set_access_flags directly call
__ptep_set_access_flags so that we can compute the hugetlb page size in
hugetlb function.
Now that ptep_set_access_flags won't be called for hugetlb remove
the is_vm_hugetlb_page() check and add the assert of pte lock
unconditionally.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The function removes the process element from NPU cache.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The current implementation of TID allocation, using a global IDR, may
result in an errant process starving the system of available TIDs.
Instead, use task_pid_nr(), as mentioned by the original author. The
scenario described which prevented it's use is not applicable, as
set_thread_tidr can only be called after the task struct has been
populated.
In the unlikely event that 2 threads share the TID and are waiting,
all potential outcomes have been determined safe.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Switch the use of TIDR on it's CPU feature, rather than assuming it
is available based on architecture.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
This patch adds a CPU feature bit to show whether the CPU has
the TIDR register available, enabling as_notify/wait in userspace.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Using irq_work for processing OPAL event interrupts is not necessary.
irq_work is typically used to schedule work from NMI context, a
softirq may be more appropriate. However OPAL events are not
particularly performance or latency critical, so they can all be
invoked by kopald.
This patch removes the irq_work queueing, and instead wakes up
kopald when there is an event to be processed. kopald processes
interrupts individually, enabling irqs and calling cond_resched
between each one to minimise latencies.
Event handlers themselves should still use threaded handlers,
workqueues, etc. as necessary to avoid high interrupts-off latencies
within any single interrupt.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Although it is often possible to recover a CPU that was interrupted
from OPAL with a system reset NMI, it's undesirable to interrupt them
for a few reasons. Firstly because dump/debug code itself needs to
call firmware, so it could hang on a lock or possibly corrupt a
per-cpu data structure if it or another CPU was interrupted from
OPAL. Secondly, the kexec crash dump code will not return from
interrupt to unwind the OPAL call.
Call OPAL_QUIESCE with QUIESCE_HOLD before sending an NMI IPI to
another CPU, which wait for it to leave firmware (or time out) to
avoid this problem in normal conditions. Firmware bugs may still
result in a timeout and interrupting OPAL, but that is the best
option (stops the CPU, and possibly allows firmware to be debugged).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When the soft enabled flag was changed to a soft disable mask, xmon
and register dump code was not updated to reflect that, which is
confusing ('SOFTE: 1' previously meant interrupts were soft enabled,
currently it means the opposite, the general interrupt type has been
disabled).
Fix this by using the name irqmask, and printing it in hex.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When soft enabled was changed to irq disabled mask, this test missed
being converted (although the equivalent book3s test was converted).
The PMU drivers consider it an NMI when they take a PMI while general
interrupts are disabled. This change restores that behaviour.
Fixes: 01417c6cc7 ("powerpc/64: Change soft_enabled from flag to bitmask")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
These are not local timer interrupts but IPIs. It's good to be able
to see how timer offloading is behaving, so split these out into
their own category.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Large decrementers (e.g., POWER9) can take a very long time to wrap,
so when the timer iterrupt handler sets the decrementer to max so as
to avoid taking another decrementer interrupt when hard enabling
interrupts before running timers, it effectively disables the soft
NMI coverage for timer interrupts.
Fix this by using the traditional 31-bit value instead, which wraps
after a few seconds. masked interrupt code does the same thing, and
in normal operation neither of these paths would ever wrap even the
31 bit value.
Note: the SMP watchdog should catch timer interrupt lockups, but it
is preferable for the local soft-NMI to catch them, mainly to avoid
the IPI.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The broadcast tick recipient can call tick_receive_broadcast rather
than re-running the full timer interrupt.
It does not have to check for the next event time, because the sender
already determined the timer has expired. It does not have to test
irq_work_pending, because that's a direct decrementer interrupt and
does not go through the clock events subsystem. And it does not have
to read PURR because that was removed with the previous patch.
This results in no code size change, but both the decrementer and
broadcast path lengths are reduced.
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
For SPLPAR, lparcfg provides a sum of PURR registers for all CPUs.
Currently this is done by reading PURR in context switch and timer
interrupt, and storing that into a per-CPU variable. These are summed
to provide the value.
This does not work with all timer schemes (e.g., NO_HZ_FULL), and it
is sub-optimal for performance because it reads the PURR register on
every context switch, although that's been difficult to distinguish
from noise in the contxt_switch microbenchmark.
This patch implements the sum by calling a function on each CPU, to
read and add PURR values of each CPU.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Book3S minimum supported ISA version now requires mtmsrd L=1. This
instruction does not require bits other than RI and EE to be supplied,
so __hard_irq_enable() and __hard_irq_disable() does not have to read
the kernel_msr from paca.
Interrupt entry code already relies on L=1 support.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
This check does not catch IRQ soft mask bugs, but this option is
slightly more suitable than TRACE_IRQFLAGS.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
irq_work_raise should not cause a decrementer exception unless it is
called from NMI context. Doing so often just results in an immediate
masked decrementer interrupt:
<...>-550 90d... 4us : update_curr_rt <-dequeue_task_rt
<...>-550 90d... 5us : dbs_update_util_handler <-update_curr_rt
<...>-550 90d... 6us : arch_irq_work_raise <-irq_work_queue
<...>-550 90d... 7us : soft_nmi_interrupt <-soft_nmi_common
<...>-550 90d... 7us : printk_nmi_enter <-soft_nmi_interrupt
<...>-550 90d.Z. 8us : rcu_nmi_enter <-soft_nmi_interrupt
<...>-550 90d.Z. 9us : rcu_nmi_exit <-soft_nmi_interrupt
<...>-550 90d... 9us : printk_nmi_exit <-soft_nmi_interrupt
<...>-550 90d... 10us : cpuacct_charge <-update_curr_rt
The soft_nmi_interrupt here is the call into the watchdog, due to the
decrementer interrupt firing with irqs soft-disabled. This is
harmless, but sub-optimal.
When it's not called from NMI context or with interrupts enabled, mark
the decrementer pending in the irq_happened mask directly, rather than
having the masked decrementer interupt handler do it. This will be
replayed at the next local_irq_enable. See the comment for details.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When IODA2 creates a PE, it creates an IOMMU table with it_ops::free
set to pnv_ioda2_table_free() which calls pnv_pci_ioda2_table_free_pages().
Since iommu_tce_table_put() calls it_ops::free when the last reference
to the table is released, explicit call to pnv_pci_ioda2_table_free_pages()
is not needed so let's remove it.
This should fix double free in the case of PCI hotuplug as
pnv_pci_ioda2_table_free_pages() does not reset neither
iommu_table::it_base nor ::it_size.
This was not exposed by SRIOV as it uses different code path via
pnv_pcibios_sriov_disable().
IODA1 does not inialize it_ops::free so it does not have this issue.
Fixes: c5f7700bbd ("powerpc/powernv: Dynamically release PE")
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
match_string() returns the index of an array for a matching string,
which can be used instead of open coded variant.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
GCC 8.1 emits warnings such as the following. As arch/powerpc code is
built with -Werror, this breaks the build with GCC 8.1.
In file included from arch/powerpc/kernel/pci_64.c:23:
./include/linux/syscalls.h:233:18: error: 'sys_pciconfig_iobase' alias
between functions of incompatible types 'long int(long int, long
unsigned int, long unsigned int)' and 'long int(long int, long int,
long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
This patch inhibits those warnings.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
[mpe: Trim change log]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
GCC 8.1 warns about possible string truncation:
arch/powerpc/kernel/nvram_64.c:1042:2: error: 'strncpy' specified
bound 12 equals destination size [-Werror=stringop-truncation]
strncpy(new_part->header.name, name, 12);
arch/powerpc/platforms/ps3/repository.c:106:2: error: 'strncpy'
output truncated before terminating nul copying 8 bytes from a
string of the same length [-Werror=stringop-truncation]
strncpy((char *)&n, text, 8);
Fix it by using memcpy(). To make that safe we need to ensure the
destination is pre-zeroed. Use kzalloc() in the nvram code and
initialise the u64 to zero in the ps3 code.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
[mpe: Use kzalloc() in the nvram code, flesh out change log]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
This is a branch with a mixture of mm, x86 and powerpc commits all
relating to some minor cross-arch pkeys consolidation. The x86/mm
changes have been reviewed by Ingo & Dave Hansen and the tree has been
in linux-next for some weeks without issue.
We ended up with an ugly conflict between fixes and next in ftrace.h
involving multiple nested ifdefs, and the automatic resolution is
wrong. So merge fixes into next so we can fix it up.
A final few MIPS fixes for 4.17:
- Drop Lantiq gphy reboot/remove reset (4.14)
- prctl(PR_SET_FP_MODE): Disallow PRE without FR (4.0)
- ptrace(PTRACE_PEEKUSR): Fix 64-bit FGRs (3.15)
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQS7lRNBWUYtqfDOVL41zuSGKxAj8gUCWxHFOwAKCRA1zuSGKxAj
8i39AQCX9phkffpRDnA1e/MiGGeRZ5+f9FBOzuS1x2nzdUagoQD9FzWxdcx57Syj
ye0kUtmc/wm8U6kz3qC3OInSeVuIEQg=
=3NGM
-----END PGP SIGNATURE-----
Merge tag 'mips_fixes_4.17_3' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS fixes from James Hogan:
"A final few MIPS fixes for 4.17:
- drop Lantiq gphy reboot/remove reset (4.14)
- prctl(PR_SET_FP_MODE): Disallow PRE without FR (4.0)
- ptrace(PTRACE_PEEKUSR): Fix 64-bit FGRs (3.15)"
* tag 'mips_fixes_4.17_3' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs
MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests
MIPS: lantiq: gphy: Drop reboot/remove reset asserts
This is to avoid potential merging conflicts between commit 55e3748e89
("arm64: KVM: Add ARCH_WORKAROUND_2 support for guests") and the KVM
tree.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
* R-Mobile A1 (r8a7740) SoC
- Describe CEU, IRQC, SYS-DMAC and USB devices
- Cleanup for consistency with other Renesas SoCs and enhanced maintainability
+ Stop grouping clocks under a "clocks" subnode
+ Add soc node
+ Sort subnodes of root and soc nodes
* RZ/A1H (r7s72100) SoC
- Describe CEU device
* R-Car Gen2, RZ/G1 and RZ/A1H SoCs
- Add PMU device nodes
Geert Uytterhoeven says: "This patch series enables support for the ARM
Performance Monitor Units in Cortex-A7, Cortex-A9, and Cortex-A15 CPU
cores on Renesas RZ/A1, R-Car Gen2, and RZ/G1 SoCs. This allows for
better performance analysis using the "perf" tool."
* RZ/A1H (r7s72100) SoC
- Correct interrupt types
Geert Uytterhoeven says "RZ/A1H peripherals use a mix of level and edge
interrupts.
This patch series corrects the interrupt types for watchdog and RTC from
edge to level, to match the datasheet."
* R-Mobile APE6 (r8a73a4) APE4EVM board and SH-Mobile AG5 (sh73a0) SoC
- Use generic disable-wp instead of now deprecated
toshiba,mmc-wrprotect-disable property
* EMMA Mobile EV2 (emev2) and SH-Mobile AG5 (sh73a0) SoCs
- Add missing interrupt-affinity to PMU
Geert Uytterhoeven says "The Cortex-A9 PMU nodes on SH-Mobile AG5 and
Emma Mobile EV2 reference two interrupts, but lack interrupt-affinity
properties, leading to:
hw perfevents: no interrupt-affinity property for /pmu, guessing.
This series adds the missing properties to fix this."
* R-Car H2 (r8a7790) and R-Mobile APE6 (r8a73a4) SoCs
- Correct mask for GIC PPI interrupts
Geert Uytterhoeven says "R-Car H2 and R-Mobile APE6 contain four
Cortex-A15 and four Cortex-A7 cores, hence the second interrupt
specifier cell for Private Peripheral Interrupts should use
"GIC_CPU_MASK_SIMPLE(8)", to make sure interrupts can be delivered to
all 8 processor cores.
This brings the predecessors of R-Car Gen3 in line with what we're
doing on other big.LITTLE SoCs, like R-Car H3 and M3-W."
* Alt board for R-Car E2 (r8a7794) SoC
* RBoards for -Car Gen2 SoCs and kzm9d board for EMMA Mobile EV2 (emev2) SoC
- Drop unnecessary address properties from VIN port nodes
These are unnecessary as the nodes to not have bus addresses.
* R-Car H2 (r8a7790), M2-W (r8a7791), M2-N (r8a7793) and E2 (r8a7794) SoCs
- Describe FDP1 instances
* iW-RainboW-G23S board for RZ/G1C (r8a77470) SoC
- Initial SoC and board support
- Enable EtherAVB
- Describe all SCIF devices
* Boards for R-Car Gen2 SoCs
- Enable watchdog support
Geert Uytterhoeven says "This patch series enables the builtin watchdog
timer on R-Car Gen2 SoCs on all supported boards, and builds on top of
Fabrizio's "[RFC v4 00/26] Fix watchdog on Renesas R-Car Gen2 and
RZ/G1"."
* R-Car Gen2 and RZ/G1 SoCs
- Describe watchdog devices
- For R-Car Gen2 this involves updating the SMP routine side as
it is changed by a driver updated to allow watchdog device support
* Wheat board for V2H (r8a7792) SoC
- Correct ADV7513 address usage
Kieran Bingham says "The r8a7792 Wheat board has two ADV7513 devices
sharing a single I2C bus, however in low power mode the ADV7513 will
reset it's slave maps to use the hardware defined default addresses.
The ADV7511 driver was adapted to allow the two devices to be
registered correctly - but it did not take into account the fault
whereby the devices reset the addresses.
This results in an address conflict between the device using the
default addresses, and the other device if it is in low-power-mode.
Repair this issue by moving both devices away from the default address
definitions."
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE4nzZofWswv9L/nKF189kaWo3T74FAlr+s/0ACgkQ189kaWo3
T76NqQ/+NFpjAj5GW248b9cClqkxC1OtZOC91Yz1g0kEjH1CHBc+iNRAGFKbVlFR
k5KjRl7cp7zcJ058A47/gl0PoiRr6pXGGPqcxJwq5j5SyYb9I7bZ/wgEsd1U/cUM
vYVj+ibmwVORfDuKxsTZU70/GXBi5vOo+T/U5csmKe2Z75emltgSH6DiMHjc/nyX
uHIsj4IYIX07ZrTUFR6olFJfUr9YujdsD4/UtMOR32ifH8BHuPJDl5+jXngrBiFs
pY/rvYUVctoe2/uMWB88v0NPhkWjIbY21GMluaBBDeVfM5GN34I7gqDZVQUMOx01
Eb5L2N+BKPgRd7GrIlzsMvD/o6449p4BQ7QPqdwuY6q/5q2sZb4gA11qOGfWqnSW
+Nm/BriJuGiNcjVMn91dv5V0cdlMur4orzbOXZ7AQnSSBmlktABCOA7tbnoosVoh
ZVqQsmxks6RUCOTppi8tGpqtZhLdRXzzIPEmcuoDZOxtp55LipEwCrX+2QDSop75
DhjZqq8bTdoMdd8D05bDLFFIuamf/zBW4AGE+cLBvPrRLgA4I42/2sa8KVG6H8rM
TDAVRILt8YQmFzpW5zBRgokiE/UCZlY+g5h5K8kXEQNcl0iMiTd1seaQMjKbRP0A
bcSJ6Ln90uDo7LZ8XxuKVDKT+HTo3unGzuOaQd0Z6BSM7S6qAfk=
=LV2P
-----END PGP SIGNATURE-----
Merge tag 'renesas-dt-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/late
Renesas ARM Based SoC DT Updates for v4.18
* R-Mobile A1 (r8a7740) SoC
- Describe CEU, IRQC, SYS-DMAC and USB devices
- Cleanup for consistency with other Renesas SoCs and enhanced maintainability
* RZ/A1H (r7s72100) SoC
- Describe CEU device
* R-Car Gen2, RZ/G1 and RZ/A1H SoCs
- Add PMU device nodes
* RZ/A1H (r7s72100) SoC
- Correct interrupt types
* R-Mobile APE6 (r8a73a4) APE4EVM board and SH-Mobile AG5 (sh73a0) SoC
- Use generic disable-wp instead of now deprecated
toshiba,mmc-wrprotect-disable property
* EMMA Mobile EV2 (emev2) and SH-Mobile AG5 (sh73a0) SoCs
- Add missing interrupt-affinity to PMU
* R-Car H2 (r8a7790) and R-Mobile APE6 (r8a73a4) SoCs
- Correct mask for GIC PPI interrupts
* R-Car H2 (r8a7790), M2-W (r8a7791), M2-N (r8a7793) and E2 (r8a7794) SoCs
- Describe FDP1 instances
* R-Car Gen2 and RZ/G1 SoCs
- Describe watchdog devices
- For R-Car Gen2 this involves updating the SMP routine side as
it is changed by a driver updated to allow watchdog device support
* Alt board for R-Car E2 (r8a7794) SoC
* RBoards for -Car Gen2 SoCs and kzm9d board for EMMA Mobile EV2 (emev2) SoC
* iW-RainboW-G23S board for RZ/G1C (r8a77470) SoC
- Initial SoC and board support
- Enable EtherAVB
- Describe all SCIF devices
* Boards for R-Car Gen2 SoCs
- Enable watchdog support
* Wheat board for V2H (r8a7792) SoC
- Correct ADV7513 address usage
* tag 'renesas-dt-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (69 commits)
ARM: dts: r8a7740: Add CEU1
ARM: dts: r8a7740: Add CEU0
ARM: dts: r8a7745: Add PMU device node
ARM: dts: r8a7743: Add PMU device node
ARM: dts: r8a7794: Add PMU device node
ARM: dts: r8a7793: Add PMU device node
ARM: dts: r8a7792: Add PMU device node
ARM: dts: r8a7791: Add PMU device node
ARM: dts: r8a7790: Add PMU device nodes
ARM: dts: r7s72100: Add PMU device node
ARM: dts: r7s72100: Correct RTC interrupt types
ARM: dts: r7s72100: Correct watchdog timer interrupt type
ARM: dts: emev2: Add missing interrupt-affinity to PMU node
ARM: dts: sh73a0: Add missing interrupt-affinity to PMU node
ARM: dts: r8a73a4: Correct mask for GIC PPI interrupts
ARM: dts: r8a7790: Correct mask for GIC PPI interrupts
ARM: shmobile: r8a7794: alt: add EEPROM to DTS
ARM: dts: kzm9d: Drop unnecessary address properties from gpio_keys node
ARM: dts: silk: Drop unnecessary address properties from vin port node
ARM: dts: alt: Drop unnecessary address properties from vin port node
...
Signed-off-by: Olof Johansson <olof@lixom.net>
* Cleanups:
- Corresct whitespace
- sort subnodes of the root and soc nodes
* R-Car M3-N (r8a77965) SoC
- Describe MSIOF SPI, PWM, SDHI and I2C devices in DT
- Add thermal support
* R-Car H3 (r8a7795) and R-Car M3-W (r8a7796) SoCs
- Decrease temperature hysteresis
Niklas Söderlund says "... decrease the hysteresis from 2C to 1C for
the two boards we have described upstream. They have no dependencies
and are ready to be accepted if the review is in favor of them."
* R-Car H3 (r8a7795), M3-W (r8a7796) and M3-N (r8a77965) SoCs
- Add address properties to rcar_sound port nodes
The rcar_sound port nodes have unit names and thus should have register
properties.
* R-Car H3 (r8a7795), M3-W (r8a7796) V3M (r8a77970) and D3 (r8a77995) SoCs
- Enable IPMMU devices
Magnus Damm says "Following the policy of using DT to describe the
hardware and not software support state, this series makes sure all
IPMMU devices are enabled in DT for SoCs such as r8a7795, r8a7796,
r8a77970 and r8a77995."
* R-Car M3-N (r8a77965) and V3H (r8a77980) SoCs
- Use sysc binding macros
These can be used now that they are present in Linus's tree.
This is a simple replacement of numeric values with symbolic ones.
- Describe USB2 and USB3 devices in DT
* R-Car V3M (r8a77970) SoC
- Add SMP Support
Geert Uytterhoeven says "This patch series enables SMP support on the
R-Car V3M SoC, by adding the second Cortex-A53 CPU core. It also adds
the performance monitor unit, and links it to both CPU cores."
- Correct IPMMU DS1 bit number
Magnus Damm says "Judging by "R-Car-Gen3-rev0.80" IPMMU IMSSTR register
documentation for [R-Car V3M] the DS1 bit field should be bit 0."
* R-Car V3H (r8a77980) SoC
- Use CPG clock binding macros
These can be used now that they are present in Linus's tree.
This is a simple replacement of numeric values with symbolic ones.
* R-Car V3H (r8a77980) and V3M (r8a77970) SoCs
- Disable EtherAVB
Sergei Shtylov says "I'm fixing the issue in the EtherAVB device nodes
in the R8A779{7|8}0 device trees that missed the "status" prop, usually
disabling the SoC devices in anticipation that the board device trees
enable the devices according to their needs. There should be no issues
with the current R8A779{7|8}0 board device trees, as all of them use
EtherAVB anyway, so I'm sending the patches generated against the
'devel' branch..."
* R-Car D3 (r8a77995) SoC
- Describe VIN4 in DT
* Ebisu board with R-Car E3 (r8a77990) SoC
- Initial support:
+ PSCI
+ CPU (single)
+ Cache controller
+ Main clocks and controller
+ Interrupt controller
+ Timer
+ PMU
+ Reset controller
+ Product register
+ System controller
+ UART for console
* Salvator-XS boards with R-Car H3 (r8a7795) SoC
- Enable USB2.0 channel 3
* Salvator-X and Salvator-XS boards with M3-N (r8a77965) SoC
- Enable DU
Kieran Bingham "This series enables the DU for the M3-N R8A77965 SoC,
and provides output on the VGA and HDMI connectors.
LVDS is not yet supported or tested."
* Salvator-X and Salvator-XS boards with
R-Car H3 (r8a7795), M3-W (r8a7796) and M3-N (r8a77965) SoCs
- Enable nable VIN, CSI-2 and ADV7482
Niklas Söderlund says "This series enable capture for H3, M3-W, M3-N
Salvator-X and Salvator-XS boards. It also adds the VIN and CSI-2 nodes
for V3M, but as the ADV7482 is on the V3M expansion boards I have
chosen not include that enablement in this series."
- Add PMIC DDR Backup Power config
Geert Uytterhoeven says " The ROHM BD9571MWV PMIC on the Renesas
Salvator-X(S) and ULCB development boards supports DDR Backup Power,
which means that the DDR power rails can be kept powered while the main
SoC is powered down.
For this to function correctly, the DDR Backup Power configuration
must be described in DT, which is the topic of this series:
- The first patch adds the missing device node for the BD9571 PMIC on
the ULCB boards,
- The last two patches add DDR Backup Mode configuration for
Salvator-X(S) and ULCB."
- Add EEPROM
Wolfram Sang says "Add the EEPROM found on Salvator-X and -XS boards
for H3, M3-W, and M3-N on the IIC_DVFS bus."
- Enable HDMI Sound
* Salvator-X and Salvator-XS boards with
R-Car H3 (r8a7795), M3-W (r8a7796) and M3-N (r8a77965) SoCs, and
Draak board with R-Car D3 (r8a77995) SoC
- Consistently name EtherAVB mdio pin group
Geert Uytterhoeven says "When initial support was added for R-Car H3,
the MDIO pin was forgotten, and the MDC pin got its own group named
"mdc". During the addition of support for R-Car M3-W, this mistake was
noticed. But as R-Car H3 and M3-W are pin compatible, and can be
mounted on the same boards, the decision was made to just add the MDIO
pin to the existing "mdc" group. Later this was extended to R-Car H3
ES2.0, and M3-N, because of pin compatibility, and to R-Car D3, in the
name of consistency among R-Car Gen3 SoCs.
However, this decision keeps on being questioned when adding new SoC
support. Hence bite the bullet and admit our mistake, and rename the
pin group from "mdc" to "mdio", like on R-Car Gen2 SoCs."
* Ebisu board with R-Car E3 (r8a77990) SoC
- Initial support: Memory, Main crystal, Serial console
- Enable Ethernet
- Revise PSCI node
Yoshihiro Shimoda says "The basic support patch 2d2dbadba421 ("arm64:
dts: renesas: Add Renesas R8A77990 SoC support") lacks the compatible
"arm,psci-1.0" in the psci node."
- Revise cache controller node
Yoshihiro Shimoda says "The cache controller node should not have
unit-addresses and reg properties."
* V3HSK board with R-Car V3H (r8a77980) SoC
- Initial board device tree
Sergei Shtylov says "Add the initial device tree for the V3H Starter
Kit board. The board has 1 debug serial port (SCIF0); include support
for it, so that the serial console can work."
- Enable PFC support and use for EtherAVB
* V3MSK board with R-Car V3M (r8a77970) SoC
- Add DU/LVDS/HDMI support
Sergei Shtylyov says "Define the V3M Starter Kit board dependent part
of the DU and LVDS device nodes. Also add the device nodes for Thine
THC63LVD1024 LVDS decoder and Analog Devices ADV7511W HDMI
transmitter..."
- Enable PFC for EtherAVB
* Condor board with R-Car V3H (r8a77980) SoC
- Enable eMMC
Sergei Shtylyov says "We're adding the R8A77980 MMC (SDHI)
device nodes and then enable eMMC support on the Condor board."
- Enable PFC support and use for EtherAVB and SCIF0
* Eagle board with R-Car V3M (r8a77970) SoC
- Enable HDMI output
* Eagle board with R-Car V3M (r8a77970) SoC and
Condor board with R-Car V3H (r8a77980) SoC
- Enable CAN-FD
Adds the CAN-FD device nodes so the DT SoC files and enables
single channel CAN-FD support in DT board files.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE4nzZofWswv9L/nKF189kaWo3T74FAlr+pZkACgkQ189kaWo3
T77FOhAAs+F25gyyQZ13/JE38Q+ku2gSrpJLwJJYjztez1EA9Jh15k7xlgU2uEaa
+YtOodVHqL85LeHp8FMyahOmG6bh+pvqXjAc47ZVDootNm+518gdPvhZ0nWbWuYu
SKskMN+W5pxkbDNUfIij3TCApAWEAQH4ExJxAMjTJc9ddTPmYKvOyWZTyQvm3qQA
XsH0uOeDCmasRiJ9rUf6nPBCS4vn7U5w8cbRYQkDymrUmpEO8f+K6nMj+2yTvJJ/
G0sA8R7Q/9ULRGs4XGadIcQ71xmwpBr13FKMC9xtlhI1NI6HIGo2RkHBRwD4mGay
PgBhAQR4oekdyEoVwKu3KlTa3Fpohu/NbiwJMTu1QCgAtdd4MCv1RXq3QZIZtTQn
V3FNVwaH2u4DaX814C2Dmj11zkcehc02uURzRU/pk5UmnIJ4utghu2RmpwO7YQX7
LqBrzRFHd+Qt03Thp/fwbsdWPYvgrRDSL5v9VV/87RD0zJ9yQR/mjr4OyI5DT6g5
bEcj535n9X3FY2SFjFWKl4BjuwOcTtiY15oFKdnFcBF2wobaiKO68YgvaYgFpHMD
T5e+bOgq2IPKW8Z6qMboyj2z9a3oHa6xkEJMEJGKxotViQQC7JUHu3/7cknUelSs
LP1cJy7IP/62Qb9lvUqJ70Py+L430cuHw6+/Ssf98sRaTx0VD2I=
=4IoI
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm64-dt-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/late
Renesas ARM64 Based SoC DT Updates for v4.18
* Cleanups:
- Correct whitespace
- sort subnodes of the root and soc nodes
* R-Car M3-N (r8a77965) SoC
- Describe MSIOF SPI, PWM, SDHI and I2C devices in DT
- Add thermal support
* R-Car H3 (r8a7795) and R-Car M3-W (r8a7796) SoCs
- Decrease temperature hysteresis
* R-Car H3 (r8a7795), M3-W (r8a7796) and M3-N (r8a77965) SoCs
- Add address properties to rcar_sound port nodes
* R-Car H3 (r8a7795), M3-W (r8a7796) V3M (r8a77970) and D3 (r8a77995) SoCs
- Enable IPMMU devices
* R-Car M3-N (r8a77965) and V3H (r8a77980) SoCs
- Use sysc binding macros
- Describe USB2 and USB3 devices in DT
* R-Car V3M (r8a77970) SoC
- Add SMP Support
- Correct IPMMU DS1 bit number
* R-Car V3H (r8a77980) SoC
- Use CPG clock binding macros
* R-Car V3H (r8a77980) and V3M (r8a77970) SoCs
- Disable EtherAVB
* R-Car D3 (r8a77995) SoC
- Describe VIN4 in DT
* Ebisu board with R-Car E3 (r8a77990) SoC
- Initial support
* Salvator-XS boards with R-Car H3 (r8a7795) SoC
- Enable USB2.0 channel 3
* Salvator-X and Salvator-XS boards with M3-N (r8a77965) SoC
- Enable DU
* Salvator-X and Salvator-XS boards with
R-Car H3 (r8a7795), M3-W (r8a7796) and M3-N (r8a77965) SoCs
- Enable nable VIN, CSI-2 and ADV7482
- Add PMIC DDR Backup Power config
- Add EEPROM
- Enable HDMI Sound
* Salvator-X and Salvator-XS boards with
R-Car H3 (r8a7795), M3-W (r8a7796) and M3-N (r8a77965) SoCs, and
Draak board with R-Car D3 (r8a77995) SoC
- Consistently name EtherAVB mdio pin group
* Ebisu board with R-Car E3 (r8a77990) SoC
- Initial support: Memory, Main crystal, Serial console
- Enable Ethernet
- Revise PSCI node
- Revise cache controller node
* V3HSK board with R-Car V3H (r8a77980) SoC
- Initial board device tree
- Enable PFC support and use for EtherAVB
* V3MSK board with R-Car V3M (r8a77970) SoC
- Add DU/LVDS/HDMI support
- Enable PFC for EtherAVB
* Condor board with R-Car V3H (r8a77980) SoC
- Enable eMMC
- Enable PFC support and use for EtherAVB and SCIF0
* Eagle board with R-Car V3M (r8a77970) SoC
- Enable HDMI output
* Eagle board with R-Car V3M (r8a77970) SoC and
Condor board with R-Car V3H (r8a77980) SoC
- Enable CAN-FD
* tag 'renesas-arm64-dt-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (102 commits)
arm64: dts: renesas: salvator-common: Add ADV7482 support
arm64: dts: renesas: salvator-common: enable VIN
arm64: dts: renesas: r8a77970: add VIN and CSI-2 nodes
arm64: dts: renesas: r8a77965: add VIN and CSI-2 nodes
arm64: dts: renesas: r8a7796: add VIN and CSI-2 nodes
arm64: dts: renesas: r8a7795-es1: add CSI-2 node
arm64: dts: renesas: r8a7795: add VIN and CSI-2 nodes
arm64: dts: renesas: r8a77965: add I2C support
arm64: dts: renesas: r8a77990: ebisu: Enable EthernetAVB
arm64: dts: renesas: r8a77990: Add EthernetAVB device nodes
arm64: dts: renesas: r8a77990: Add GPIO device nodes
arm64: dts: renesas: r8a77990: Add PFC device node
arm64: dts: renesas: initial V3HSK board device tree
arm64: dts: renesas: r8a77980: disable EtherAVB
arm64: dts: renesas: r8a77970: disable EtherAVB
arm64: dts: renesas: r8a77995: Add VIN4
arm64: dts: renesas: r8a77980: add resets property to CAN-FD node
arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node
arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
arm64: dts: renesas: r8a77965: Add SDHI device nodes
...
Signed-off-by: Olof Johansson <olof@lixom.net>
- change to phase out at24 eeprom platform data
- add a missing wakeup pin on pxa320 SoCs
-----BEGIN PGP SIGNATURE-----
iQJLBAABCAA1FiEExgkueSa0u8n4Ls+HA/Z63R24yxIFAlsIfowXHHJvYmVydC5q
YXJ6bWlrQGZyZWUuZnIACgkQA/Z63R24yxI4gQ//S6EG4IeieVD8FGt7jcqp8dW/
RDZUjK42yjTW6IRYDU5WMsTwELdYb7QwSlPe4PDxijbJC1PbeoMqLWHrZAFm+Ni5
tDiFArgEegDbJ+nHf12fBHgUrUgoRJgnOEMKC/VGbGrfmYbfooyRsDu4Rw/pfAv0
N3k+3+F27Ip7nzQmjZ0Uut+L0fibQz1Eoz49CB8xJ8mNZ79B/tsse3iXqqCksVRG
0v2rGcJherHN751R02SY3sB2vg6puIGRnUiIBzMrNNT5GgD0aW3PE5yqjm0CCk61
jTynydbrQr1A9zlAUgJqWrUKhW2Gt+C0uAGJkFh0ssRNGN6vZth8O69UaqBPXljA
deUMOLHYhp255BKfBwi3EEvCGJPw8QHj3s0sqrjjN3aeYJG5wGBSz7An1VrLyJtR
waGU3Ux6SAvwU2hVvXDAfICudBuKJcuUOblP5HZrVpRJyIQA5hrhAcMfyxU8ZCmY
nXCDNZX0LUenj5NnPXFmi4+4kg1osmDU9TGmg5Zc1AicxiUbWQ8rmUJzj4geqpG/
hOXMSr2D1wvu/bcM7cOT8WbUNBrXlLNXAfy83+CW5GSTsI1nY7i8X1c+wjbIEFd+
5OvALK9B1R4xlqIqovnoXzYbd6h8thrfrXIlHMpoG9REB9gAqQVa4jz+nrnAFnVN
s8l2UC4bpxKMnoCbzrQ=
=/4US
-----END PGP SIGNATURE-----
Merge tag 'pxa-for-4.18' of https://github.com/rjarzmik/linux into next/soc
This is is the pxa changes for v4.18 cycle :
- change to phase out at24 eeprom platform data
- add a missing wakeup pin on pxa320 SoCs
* tag 'pxa-for-4.18' of https://github.com/rjarzmik/linux:
ARM: pxa3xx: enable external wakeup pins
ARM: pxa: stargate2: use device properties for at24 eeprom
Signed-off-by: Olof Johansson <olof@lixom.net>
The register address should be the full address of the rng, not the
offset from the start of the SCU.
Fixes: 5daa8212c0 ("ARM: dts: aspeed: Describe random number device")
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Olof Johansson <olof@lixom.net>
According to the Intel Software Developers' Manual, Vol. 4, Order No.
335592, these macros have been reversed since they were added in the
initial turbostat commit. The reversed definitions were presumably
copied from turbostat.c to this file.
Fixes: 9c63a650bb ("tools/power/x86/turbostat: share kernel MSR #defines")
Signed-off-by: Matt Turner <mattst88@gmail.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Len Brown <len.brown@intel.com>
ENET "ipg" clock should be IMX7D_ENETx_IPG_ROOT_CLK
rather than IMX7D_ENET_AXI_ROOT_CLK which is for ENET bus
clock.
Based on Andy Duan's patch from the NXP kernel tree.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up the error handling a lot, as this code will never get
hit.
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim KrÄmář" <rkrcmar@redhat.com>
Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: kvmarm@lists.cs.columbia.edu
Cc: kvm@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The kvm struct has been bloating. For example, it's tens of kilo-bytes
for x86, which turns out to be a large amount of memory to allocate
contiguously via kzalloc. Thus, this patch does the following:
1. Uses architecture-specific routines to allocate the kvm struct via
vzalloc for x86.
2. Switches arm to __KVM_HAVE_ARCH_VM_ALLOC so that it can use vzalloc
when has_vhe() is true.
Other architectures continue to default to kalloc, as they have a
dependency on kalloc or have a small-enough struct kvm.
Signed-off-by: Marc Orr <marcorr@google.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
commit 1c8f422059 ("mm: change return type to vm_fault_t")
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- Lazy context-switching of FPSIMD registers on arm64
- Allow virtual redistributors to be part of two or more MMIO ranges
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAlsRY14VHG1hcmMuenlu
Z2llckBhcm0uY29tAAoJECPQ0LrRPXpDMGwP/A3FDrzGSjgC65m037/dsQj/Eniv
NkpueEVO3Z8UN44j0TNdeUzj6vQD376GVDwnW3mFlQ416A4ZwwHkk8cQhbpP2UvQ
EqKKUgujvLueZeuAwYG/DtrR9VZ6fh7QLD7Mv8DW/0AaNdBN2LyHEkW0qx7cSXqu
PijTsImj9B8TSykYc0SlJz7Q7Y5QUOYbWrJqqa1cskOdmpN2ATInnA2haXeO7j8v
lkb+WZ9R6xiJSzMCeLEzFV6tUvTiaSw5lVL64jpJhbkBNWPIVAza0erm9TSlQaTw
d3uJlAy0W9UkXSSqvbmtXvBFqCyEOzZ0hwi2MF6RoVuFt1yXwLgHGps6OUkho4Kq
pXWImaRHwxyQGrOY0qm0cxr+6TjYnjn8rIOzmzBOrKKq+aCIQ+Sl+CtNYzczQYeE
rOFBQFsMlzSRJWyabUjhBGFNfDmZZaVFKnUekEqXXETtLxzLZtx+W9i4tzoA1stv
y0+4yAjEyOQoRsAAE3GmzpDsu7Eu2sae6+lTo7DX1y+A7Wi94HKmy47sVjrS+evV
2SLyVZ4mhwMzaQ7ngrjHLD1GXDlBxxk2X+NSmBVe5z4AsuWeoqy81f0rgjyCQNxo
swEqs0k7mMDo8GQNjawwzhdDuHYm4gTX5iGs/Nxx6K4OoJ0bgv83yb/goArp+LEU
/QWT4T37A/pEEECe
=DUmC
-----END PGP SIGNATURE-----
Merge tag 'kvmarm-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/ARM updates for 4.18
- Lazy context-switching of FPSIMD registers on arm64
- Allow virtual redistributors to be part of two or more MMIO ranges
Fix the below crash on Book3E 64. pgtable_page_dtor expects struct
page *arg.
Also call the destructor on non book3s platforms correctly. This frees
up the split PTL locks correctly if we had allocated them before.
Call Trace:
.kmem_cache_free+0x9c/0x44c (unreliable)
.ptlock_free+0x1c/0x30
.tlb_remove_table+0xdc/0x224
.free_pgd_range+0x298/0x500
.shift_arg_pages+0x10c/0x1e0
.setup_arg_pages+0x200/0x25c
.load_elf_binary+0x450/0x16c8
.search_binary_handler.part.11+0x9c/0x248
.do_execveat_common.isra.13+0x868/0xc18
.run_init_process+0x34/0x4c
.try_to_run_init_process+0x1c/0x68
.kernel_init+0xdc/0x130
.ret_from_kernel_thread+0x58/0x7c
Fixes: 702346768 ("powerpc/mm/nohash: Remove pte fragment dependency from nohash")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
In commit eae5f709a4 ("powerpc: Add __printf verification to
prom_printf") __printf attribute was added to prom_printf(), which
means GCC started warning about type/format mismatches. As part of
that commit we changed some "%lx" formats to "%llx" where the type is
actually unsigned long long.
Unfortunately prom_printf() doesn't know how to print "%llx", it just
prints a literal "lx", eg:
reserved memory map:
lx - lx
lx - lx
prom_printf() also doesn't know how to print "%u" (only "%lu"), it
just prints a literal "u", eg:
Max number of cores passed to firmware: u (NR_CPUS = 2048)
Instead of:
Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
This commit adds support for the missing formatters.
Fixes: eae5f709a4 ("powerpc: Add __printf verification to prom_printf")
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Stateful CPU architecture extensions may require the signal frame
to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
However, changing this #define is an ABI break.
To allow userspace the option of determining the signal frame size
in a more forwards-compatible way, this patch adds a new auxv entry
tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
size that the process can observe during its lifetime.
If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
assume that the MINSIGSTKSZ #define is sufficient. This allows for
a consistent interface with older kernels that do not provide
AT_MINSIGSTKSZ.
The idea is that libc could expose this via sysconf() or some
similar mechanism.
There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
about userspace's own stack overheads and should not pretend to
know.
For arm64:
The primary motivation for this interface is the Scalable Vector
Extension, which can require at least 4KB or so of extra space
in the signal frame for the largest hardware implementations.
To determine the correct value, a "Christmas tree" mode (via the
add_all argument) is added to setup_sigframe_layout(), to simulate
addition of all possible records to the signal frame at maximum
possible size.
If this procedure goes wrong somehow, resulting in a stupidly large
frame layout and hence failure of sigframe_alloc() to allocate a
record to the frame, then this is indicative of a kernel bug. In
this case, we WARN() and no attempt is made to populate
AT_MINSIGSTKSZ for userspace.
For arm64 SVE:
The SVE context block in the signal frame needs to be considered
too when computing the maximum possible signal frame size.
Because the size of this block depends on the vector length, this
patch computes the size based not on the thread's current vector
length but instead on the maximum possible vector length: this
determines the maximum size of SVE context block that can be
observed in any signal frame for the lifetime of the process.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Now that the kernel SVE support is reasonably mature, it is
excessive to default sve_max_vl to the invalid value -1 and then
sprinkle WARN_ON()s around the place to make sure it has been
initialised before use. The cpufeatures code already runs pretty
early, and will ensure sve_max_vl gets initialised.
This patch initialises sve_max_vl to something sane that will be
supported by every SVE implementation, and removes most of the
sanity checks.
The checks in find_supported_vector_length() are retained for now.
If anything goes horribly wrong, we are likely to trip a check here
sooner or later.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The powerpc toolchain can compile combinations of 32/64 bit and
big/little endian, so it's convenient to consider, e.g.,
`CC -m64 -mbig-endian`
To be the C compiler for the purpose of invoking it to build target
artifacts. So overriding the CC variable to include these flags works
for this purpose.
Unfortunately that is not compatible with the way the proposed new
Kconfig macro language will work.
After previous patches in this series, these flags can be carefully
passed in using flags instead.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Switch VDSO32 build over to use CROSS32_COMPILE directly, and have
it pass in -m32 after the standard c_flags. This allows endianness
overrides to be removed and the endian and bitness flags moved into
standard flags variables.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Some 64-bit toolchains uses the wrong ISA variant for compiling 32-bit
kernels, even with -m32. Debian's powerpc64le is one such case, and
that is because it is built with --with-cpu=power8.
So when cross compiling a 32-bit kernel with a 64-bit toolchain, set
-mcpu=powerpc initially, which is the generic 32-bit powerpc machine
type and scheduling model. CPU and platform code can override this
with subsequent -mcpu flags if necessary.
This is not done for 32-bit toolchains otherwise it would override
their defaults, which are presumably set appropriately for the
environment (moreso than a 64-bit cross compiler).
This fixes a lot of build failures due to incompatible assembly when
compiling 32-bit kernel with the Debian powerpc64le 64-bit toolchain.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
By default, sparse assumes a 64bit machine when compiled on x86-64
and 32bit when compiled on anything else.
This can of course create all sort of problems for the other archs, like
issuing false warnings ('shift too big (32) for type unsigned long'), or
worse, failing to emit legitimate warnings.
Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
to CHECKFLAGS in the main Makefile (and so for all archs).
Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
We need to migrate PR KVM during transaction and userspace will use
kvmppc_get_one_reg_pr()/kvmppc_set_one_reg_pr() APIs to get/set
transaction checkpoint state. This patch adds support for that.
So far, QEMU on PR KVM doesn't fully function for migration but the
savevm/loadvm can be done against a RHEL72 guest. During savevm/
loadvm procedure, the kvm ioctls will be invoked as well.
Test has been performed to savevm/loadvm for a guest running
a HTM test program:
https://github.com/justdoitqd/publicFiles/blob/master/test-tm-mig.c
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
In both HV and PR KVM, the KVM_SET_REGS/KVM_GET_REGS ioctl should
be able to perform without the vcpu loaded.
Since the vcpu mutex locking/unlock has been moved out of vcpu_load()
/vcpu_put(), KVM_SET_REGS/KVM_GET_REGS don't need to do ioctl with
the vcpu loaded anymore. This patch removes vcpu_load()/vcpu_put()
from KVM_SET_REGS/KVM_GET_REGS ioctl.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Since the vcpu mutex locking/unlock has been moved out of vcpu_load()
/vcpu_put(), KVM_GET_ONE_REG and KVM_SET_ONE_REG doesn't need to do
ioctl with loading vcpu anymore. This patch removes vcpu_load()/vcpu_put()
from KVM_GET_ONE_REG and KVM_SET_ONE_REG ioctl.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Although we already have kvm_arch_vcpu_async_ioctl() which doesn't require
ioctl to load vcpu, the sync ioctl code need to be cleaned up when
CONFIG_HAVE_KVM_VCPU_ASYNC_IOCTL is not configured.
This patch moves vcpu_load/vcpu_put down to each ioctl switch case so that
each ioctl can decide to do vcpu_load/vcpu_put or not independently.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Currently guest kernel doesn't handle TAR facility unavailable and it
always runs with TAR bit on. PR KVM will lazily enable TAR. TAR is not
a frequent-use register and it is not included in SVCPU struct.
Due to the above, the checkpointed TAR val might be a bogus TAR val.
To solve this issue, we will make vcpu->arch.fscr tar bit consistent
with shadow_fscr when TM is enabled.
At the end of emulating treclaim., the correct TAR val need to be loaded
into the register if FSCR_TAR bit is on.
At the beginning of emulating trechkpt., TAR needs to be flushed so that
the right tar val can be copied into tar_tm.
Tested with:
tools/testing/selftests/powerpc/tm/tm-tar
tools/testing/selftests/powerpc/ptrace/ptrace-tm-tar (remove DSCR/PPR
related testing).
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Currently PR KVM doesn't support transaction memory in guest privileged
state.
This patch adds a check at setting guest msr, so that we can never return
to guest with PR=0 and TS=0b10. A tabort will be emulated to indicate
this and fail transaction immediately.
[paulus@ozlabs.org - don't change the TM_CAUSE_MISC definition, instead
use TM_CAUSE_KVM_FAC_UNAV.]
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Currently privileged-state guest will be run with TM disabled.
Although the privileged-state guest cannot initiate a new transaction,
it can use tabort to terminate its problem state's transaction.
So it is still necessary to emulate tabort. for privileged-state guest.
Tested with:
https://github.com/justdoitqd/publicFiles/blob/master/test_tabort.c
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This patch adds host emulation when guest PR KVM executes "trechkpt.",
which is a privileged instruction and will trap into host.
We firstly copy vcpu ongoing content into vcpu tm checkpoint
content, then perform kvmppc_restore_tm_pr() to do trechkpt.
with updated vcpu tm checkpoint values.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This patch adds support for "treclaim." emulation when PR KVM guest
executes treclaim. and traps to host.
We will firstly do treclaim. and save TM checkpoint. Then it is
necessary to update vcpu current reg content with checkpointed vals.
When rfid into guest again, those vcpu current reg content (now the
checkpoint vals) will be loaded into regs.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Currently kvmppc_handle_fac() will not update NV GPRs and thus it can
return with GUEST_RESUME.
However PR KVM guest always disables MSR_TM bit in privileged state.
If PR privileged-state guest is trying to read TM SPRs, it will
trigger TM facility unavailable exception and fall into
kvmppc_handle_fac(). Then the emulation will be done by
kvmppc_core_emulate_mfspr_pr(). The mfspr instruction can include a
RT with NV reg. So it is necessary to restore NV GPRs at this case, to
reflect the update to NV RT.
This patch make kvmppc_handle_fac() return GUEST_RESUME_NV for TM
facility unavailable exceptions in guest privileged state.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Reviewed-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Currently the kernel doesn't use transaction memory.
And there is an issue for privileged state in the guest that:
tbegin/tsuspend/tresume/tabort TM instructions can impact MSR TM bits
without trapping into the PR host. So following code will lead to a
false mfmsr result:
tbegin <- MSR bits update to Transaction active.
beq <- failover handler branch
mfmsr <- still read MSR bits from magic page with
transaction inactive.
It is not an issue for non-privileged guest state since its mfmsr is
not patched with magic page and will always trap into the PR host.
This patch will always fail tbegin attempt for privileged state in the
guest, so that the above issue is prevented. It is benign since
currently (guest) kernel doesn't initiate a transaction.
Test case:
https://github.com/justdoitqd/publicFiles/blob/master/test_tbegin_pr.c
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The mfspr/mtspr on TM SPRs(TEXASR/TFIAR/TFHAR) are non-privileged
instructions and can be executed by PR KVM guest in problem state
without trapping into the host. We only emulate mtspr/mfspr
texasr/tfiar/tfhar in guest PR=0 state.
When we are emulating mtspr tm sprs in guest PR=0 state, the emulation
result needs to be visible to guest PR=1 state. That is, the actual TM
SPR val should be loaded into actual registers.
We already flush TM SPRs into vcpu when switching out of CPU, and load
TM SPRs when switching back.
This patch corrects mfspr()/mtspr() emulation for TM SPRs to make the
actual source/dest be the actual TM SPRs.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The math registers will be saved into vcpu->arch.fp/vr and corresponding
vcpu->arch.fp_tm/vr_tm area.
We flush or giveup the math regs into vcpu->arch.fp/vr before saving
transaction. After transaction is restored, the math regs will be loaded
back into regs.
If there is a FP/VEC/VSX unavailable exception during transaction active
state, the math checkpoint content might be incorrect and we need to do
treclaim./load the correct checkpoint val/trechkpt. sequence to retry the
transaction. That will make our solution complicated. To solve this issue,
we always make the hardware guest MSR math bits (shadow_msr) consistent
with the MSR val which guest sees (kvmppc_get_msr()) when guest msr is
with tm enabled. Then all FP/VEC/VSX unavailable exception can be delivered
to guest and guest handles the exception by itself.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The transaction memory checkpoint area save/restore behavior is
triggered when VCPU qemu process is switching out/into CPU, i.e.
at kvmppc_core_vcpu_put_pr() and kvmppc_core_vcpu_load_pr().
MSR TM active state is determined by TS bits:
active: 10(transactional) or 01 (suspended)
inactive: 00 (non-transactional)
We don't "fake" TM functionality for guest. We "sync" guest virtual
MSR TM active state(10 or 01) with shadow MSR. That is to say,
we don't emulate a transactional guest with a TM inactive MSR.
TM SPR support(TFIAR/TFAR/TEXASR) has already been supported by
commit 9916d57e64 ("KVM: PPC: Book3S PR: Expose TM registers").
Math register support (FPR/VMX/VSX) will be done at subsequent
patch.
Whether TM context need to be saved/restored can be determined
by kvmppc_get_msr() TM active state:
* TM active - save/restore TM context
* TM inactive - no need to do so and only save/restore
TM SPRs.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Suggested-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This patch adds 2 new APIs, kvmppc_save_tm_sprs() and
kvmppc_restore_tm_sprs(), for the purpose of TEXASR/TFIAR/TFHAR
save/restore.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This patch adds 2 new APIs: kvmppc_copyto_vcpu_tm() and
kvmppc_copyfrom_vcpu_tm(). These 2 APIs will be used to copy from/to TM
data between VCPU_TM/VCPU area.
PR KVM will use these APIs for treclaim. or trechkpt. emulation.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
PR KVM host usually runs with TM enabled in its host MSR value, and
with non-transactional TS value.
When a guest with TM active traps into PR KVM host, the rfid at the
tail of kvmppc_interrupt_pr() will try to switch TS bits from
S0 (Suspended & TM disabled) to N1 (Non-transactional & TM enabled).
That will leads to TM Bad Thing interrupt.
This patch manually sets target TS bits unchanged to avoid this
exception.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
According to ISA specification for RFID, in MSR TM disabled and TS
suspended state (S0), if the target MSR is TM disabled and TS state is
inactive (N0), rfid should suppress this update.
This patch makes the RFID emulation of PR KVM consistent with this.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
MSR TS bits can be modified with non-privileged instruction such as
tbegin./tend. That means guest can change MSR value "silently" without
notifying host.
It is necessary to sync the TM bits to host so that host can calculate
shadow msr correctly.
Note, privileged mode in the guest will always fail transactions so we
only take care of problem state mode in the guest.
The logic is put into kvmppc_copy_from_svcpu() so that
kvmppc_handle_exit_pr() can use correct MSR TM bits even when preemption
occurs.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
PowerPC TM functionality needs MSR TM/TS bits support in hardware level.
Guest TM functionality can not be emulated with "fake" MSR (msr in magic
page) TS bits.
This patch syncs TM/TS bits in shadow_msr with the MSR value in magic
page, so that the MSR TS value which guest sees is consistent with actual
MSR bits running in guest.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This patch simulates interrupt behavior per Power ISA while injecting
interrupt in PR KVM:
- When interrupt happens, transactional state should be suspended.
kvmppc_mmu_book3s_64_reset_msr() will be invoked when injecting an
interrupt. This patch performs this ISA logic in
kvmppc_mmu_book3s_64_reset_msr().
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Currently __kvmppc_save/restore_tm() APIs can only be invoked from
assembly function. This patch adds C function wrappers for them so
that they can be safely called from C function.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
kvmppc_save_tm() invokes store_fp_state/store_vr_state(). So it is
mandatory to turn on FP/VSX/VMX MSR bits for its execution, just
like what kvmppc_restore_tm() did.
Previously HV KVM has turned the bits on outside of function
kvmppc_save_tm(). Now we include this bit change in kvmppc_save_tm()
so that the logic is cleaner. And PR KVM can reuse it later.
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Reviewed-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
HV KVM and PR KVM need different MSR source to indicate whether
treclaim. or trecheckpoint. is necessary.
This patch add new parameter (guest MSR) for these kvmppc_save_tm/
kvmppc_restore_tm() APIs:
- For HV KVM, it is VCPU_MSR
- For PR KVM, it is current host MSR or VCPU_SHADOW_SRR1
This enhancement enables these 2 APIs to be reused by PR KVM later.
And the patch keeps HV KVM logic unchanged.
This patch also reworks kvmppc_save_tm()/kvmppc_restore_tm() to
have a clean ABI: r3 for vcpu and r4 for guest_msr.
During kvmppc_save_tm/kvmppc_restore_tm(), the R1 need to be saved
or restored. Currently the R1 is saved into HSTATE_HOST_R1. In PR
KVM, we are going to add a C function wrapper for
kvmppc_save_tm/kvmppc_restore_tm() where the R1 will be incremented
with added stackframe and save into HSTATE_HOST_R1. There are several
places in HV KVM to load HSTATE_HOST_R1 as R1, and we don't want to
bring risk or confusion by TM code.
This patch will use HSTATE_SCRATCH2 to save/restore R1 in
kvmppc_save_tm/kvmppc_restore_tm() to avoid future confusion, since
the r1 is actually a temporary/scratch value to be saved/stored.
[paulus@ozlabs.org - rebased on top of 7b0e827c69 ("KVM: PPC: Book3S HV:
Factor fake-suspend handling out of kvmppc_save/restore_tm", 2018-05-30)]
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Prevent speculation at the syscall table decoding by clamping the index
used to zero on invalid system call numbers, and using the csdb
speculative barrier.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Add an implementation of the array_index_mask_nospec() function for
mitigating Spectre variant 1 throughout the kernel.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Add assembly and C macros for the new CSDB instruction.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Now that all our infrastructure is in place, let's expose the
availability of ARCH_WORKAROUND_2 to guests. We take this opportunity
to tidy up a couple of SMCCC constants.
Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
In order to forward the guest's ARCH_WORKAROUND_2 calls to EL3,
add a small(-ish) sequence to handle it at EL2. Special care must
be taken to track the state of the guest itself by updating the
workaround flags. We also rely on patching to enable calls into
the firmware.
Note that since we need to execute branches, this always executes
after the Spectre-v2 mitigation has been applied.
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
In order to offer ARCH_WORKAROUND_2 support to guests, we need
a bit of infrastructure.
Let's add a flag indicating whether or not the guest uses
SSBD mitigation. Depending on the state of this flag, allow
KVM to disable ARCH_WORKAROUND_2 before entering the guest,
and enable it when exiting it.
Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
As we're going to require to access per-cpu variables at EL2,
let's craft the minimum set of accessors required to implement
reading a per-cpu variable, relying on tpidr_el2 to contain the
per-cpu offset.
Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
If running on a system that performs dynamic SSBD mitigation, allow
userspace to request the mitigation for itself. This is implemented
as a prctl call, allowing the mitigation to be enabled or disabled at
will for this particular thread.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
In order to allow userspace to be mitigated on demand, let's
introduce a new thread flag that prevents the mitigation from
being turned off when exiting to userspace, and doesn't turn
it on on entry into the kernel (with the assumption that the
mitigation is always enabled in the kernel itself).
This will be used by a prctl interface introduced in a later
patch.
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
On a system where firmware can dynamically change the state of the
mitigation, the CPU will always come up with the mitigation enabled,
including when coming back from suspend.
If the user has requested "no mitigation" via a command line option,
let's enforce it by calling into the firmware again to disable it.
Similarily, for a resume from hibernate, the mitigation could have
been disabled by the boot kernel. Let's ensure that it is set
back on in that case.
Acked-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
In order to avoid checking arm64_ssbd_callback_required on each
kernel entry/exit even if no mitigation is required, let's
add yet another alternative that by default jumps over the mitigation,
and that gets nop'ed out if we're doing dynamic mitigation.
Think of it as a poor man's static key...
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
We're about to need the mitigation state in various parts of the
kernel in order to do the right thing for userspace and guests.
Let's expose an accessor that will let other subsystems know
about the state.
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
On a system where the firmware implements ARCH_WORKAROUND_2,
it may be useful to either permanently enable or disable the
workaround for cases where the user decides that they'd rather
not get a trap overhead, and keep the mitigation permanently
on or off instead of switching it on exception entry/exit.
In any case, default to the mitigation being enabled.
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
As for Spectre variant-2, we rely on SMCCC 1.1 to provide the
discovery mechanism for detecting the SSBD mitigation.
A new capability is also allocated for that purpose, and a
config option.
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
In a heterogeneous system, we can end up with both affected and
unaffected CPUs. Let's check their status before calling into the
firmware.
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
In order for the kernel to protect itself, let's call the SSBD mitigation
implemented by the higher exception level (either hypervisor or firmware)
on each transition between userspace and kernel.
We must take the PSCI conduit into account in order to target the
right exception level, hence the introduction of a runtime patching
callback.
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The counters in client IMC uncore are free running counters, not fixed
counters. It should be corrected. The new infrastructure for free
running counter should be applied.
Introducing a new type SNB_PCI_UNCORE_IMC_DATA for client IMC free
running counters.
Keeping the customized event_init() function to be compatible with old
event encoding.
Clean up other customized event_*() functions.
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: acme@kernel.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1525371913-10597-8-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Some uncores have customized PMU. For customized PMU, it does not need
to customize everything. For example, it only needs to customize init()
function for client IMC uncore. Other functions like
add()/del()/start()/stop()/read() can use generic code.
Expose the uncore_pmu_event_add/del/start/stop() functions.
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: acme@kernel.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1525371913-10597-7-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
As of Skylake Server, there are a number of free running counters in
each IIO Box that collect counts of per-box IO clocks and per-port
Input/Output x BW/Utilization.
The free running counters cannot be part of the existing IIO BOX,
because, quoting from Peter Zijlstra:
"This will result in some (probably) unexpected scheduling artifacts.
Probably the only way to really cure that is to have the free running
counters in their own PMU and not share with the GP counters of this
box."
So let's add a new PMU for the free running counters, as suggested.
The free-running counter is read-only and always active. Counting will
be suspended only when the IIO Box is powered down.
There are three types of IIO free-running counters on Skylake server, IO
CLOCKS counter, BANDWIDTH counters and UTILIZATION counters.
IO CLOCKS counter is a clock of IIO box.
BANDWIDTH counters are to count inbound(PCIe->CPU)/outbound(CPU->PCIe)
bandwidth.
UTILIZATION counters are to count input/output utilization.
The bit width of the free-running counters is 36-bits.
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: acme@kernel.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1525371913-10597-6-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There are a number of free running counters introduced for uncore, which
provide highly valuable information to a wide array of customers.
However, the generic uncore code doesn't support them yet.
The free running counters will be specially handled based on their
unique attributes:
- They are read-only. They cannot be enabled/disabled.
- The event and the counter are always 1:1 mapped. It doesn't need to
be assigned nor tracked by event_list.
- They are always active. It doesn't need to check the availability.
- They have different bit width.
Also, using inline helpers to replace the check for fixed counter and
free running counter.
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: acme@kernel.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1525371913-10597-5-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There are a number of free running counters introduced for uncore, which
provide highly valuable information to a wide array of customers.
For example, Skylake Server has IIO free running counters to collect
Input/Output x BW/Utilization.
There is NO event available on the general purpose counters, that is
exactly the same as the free running counters. The generic uncore code
needs to be enhanced to support the new counters.
In the uncore document, there is no event-code assigned to free running
counters. Some events need to be defined to indicate the free running
counters. The events are encoded as event-code + umask-code.
The event-code for all free running counters is 0xff, which is the same
as the fixed counters:
- It has not been decided what code will be used for common events on
future platforms. 0xff is the only one which will definitely not be
used as any common event-code.
- Cannot re-use current events on the general purpose counters. Because
there is NO event available, that is exactly the same as the free
running counters.
- Even in the existing codes, the fixed counters for core, that have the
same event-code, may count different things. Hence, it should not
surprise the users if the free running counters that share the same
event-code also count different things.
Umask will be used to distinguish the counters.
The umask-code is used to distinguish a fixed counter and a free running
counter, and different types of free running counters.
For fixed counters, the umask-code is 0x0X, where X indicates the index
of the fixed counter, which starts from 0.
- Compatible with the old event encoding.
- Currently, there is only one fixed counter. There are still 15
reserved spaces for extension.
For free running counters, the umask-code uses the rest of the space.
It would follow the format of 0xXY:
- X stands for the type of free running counters, which starts from 1.
- Y stands for the index of free running counters of same type, which
starts from 0.
- The free running counters do different thing. It can be categorized to
several types, according to the MSR location, bit width and
definition. E.g. there are three types of IIO free running counters on
Skylake server to monitor IO CLOCKS, BANDWIDTH and UTILIZATION on
different ports. It makes it easy to locate the free running counter
of a specific type.
- So far, there are at most 8 counters of each type. There are still 8
reserved spaces for extension.
Introducing a new index to indicate the free running counters. Only one
index is enough for all free running counters. Because the free running
counters are always active, and the event and free running counter are
always 1:1 mapped, it does not need extra index to indicate the assigned
counter.
Introducing a new data structure to store free running counters related
information for each type. It includes the number of counters, bit
width, base address, offset between counters and offset between boxes.
Introducing several inline helpers to check index for fixed counter and
free running counter, validate free running counter event, and retrieve
the free running counter information according to box and event.
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: acme@kernel.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1525371913-10597-4-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There is no index which is bigger than UNCORE_PMC_IDX_FIXED. The only
exception is client IMC uncore, which has been specially handled.
For generic code, it is not correct to use >= to check fixed counter.
The code quality issue will bring problem when a new counter index is
introduced.
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: acme@kernel.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1525371913-10597-3-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
For Nehalem and Westmere, there is only one fixed counter for W-Box.
There is no index which is bigger than UNCORE_PMC_IDX_FIXED.
It is not correct to use >= to check fixed counter.
The code quality issue will bring problem when new counter index is
introduced.
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: acme@kernel.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1525371913-10597-2-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There are two free-running counters for client IMC uncore. The
customized event_init() function hard codes their index to
'UNCORE_PMC_IDX_FIXED' and 'UNCORE_PMC_IDX_FIXED + 1'.
To support the index 'UNCORE_PMC_IDX_FIXED + 1', the generic
uncore_perf_event_update is obscurely hacked.
The code quality issue will bring problems when a new counter index is
introduced into the generic code, for example, a new index for
free-running counter.
Introducing a customized event_read() function for client IMC uncore.
The customized function is copied from previous generic
uncore_pmu_event_read().
The index 'UNCORE_PMC_IDX_FIXED + 1' will be isolated for client IMC
uncore only.
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: acme@kernel.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1525371913-10597-1-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The reference to camera_supply_gpiod_table was added in the wrong function,
as observed from this randconfig build failure:
arch/arm/mach-pxa/ezx.c: In function 'e680_init':
arch/arm/mach-pxa/ezx.c:905:26: error: 'camera_supply_gpiod_table' undeclared (first use in this function)
gpiod_add_lookup_table(&camera_supply_gpiod_table);
Fixes: 6059577cb2 ("regulator: fixed: Convert to use GPIO descriptor only")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Report support for SMCCC_ARCH_WORKAROUND_1 to KVM guests for affected
CPUs.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
We want SMCCC_ARCH_WORKAROUND_1 to be fast. As fast as possible.
So let's intercept it as early as we can by testing for the
function call number as soon as we've identified a HVC call
coming from the guest.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Include Brahma B15 in the Spectre v2 KVM workarounds.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
In order to avoid aliasing attacks against the branch predictor
on Cortex-A15, let's invalidate the BTB on guest exit, which can
only be done by invalidating the icache (with ACTLR[0] being set).
We use the same hack as for A12/A17 to perform the vector decoding.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
In order to avoid aliasing attacks against the branch predictor,
let's invalidate the BTB on guest exit. This is made complicated
by the fact that we cannot take a branch before invalidating the
BTB.
We only apply this to A12 and A17, which are the only two ARM
cores on which this useful.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Warn at error level if the context switching function is not what we
are expecting. This can happen with big.Little systems, which we
currently do not support.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Add firmware based hardening for cores that require more complex
handling in firmware.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
In order to prevent aliasing attacks on the branch predictor,
invalidate the BTB or instruction cache on CPUs that are known to be
affected when taking an abort on a address that is outside of a user
task limit:
Cortex A8, A9, A12, A17, A73, A75: flush BTB.
Cortex A15, Brahma B15: invalidate icache.
If the IBE bit is not set, then there is little point to enabling the
workaround.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
When the branch predictor hardening is enabled, firmware must have set
the IBE bit in the auxiliary control register. If this bit has not
been set, the Spectre workarounds will not be functional.
Add validation that this bit is set, and print a warning at alert level
if this is not the case.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Harden the branch predictor against Spectre v2 attacks on context
switches for ARMv7 and later CPUs. We do this by:
Cortex A9, A12, A17, A73, A75: invalidating the BTB.
Cortex A15, Brahma B15: invalidating the instruction cache.
Cortex A57 and Cortex A72 are not addressed in this patch.
Cortex R7 and Cortex R8 are also not addressed as we do not enforce
memory protection on these cores.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Add a Kconfig symbol for CPUs which are vulnerable to the Spectre
attacks.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Add support for per-processor bug checking - each processor function
descriptor gains a function pointer for this check, which must not be
an __init function. If non-NULL, this will be called whenever a CPU
enters the kernel via which ever path (boot CPU, secondary CPU startup,
CPU resuming, etc.)
This allows processor specific bug checks to validate that workaround
bits are properly enabled by firmware via all entry paths to the kernel.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Check for CPU bugs when secondary processors are being brought online,
and also when CPUs are resuming from a low power mode. This gives an
opportunity to check that processor specific bug workarounds are
correctly enabled for all paths that a CPU re-enters the kernel.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Prepare the processor bug infrastructure so that it can be expanded to
check for per-processor bugs.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Add CPU part numbers for Cortex A53, A57, A72, A73, A75 and the
Broadcom Brahma B15 CPU.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
This avoids a WARNING splat when loading the macsonic or macmace driver.
Please see commit 205e1b7f51 ("dma-mapping: warn when there is no
coherent_dma_mask").
This implementation of arch_setup_pdev_archdata() differs from the
powerpc one, in that this one avoids clobbering a device dma mask
which has already been initialized.
Cc: Christoph Hellwig <hch@lst.de>
Cc: Greg Ungerer <gerg@linux-m68k.org>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Acked-by: Greg Ungerer <gerg@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
It is a simple patch just for moving kvmppc_save_tm/kvmppc_restore_tm()
functionalities to tm.S. There is no logic change. The reconstruct of
those APIs will be done in later patches to improve readability.
It is for preparation of reusing those APIs on both HV/PR PPC KVM.
Some slight change during move the functions includes:
- surrounds some HV KVM specific code with CONFIG_KVM_BOOK3S_HV_POSSIBLE
for compilation.
- use _GLOBAL() to define kvmppc_save_tm/kvmppc_restore_tm()
[paulus@ozlabs.org - rebased on top of 7b0e827c69 ("KVM: PPC: Book3S HV:
Factor fake-suspend handling out of kvmppc_save/restore_tm", 2018-05-30)]
Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This merges in the ppc-kvm topic branch of the powerpc repository
to get some changes on which future patches will depend, in particular
some new exports and TEXASR bit definitions.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This splits out the handling of "fake suspend" mode, part of the
hypervisor TM assist code for POWER9, and puts almost all of it in
new kvmppc_save_tm_hv and kvmppc_restore_tm_hv functions. The new
functions branch to kvmppc_save/restore_tm if the CPU does not
require hypervisor TM assistance.
With this, it will be more straightforward to move kvmppc_save_tm and
kvmppc_restore_tm to another file and use them for transactional
memory support in PR KVM. Additionally, it also makes the code a
bit clearer and reduces the number of feature sections.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Currently, PR KVM does not implement the configure_mmu operation, and
so the KVM_PPC_CONFIGURE_V3_MMU ioctl always fails with an EINVAL
error. This causes recent kernels to fail to boot as a PR KVM guest
on POWER9, since recent kernels booted in HPT mode do the
H_REGISTER_PROC_TBL hypercall, which causes userspace (QEMU) to do
KVM_PPC_CONFIGURE_V3_MMU, which fails.
This implements a minimal configure_mmu operation for PR KVM. It
succeeds only if the MMU is being configured for HPT mode and no
process table is being registered. This is enough to get recent
kernels to boot as a PR KVM guest.
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The x86 assembly implementations of Salsa20 use the frame base pointer
register (%ebp or %rbp), which breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Recent (v4.10+) kernels will warn about this, e.g.
WARNING: kernel stack regs at 00000000a8291e69 in syzkaller047086:4677 has bad 'bp' value 000000001077994c
[...]
But after looking into it, I believe there's very little reason to still
retain the x86 Salsa20 code. First, these are *not* vectorized
(SSE2/SSSE3/AVX2) implementations, which would be needed to get anywhere
close to the best Salsa20 performance on any remotely modern x86
processor; they're just regular x86 assembly. Second, it's still
unclear that anyone is actually using the kernel's Salsa20 at all,
especially given that now ChaCha20 is supported too, and with much more
efficient SSSE3 and AVX2 implementations. Finally, in benchmarks I did
on both Intel and AMD processors with both gcc 8.1.0 and gcc 4.9.4, the
x86_64 salsa20-asm is actually slightly *slower* than salsa20-generic
(~3% slower on Skylake, ~10% slower on Zen), while the i686 salsa20-asm
is only slightly faster than salsa20-generic (~15% faster on Skylake,
~20% faster on Zen). The gcc version made little difference.
So, the x86_64 salsa20-asm is pretty clearly useless. That leaves just
the i686 salsa20-asm, which based on my tests provides a 15-20% speed
boost. But that's without updating the code to not use %ebp. And given
the maintenance cost, the small speed difference vs. salsa20-generic,
the fact that few people still use i686 kernels, the doubt that anyone
is even using the kernel's Salsa20 at all, and the fact that a SSE2
implementation would almost certainly be much faster on any remotely
modern x86 processor yet no one has cared enough to add one yet, I don't
think it's worthwhile to keep.
Thus, just remove both the x86_64 and i686 salsa20-asm implementations.
Reported-by: syzbot+ffa3a158337bbc01ff09@syzkaller.appspotmail.com
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Several source files have been taken from OpenSSL. In some of them a
comment that "permission to use under GPL terms is granted" was
included below a contradictory license statement. In several cases,
there was no indication that the license of the code was compatible
with the GPLv2.
This change clarifies the licensing for all of these files. I've
confirmed with the author (Andy Polyakov) that a) he has licensed the
files with the GPLv2 comment under that license and b) that he's also
happy to license the other files under GPLv2 too. In one case, the
file is already contained in his CRYPTOGAMS bundle, which has a GPLv2
option, and so no special measures are needed.
In all cases, the license status of code has been clarified by making
the GPLv2 license prominent.
The .S files have been regenerated from the updated .pl files.
This is a comment-only change. No code is changed.
Signed-off-by: Adam Langley <agl@chromium.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Commit 56e8e57fc3 ("crypto: morus - Add common SIMD glue code for
MORUS") accidetally consiedered the glue code to be usable by different
architectures, but it seems to be only usable on x86.
This patch moves it under arch/x86/crypto and adds 'depends on X86' to
the Kconfig options and also removes the prompt to hide these internal
options from the user.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Ondrej Mosnacek <omosnacek@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Pull s390 fixes from Martin Schwidefsky:
- a missing -msoft-float for the compile of the kexec purgatory
- a fix for the dasd driver to avoid the double use of a field in the
'struct request'
[ That latter one is being discussed, and Christoph asked for something
cleaner, but for now it's a fix ]
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/dasd: use blk_mq_rq_from_pdu for per request data
s390/purgatory: Fix endless interrupt loop
This reverts commit 3c6b38d45f "regulator: wm8994: Pass
descriptor instead of GPIO number" as it has problems with shared
GPIOs similar to that on s2mps11.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The arch_get_random_seed_long() invocation done by the random device
driver is done in interrupt context and may be invoked very very
frequently. The existing s390 arch_get_random_seed*() implementation
uses the PRNO(TRNG) instruction which produces excellent high quality
entropy but is relatively slow and thus expensive.
This fix reworks the arch_get_random_seed* implementation. It
introduces a buffer concept to decouple the delivery of random data
via arch_get_random_seed*() from the generation of new random
bytes. The buffer of random data is filled asynchronously by a
workqueue thread.
If there are enough bytes in the buffer the s390_arch_random_generate()
just delivers these bytes. Otherwise false is returned until the worker
thread refills the buffer.
The worker fills the rng buffer by pulling fresh entropy from the
high quality (but slow) true hardware random generator. This entropy
is then spread over the buffer with an pseudo random generator.
As the arch_get_random_seed_long() fetches 8 bytes and the calling
function add_interrupt_randomness() counts this as 1 bit entropy the
distribution needs to make sure there is in fact 1 bit entropy
contained in 8 bytes of the buffer. The current values pull 32 byte
entropy and scatter this into a 2048 byte buffer. So 8 byte in the
buffer will contain 1 bit of entropy.
The worker thread is rescheduled based on the charge level of the
buffer but at least with 500 ms delay to avoid too much cpu consumption.
So the max. amount of rng data delivered via arch_get_random_seed is
limited to 4Kb per second.
Signed-off-by: Harald Freudenberger <freude@de.ibm.com>
Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390 hardware supports the definition of a so-call Physical NETwork
IDentifier (short PNETID) per network device port. These PNETIDS
can be used to identify network devices that are attached to the same
physical network (broadcast domain).
This patch provides the interface to extract the PNETID of a port of
a device attached to the ccw-bus or pci-bus.
Parts of this patch are based on an initial implementation by
Thomas Richter.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Pull RCU fix from Paul E. McKenney:
"This additional v4.18 pull request contains a single commit that fell
through the cracks:
Provide early rcu_cpu_starting() callback for the benefit of the
x86/mtrr code, which needs RCU to be available on incoming CPUs
earlier than has been the case in the past."
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Now that the ARM CCI PMU driver can be built as a loadable module,
we get a link failure when MCPM is enabled:
ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
The simplest fix is to export that helper function.
Fixes: 8b0c93c20e ("perf/arm-cci: Allow building as a module")
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Geert Uytterhoeven <geert@linux-m68k.org> reported:
> HOSTLD scripts/mod/modpost
> CC arch/sh/kernel/traps_32.o
> arch/sh/kernel/traps_32.c: In function 'do_divide_error':
> arch/sh/kernel/traps_32.c:606:17: error: 'code' may be used uninitialized in this function [-Werror=uninitialized]
> cc1: all warnings being treated as errors
It is clear from inspection that do_divide_error is only called with
TRAP_DIVZERO_ERROR or TRAP_DIVOVF_ERROR, as that is the way
set_exception_table_vec is called. So let gcc know the other cases
should not be considered by returning in all other cases.
This removes the warning and let's the code continue to build.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes: c65626c0cd ("signal/sh: Use force_sig_fault where appropriate")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
We augment the GPIO regulator to get the *enable* regulator
GPIO line (not the other lines) using a descriptor rather than
a global number.
We then pass this into the regulator core which has been
prepared to hande enable descriptors in a separate patch.
Switch over the two boardfiles using this facility and clean
up so we only pass descriptors around.
Cc: Philipp Zabel <philipp.zabel@gmail.com> # HX4700/Magician maintainer
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
As we augmented the regulator core to accept a GPIO descriptor instead
of a GPIO number, we can augment the fixed GPIO regulator to look up
and pass that descriptor directly from device tree or board GPIO
descriptor look up tables.
Some boards just auto-enumerate their fixed regulator platform devices
and I have assumed they get names like "fixed-regulator.0" but it's
pretty hard to guess this. I need some testing from board maintainers to
be sure. Other boards are straight forward, using just plain
"fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the
device ID.
The OMAP didn't have proper label names on its GPIO chips so I have fixed
this with a separate patch to the GPIO tree, see
commit 088413bc0b
"gpio: omap: Give unique labels to each GPIO bank/chip"
It seems the da9055 and da9211 has never got around to actually passing
any enable gpio into its platform data (not the in-tree code anyway) so we
can just decide to simply pass a descriptor instead.
The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named
"*_dummy_supply_device" while it is a very real device backed by a GPIO
line. There is nothing dummy about it at all, so I renamed it with the
infix *_regulator_* as part of this patch set.
For the patch hunk hitting arch/blackfin I would say I do not expect
testing, review or ACKs anymore so if it works, it works.
The hunk hitting the x86 BCM43xx driver is especially tricky as the number
comes out of SFI which is a mystery to me. I definately need someone to
look at this. (Hi Andy.)
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Check the x86 BCM stuff
Cc: Alexander Shiyan <shc_work@mail.ru> # i.MX boards user
Cc: Haojian Zhuang <haojian.zhuang@gmail.com> # MMP2 maintainer
Cc: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP1 maintainer
Cc: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> # EM-X270 maintainer
Cc: Robert Jarzmik <robert.jarzmik@free.fr> # EZX maintainer
Cc: Philipp Zabel <philipp.zabel@gmail.com> # Magician maintainer
Cc: Daniel Mack <zonque@gmail.com> # Raumfeld maintainer
Cc: Marc Zyngier <marc.zyngier@arm.com> # Zeus maintainer
Cc: Geert Uytterhoeven <geert+renesas@glider.be> # SuperH pinctrl/GPIO maintainer
Cc: Russell King <rmk+kernel@armlinux.org.uk> # SA1100
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Greentime Hu <greentime@andestech.com>
Tested-by: Greentime Hu <greentime@andestech.com>
This matches the implementation of the more commonly used unmap_single
routines and the sync_sg_for_cpu method which should provide equivalent
cache maintainance.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Greentime Hu <greentime@andestech.com>
Tested-by: Greentime Hu <greentime@andestech.com>
Make sure all other DMA methods call nds32_dma_sync_single_for_{device,cpu}
to perform cache maintaince, and remove the consisteny_sync helper that
implemented both with entirely separate code based off an argument.
Also make sure these helpers handled highmem properly, for which code
is copy and pasted from mips.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Greentime Hu <greentime@andestech.com>
Tested-by: Greentime Hu <greentime@andestech.com>
The kernel depends on macros like __BYTE_ORDER__,
__BIG_ENDIAN__ or __LITTLE_ENDIAN__.
OTOH, sparse doesn't know about the endianness of the kernel and
by default uses the same as the machine on which sparse was built.
Ensure that sparse can predefine the macros corresponding to
how the kernel was configured by adding -m{big,little}-endian
to CHECKFLAGS in the main Makefile (and so for all archs).
Also, remove the equivalent done in arch specific Makefiles.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Kconfig got text processing tools like we see in Make. Add Kconfig
helper macros to scripts/Kconfig.include like we collect Makefile
macros in scripts/Kbuild.include.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
The kernel configuration phase is now tightly coupled with the compiler
in use. It will be nice to show the compiler information in Kconfig.
The compiler information will be displayed like this:
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config
scripts/kconfig/conf --oldaskconfig Kconfig
*
* Linux/arm64 4.16.0-rc1 Kernel Configuration
*
*
* Compiler: aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
*
*
* General setup
*
Compile also drivers which will not load (COMPILE_TEST) [N/y/?]
If you use GUI methods such as menuconfig, it will be displayed in the
top menu.
This is simply implemented by using the 'comment' statement. So, it
will be saved into the .config file as well.
This commit has a very important meaning. If the compiler is upgraded,
Kconfig must be re-run since different compilers have different sets
of supported options.
All referenced environments are written to include/config/auto.conf.cmd
so that any environment change triggers syncconfig, and prompt the user
to input new values if needed.
With this commit, something like follows will be added to
include/config/auto.conf.cmd
ifneq "$(CC_VERSION_TEXT)" "aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011"
include/config/auto.conf: FORCE
endif
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
To get access to environment variables, Kconfig needs to define a
symbol using "option env=" syntax. It is tedious to add a symbol entry
for each environment variable given that we need to define much more
such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
in Kconfig.
Adding '$' for symbol references is grammatically inconsistent.
Looking at the code, the symbols prefixed with 'S' are expanded by:
- conf_expand_value()
This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
- sym_expand_string_value()
This is used to expand strings in 'source' and 'mainmenu'
All of them are fixed values independent of user configuration. So,
they can be changed into the direct expansion instead of symbols.
This change makes the code much cleaner. The bounce symbols 'SRCARCH',
'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.
sym_init() hard-coding 'UNAME_RELEASE' is also gone. 'UNAME_RELEASE'
should be replaced with an environment variable.
ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
without '$' prefix.
The new syntax is addicted by Make. The variable reference needs
parentheses, like $(FOO), but you can omit them for single-letter
variables, like $F. Yet, in Makefiles, people tend to use the
parenthetical form for consistency / clarification.
At this moment, only the environment variable is supported, but I will
extend the concept of 'variable' later on.
The variables are expanded in the lexer so we can simplify the token
handling on the parser side.
For example, the following code works.
[Example code]
config MY_TOOLCHAIN_LIST
string
default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"
[Result]
$ make -s alldefconfig && tail -n 1 .config
CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Here is the nds32 patch set based on 4.17-rc6.
Contained in here are the bug fixes and building error fixes for nds32.
These are the LTP20170427 testing results. hackbench01 may fail sometimes.
We are still investigating this issue.
Total Tests: 1902
Total Skipped Tests: 593
Total Failures: 420
Kernel Version: 4.17.0-rc6-00018-ga30e7d1e37e8
Machine Architecture: nds32
Total Tests: 1902
Total Skipped Tests: 593
Total Failures: 419
Kernel Version: 4.17.0-rc5-00018-g27288975a735
Machine Architecture: nds32
Signed-off-by: Greentime Hu <greentime@andestech.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iQIcBAABAgAGBQJbC2uYAAoJEHfB0l0b2JxEpToP/2JaTE+YC+0wiri4ljYB/z9G
z9cG81tD6R6tCHoc01MdxL8xoUNoum3DMesp0M4l27wLLln+KOjs7UL3ry6CjqmO
E3LSISkjy2JAllX2CUxN4xWm70a2QDSFKUmndw71vxljLfkvKjvEpErQyfvzU24S
PcQ/AfOBeeMQTzePILxLkCg/atSdXMOjhVGTxB2np8B6EjrIIELjy5rwr7CD2Fw6
+KEgKKW+/4BkVMn4liJeAX7ywA8V81yj3AWq4omEbb+hT3ugckZ36XxnmhdT0P+8
fXQvxoVrlb2kpBhuKU6yu8aQcMJ/oMa/uUvbPrG8PhSDAllrw05s+Bn9r9d8iqfR
EE9As6tAjrApYbxQ2K+q3qiZULKV0nhwTmhjaj30S+UnC2j+yJbpGvSyJBic9mC5
PA2/+jaeoLwb3pfrxzaoMKc5UKPBZKZhuk81CMTK2SjUoZWF9fp/ansquBLZU1IY
34wuKroIjsDHLgd/Xt4lCQTIg8tU/IO3Hg0jnYuvwnRwi2ocGnjW8To9e8Q5w7NV
OKFvtIUeSBHo02OhvsmOthN2ZQTSFQDAHUromr+XZ0W8s97lN8e1WqOJYMJuGE21
ExJ9jbpTnni4Q5Yjl0FvnwntJFgXRfAYV18W2Icn0nIrgeNFCBZ4pmH7HQAPvHBs
conjeO3e+wJKMHj96fgP
=qlw2
-----END PGP SIGNATURE-----
Merge tag 'nds32-for-linus-4.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux
Pull nds32 fixes from Greentime Hu:
"Bug fixes and build error fixes for nds32"
* tag 'nds32-for-linus-4.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux:
nds32: Fix compiler warning, Wstringop-overflow, in vdso.c
nds32: Disable local irq before calling cpu_dcache_wb_page in copy_user_highpage
nds32: Flush the cache of the page at vmaddr instead of kaddr in flush_anon_page
nds32: Correct flush_dcache_page function
nds32: Fix the unaligned access handler
nds32: Renaming the file for unaligned access
nds32: To fix a cache inconsistency issue by setting correct cacheability of NTC
nds32: To refine readability of INT_MASK_INITAIAL_VAL
nds32: Fix the virtual address may map too much range by tlbop issue.
nds32: Fix the allmodconfig build. To make sure CONFIG_CPU_LITTLE_ENDIAN is default y
nds32: Fix build failed because arch_trace_hardirqs_off is changed to trace_hardirqs_off.
nds32: Fix the unknown type u8 issue.
nds32: Fix the symbols undefined issue by exporting them.
nds32: Fix xfs_buf built failed by export invalidate_kernel_vmap_range and flush_kernel_vmap_range
nds32: Fix drivers/gpu/drm/udl/udl_fb.c building error by defining PAGE_SHARED
nds32: Fix building error of crypto/xor.c by adding xor.h
nds32: Fix building error when CONFIG_FREEZE is enabled.
nds32: lib: To use generic lib instead of libgcc to prevent the symbol undefined issue.
Instead of globally disabling > 32bit DMA using the arch_dma_supported
hook walk the PCI bus under the actually affected bridge and mark every
device with the dma_32bit_limit flag. This also gets rid of the
arch_dma_supported hook entirely.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
This is something drivers should decide (modulo chipset quirks like
for VIA), which as far as I can tell is how things have been handled
for the last 15 years.
Note that we keep the usedac option for now, as it is used in the wild
to override the too generic VIA quirk.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Limiting the dma mask to avoid PCI (pre-PCIe) DAC cycles while paying
the huge overhead of an IOMMU is rather pointless, and this seriously
gets in the way of dma mapping work.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
The toc field in the mod_arch_specific struct isn't actually used
anywhere, so remove it.
Also the ftrace-specific fields are now common between 32-bit and
64-bit, so simplify the struct definition a bit by moving them out of
the __powerpc64__ #ifdef.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Init all present cpus for deep states instead of "all possible" cpus.
Init fails if a possible cpu is guarded. Resulting in making only
non-deep states available for cpuidle/hotplug.
Stewart says, this means that for single threaded workloads, if you
guard out a CPU core you'll not get WoF (Workload Optimised
Frequency), which means that performance goes down when you wouldn't
expect it to.
Fixes: 77b54e9f21 ("powernv/powerpc: Add winkle support for offline cpus")
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The ColdFire PCI configuration space access functions swap addressing
regions to do their work. Just letting the read/write cycles exit
the CPU core (via the ColdFire "nop" instruction) is not enough to
guarantee that the address region remapping has actually completed.
Insert a read back of the mapping register to be absolutely sure
that the remapping has completed.
This fixes an occasional boot hang during the ColdFire PCI initialization
phase.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
A lot of the ColdFire internal peripherals (clocks, timers, interrupt
controllers, etc) are addressed using constants. The only problem with
that is they are not type clean when used with __raw_read/__raw_write
and read/write - they should be of type "void __iomem". This isn't
a problem currently because the IO access functions are local macros.
To switch to using the asm-generic implementations of these we need to
clean up the types. Otherwise you get warnings like this:
In file included from ./arch/m68k/include/asm/mcfsim.h:24:0,
from arch/m68k/coldfire/intc-simr.c:20:
arch/m68k/coldfire/intc-simr.c: In function ‘init_IRQ’:
./arch/m68k/include/asm/m520xsim.h:40:29: warning: passing argument 2 of ‘__raw_writeb’ makes pointer from integer without a cast [-Wint-conversion]
#define MCFINTC0_SIMR (MCFICM_INTC0 + MCFINTC_SIMR)
^
arch/m68k/coldfire/intc-simr.c:182:21: note: in expansion of macro ‘MCFINTC0_SIMR’
__raw_writeb(0xff, MCFINTC0_SIMR);
^
In file included from ./arch/m68k/include/asm/io_no.h:120:0,
from ./arch/m68k/include/asm/io.h:3,
from ./include/linux/io.h:25,
from ./include/linux/irq.h:25,
from ./include/asm-generic/hardirq.h:13,
from ./arch/m68k/include/asm/hardirq.h:25,
from ./include/linux/hardirq.h:9,
from ./include/linux/interrupt.h:13,
from arch/m68k/coldfire/intc-simr.c:16:
./include/asm-generic/io.h:71:22: note: expected ‘volatile void *’ but argument is of type ‘unsigned int’
#define __raw_writeb __raw_writeb
^
./include/asm-generic/io.h:72:20: note: in expansion of macro ‘__raw_writeb’
static inline void __raw_writeb(u8 value, volatile void __iomem *addr)
^
To start this clean up process introduce a macro, iomem(), that converts
a constant address to the correct "void __iomem *" type.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Up to now we have only had support for the PCI bus when running the
ColdFire CPU family with the MMU enabled. The only reason for this was
the incomplete state of the IO remapping and access functions when
running with the MMU disabled.
Recent fixes and improvements to the ColdFire IO access code means we
can now support the PCI bus when running non-MMU enabled as well.
So modify the configuration support to allow it to be selected no matter
what choice of MMU mode is used.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
The ColdFire SoC internal peripherals are mapped into virtual address
space using the ACR registers of the cache control unit. This means we
are using a 1:1 physical:virtual mapping for them that does not rely on
page table mappings. We can quickly determine if we are accessing an
internal peripheral device given the physical or vitrual address using
the same range check.
The implications of this mapping is that an ioremap should return the
physical address as the virtual mapping __iomem cookie as well. So fix
ioremap() to deal with this on ColdFire. Of course you need to take
care of this in the iounmap() path as well.
Reported-by: Angelo Dureghello <angelo@sysam.it>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
We need to treat built-in peripherals and bus based address ranges
differently. Local built-in peripherals (and the ColdFire SoC parts
have quite a lot of them) are always native endian - which is big
endian on m68k/ColdFire. Bus based address ranges, like the PCI bus,
are accessed little endian - so we need to byte swap those.
So implement readw/writew and readl/writel functions to deal with
memory mapped accesses correctly based on the address range being
accessed.
This fixes readw/writew and readl/writel so that they can be used in
drivers for native SoC hardware modules (many of which are shared with
other architectures (ARM in Freescale SoC parts for example). And also
drivers for PCI devices.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Some ColdFire platforms do have real PCI buses, so we should not be
re-defining or otherwise mangling the IO access functions for them.
So when CONFIG_PCI is true use the real io.h support.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
All the ColdFire IO access support code has been moved to io_no.h.
This means that all ColdFire support is at least now consistent no
matter whether the MMU is enabled or not for them.
Now that io_mm.h has reverted to only support the traditional m68k MMU
enabled processors we can remove the ColdFire specific definitions.
We can also remove the old ColdFire PCI bus IO access functions.
The new io_no.h uses asm-generic/io.h to provide all the basic support.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Use the io_no.h IO access support for all ColdFire systems, no matter
whether configured with MMU enabled or disabled. Previously there was
subtle differences in IO access functions used in both cases, and these
resulted in broken behavior for some drivers.
As observed and reported by Angelo when using MMU enabled systems the
read/write family of functions was using little endian access, while the
non-MMU enabled systems were using native endian. This results in drivers
that are shared across Freescale processors (for some of the common
internal SoC peripherals) not working - since they are wired up for native
endian access.
This problem brings to light issues with PCI bus access and local
peripheral access - but these are not addressed with this fix.
Reported-by: Angelo Dureghello <angelo@sysam.it>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Ultimately we want the ColdFire IO access support to be consisent no matter
whether it is configured with MMU enabled or disabled. To acheive that we
need to get all the ColdFire IO access support code together in one place,
in this case io_no.h. The last big piece not in io_no.h is the PCI bus
support functions.
Define the IO mapping addresses required to use the asm-generic IO
access functions. They can provide everything we need - no need for us
to duplicate or have local in/out or read/write access functions.
Note that this support is not active yet, since we haven't done the
full switch over to using the asm-generic functions yet. And also note
that we do not yet remove the old PCI functions from io_mm.h yet.
Consolodating all this IO access support in a single place will make
it easier in the future to enable PCI bus support for non-MMU enabled
ColdFire (which we currently cannot do).
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Create a new header file, kmap.h, that groups all the definitions and
functions associated with the io mapping and remapping.
Currently the functions are spread across raw_io.h and io_mm.h. And in
the future we will want to use these in io_no.h as well. So it makes
sense to move them all together into a single header file.
It is named after the arch/m68k/mm/kmap.c file that actually implements
many of the exported functions.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Tested-by: Angelo Dureghello <angelo@sysam.it>
The primary and fundamental access macros are really the __raw versions.
So make them the actual implementation for access, and not the read/write
access macros. The read/write macros and functions are built on top of
the raw access (with byte swapping or other actions as required).
This in itself causes no functional change right now. But it will make it
easier to fix and resolve problems with PCI bus access in the future.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
There is nothing really special about the non-MMU m68k IO access functions.
So we can easily switch to using the asm-generic/io.h functions.
The only thing we do need to handle is that historically the m68k IO access
functions for readw/readl/writew/writel use native CPU endian ordering. So
for us on m68k/ColdFire that means they are big-endian. Leave the existing
set of _raw_read/__raw_write and read/write macros in place to deal with
them. (They are ripe for later cleanup, but that is for another patch).
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
The non-MMU and ColdFire IO access functions will be moving to using the
asm-generic/io.h in the near future. To make that possible we need define
guards around the m68k specific virt_to_phys() and phys_to_virt()
functions.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Move a copy of the definitions of the *_relaxed() macros into io_no.h
and io_mm.h. This precedes a change to the io_no.h file to use
asm-generic/io.h. They will be removed from io_no.h at that point.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
__reload_late() is called from stop_machine context and thus cannot
acquire a non-raw spinlock on PREEMPT_RT.
Signed-off-by: Scott Wood <swood@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Pei Zhang <pezhang@redhat.com>
Cc: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/20180524154420.24455-1-swood@redhat.com
* SoC
- Change platform dependency to ARCH_RENESAS
Geert Uytterhoeven says "The Renesas Fine Display Processor driver is
used on Renesas R-Car SoCs only. Since commit 9b5ba0df4e ("ARM:
shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate
platform dependency than the legacy ARCH_SHMOBILE, hence use the
former.
This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future."
- Add the to Kconfig RZ/N1D (r9a06g032) SoC
In preparation for upstream support of this SoC
- Identify R-Car E3 (r8a77990) SoC
- Identify and add minimal support for RZ/G1C (r8a77470) SoC
* R-Car SYSC
- Add support for R-Car E3 (r8a77990) SoC
Shimoda-san says this adds:
+ "Cortex-A53 CPU{0,1}, Cortex-A53 SCU, Cortex-R7, A3VC,
A2VC1 and 3DG-{A,B} power domain areas..."
+ "workaround for 3DG-{A,B} of R-Car E3 ES1.0 because
the SoC has a restriction about the order."
- Remove unused inclusion of <linux/sys_soc.h>,
- Make r8a77995_areas[] const.
* R-Car Reset
- Add support for R-Car E3 (r8a77990) SoC
This driver is needed for the clock driver to work
* Debug-LL
- Add support for RZ/G1C (r8a77470) SoC
RZ/G1C uses SCIF1 for the debug console
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE4nzZofWswv9L/nKF189kaWo3T74FAlr+qd0ACgkQ189kaWo3
T76ogQ//XbXLPdjG7qNVoBfM3ILyWGlr3KKZ+29UBCVpfGcbQAEqCr1bB1hHvZUP
CS8Hq9Bw5fFBD1/mRTF9BW27wJTxqAj+ZcWf2b0+lCfdz0KZQdtXckTpvwAW4V6V
aizz08cbDAXs4SeGfRYAFNe3OmiryHEnTr3V6PTzGypDpkKSemKhhWMlxdxLtWL0
FfdC6Q5vFDjEXbF58yvFM7uVJy0GMBYh9CG6cbFham1dSMjlns/Gd1FBMftOjLqC
BlxfVKP8Ju+NKZDTZInZeYwOhgAqFldwdqO8UQxyXYKqFlvpvhGasaD1J2HaVfIV
nMVR9Ih9btd+0ob7Oe+hvQsXZedLk0wbYqIpMu3BN+1ynu525VtP+TqvnKRtFkBO
vFnps69tQ5FEnb7V0toa3k2dNsLbFZlbZQ6cvklRyWY+5uvbXioYZnN84UGQdBhj
u+vz+Pdoyakr/o3zwrJ9s/AhBdKSgxtxXgqmiW4xXCAeykqkPUDyfx5ALyYtD/vG
XuC4PR5XDg1PGIzqU37gk34PG8I+G4ybbMdcL7KZeKknFHppBM4242gre9VJ580K
TJTcCg9LW4f8Tqa6CpNboj+X36PjLl611XcZdFGvHMl28V267VtDFWAIeljBIh1p
Xau0jvz6Yxt08/zdQ29N7piJ0Oc6Vt9ZwwdKlwseNPLQJhmJv6w=
=xLPA
-----END PGP SIGNATURE-----
Merge tag 'renesas-soc-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/soc
Renesas ARM Based SoC Updates for v4.18
* SoC
- Change platform dependency to ARCH_RENESAS
This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.
- Add the to Kconfig RZ/N1D (r9a06g032) SoC
- Identify R-Car E3 (r8a77990) SoC
- Identify and add minimal support for RZ/G1C (r8a77470) SoC
* R-Car SYSC
- Add support for R-Car E3 (r8a77990) SoC
- Remove unused inclusion of <linux/sys_soc.h>,
- Make r8a77995_areas[] const.
* R-Car Reset
- Add support for R-Car E3 (r8a77990) SoC
* Debug-LL
- Add support for RZ/G1C (r8a77470) SoC
* tag 'renesas-soc-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}
soc: renesas: rcar-sysc: Add support for R-Car E3 power areas
arm: shmobile: Add the RZ/N1D (R9A06G032) to the shmobile Kconfig
arm: shmobile: Change platform dependency to ARCH_RENESAS
soc: renesas: r8a77995-sysc: Cleanups
soc: renesas: rcar-rst: Add support for R-Car E3
soc: renesas: Add r8a77990 SYSC PM Domain Binding Definitions
soc: renesas: identify R-Car E3
ARM: debug-ll: Add support for r8a77470
ARM: shmobile: Add the RZ/N1 arch to the shmobile Kconfig
ARM: shmobile: r8a77470: basic SoC support
soc: renesas: rcar-sysc: Add r8a77470 support
soc: renesas: rcar-rst: Add support for RZ/G1C
soc: renesas: Identify RZ/G1C
Signed-off-by: Olof Johansson <olof@lixom.net>
A few more fixes for v4.17:
- A fix for a crash in scm_call_atomic on qcom platforms
- Display fix for Allwinner A10
- A fix that re-enables ethernet on Allwinner H3 (C.H.I.P et al)
- A fix for eMMC corruption on hikey
- i2c-gpio descriptor tables for ixp4xx
+ a small typo fix
-----BEGIN PGP SIGNATURE-----
iQJDBAABCAAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAlsJynEPHG9sb2ZAbGl4
b20ubmV0AAoJEIwa5zzehBx3QEkP/A5dGXeQkArCWPvWoFr+20KjIS07f7F8olNy
9JKG3R2uEZsqjD3c6HFkd1abTtUQmgg/hmpxakAI8vbypA4gsq9jyFC6TxqsBSyz
uw7hQ5XcGA99pQXp8jYUrazi/XnG9Wm8LLBslsx75wJwNikzlAl6PStKDFcz0Pr6
A9JXWnqFY50YRzUr4y9GrSo3o4dvVniF3PUFEwnYliUI5qszph2/rwaE2zLQt/PT
X0DMA4v+c+4ngS5TGipY4vFjRyvsOv/NeDQzGTvGcU6QMdP4ZEsQBrye6BqowmaD
DqaoSHvsi7Lel4u29p5KyBKrM0bAhtFX+iCGiqTfkKwRWHkh7CHombUk2qX/9OJW
oB9orkKgiP35xAL5xFmB5tf03s0tQ8/qicE72tGW/TVIEBX/l+ymD76DH4rmYvRw
wNZ+HwHrMVkYgVG0TQIxxEgkXbPsyDbk3DbNbQkHf/pV5+PsMrp0iSo7oaglsS9Y
NYTRA/DQCldzhv68YRoMBh5gD4oE5iK3e3c4nLm80vd7zj8YsuXnc4+55a8PrHfs
oVg0PE5fVlP3AVRJW09ikdf03U7m0AFX/fFKHrAwWylT1+Z1KSJhM4ZaXGgdvuOV
asFUenzF3WF6Nsx+smL/vLzr/AvvYeq80Q9OdLWQl4056HurkrpL/E2HVj4MYaoW
WKKRdfzX
=mga+
-----END PGP SIGNATURE-----
Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A few more fixes for v4.17:
- a fix for a crash in scm_call_atomic on qcom platforms
- display fix for Allwinner A10
- a fix that re-enables ethernet on Allwinner H3 (C.H.I.P et al)
- a fix for eMMC corruption on hikey
- i2c-gpio descriptor tables for ixp4xx
... plus a small typo fix"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: Fix i2c-gpio GPIO descriptor tables
arm64: dts: hikey: Fix eMMC corruption regression
firmware: qcom: scm: Fix crash in qcom_scm_call_atomic1()
ARM: sun8i: v3s: fix spelling mistake: "disbaled" -> "disabled"
ARM: dts: sun4i: Fix incorrect clocks for displays
ARM: dts: sun8i: h3: Re-enable EMAC on Orange Pi One
Pull x86 store buffer fixes from Thomas Gleixner:
"Two fixes for the SSBD mitigation code:
- expose SSBD properly to guests. This got broken when the CPU
feature flags got reshuffled.
- simplify the CPU detection logic to avoid duplicate entries in the
tables"
* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/speculation: Simplify the CPU bug detection logic
KVM/VMX: Expose SSBD properly to guests
* Enable in shmobile and multi_v7 defconfigs to give wider test coverage:
- Recently mainlined support for RZ/G1C (r8a77470) SoC
- Renesas Watchdog (RENESAS_WDT) which is used on
R-Car Gen2 and RZ/G1 platforms.
* Disable in shmobile and multi_v7 defconfigs to avoid unecessary bloat:
FB_SH_MOBILE_MERAM the last user of which was removed in v4.1 by
a521422ea4 ("ARM: shmobile: mackerel: Remove Legacy C board
code").
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE4nzZofWswv9L/nKF189kaWo3T74FAlr9SFwACgkQ189kaWo3
T752yg/+Jr9NOkyaSCT2m6XE/x87KsJZW1l8abBORQe+ATwQ+54ab6UMp8r1SzWi
hXPB0MyZhzTfPkWaAzg19mJqJ90TJXmvXDsV0YsIXxi6cp8Kudwie7ZzJEmMIWd5
c/sKZcvjCiSubc+NSFGlsW23ID0ChpD4/+3YSfRJaG2ZfaBjqjW7rln1S1+DuCwR
Jl0k4DvwVDtOb3p7auMLe/aE+AMS1tIXy+gCcdqZG03p2Hx29xz6qwElxmAAEJs3
rmi3V/RESrUnzMvko+u+bGRd1ytC8+6Vpj28pIqR8B2mg+fXxsZfl0cUF70OiI7Z
7Sb7UUPJCwqTATgz3HCqccIGK+KBt0lCQds8ogdfm3ixeYQzUKRnGUPLO0kevwD3
DahWscolbuDhTN2TwvjyMctSfk0QbuNTYpbzQNQLReMV+MBIjD+kKujBeJfDlZf7
xxNSPz/Z0r4IvnfuAX+6NcWKd2NVWyoztqyDEuqWFo3UqUciy+7Ol/Y/vozM1SwN
yNbQd9khzE1LEgm87nJFH6gsMpBJnAC4f329lDBgvDb/pPoxQ/NkvaQ/FuSzkCKV
Sr8ZUFBck/H+SYIdqPcM3TSRm7WCgDxOPB8bV2USfVFQ1c9v/R7cW0bpIo6uKytM
nGwqShWNWROhjIateQRNdowck2XpaSPi0lbesFzL8zrpBne10vg=
=q3Ut
-----END PGP SIGNATURE-----
Merge tag 'renesas-defconfig-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/defconfig
Renesas ARM Based SoC Defconfig Updates for v4.18
* Enable in shmobile and multi_v7 defconfigs to give wider test coverage:
- Recently mainlined support for RZ/G1C (r8a77470) SoC
- Renesas Watchdog (RENESAS_WDT) which is used on
R-Car Gen2 and RZ/G1 platforms.
* Disable in shmobile and multi_v7 defconfigs to avoid unecessary bloat:
FB_SH_MOBILE_MERAM the last user of which was removed in v4.1 by
a521422ea4 ("ARM: shmobile: mackerel: Remove Legacy C board
code").
* tag 'renesas-defconfig-for-v4.18' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: multi_v7_defconfig: Enable RENESAS_WDT
ARM: shmobile: defconfig: Enable RENESAS_WDT_GEN
ARM: multi_v7_defconfig: Disable CONFIG_FB_SH_MOBILE_MERAM
ARM: shmobile: defconfig: Disable CONFIG_FB_SH_MOBILE_MERAM
ARM: multi_v7_defconfig: Enable r8a77470 SoC
ARM: shmobile: defconfig: Enable r8a77470 SoC
Signed-off-by: Olof Johansson <olof@lixom.net>
* Enable UFS and PCIe for Qualcomm msm8996/db820c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJbCHdwAAoJEFKiBbHx2RXV/5sQAIx4JnUs2HfYYnK1ILooGk5h
D95ck/OUAtnAeNfMo6pm13MPd3rMCm5Sjp8qp6vvR4JnImRuIQzPD9MD7s1kgAHm
fPQrEcENfBtPBrYs8skoJQxBuAGcQHOZSyqrTwYJYCqKMm2UymtlpS1zw/N/nWc9
h9Nh2vKc9wgF5sGdDEhCMXMnSqgWTKnAvuJQXAl7FCN1r5AIsI5myMoh1weVPZG2
PseiT2w6KAP38kZkNh/OPx5SDjcRLSrLTlK6s2i5SycAaEstYbPr/3wfsyhR26pH
nhWZzYUDZw5fBhWOBIbKv1vRmBp7Qc312sOcpODoosA7SjQn12Yqt56AC88g5krG
ijJL81Q9OePLh6MAO2oIg04pUSB2TA64b/83VaTXPdWXLxkajaQhIq4Z/JJKGXws
toiv60QaifQW3jvmpSIP2vR68iUHxVchtSu4UvWLlIqKRfCEzq2d0R+cNrwVDM4x
saOfCNee7i3eIDyWkfRzfZNk3gMIGdsmEAxJ9flvtQscNIXGvxKasOLy7bi2iWQ4
G+AXS1hmSHkugeZwU8h2RjOlKkTO5yvWQm9vi60gB/So14RLajgF120Yn2rOF5IS
r+14YXEDHZkGm3FczIgT2drdtXfEmadbYpTROvifnj3WrTi7NJDBOTsf8kV85aa6
Zc/sU/BazzUqQat30BiX
=sPLc
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux into next/defconfig
Qualcomm ARM64 Based defconfig Updates for v4.18
* Enable UFS and PCIe for Qualcomm msm8996/db820c
* tag 'qcom-arm64-defconfig-for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux:
arm64: defconfig: Enable PCIe on msm8996 and db820c
arm64: defconfig: Enable UFS on msm8996
Signed-off-by: Olof Johansson <olof@lixom.net>
- small DT improvements without functional changes
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEXx9Viay1+e7J/aM4AyWl4gNJNJIFAlsIkbUACgkQAyWl4gNJ
NJLOxQ//TmBf3vZ1G/nD/hUD570WaQfxsGXq9846xBuoEaGaore0A3va54j0PelG
OE7fSRB/qy5+q1cVhRdXNmaqS/SHaghpqF2HM8aCmP8FQf1yenCD0pbVoqDRzdRt
n1kna9tjl7tXejDT0UUAHgj/cW6DuquB9qtY8jy8dOsQ1i1JBxn/nSJG8sYFXm7t
/nE28jom0Uu3tzVRbKu4rVpWLRqLaot0CCychLhf3VdKOgzMzGXN+RcRNP/t58S8
W/FltbFCBCuKwiZnCq1vny3UMdZCrwZmAJlTdqCsSrkDDYEeCDYlOgLqPTpWDzxI
K2BEqMy+H+JHYYTe5YPmndCx9QhjalEAVInXdRivaI9P0KeeBrLua9D9EM7gECMJ
GYiaWAs7b4ibyS2imOICPRYOwjk0WyrmBx9YcH1QC5YDeP9B+4epT748/W+bGhI4
Aiwrhzvw143d/uxpANe/J6m85Q66Kl7Nh94E/JClVGkPqZctMhK0LXSYwvGls8XN
RjvUjWYp8ig3pxHZFe50F1S5oOGJGx/Rt/EUgHqUkpM3y8VHpKhQimzgDyl6bDML
VWkGGeK3tCW/IAMhq33Pi1HKB8sfJSd2fhjB6GPsQJtAerK46H6ximv+MLfT3iiE
t0+THwUlSVt5+7w6MOmJIDB0NUB7chmqfeaSApbRARsUDEE0yVo=
=xoAj
-----END PGP SIGNATURE-----
Merge tag 'at91-ab-4.18-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into next/dt
AT91 DT for 4.18:
- small DT improvements without functional changes
* tag 'at91-ab-4.18-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
ARM: dts: at91-sama5d2_xplained: Use IRQ_TYPE specifier
ARM: dts: at91: sama5d4ek: use canonical compatible for touchscreen
Signed-off-by: Olof Johansson <olof@lixom.net>
I used bad names in my clumsiness when rewriting many board
files to use GPIO descriptors instead of platform data. A few
had the platform_device ID set to -1 which would indeed give
the device name "i2c-gpio".
But several had it set to >=0 which gives the names
"i2c-gpio.0", "i2c-gpio.1" ...
Fix the offending instances in the ARM tree. Sorry for the
mess.
Fixes: b2e6355559 ("i2c: gpio: Convert to use descriptors")
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Reported-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
PPC:
- Close a hole which could possibly lead to the host timebase getting
out of sync.
- Three fixes relating to PTEs and TLB entries for radix guests.
- Fix a bug which could lead to an interrupt never getting delivered
to the guest, if it is pending for a guest vCPU when the vCPU gets
offlined.
s390:
- Fix false negatives in VSIE validity check (Cc stable)
x86:
- Fix time drift of VMX preemption timer when a guest uses LAPIC timer
in periodic mode (Cc stable)
- Unconditionally expose CPUID.IA32_ARCH_CAPABILITIES to allow
migration from hosts that don't need retpoline mitigation (Cc stable)
- Fix guest crashes on reboot by properly coupling CR4.OSXSAVE and
CPUID.OSXSAVE (Cc stable)
- Report correct RIP after Hyper-V hypercall #UD (introduced in -rc6)
-----BEGIN PGP SIGNATURE-----
iQEcBAABCAAGBQJbCXxHAAoJEED/6hsPKofon5oIAKTwpbpBi0UKIyYcHQ2pwIoP
+qITTZUGGhEaIfe+aDkzE4vxVIA2ywYCbaC2+OSy4gNVThnytRL8WuhLyV8WLmlC
sDVSQ87RWaN8mW6hEJ95qXMS7FS0TsDJdytaw+c8OpODrsykw1XMSyV2rMLb0sMT
SmfioO2kuDx5JQGyiAPKFFXKHjAnnkH+OtffNemAEHGoPpenJ4qLRuXvrjQU8XT6
tVARIBZsutee5ITIsBKVDmI2n98mUoIe9na21M7N2QaJ98IF+qRz5CxZyL1CgvFk
tHqG8PZ/bqhnmuIIR5Di919UmhamOC3MODsKUVeciBLDS6LHlhado+HEpj6B8mI=
=ygB7
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Radim Krčmář:
"PPC:
- Close a hole which could possibly lead to the host timebase getting
out of sync.
- Three fixes relating to PTEs and TLB entries for radix guests.
- Fix a bug which could lead to an interrupt never getting delivered
to the guest, if it is pending for a guest vCPU when the vCPU gets
offlined.
s390:
- Fix false negatives in VSIE validity check (Cc stable)
x86:
- Fix time drift of VMX preemption timer when a guest uses LAPIC
timer in periodic mode (Cc stable)
- Unconditionally expose CPUID.IA32_ARCH_CAPABILITIES to allow
migration from hosts that don't need retpoline mitigation (Cc
stable)
- Fix guest crashes on reboot by properly coupling CR4.OSXSAVE and
CPUID.OSXSAVE (Cc stable)
- Report correct RIP after Hyper-V hypercall #UD (introduced in
-rc6)"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: fix #UD address of failed Hyper-V hypercalls
kvm: x86: IA32_ARCH_CAPABILITIES is always supported
KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changed
x86/kvm: fix LAPIC timer drift when guest uses periodic mode
KVM: s390: vsie: fix < 8k check for the itdba
KVM: PPC: Book 3S HV: Do ptesync in radix guest exit path
KVM: PPC: Book3S HV: XIVE: Resend re-routed interrupts on CPU priority change
KVM: PPC: Book3S HV: Make radix clear pte when unmapping
KVM: PPC: Book3S HV: Make radix use correct tlbie sequence in kvmppc_radix_tlbie_page
KVM: PPC: Book3S HV: Snapshot timebase offset on guest entry
This patch is a partial revert of
commit abd7d0972a ("arm64: dts: hikey: Enable HS200 mode on eMMC")
which has been causing eMMC corruption on my HiKey board.
Symptoms usually looked like:
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
...
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc0: new HS200 MMC card at address 0001
...
dwmmc_k3 f723d000.dwmmc0: Unexpected command timeout, state 3
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
print_req_error: I/O error, dev mmcblk0, sector 8810504
Aborting journal on device mmcblk0p10-8.
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
EXT4-fs error (device mmcblk0p10): ext4_journal_check_start:61: Detected aborted journal
EXT4-fs (mmcblk0p10): Remounting filesystem read-only
And quite often this would result in a disk that wouldn't properly
boot even with older kernels.
It seems the max-frequency property added by the above patch is
causing the problem, so remove it.
Cc: Ryan Grachek <ryan@edited.us>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: YongQin Liu <yongqin.liu@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Wei Xu <xuwei04@gmail.com>
AEGIS-256 key is two blocks, not one.
Fixes: 1d373d4e8e ("crypto: x86 - Add optimized AEGIS implementations")
Reported-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Ondrej Mosnacek <omosnacek@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
We need a new capability to indicate support for the newly added
HvFlushVirtualAddress{List,Space}{,Ex} hypercalls. Upon seeing this
capability, userspace is supposed to announce PV TLB flush features
by setting the appropriate CPUID bits (if needed).
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Implement HvFlushVirtualAddress{List,Space} hypercalls in a simplistic way:
do full TLB flush with KVM_REQ_TLB_FLUSH and kick vCPUs which are currently
IN_GUEST_MODE.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Prepare to support TLB flush hypercalls, some of which are REP hypercalls.
Also, return HV_STATUS_INVALID_HYPERCALL_INPUT as it seems more
appropriate.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Hyper-V TLB flush hypercalls definitions will be required for KVM so move
them hyperv-tlfs.h. Structures also need to be renamed as '_pcpu' suffix is
irrelevant for a general-purpose definition.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Add the rtc enable clock for watchdog controller to make it work well.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
This patch adds device nodes to enable one GPIO controller located on
digital chip, 2 EIC (external interrupt controller) controllers loacted
on PMIC and digital chip for Spreadtrum SC9860 platform.
Moreover this patch adds 3 GPIO keys relied on EIC controller to support
power key and volume up/down keys.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
- Enable the support of ethernet, eMMC, Combo/INNO phy
and PCIe for Hi3798CV200
- Enable the LPC for hip06 and hip07
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJbCDTrAAoJEAvIV27ZiWZcESIP/jd+gcVS2D0gxbtT85sWoW+e
UvScBrFNUly+WPpd3txfncrQ5IEOzR1NdzWmdKn29KqvmvM/zbuoNpS0+0IZZ/YX
acSF3FnGJazIQHz2bYu/0A53cV7Xu+41Ml/NVaRFet4IimZsa/R8j7mIcz0FfDnu
CBR6A4DfF9G9WD14x/yKhTbs7LSyqFQsSdzOWD9W13pcIoX5KFkfwcoaDKOWJLbF
0n+v6c/DB9L/UWMub/ihE6FWJcvyPLTEIPtPnQD2rZRnRtp429PRNwkIDj3TUdQq
0hmJpix2eygMhhDo2wuQEyUECok9VRKh1zVQAs+ScFYvbRsneHiBXDWSAr068OSf
+f1h0EYjxR85nlcA+HLgwVK/sztoedDdOiJJFLUjPaKejUfMFvAa3wcKnRKpVdE0
dJaQ+j93f6Xz/0qy5bIhDrRwAnKPWdRf87DktH6jLUSx6JLRCTRNwO7GG4mMsrFs
QuE/6E7p3BQ98Y2oCAfK0vzJ6sFo/w0N5ImD2sjbetrA3v4XjQLY38ZiqlFh0WeW
bSSCroGFcRgldq/nm4NOWXObnWucu2ODTdKBCgAjozQP6EJwXLcurxE08d1/wdhN
KdN4MR7U4uq4IYg8yi5YadcWxBi3tPEW0huCEov/gQ1gzFIpSAQ/Ywz0qOdTnoJd
4FqgwVIc8UGtY0QKxOT7
=l2fi
-----END PGP SIGNATURE-----
Merge tag 'hisi-defconfig-for-4.18v3' of git://github.com/hisilicon/linux-hisi into next/defconfig
ARM64: hisilicon: defconfig updates for 4.18
- Enable the support of ethernet, eMMC, Combo/INNO phy
and PCIe for Hi3798CV200
- Enable the LPC for hip06 and hip07
* tag 'hisi-defconfig-for-4.18v3' of git://github.com/hisilicon/linux-hisi:
arm64: defconfig: Enable HISILICON_LPC
arm64: defconfig: enable drivers for Poplar support
Signed-off-by: Olof Johansson <olof@lixom.net>
The patch that enabled these had no useful changelog that explains
why it is done, and it causes a build warning:
WARNING: unmet direct dependencies detected for STM32_DMA
Depends on [n]: DMADEVICES [=n] && (ARCH_STM32 [=y] || COMPILE_TEST [=y])
Selected by [y]:
- MACH_STM32MP157 [=y] && ARCH_STM32 [=y] && ARCH_MULTI_V7 [=y]
Generally, platforms should not select arbitrary drivers, so let's
just revert that change.
Fixes: de6037fa20 ("ARM: stm32: Select DMA, DMAMUX and MDMA support on STM32MP157C")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
This series contains two omap1 ams-delta GPIO clean-up patches to get
started with removal of hard-coded GPIO numbers from drivers. And then
the removal of board mach includes from drivers. The second patch mostly
touches the ams-delta audio driver but is included here because of the
removal of the latch gpios and is acked by Mark Brown.
And there are two more am437x related PM patches to save and restore
control module and timer registers for RTC only suspend mode. Looks like
the patch title for the timer changes is a bit misleading, not all the
timer code is yet living under drivers/clocksource. But I had already
pushed out the branch before I noticed this.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAlsIImcRHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXPX1BAAvdPioDGVefuV4hGTjj04lT3pj/a+Xl44
DV9osD2mWlFXF3FIxOhEcZcwzjKdCmeEm01jhw+gLJJboxB96w02tFJj5oAebEo5
ETD9F+Hu8TfvAAIegMaozlEdHmlmlGJ3COBBX+bOmfShwak4EDOEGbR5lpLYh2A1
/NJHjNOa7JLrl/oltnjJv1P6CggCCBFQyzIscJaGa2Dq5bAc04TYTCo83y6hVcmS
VZDfoqKi0f576sAdCazCIxzFdmI6D9P2buEgiEWpmMaB/x+agiB5++wAhxs8C/Dw
MH1HZuBdB87PBBPKNfXuL0MlYwKY/Gf7n0hGnTsuM7twy3tQsHB1fdQbvrx7E8Wz
PyPwARIXuOKaqZL9g1RmUjWwKkx6j7Srh5UatOiLUSoMwkcJLBpjMYnkilbptZKA
ofy1WoOV2NNzLPWHAMDTWxUjc8amOX9LhMehnLty4smwe7ZLiykTO++E9ozx/0g/
62ihp6GRU3N7li3ZaXKk2yaaqE7h8fxLVCkw26bWew6RdNT0XBFyp8IQTNrQSyya
z47RRfifRgzR2gklInsrt56pileyYYnK3WA0sXzvo0w09XVzbsYNuoA0maxzp/H8
BdIov5yuSkaaw9aj1yqfkL7sYI+Ss0QpsjHqa964o48kRdDWinWEPfZYCD7f2qzy
IItK4y94bMg=
=gBpR
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.18/soc-late-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/soc
Late omap soc changes for v4.18 merge window
This series contains two omap1 ams-delta GPIO clean-up patches to get
started with removal of hard-coded GPIO numbers from drivers. And then
the removal of board mach includes from drivers. The second patch mostly
touches the ams-delta audio driver but is included here because of the
removal of the latch gpios and is acked by Mark Brown.
And there are two more am437x related PM patches to save and restore
control module and timer registers for RTC only suspend mode. Looks like
the patch title for the timer changes is a bit misleading, not all the
timer code is yet living under drivers/clocksource. But I had already
pushed out the branch before I noticed this.
* tag 'omap-for-v4.18/soc-late-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
OMAP: CLK: CLKSRC: Add suspend resume hooks
ARM: AM43XX: Add functions to save/restore am43xx control registers
ASoC: ams_delta: use GPIO lookup table
ARM: OMAP1: ams-delta: add GPIO lookup tables
Signed-off-by: Olof Johansson <olof@lixom.net>
New hardware support added:
USB controllers for AST2400 and AST2500 which have drivers
merged in 4.18.
Hardware random number generator which we made enhancements to many
releases ago, but never added the device tree parts.
Misc changes to support watchdog and gpio-keys features used by
OpenBMC systems.
New machines:
Intel S2600WF, an Intel platform family with an ASPEED AST2500 BMC.
Inventec Lanyang, a Power 9 platform with AST2500.
Portwell Neptune, a x86 server development kit with an AST2500.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+nHMAt9PCBDH63wBa3ZZB4FHcJ4FAlsHkpcACgkQa3ZZB4FH
cJ7PExAApmFTUgXZ+33an7oBKNeW4l79D1IQaxg3x98cebOkPufWDoPYpsiCh9NB
1WKszksGqv1efa3IKeGjW2YfKyO0dT3di08b0KwKhDEl+gbqycVbyWnAXmB1lbLE
cRAZlztP864aVhcCDS2YAK+kL8QOSBkvlPjzE+7nuP2s5j5xgzsIGs0Dy0dHja70
1PYttP9lL6UNcI2VH5EE92yjzBJMF79GkH6gNj4NObKwwMI04C7nZ9/edLuJv5lW
mue0CDFwDnVMuUdUQcaqhlDeIcRn/r0QyesnYpvrx1QlfLeYvt5Phi7FlwVcBe8t
1uy3/nNoiRvj1M6Va8bcl03Tzazcozi5O/DxCzFXZu0yDOBMnQ8JxQ/HeftQD21p
+DPsuiplL+BPUqK8bwbRRsiEKCzlbTZleIyYvRp9wai7aunX/4aYnv/A1CxxwmXn
BiUQSN17PqqBSDmrPx7osmBB5jsZFGD+4wTxj32v/sJ63eybdXBkPnidS7X3+ltB
wXHIZ1f+W4AuDKzlW7jLlL775xthjFn+4PjkkGCJWB0+m3XcXDFNp8ktZazHXvJ/
B3G5JtM1z/+QjEUKK0ZaX6AkfYnwzC8EUO3uuCJ/pxsAIZsEQ+u/Y8kIug6vr2Tr
KnGKlnqHEdv8IQRMzVwIzu/WAu2T9y2ty06fYp7JIQifYnJIgEM=
=bGbT
-----END PGP SIGNATURE-----
Merge tag 'aspeed-4.18-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed into next/dt
ASPEED device tree updates for 4.18
New hardware support added:
USB controllers for AST2400 and AST2500 which have drivers
merged in 4.18.
Hardware random number generator which we made enhancements to many
releases ago, but never added the device tree parts.
Misc changes to support watchdog and gpio-keys features used by
OpenBMC systems.
New machines:
Intel S2600WF, an Intel platform family with an ASPEED AST2500 BMC.
Inventec Lanyang, a Power 9 platform with AST2500.
Portwell Neptune, a x86 server development kit with an AST2500.
* tag 'aspeed-4.18-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed:
ARM: dts: Aspeed: Enable USB ports on eval board.
ARM: dts: Add Aspeed SoC USB controllers to device-tree
ARM: dts: aspeed: Add S2600WF BMC Machine
ARM: dts: aspeed: Add Inventec Lanyang BMC
ARM: dts: aspeed: Add Portwell Neptune machine
ARM: dts: aspeed: witherspoon: Set alternate boot
ARM: dts: aspeed: witherspoon: Add gpio keys for power supply presence
ARM: dts: aspeed: witherspoon: Enable checkstop and cooling gpio keys
ARM: dts: aspeed: zaius: Add pcie-e2b-present gpio key
ARM: dts: aspeed: romulus: Add id-button gpio key
ARM: dts: aspeed: Describe random number device
Signed-off-by: Olof Johansson <olof@lixom.net>
dtc now warns on incomplete OF graph endpoint connections:
arch/arm64/boot/dts/sprd/sp9860g-1h10.dtb: Warning (graph_endpoint): /soc/stm@10006000/port/endpoint: graph connection to node '/soc/funnel@10001000/ports/port@2/endpoint' is not bidirectional
The cause is a typo in 'remote-endpoint'.
Cc: Orson Zhai <orsonzhai@gmail.com>
Cc: Baolin Wang <baolin.wang@linaro.org>
Cc: Chunyan Zhang <zhang.lyra@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Allwinner fixes for 4.17
Here is a bunch of fixes for merge issues, typos and wrong clocks being
described for simplefb, resulting in non-working displays.
* tag 'sunxi-fixes-for-4.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
ARM: sun8i: v3s: fix spelling mistake: "disbaled" -> "disabled"
ARM: dts: sun4i: Fix incorrect clocks for displays
ARM: dts: sun8i: h3: Re-enable EMAC on Orange Pi One
Signed-off-by: Olof Johansson <olof@lixom.net>
1. Add clocks necessary for DECON hardware windows no 4 and 5 on
Exynos5433.
-----BEGIN PGP SIGNATURE-----
iQItBAABCAAXBQJbBwHaEBxrcnprQGtlcm5lbC5vcmcACgkQwTdm5oaLg9f4URAA
i0ExFHHBL9iG7/X3ixhpkHZQr1zw7wn7lEWVDY1O3BWo9WKT7MgnfqxOBe8IXU5i
Q6ao1ExBhWX5S3H8urtx6kNtc8hYRz4Iusysbdu11miuxE5Msljz+lFvDJLIE5bR
WLIVfm+3pZtsOSWVRvEQjWlAHeFv9kElXQOlXQyX8s6mM9PSvaWmXn2ttCOEgphT
EUoyAARb94q3z7smU4XjYYeOTxXahBGb4XHecTRu+Pd0Y/veNbGdtR79t9goHzsX
jVDDbCDpQifUVcUjsddHMiKhY8EQWepsLcELpYD01s1GWqMHtQZ0bE9wZNSxeZyg
pqXpqu1H8FBsnmxmWMAjtprSKYwRobaMWsGnibc995dZgEjaMVgUvoltBzwo/1Ze
Mq9iFCGPLgfD/cRI0c9zOYezFpAwbOGYlVcV5JIS+7Fltq1IGzTgp7O54Inl/D9Z
vqhF8rTe9UI73T6tnwvp2mO0+PxqmNyqfcClEPpm9WJNauBdaK/JR++72itWnKKd
USdR85M1cXDLdZFpa2PRbhQDgw+Wej/i1x6WgpzmU4TIFDxsLXSpRhjhtR/D3fTK
+aPwLUHkmufLX/poHdPcQYJPhkogtc2Q+i2zdo/oClPO/naO7+WRDn8+gttFk8yS
CBescFGGrk0Eqt1usaTI4eQk8CFaDiiSJvLq4Nx8lwE=
=6wYh
-----END PGP SIGNATURE-----
Merge tag 'samsung-dt64-4.18-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into next/dt
Samsung DTS ARM64 changes for v4.18, part 2
1. Add clocks necessary for DECON hardware windows no 4 and 5 on
Exynos5433.
* tag 'samsung-dt64-4.18-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
arm64: dts: exynos: Add more clocks to Exynos5433 Decon/DeconTV
Signed-off-by: Olof Johansson <olof@lixom.net>
1. Add support for audio over HDMI for Odroid X/X2/U3.
-----BEGIN PGP SIGNATURE-----
iQItBAABCAAXBQJbBwGHEBxrcnprQGtlcm5lbC5vcmcACgkQwTdm5oaLg9e3FxAA
iI9TPJamfrLNrfWmLvBIFnPdcLpWTKckoObWUWfeOJeA5yU6Fb9a0BIx2DzDMB05
sxQEXLgFtfAg3iliTh/7Iy7Nogjo0iMixTBcdtK3hHm9h99uibrB4RcBLRQUkTgL
qUJzZgNYXP6ZE2hUlph5BegjDZZliVMGYde/iC5KQwJ2+kC882TRJute3A0M79O0
IDN8JuJI5b+imMDApb8lXXqSa8vk/nAGDhzZbU7zwQ4Klx/VO7CZ4WetditJOnH4
/QGEO7YdLsXfKyYzZXx52VThem4gh94hrLt3NqnwrOs6x8Dga3oiZK9wvvkpGgGt
+Aqz8doQb485yn9Z5Ca1QIhdR1fQFllOtgBCSqgXefeBTV7En9dYDcd2Qw39MonY
+XMpciJz/VqjLdUgJ3Yw/pVJ0QlgsYsEAhzYFiWVS0KtpNFUTXOqDDjHmyLePc6X
syRNJAYkvMCVUoNyYgcGWfoxiruIP6szw9zxV07T1hx8HtdMnlcKNwsXpQAbcFFT
hpihXdV7MBfEaN67z4BCVOUw49cmTkDPWq4s1C9ioneyqK4cAf/4tvzaGur4VmBR
+2RJflCN1aWGspu+DJAbOlGbh5I0l+XoU7KeBDjYcNm1j8ou14JGAI+tb5Q74Bw7
t/8klRnIqTCChBc6G/Q2Qhk7h4YA1xGdl/Yv4ESJFuM=
=Bzy3
-----END PGP SIGNATURE-----
Merge tag 'samsung-dt-4.18-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into next/dt
Samsung DTS ARM changes for v4.18, part 2
1. Add support for audio over HDMI for Odroid X/X2/U3.
* tag 'samsung-dt-4.18-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: dts: exynos: Add support for audio over HDMI for Odroid X/X2/U3
Signed-off-by: Olof Johansson <olof@lixom.net>
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEE2MW6uuYZ+0zBfpF41kg+k28NbwgFAlsGahUTHGpzemhhbmcz
QGdtYWlsLmNvbQAKCRDWSD6Tbw1vCPj1D/0WfMrbjNWnUUkVfyIs+91UuAXKsgAm
s4soQ41DeYpsG3DVVykYy6CY20XG8ueAYZkLh8h52zipGV50Yq7fpZJGIDyXbP+V
aE4B3MPBFtZF07SPvrBOMF/6E7xIeTgHhm0sgKECFZteDlRgCsvK/RK5gthmx67X
mbX/CLELLj9RglomVrV/7ZAGkBG7bX35mn5yIocJ/u7qwXdO3wyIEE2lelaH+OaN
335XDJEIXrwHI5imNXnTgQ2YjgkoUbGPAjUQce1ZBKLPunt20IQMipmHJNJFeD6d
wY+BGtxjKQ2GZSSNPsaa/0nV5wTdvN+xWfXPfLFe32BWj3RVkB9E9azT4nZ80NhI
dfjMfk2umTcu1eVbc9wqKo0q005YcwiX+gRX5sWA4YXhwNGO6Vvf3KxM16QZlE56
pS+Lz1iU+WEATbR0+72hXU8pa8RxcDYc580LmnoH87sC7bab7dOXOqpZudp87n73
M0EW/tNZiiINF4c/Oix5YhoeJPwRtXAujH3Ccprt2SZbor4ognCJ+k+Lc3ZM8Nc1
K4LHEkmjqE3Ly15U1WgFvAp2TyMEZ0bFTQXvqy05MPVlTVWxBIAtNUuMg7vdodc8
ShdD6429UBrXOx2jODGpOX/AnGkCF35QkPWm36km+E8zrx4/PmW7hPNcE7QnAoiX
MRWLwL77l+RRHw==
=L7gS
-----END PGP SIGNATURE-----
Merge tag 'berlin-dt-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jszhang/linux-berlin into next/dt
berlin DT changes for v4.18
* tag 'berlin-dt-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jszhang/linux-berlin:
ARM: dts: berlin2q: move PMU node from soc to root
ARM: dts: berlin*-dts: use SPDX-License-Identifier for berlin based board
ARM: dts: berlin*.dtsi: use SPDX-License-Identifier for berlin SoCs
ARM: dts: berlin2: fix irq type for arm twd timer
ARM: dts: berlin2q: fix irq type for arm twd timer
ARM: dts: berlin2q: add "cache-unified" to l2 node
ARM: dts: berlin2q: add interrupt-affinity to pmu node
ARM: dts: chromecast: use PWM for LEDs
ARM: dts: chromecast: override bad bootloader memory info
ARM: dts: berlin2cd: add Valve Steam Link board
ARM: dts: berlin2cd: add a label for the CPU node
ARM: dts: berlin2cd: add remaining nodes to apb subtrees
ARM: dts: berlin2cd: add remaining Cortex-A9 nodes
ARM: dts: berlin2cd: add ADC/thermal sensor node
ARM: dts: berlin2cd: move PMU node from soc to root
ARM: dts: berlin2cd: fix local timer interrupt flags
Signed-off-by: Olof Johansson <olof@lixom.net>
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEE2MW6uuYZ+0zBfpF41kg+k28NbwgFAlsGU58THGpzemhhbmcz
QGdtYWlsLmNvbQAKCRDWSD6Tbw1vCOOzD/4wBhoFn/97yrZSJeOpbctEFmqjWuls
d1ogSCRTOvmlG6FwBXFoZiatF6DwMjkv0hKxuhW4wjmV6n9HwlgonAYXurHMAD0a
xSHbjEqvu1aX8XGPRq0WKa/oyQrCLCiiO6/9+hIfIZbGoRVkkLWBQ7KB+1UMpgPb
Y9BCoPaOrFR78emcNDjBVkZ+QWCnOm2MkQO7CZa8DOrgsNEW5247hE0c6H2fwRa1
5kulVElAs2XVlx9HXxiNbrhDA7kwvxCSJiFkCB/w3YsSdSk7RUN/cSXj5xSnFdPW
74gD/fCzLyL3vVkogegqBmpSh6NavppZlw0yJlDeszQGO/YXjDpu2Tol+Mp7KH0W
LdIJltdc/kqe7bw8eSm3cWwJiXtSIzFX5Rn456DxvezWUF4rjSZgUu41bnBR7KHw
Kq/w1800pU6pHFvx57Kq/zIid5usB83BoOVuMz0Ul86b/dbBvxQdzZlHbT0/ZVkD
l5UcaoCvNh4NzDbx5fRGLwTLcaUz0ZJb0M6MxM/Dm/+qebU/0tMowPsV9hk7G7Vb
QyfdU8b4dUYZAlFp+sSvEXXo1qfAREofdIpDsVYvTQqepdoelk8K93uzTUUdqWCc
INBpe0sZpT82vq1Rc2svyMysQhFKboyWwjR0DHOTOU64g8tC280M1ozB1eptf0N0
BQrlrw1ttJWmJA==
=corl
-----END PGP SIGNATURE-----
Merge tag 'berlin64-dt-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jszhang/linux-berlin into next/dt
Berlin64 DT changes for v4.18
* tag 'berlin64-dt-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jszhang/linux-berlin:
arm64: dts: move berlin SoC files from marvell dir to synaptics dir
arm64: dts: berlin4ct-*.dts: use SPDX-License-Identifier
arm64: dts: berlin4ct: use SPDX-License-Identifier
Signed-off-by: Olof Johansson <olof@lixom.net>
- remove MACH_MESON8B, only used for building DTs
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEe4dGDhaSf6n1v/EMWTcYmtP7xmUFAlsFpCUACgkQWTcYmtP7
xmUg/A//Sqw57ztxf6gIDCWV6dKdiflt6aZwxf3qlWVagS5/93zRPavfdqLEGBzv
mPOEY98dvFd65lMW6FscogRfeml3gKnhX/4Mew9L1PsShqYhvMPMSweuI6TOJ5KP
YlfF3lnjElXBXgWval+YDfEn33iQbaQre10iQa+qEE9XlUoSK8jkkDd6zP2t481B
EFl9nCvRydLENwtdsO6LnxeN8svFj/WQjdeuHXrMh/YECrphCA3eQVrGZLm6UtJU
eY499ZcdxPZW6nU5PTvC+JQ+7r4AjArmjUyWgjYdljMGtWsWB/eXLTaUkTJvyFVg
+yX2WI+R21d/YT8iJpQhM02HNXENgtHa3PsYFteO2PRgxtuGmD5C4tpL25FT62Dj
wVxVJrPnAadA6yZ9X1OOMIP0Qd2X0cI02iruXCld48h3koVJUFHjlxxzk3XIi2+8
1z0wNmTJd+I5HsNxLHLILy/rYsjM533FxyQvFROWCuMz+WhwF0Ypd/WrMvv7OnPl
p52T1/0nSi+aHLRjaHV+jbh7TO+pattYQ7vwXimNy2ZrHhH0OlS5CseC9JAkQsei
mXUORAlFhKIJr8LOSqWA+sj0MqCGE9//mC+JJyqvqDdtbYbR6idj0wLsfsA/1nub
m8It2huFmrrTtr7q57kAnkoEpkOmfxqDDfnBfEfANFkBYqP18bc=
=7Isa
-----END PGP SIGNATURE-----
Merge tag 'amlogic-dt-2' of https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into next/dt
Amlogic 32-bit DT changes for v4.18, round 2
- remove MACH_MESON8B, only used for building DTs
* tag 'amlogic-dt-2' of https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic:
ARM: meson: merge Kconfig symbol MACH_MESON8B into MACH_MESON8
ARM: dts: meson: build the Meson8b .dtbs with MACH_MESON8
Signed-off-by: Olof Johansson <olof@lixom.net>
