- 27 Jul, 2022 21 commits
-
-
Rashmica Gupta authored
Currently the perf CPU backend drivers detect what CPU they're on using cur_cpu_spec->oprofile_cpu_type. Although that works, it's a bit crufty to be using oprofile related fields, especially seeing as oprofile is more or less unused these days. It also means perf is reliant on the fragile logic in setup_cpu_spec() which detects when we're using a logical PVR and copies back the PMU related fields from the raw CPU entry. So lets check the PVR directly. Suggested-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> [chleroy: Added power10 and fixed checkpatch issues] Reviewed-and-tested-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Reviewed-and-tested-By: Kajol Jain <kjain@linux.ibm.com> [For 24x7 side changes] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20c0ee7f99dbf0dbf8658df6b39f84753e6db1ef.1657204631.git.christophe.leroy@csgroup.eu
-
Christophe Leroy authored
Since commit 4291d085 ("powerpc/32s: Make pte_update() non atomic on 603 core"), pte_update() has been using mmu_has_feature(MMU_FTR_HPTE_TABLE) to avoid a useless atomic operation on 603 cores. When kasan_early_init() sets up the early zero shadow, it uses __set_pte_at(). On book3s/32, __set_pte_at() calls pte_update() when CONFIG_SMP is selected in order to ensure the preservation of _PAGE_HASHPTE in case of concurrent update of the PTE. But that's too early for mmu_has_feature(), so when CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG is selected, mmu_has_feature() calls printk(). That's too early to call printk() because KASAN early zero shadow page is not set up yet. It leads to a deadlock. However, when kasan_early_init() is called, there is only one CPU running and no risk of concurrent PTE update. So __set_pte_at() can be called with the 'percpu' flag. With that flag set, the PTE is written directly instead of being written via pte_update(). Fixes: 4291d085 ("powerpc/32s: Make pte_update() non atomic on 603 core") Reported-by: Erhard Furtner <erhard_f@mailbox.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/2ee707512b8b212b079b877f4ceb525a1606a3fb.1656655567.git.christophe.leroy@csgroup.eu
-
Christophe Leroy authored
Always set an IBAT covering up to _einittext during init because when CONFIG_MODULES is not selected there is no reason to have an exception handler for kernel instruction TLB misses. It implies DBAT and IBAT are now totaly independent, IBATs are set by setibat() and DBAT by setbat(). This allows to revert commit 9bb162fa ("powerpc/603: Fix boot failure with DEBUG_PAGEALLOC and KFENCE") Reported-by: Maxime Bizon <mbizon@freebox.fr> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/ce7f04a39593934d9b1ee68c69144ccd3d4da4a1.1655202804.git.christophe.leroy@csgroup.eu
-
Christophe Leroy authored
mark_initmem_nx() calls either mmu_mark_initmem_nx() or set_memory_attr() based on return from v_block_mapped() of _sinittext. But we can now handle text and data independently, so that text may be mapped by block even when data is mapped by pages. On the 8xx for instance, at startup 32Mbytes of memory are pinned in TLB. So the pinned entries need to go away for sinittext. In next patch a BAT will be set to also covers sinittext on book3s/32. So it will also be needed to call mmu_mark_initmem_nx() even when data above sinittext is not mapped with BATs. As this is highly dependent on the platform, call mmu_mark_initmem_nx() regardless of data block mapping. Then the platform will know what to do. Modify 8xx mmu_mark_initmem_nx() so that inittext mapping is modified only when pagealloc debug and kfence are not active, otherwise inittext is mapped with standard pages. And don't do anything on kernel text which is already mapped with PAGE_KERNEL_TEXT. Fixes: da1adea0 ("powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/db3fc14f3bfa6215b0786ef58a6e2bc1e1f964d7.1655202804.git.christophe.leroy@csgroup.eu
-
Nicholas Piggin authored
cpu_to_node() is not yet available (setup_arch() is called before setup_per_cpu_areas() by start_kernel()). Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220711030653.150950-1-npiggin@gmail.com
-
Nicholas Piggin authored
Commit 6d8278c4 ("powerpc/64s/radix: do not flush TLB on spurious fault") removed the TLB flush for spurious faults, except when a coprocessor (nest MMU) maps the address space. This is not needed because the NMMU workaround in the PTE permission upgrade paths prevents PTEs existing with less restrictive access permissions than their corresponding TLB entries have. Remove it and replace with a comment. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220525022358.780745-4-npiggin@gmail.com
-
Nicholas Piggin authored
The nest MMU in POWER9 does not re-fetch the PTE in response to permission mismatch, contrary to the architecture[*] and unlike the core MMU. This requires a TLB flush before upgrading permissions of valid PTEs, for any address space with a coprocessor attached. Per (non-public) Nest MMU Workbook, POWER10 nest MMU conforms to the architecture in this regard, so skip the workaround. [*] See: Power ISA Version 3.1B, 6.10.1.2 Modifying a Translation Table Entry, 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 upgrade access authority, 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." Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220525022358.780745-3-npiggin@gmail.com
-
Nicholas Piggin authored
Per (non-public) Nest MMU Workbook, POWER10 and POWER9P NMMU does not cache PTEs in PWC, so does not require PWC flush to invalidate these translations. Skip the workaround on POWER10 and later. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220525022358.780745-2-npiggin@gmail.com
-
Nicholas Piggin authored
Take the arm64 HWCAP documentation file and adjust it for powerpc. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> [mpe: Fix ARCH_2_05 comment, as noticed by Tulio.] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220715012636.165948-1-npiggin@gmail.com
-
Nicholas Piggin authored
Processors with coherent icache require the sequence sync ; icbi ; isync to entire store->execute coherency. icbi (to any address) must be executed to ensure isync flushes the pipeline. See "POWER9 Processor User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi)" for details. __kernel_sync_dicache is missing icbi for the coherent icache path. Add it. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220520123649.258440-1-npiggin@gmail.com
-
Pali Rohár authored
By default on PPC32 PCI bus numbers are unique across all PCI domains. So a system could have only 256 PCI buses independently of available PCI domains. This is due to filling DT property pci-OF-bus-map which does not support a multi-domain setup. On all powerpc platforms except chrp and powermac there is no DT property pci-OF-bus-map anymore and therefore it is possible on non-chrp/powermac platforms to avoid this limitation of maximum number of 256 PCI buses in a system even on multi-domain setup. But avoiding this limitation would mean that all PCI and PCIe devices would be present on completely different BDF addresses as every PCI domain starts numbering PCI bueses from zero (instead of the last bus number of previous enumerated PCI domain). Such change could break existing software which expects fixed PCI bus numbers. So add a new config option CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT which enables this change. By default it is disabled. It causes the initial value of hose->first_busno to be zero. Signed-off-by: Pali Rohár <pali@kernel.org> [mpe: Minor change log wording] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220706104308.5390-6-pali@kernel.org
-
Pali Rohár authored
Creating or filling pci-OF-bus-map property in the device-tree is deprecated since May 2006 [1] and was used only in old platforms like PowerMac. Currently kernel code handles it only for chrp and powermac code. So completely disable filling pci-OF-bus-map property for non-chrp and non-powermac platforms. [1] - https://lore.kernel.org/linuxppc-dev/1148016268.13249.14.camel@localhost.localdomain/Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220706104308.5390-5-pali@kernel.org
-
Pali Rohár authored
Function pci_create_OF_bus_map() is used only in chrp code. So hide it from all other platforms. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220706104308.5390-4-pali@kernel.org
-
Pali Rohár authored
Function pcibios_make_OF_bus_map() is used only in pci_32.c. So make it static. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220706104308.5390-3-pali@kernel.org
-
Pali Rohár authored
Function pci_device_from_OF_node() is used only in powermac code. So hide it from all other platforms. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220706104308.5390-2-pali@kernel.org
-
Pali Rohár authored
CPLD firmware can reset board by writing value 0x01 at CPLD memory offset 0x0d. Define syscon-reboot node for this reset support. Fixes: 54c15ec3 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220713134429.18748-1-pali@kernel.org
-
Pali Rohár authored
By default old pre-3.0 Freescale PCIe controllers reports invalid PCI Class Code 0x0b20 for PCIe Root Port. It can be seen by lspci -b output on P2020 board which has this pre-3.0 controller: $ lspci -bvnn 00:00.0 Power PC [0b20]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21) !!! Invalid class 0b20 for header type 01 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Fix this issue by programming correct PCI Class Code 0x0604 for PCIe Root Port to the Freescale specific PCIe register 0x474. With this change lspci -b output is: $ lspci -bvnn 00:00.0 PCI bridge [0604]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21) (prog-if 00 [Normal decode]) Capabilities: [4c] Express Root Port (Slot-), MSI 00 Without any "Invalid class" error. So class code was properly reflected into standard (read-only) PCI register 0x08. Same fix is already implemented in U-Boot pcie_fsl.c driver in commit: http://source.denx.de/u-boot/u-boot/-/commit/d18d06ac35229345a0af80977a408cfbe1d1015b Fix activated by U-Boot stay active also after booting Linux kernel. But boards which use older U-Boot version without that fix are affected and still require this fix. So implement this class code fix also in kernel fsl_pci.c driver. Cc: stable@vger.kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220706101043.4867-1-pali@kernel.org
-
Masahiro Yamada authored
The .incbin assembler directive is much faster than bin2c + $(CC). Do similar refactoring as in commit 4c0f032d ("s390/purgatory: Omit use of bin2c"). Please note the .quad directive matches to size_t in C (both 8 byte) because the purgatory is compiled only for the 64-bit kernel. (KEXEC_FILE depends on PPC64). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220725015619.618070-1-masahiroy@kernel.org
-
Laurent Dufour authored
During an LPM, while the memory transfer is in progress on the arrival side, some latencies are generated when accessing not yet transferred pages on the arrival side. Thus, the NMI watchdog may be triggered too frequently, which increases the risk to hit an NMI interrupt in a bad place in the kernel, leading to a kernel panic. Disabling the Hard Lockup Watchdog until the memory transfer could be a too strong work around, some users would want this timeout to be eventually triggered if the system is hanging even during an LPM. Introduce a new sysctl variable nmi_watchdog_factor. It allows to apply a factor to the NMI watchdog timeout during an LPM. Just before the CPUs are stopped for the switchover sequence, the NMI watchdog timer is set to watchdog_thresh + factor% A value of 0 has no effect. The default value is 200, meaning that the NMI watchdog is set to 30s during LPM (based on a 10s watchdog_thresh value). Once the memory transfer is achieved, the factor is reset to 0. Setting this value to a high number is like disabling the NMI watchdog during an LPM. Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220713154729.80789-5-ldufour@linux.ibm.com
-
Laurent Dufour authored
Introduce a factor which would apply to the NMI watchdog timeout. This factor is a percentage added to the watchdog_tresh value. The value is set under the watchdog_mutex protection and lockup_detector_reconfigure() is called to recompute wd_panic_timeout_tb. Once the factor is set, it remains until it is set back to 0, which means no impact. Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220713154729.80789-4-ldufour@linux.ibm.com
-
Laurent Dufour authored
In some circumstances it may be interesting to reconfigure the watchdog from inside the kernel. On PowerPC, this may helpful before and after a LPAR migration (LPM) is initiated, because it implies some latencies, watchdog, and especially NMI watchdog is expected to be triggered during this operation. Reconfiguring the watchdog with a factor, would prevent it to happen too frequently during LPM. Rename lockup_detector_reconfigure() as __lockup_detector_reconfigure() and create a new function lockup_detector_reconfigure() calling __lockup_detector_reconfigure() under the protection of watchdog_mutex. Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> [mpe: Squash in build fix from Laurent, reported by Sachin] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220713154729.80789-3-ldufour@linux.ibm.com
-
- 25 Jul, 2022 16 commits
-
-
Laurent Dufour authored
In pseries_migration_partition(), loop until the memory transfer is complete. This way the calling drmgr process will not exit earlier, allowing callbacks to be run only once the migration is fully completed. If reading the VASI state is done after the hypervisor has completed the migration, the HCALL is returning H_PARAMETER. We can safely assume that the memory transfer is achieved if this happens. This will also allow to manage the NMI watchdog state in the next commits. Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220713154729.80789-2-ldufour@linux.ibm.com
-
Michael Ellerman authored
Currently the ptrace-gpr test only tests the GET/SET(FP)REGS ptrace APIs. But there's an alternate (older) API, called PEEK/POKEUSR. Add some minimal testing of PEEK/POKEUSR of the FPRs. This is sufficient to detect the bug that was fixed recently in the 32-bit ptrace FPR handling. Depends-on: 8e127844 ("powerpc/32: Fix overread/overwrite of thread_struct via ptrace") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-13-mpe@ellerman.id.au
-
Michael Ellerman authored
The ptrace-gpr test uses fixed values to test that registers can be read/written via ptrace. In particular it sets all GPRs to 1, which means the test could miss some types of bugs - eg. if the kernel was only returning the low word. So generate some random values at startup and use those instead. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-12-mpe@ellerman.id.au
-
Michael Ellerman authored
Use the FAIL_IF() macro so that errors in the child report a line number, rather than just silently exiting. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-11-mpe@ellerman.id.au
-
Michael Ellerman authored
The ptrace-gpr test includes some inline asm to load GPR and FPR registers. It then goes back to C to wait for the parent to trace it and then checks register contents. The split between inline asm and C is fragile, it relies on the compiler not using any non-volatile GPRs after the inline asm block. It also requires a very large and unwieldy inline asm block. So convert the logic to set registers, wait, and store registers to a single asm function, meaning there's no window for the compiler to intervene. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-10-mpe@ellerman.id.au
-
Michael Ellerman authored
The ptrace-gpr test can now be built 32-bit, so do that if that's the compiler default rather than forcing a 64-bit build. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-9-mpe@ellerman.id.au
-
Michael Ellerman authored
Some of the ptrace tests check the contents of floating pointer registers. Currently these use float, which is always 4 bytes, but the ptrace API supports saving/restoring 8 bytes per register, so switch to using doubles to exercise the code more fully. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-8-mpe@ellerman.id.au
-
Michael Ellerman authored
This function is never called, drop it. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-7-mpe@ellerman.id.au
-
Michael Ellerman authored
Add support for 32-bit builds to the asm helpers. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-6-mpe@ellerman.id.au
-
Michael Ellerman authored
Thare are some asm helpers for creating/popping stack frames in basic_asm.h. They always save/restore r2 (TOC pointer), but none of the selftests change r2, so it's unnecessary to save it by default. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-5-mpe@ellerman.id.au
-
Michael Ellerman authored
Thare are some asm helpers for creating/popping stack frames in basic_asm.h. They always save/restore CR, but none of the selftests tests touch non-volatile CR fields, so it's unnecessary to save them by default. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-4-mpe@ellerman.id.au
-
Michael Ellerman authored
Currently all ptrace tests are built 64-bit and with TM enabled. Only the TM tests need TM enabled, so split those out into a separate variable so that can be specified precisely. Split the rest of the tests into a variable, and add -m64 to CFLAGS for those tests, so that in a subsequent patch some tests can be made to build 32-bit. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-3-mpe@ellerman.id.au
-
Michael Ellerman authored
Set LOCAL_HDRS so header changes cause rebuilds. The lib.mk logic adds all the headers in LOCAL_HDRS as dependencies, so there's no need to also list them explicitly. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-2-mpe@ellerman.id.au
-
Michael Ellerman authored
The PUSH/POP_BASIC_STACK helpers in basic_asm.h do not ensure that the stack pointer is always 16-byte aligned, which is required per the ABI. Fix the macros to do the alignment if the caller fails to. Currently only one caller passes a non-aligned size, tm_signal_self(), which hasn't been caught in testing, presumably because it's a leaf function. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627140239.2464900-1-mpe@ellerman.id.au
-
Michael Ellerman authored
Since commit 87c78b61 ("powerpc: Fix all occurences of "the the"") fixed "the the", there's now a steady stream of patches fixing other duplicate words. Just fix them all at once, to save the overhead of dealing with individual patches for each case. This leaves a few cases of "that that", which in some contexts is correct. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220718095158.326606-1-mpe@ellerman.id.au
-
Michael Ellerman authored
Bring in a build fix for GCC12 from our fixes branch.
-
- 20 Jul, 2022 3 commits
-
-
Ning Qiang authored
In do_adb_query() function of drivers/macintosh/adb.c, req->data is copied form userland. The parameter "req->data[2]" is missing check, the array size of adb_handler[] is 16, so adb_handler[req->data[2]].original_address and adb_handler[req->data[2]].handler_id will lead to oob read. Cc: stable <stable@kernel.org> Signed-off-by: Ning Qiang <sohu0106@126.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220713153734.2248-1-sohu0106@126.com
-
Scott Cheloha authored
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits guest control of one or more virtual watchdog timers. The timers have millisecond granularity. The guest is terminated when a timer expires. This patch adds a watchdog driver for these timers, "pseries-wdt". pseries_wdt_probe() currently assumes the existence of only one platform device and always assigns it watchdogNumber 1. If we ever expose more than one timer to userspace we will need to devise a way to assign a distinct watchdogNumber to each platform device at device registration time. Signed-off-by: Scott Cheloha <cheloha@linux.ibm.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220713202335.1217647-5-cheloha@linux.ibm.com
-
Scott Cheloha authored
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits guest control of one or more virtual watchdog timers. These timers do not conform to PowerPC device conventions. They are not affixed to any extant bus, nor do they have full representation in the device tree. As a workaround we represent them as platform devices. This patch registers a single platform device, "pseries-wdt", with the platform bus if the FW_FEATURE_WATCHDOG flag is set. A driver for this device, "pseries-wdt", will be introduced in a subsequent patch. Signed-off-by: Scott Cheloha <cheloha@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220713202335.1217647-4-cheloha@linux.ibm.com
-