summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2021-04-08powerpc/64s: power4 nap fixup in CNicholas Piggin5-45/+35
There is no need for this to be in asm, use the new intrrupt entry wrapper. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Tested-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210406025508.821718-1-npiggin@gmail.com
2021-04-08powerpc/perf: Fix PMU constraint check for EBB eventsAthira Rajeev1-2/+2
The power PMU group constraints includes check for EBB events to make sure all events in a group must agree on EBB. This will prevent scheduling EBB and non-EBB events together. But in the existing check, settings for constraint mask and value is interchanged. Patch fixes the same. Before the patch, PMU selftest "cpu_event_pinned_vs_ebb_test" fails with below in dmesg logs. This happens because EBB event gets enabled along with a non-EBB cpu event. [35600.453346] cpu_event_pinne[41326]: illegal instruction (4) at 10004a18 nip 10004a18 lr 100049f8 code 1 in cpu_event_pinned_vs_ebb_test[10000000+10000] Test results after the patch: $ ./pmu/ebb/cpu_event_pinned_vs_ebb_test test: cpu_event_pinned_vs_ebb tags: git_version:v5.12-rc5-93-gf28c3125acd3-dirty Binding to cpu 8 EBB Handler is at 0x100050c8 read error on event 0x7fffe6bd4040! PM_RUN_INST_CMPL: result 9872 running/enabled 37930432 success: cpu_event_pinned_vs_ebb This bug was hidden by other logic until commit 1908dc911792 (perf: Tweak perf_event_attr::exclusive semantics). Fixes: 4df489991182 ("powerpc/perf: Add power8 EBB support") Reported-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com> [mpe: Mention commit 1908dc911792] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1617725761-1464-1-git-send-email-atrajeev@linux.vnet.ibm.com
2021-04-08powerpc/powernv/memtrace: Allow mmaping trace buffersJordan Niethe1-1/+17
Let the memory removed from the linear mapping to be used for the trace buffers be mmaped. This is a useful way of providing cache-inhibited memory for the alignment_handler selftest. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> [mpe: make memtrace_mmap() static as noticed by lkp@intel.com] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210225032108.1458352-1-jniethe5@gmail.com
2021-04-08powerpc/kexec: Don't use .machine ppc64 in trampoline_64.SMichael Ellerman1-1/+0
As best as I can tell the ".machine" directive in trampoline_64.S is no longer, or never was, necessary. It was added in commit 0d97631392c2 ("powerpc: Add purgatory for kexec_file_load() implementation."), which created the file based on the kexec-tools purgatory. It may be/have-been necessary in the kexec-tools version, but we have a completely different build system, and we already pass the desired CPU flags, eg: gcc ... -m64 -Wl,-a64 -mabi=elfv2 -Wa,-maltivec -Wa,-mpower4 -Wa,-many ... arch/powerpc/purgatory/trampoline_64.S So drop the ".machine" directive and rely on the assembler flags. Reported-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Link: https://lore.kernel.org/r/20210315034159.315675-1-mpe@ellerman.id.au
2021-04-08powerpc/64: Move security code into security.cMichael Ellerman2-264/+261
When the original spectre/meltdown mitigations were merged we put them in setup_64.c for lack of a better place. Since then we created security.c for some of the other mitigation related code. But it should all be in there. This sort of code movement can cause trouble for backports, but hopefully this code is relatively stable these days (famous last words). Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210326101201.1973552-1-mpe@ellerman.id.au
2021-04-08powerpc/mm/64s: Allow STRICT_KERNEL_RWX againMichael Ellerman1-1/+1
We have now fixed the known bugs in STRICT_KERNEL_RWX for Book3S 64-bit Hash and Radix MMUs, see preceding commits, so allow the option to be selected again. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210331003845.216246-6-mpe@ellerman.id.au
2021-04-08powerpc/mm/64s/hash: Add real-mode change_memory_range() for hash LPARMichael Ellerman1-1/+104
When we enabled STRICT_KERNEL_RWX we received some reports of boot failures when using the Hash MMU and running under phyp. The crashes are intermittent, and often exhibit as a completely unresponsive system, or possibly an oops. One example, which was caught in xmon: [ 14.068327][ T1] devtmpfs: mounted [ 14.069302][ T1] Freeing unused kernel memory: 5568K [ 14.142060][ T347] BUG: Unable to handle kernel instruction fetch [ 14.142063][ T1] Run /sbin/init as init process [ 14.142074][ T347] Faulting instruction address: 0xc000000000004400 cpu 0x2: Vector: 400 (Instruction Access) at [c00000000c7475e0] pc: c000000000004400: exc_virt_0x4400_instruction_access+0x0/0x80 lr: c0000000001862d4: update_rq_clock+0x44/0x110 sp: c00000000c747880 msr: 8000000040001031 current = 0xc00000000c60d380 paca = 0xc00000001ec9de80 irqmask: 0x03 irq_happened: 0x01 pid = 347, comm = kworker/2:1 ... enter ? for help [c00000000c747880] c0000000001862d4 update_rq_clock+0x44/0x110 (unreliable) [c00000000c7478f0] c000000000198794 update_blocked_averages+0xb4/0x6d0 [c00000000c7479f0] c000000000198e40 update_nohz_stats+0x90/0xd0 [c00000000c747a20] c0000000001a13b4 _nohz_idle_balance+0x164/0x390 [c00000000c747b10] c0000000001a1af8 newidle_balance+0x478/0x610 [c00000000c747be0] c0000000001a1d48 pick_next_task_fair+0x58/0x480 [c00000000c747c40] c000000000eaab5c __schedule+0x12c/0x950 [c00000000c747cd0] c000000000eab3e8 schedule+0x68/0x120 [c00000000c747d00] c00000000016b730 worker_thread+0x130/0x640 [c00000000c747da0] c000000000174d50 kthread+0x1a0/0x1b0 [c00000000c747e10] c00000000000e0f0 ret_from_kernel_thread+0x5c/0x6c This shows that CPU 2, which was idle, woke up and then appears to randomly take an instruction fault on a completely valid area of kernel text. The cause turns out to be the call to hash__mark_rodata_ro(), late in boot. Due to the way we layout text and rodata, that function actually changes the permissions for all of text and rodata to read-only plus execute. To do the permission change we use a hypervisor call, H_PROTECT. On phyp that appears to be implemented by briefly removing the mapping of the kernel text, before putting it back with the updated permissions. If any other CPU is executing during that window, it will see spurious faults on the kernel text and/or data, leading to crashes. To fix it we use stop machine to collect all other CPUs, and then have them drop into real mode (MMU off), while we change the mapping. That way they are unaffected by the mapping temporarily disappearing. We don't see this bug on KVM because KVM always use VPM=1, where faults are directed to the hypervisor, and the fault will be serialised vs the h_protect() by HPTE_V_HVLOCK. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210331003845.216246-5-mpe@ellerman.id.au
2021-04-08powerpc/mm/64s/hash: Factor out change_memory_range()Michael Ellerman1-8/+15
Pull the loop calling hpte_updateboltedpp() out of hash__change_memory_range() into a helper function. We need it to be a separate function for the next patch. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210331003845.216246-4-mpe@ellerman.id.au
2021-04-08powerpc/64s: Use htab_convert_pte_flags() in hash__mark_rodata_ro()Michael Ellerman1-2/+4
In hash__mark_rodata_ro() we pass the raw PP_RXXX value to hash__change_memory_range(). That has the effect of setting the key to zero, because PP_RXXX contains no key value. Fix it by using htab_convert_pte_flags(), which knows how to convert a pgprot into a pp value, including the key. Fixes: d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Daniel Axtens <dja@axtens.net> Link: https://lore.kernel.org/r/20210331003845.216246-3-mpe@ellerman.id.au
2021-04-08powerpc/pseries: Add key to flags in pSeries_lpar_hpte_updateboltedpp()Michael Ellerman1-1/+3
The flags argument to plpar_pte_protect() (aka. H_PROTECT), includes the key in bits 9-13, but currently we always set those bits to zero. In the past that hasn't been a problem because we always used key 0 for the kernel, and updateboltedpp() is only used for kernel mappings. However since commit d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation") we are now inadvertently changing the key (to zero) when we call plpar_pte_protect(). That hasn't broken anything because updateboltedpp() is only used for STRICT_KERNEL_RWX, which is currently disabled on 64s due to other bugs. But we want to fix that, so first we need to pass the key correctly to plpar_pte_protect(). We can't pass our newpp value directly in, we have to convert it into the form expected by the hcall. The hcall we're using here is H_PROTECT, which is specified in section 14.5.4.1.6 of LoPAPR v1.1. It takes a `flags` parameter, and the description for flags says: * flags: AVPN, pp0, pp1, pp2, key0-key4, n, and for the CMO option: CMO Option flags as defined in Table 189‚ If you then go to the start of the parent section, 14.5.4.1, on page 405, it says: Register Linkage (For hcall() tokens 0x04 - 0x18) * On Call * R3 function call token * R4 flags (see Table 178‚ “Page Frame Table Access flags field definition‚” on page 401) Then you have to go to section 14.5.3, and on page 394 there is a list of hcalls and their tokens (table 176), and there you can see that H_PROTECT == 0x18. Finally you can look at table 178, on page 401, where it specifies the layout of the bits for the key: Bit Function ----------------- 50-54 | key0-key4 Those are big-endian bit numbers, converting to normal bit numbers you get bits 9-13, or 0x3e00. In the kernel we have: #define HPTE_R_KEY_HI ASM_CONST(0x3000000000000000) #define HPTE_R_KEY_LO ASM_CONST(0x0000000000000e00) So the LO bits of newpp are already in the right place, and the HI bits need to be shifted down by 48. Fixes: d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210331003845.216246-2-mpe@ellerman.id.au
2021-04-08powerpc/mm/64s: Add _PAGE_KERNEL_ROXMichael Ellerman1-0/+1
In the past we had a fallback definition for _PAGE_KERNEL_ROX, but we removed that in commit d82fd29c5a8c ("powerpc/mm: Distribute platform specific PAGE and PMD flags and definitions") and added definitions for each MMU family. However we missed adding a definition for 64s, which was not really a bug because it's currently not used. But we'd like to use PAGE_KERNEL_ROX in a future patch so add a definition now. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210331003845.216246-1-mpe@ellerman.id.au
2021-04-08powerpc/64s: Fix pte update for kernel memory on radixJordan Niethe2-4/+6
When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults. As the code patching is done using __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen: BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1 This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/ Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) & Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------ ftrace failed to modify [<c000000000bf8e5c>] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here ]------------ WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call Trace: ftrace_bug+0x288/0x2e8 (unreliable) ftrace_modify_all_code+0x168/0x210 arch_ftrace_update_code+0x18/0x30 ftrace_run_update_code+0x44/0xc0 ftrace_startup+0xf8/0x1c0 register_ftrace_function+0x4c/0xc0 function_trace_init+0x80/0xb0 tracing_set_tracer+0x2a4/0x4f0 tracing_set_trace_write+0xd4/0x130 vfs_write+0xf0/0x330 ksys_write+0x84/0x140 system_call_exception+0x14c/0x230 system_call_common+0xf0/0x27c To fix this when updating kernel memory PTEs using ptesync. Fixes: f1cb8f9beba8 ("powerpc/64s/radix: avoid ptesync after set_pte and ptep_set_access_flags") Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Tidy up change log slightly] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210208032957.1232102-1-jniethe5@gmail.com
2021-04-08powerpc: Spelling/typo fixesBhaskar Chowdhury3-3/+3
Various spelling/typo fixes. Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2021-04-08Merge remote-tracking branch 'arm64/for-next/fiq'Hector Martin10-70/+123
The FIQ support series, already merged into arm64, is a dependency of the M1 bring-up series and was split off after the first few versions. Signed-off-by: Hector Martin <marcan@marcan.st>
2021-04-08Merge commit '71b25f4df984' from tty/tty-nextHector Martin2-39/+7
This point in gregkh's tty-next tree includes all the samsung_tty changes that were part of v3 of the M1 bring-up series, and have already been merged in. Signed-off-by: Hector Martin <marcan@marcan.st>
2021-04-08x86/msr: Make locally used functions staticZhao Xuehui1-2/+2
The functions msr_read() and msr_write() are not used outside of msr.c, make them static. [ bp: Massage commit message. ] Signed-off-by: Zhao Xuehui <zhaoxuehui1@huawei.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210408095218.152264-1-zhaoxuehui1@huawei.com
2021-04-08ARM: dts: Add board-specific compatible string to npcm750-evb devicetreeJonathan Neuschäfer1-1/+1
According to the revised binding, the devicetree needs a board-specific compatible string. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20210320164023.614059-2-j.neuschaefer@gmx.net Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: nuvoton: Add Quanta GBS BMC Device TreeGeorge Hung2-0/+1136
Add the device tree for the Quanta GBS BMC based on NPCM730 SoC. Signed-off-by: George Hung <george.hung@quantatw.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20210330071336.18370-1-george.hung@quantatw.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: mihawk: Add GPIO line namesNichole Wang1-0/+33
Name the GPIOs to help userspace work with them. The names describe the functionality the lines provide, not the net or ball name. This makes it easier to share userspace code across different systems and makes the use of the lines more obvious. Signed-off-by: Nichole Wang <Nichole_Wang@wistron.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20210330020808.830-1-Nichole_Wang@wistron.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: Add Rainier 1S4U machineEddie James3-1/+16
The 1S4U version of the Rainier system has only 4 fans. Create a new tree, include the 4U version, and delete the 2 extra fans. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-23-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: Add size/address cellsJoel Stanley1-0/+4
The gpio and fan nodes reg properties cause dtc to emit a noisy warning about relying on default sizes. Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: Enable fan watchdogEddie James1-0/+14
Set watchdog 1 to pulse the fan watchdog circuit that drives the FAULT pin of the MAX31785, resulting in fans running at full speed, if at any point the BMC stops pulsing it, such as a BMC reboot at runtime. Enable watchdog 2 for BMC reboots. Signed-off-by: Matthew Barth <msbarth@linux.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-21-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: Add RTCEddie James1-0/+5
Add the RTC at the appropriate I2C bus and address. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-20-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: GPIOs supportAlpana Kumari1-0/+297
This commit adds support for- - Presence GPIOs - I2C control GPIOs - Op-panel GPIOs (ex PHR) Signed-off-by: Alpana Kumari <alpankum@in.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Brandon Wyman <bjwyman@gmail.com> Link: https://lore.kernel.org/r/20210329150020.13632-19-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: Add UCD90320 power sequencerJim Wright1-0/+5
Add UCD90320 chip to Everest device tree. Signed-off-by: Jim Wright <jlwright@us.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-18-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: Add power supply i2c devicesBrandon Wyman1-0/+20
Add the i2c/pmbus power supply devices to the everest device tree. Signed-off-by: Brandon Wyman <bjwyman@gmail.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-17-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: Add pca9552 fan presenceMatthew Barth1-0/+128
Add the pca9552 at address 0x61 on i2c14 behind mux0 channel 3 with the 4 GPIO fan presence inputs. Signed-off-by: Matthew Barth <msbarth@us.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Brandon Wyman <bjwyman@gmail.com> Link: https://lore.kernel.org/r/20210329150020.13632-16-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: Add FSI CFAMs and re-number enginesEddie James1-4/+644
Add additional CFAMs and re-number the existing engines for the extra processors present on the Everest system. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-15-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: Add max31785 fan controller deviceMatthew Barth1-4/+40
Add the max31785 configuration at address 0x52 on i2c14 behind mux0 channel 3. Signed-off-by: Matthew Barth <msbarth@us.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-14-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: everest: Add I2C componentsPriyanga Ramasamy1-0/+408
Tested and able to bound the devices with i2c driver. Signed-off-by: Priyanga Ramasamy <priyanga24@in.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-13-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: rainier 4U: Fix fan configurationEddie James1-0/+14
The 4U fans didn't have the correct properties since the fan nodes were redefined. Fix this by referencing each fan individually and adding the differences to the 4U fans. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-12-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: rainier: Add missing fan nodesJoel Stanley1-0/+12
The Maxim fan controller has six fans attached. Two of these were missing from the description. Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: rainier: Enable fan watchdogEddie James1-0/+14
Set watchdog 1 to pulse the fan watchdog circuit that drives the FAULT pin of the MAX31785, resulting in fans running at full speed, if at any point the BMC stops pulsing it, such as a BMC reboot at runtime. Enable watchdog 2 for BMC reboots. Signed-off-by: Matthew Barth <msbarth@linux.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Acked-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210329150020.13632-11-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: rainier: Add presence GPIOsAlpana Kumari1-8/+248
This commit adds presence detect GPIO chips for various FRUs on Rainier. Also, correct the I2C address for the tca9554. Signed-off-by: Alpana Kumari <alpankum@in.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-10-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: rainier: Add additional processor CFAMsEddie James1-2/+281
Rainier has two dual-chip modules and therefore four CFAMs with their associated engines. Add these to the devicetree with the i2c busses that have devices on them. Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20210329150020.13632-5-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: rainier: Add gpio-keys-polled for fansBrandon Wyman1-0/+43
Add a gpio-keys-polled section to the Rainier device tree for the fan presence signals on the PCA9552 I2C device on bus 7. Signed-off-by: Brandon Wyman <bjwyman@gmail.com> Signed-off-by: Matthew Barth <msbarth@linux.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-4-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: rainier: Add directly controlled LEDsVishwanatha Subbanna1-2/+26
These LEDs are directly connected to the BMC's GPIO bank. Signed-off-by: Vishwanatha Subbanna <vishwa@linux.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210329150020.13632-3-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-08ARM: dts: aspeed: Add ASRock E3C246D4I BMCZev Weiss2-0/+203
This is a relatively low-cost AST2500-based Xeon E-2100/E-2200 series mini-ITX board that we hope can provide a decent platform for OpenBMC development. This initial device-tree provides the necessary configuration for basic BMC functionality such as host power control, serial console and KVM support, and POST code snooping. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20210401044232.9637-1-zev@bewilderbeest.net Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-04-07ARM: dts: mvebu: Add device tree for ATL-x530 BoardAryan Srivastava2-0/+236
Add device tree file for x530 board. This has an Armada 385 SoC. Has NAND-flash for user storage and SPI for booting. Covers majority of x530 and GS980MX variants. Signed-off-by: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2021-04-07Merge tag 'arc-5.12-rc7' of ↵Linus Torvalds3-16/+17
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixlets from Vineet Gupta: "A few straggler fixes for ARC" * tag 'arc-5.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: treewide: avoid the pointer addition with NULL pointer arc: kernel: Return -EFAULT if copy_to_user() fails ARC: haps: bump memory to 1 GB
2021-04-07x86/cacheinfo: Remove unneeded dead-store initializationYang Li1-1/+1
$ make CC=clang clang-analyzer (needs clang-tidy installed on the system too) on x86_64 defconfig triggers: arch/x86/kernel/cpu/cacheinfo.c:880:24: warning: Value stored to 'this_cpu_ci' \ during its initialization is never read [clang-analyzer-deadcode.DeadStores] struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu); ^ arch/x86/kernel/cpu/cacheinfo.c:880:24: note: Value stored to 'this_cpu_ci' \ during its initialization is never read So simply remove this unneeded dead-store initialization. As compilers will detect this unneeded assignment and optimize this anyway the resulting object code is identical before and after this change. No functional change. No change to object code. [ bp: Massage commit message. ] Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lkml.kernel.org/r/1617177624-24670-1-git-send-email-yang.lee@linux.alibaba.com
2021-04-07Merge tag 'at91-dt-5.13' of ↵Arnd Bergmann11-12/+21
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/dt AT91 dt for 5.13: - two little fixes (typo, W=1) - a change in gpio button keycode for recent boards * tag 'at91-dt-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: dts: at91: sama5d2: add ETB and ETM unit name ARM: dts: at91: change the key code of the gpio key ARM: dts: at91: Fix a typo Link: https://lore.kernel.org/r/20210407114415.13180-1-nicolas.ferre@microchip.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-04-07ACPI: processor: Fix build when CONFIG_ACPI_PROCESSOR=mVitaly Kuznetsov2-15/+13
Commit 8cdddd182bd7 ("ACPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead()") tried to fix CPU0 hotplug breakage by copying wakeup_cpu0() + start_cpu0() logic from hlt_play_dead()//mwait_play_dead() into acpi_idle_play_dead(). The problem is that these functions are not exported to modules so when CONFIG_ACPI_PROCESSOR=m build fails. The issue could've been fixed by exporting both wakeup_cpu0()/start_cpu0() (the later from assembly) but it seems putting the whole pattern into a new function and exporting it instead is better. Reported-by: kernel test robot <lkp@intel.com> Fixes: 8cdddd182bd7 ("CPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead()") Cc: <stable@vger.kernel.org> # 5.10+ Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-04-07Merge tag 'arm-fixes-5.11-2' of ↵Linus Torvalds15-32/+71
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Most of the changes again are devicetree fixes, but there are also five trivial build fixes for issues I found when test building with gcc-11 or when running 'make W=1', and some OMAP platform specific code fixups. Broadcom: - One revert for a Raspberry pi interrupt controller change that caused a regression. TI OMAP: - Remove unused duplicate sha2md5_fck clock node that can race with the OMAP4_SHA2MD5_CLKCTRL clock node for disable for unused clocks - Add aliases for omap4/5 mmc to put the slots back into the right order again - Fix typo for bionic voltage controllers that accidentally use mpu for all instances instead of mpu, core and iva - Fix random hangs for droid4 caused by missing fix from TI Android kernel tree to do a dummy smc call on cpuidle wakeup path NXP i.MX: - Fix a system failure on imx6qdl-phytec-pfla02 board when booting from SD, by adding missing vmmc supply for SD interfaces. - Fix address typo in i.MX8MM/Q IOMUXC_SD1_DATA0_GPIO2_IO2 definition. Marvell mvebu: - Fix storm interrupt on Turris Omnia - Enable hardware buffer management as it should be ... and build fixes for PXA, Freescale, Marvell, OMAP1 and Keystone" * tag 'arm-fixes-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin ARM: dts: turris-omnia: fix hardware buffer management Revert "arm64: dts: marvell: armada-cp110: Switch to per-port SATA interrupts" ARM: mvebu: avoid clang -Wtautological-constant warning ARM: pxa: mainstone: avoid -Woverride-init warning ARM: omap1: fix building with clang IAS soc/fsl: qbman: fix conflicting alignment attributes ARM: keystone: fix integer overflow warning ARM: dts: imx6: pbab01: Set vmmc supply for both SD interfaces arm64: dts: imx8mm/q: Fix pad control of SD1_DATA0 ARM: OMAP4: PM: update ROM return address for OSWR and OFF ARM: OMAP4: Fix PMIC voltage domains for bionic ARM: dts: Fix moving mmc devices with aliases for omap4 & 5 ARM: dts: Drop duplicate sha2md5_fck to fix clk_disable race Revert "ARM: dts: bcm2711: Add the BSC interrupt controller"
2021-04-07arm64: dts: meson: add GPIO line names to ODROID N2/N2+Hyeonki Hong1-0/+45
Add GPIO line-name identifiers to the ODROID N2/N2+ common dtsi. Signed-off-by: Hyeonki Hong <hhk7734@gmail.com> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20210407042609.9736-4-christianshewitt@gmail.com
2021-04-07arm64: dts: meson: add saradc node to ODROID N2/N2+Hyeonki Hong1-0/+5
Add the meson saradc node to the ODROID N2/N2+ common dtsi. Signed-off-by: Hyeonki Hong <hhk7734@gmail.com> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20210407042609.9736-3-christianshewitt@gmail.com
2021-04-07arm64: dts: meson: remove extra tab from ODROID N2/N2+ ext_mdio nodeChristian Hewitt1-1/+1
Remove an extra tab from the ext_mdio node in the ODROID N2/N2+ common dtsi file. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20210407042609.9736-2-christianshewitt@gmail.com
2021-04-07KVM: arm64: Initialize VCPU mdcr_el2 before loading itAlexandru Elisei3-28/+63
When a VCPU is created, the kvm_vcpu struct is initialized to zero in kvm_vm_ioctl_create_vcpu(). On VHE systems, the first time vcpu.arch.mdcr_el2 is loaded on hardware is in vcpu_load(), before it is set to a sensible value in kvm_arm_setup_debug() later in the run loop. The result is that KVM executes for a short time with MDCR_EL2 set to zero. This has several unintended consequences: * Setting MDCR_EL2.HPMN to 0 is constrained unpredictable according to ARM DDI 0487G.a, page D13-3820. The behavior specified by the architecture in this case is for the PE to behave as if MDCR_EL2.HPMN is set to a value less than or equal to PMCR_EL0.N, which means that an unknown number of counters are now disabled by MDCR_EL2.HPME, which is zero. * The host configuration for the other debug features controlled by MDCR_EL2 is temporarily lost. This has been harmless so far, as Linux doesn't use the other fields, but that might change in the future. Let's avoid both issues by initializing the VCPU's mdcr_el2 field in kvm_vcpu_vcpu_first_run_init(), thus making sure that the MDCR_EL2 register has a consistent value after each vcpu_load(). Fixes: d5a21bcc2995 ("KVM: arm64: Move common VHE/non-VHE trap config in separate functions") Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210407144857.199746-3-alexandru.elisei@arm.com
2021-04-07Merge tag 'samsung-dt64-5.13' of ↵Arnd Bergmann2-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt Samsung DTS ARM64 changes for v5.13 Two cleanups in DTS without expected impact. * tag 'samsung-dt64-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: arm64: dts: exynos: white-space cleanups arm64: dts: exynos: re-order Slim SSS clocks to match dtschema Link: https://lore.kernel.org/r/20210407065828.7213-2-krzysztof.kozlowski@canonical.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-04-07Merge tag 'samsung-dt-5.13' of ↵Arnd Bergmann12-54/+110
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt Samsung DTS ARM changes for v5.13 1. Configure battery charger and front camera on GT-I9100 phone. 2. Fix in several boards the Maxim PMIC/MUIC/fuel gauge interrupt flags to match real type of interrupt coming from the device. 3. Correct DTS with dtschema. This brings back the commit adding input clock to CMU in Exynos4412 Odroid which was reverted some time ago due to unsupported deferred probes (now supported and tested). * tag 'samsung-dt-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: dts: exynos: Add front camera support to I9100 ARM: dts: exynos: white-space cleanups ARM: dts: exynos: replace deprecated NTC/Murata compatibles ARM: dts: exynos: add input clock to CMU in Exynos4412 Odroid ARM: dts: s5pv210: correct fuel gauge interrupt trigger level on Fascinate family ARM: dts: exynos: correct PMIC interrupt trigger level on Snow ARM: dts: exynos: correct PMIC interrupt trigger level on SMDK5250 ARM: dts: exynos: correct PMIC interrupt trigger level on P4 Note family ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid X/U3 family ARM: dts: exynos: correct PMIC interrupt trigger level on Midas family ARM: dts: exynos: correct MUIC interrupt trigger level on Midas family ARM: dts: exynos: correct fuel gauge interrupt trigger level on Midas family ARM: dts: exynos: correct fuel gauge interrupt trigger level on P4 Note family ARM: dts: exynos: correct fuel gauge interrupt trigger level on GT-I9100 ARM: dts: exynos: add charger supply for I9100 Link: https://lore.kernel.org/r/20210407065828.7213-1-krzysztof.kozlowski@canonical.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-13 04:23:37 +0300