aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2022-05-03KVM: arm64: Wire up CP15 feature registers to their AArch64 equivalentsOliver Upton2-15/+78
KVM currently does not trap ID register accesses from an AArch32 EL1. This is painful for a couple of reasons. Certain unimplemented features are visible to AArch32 EL1, as we limit PMU to version 3 and the debug architecture to v8.0. Additionally, we attempt to paper over heterogeneous systems by using register values that are safe system-wide. All this hard work is completely sidestepped because KVM does not set TID3 for AArch32 guests. Fix up handling of CP15 feature registers by simply rerouting to their AArch64 aliases. Punt setting HCR_EL2.TID3 to a later change, as we need to fix up the oddball CP10 feature registers still. Signed-off-by: Oliver Upton <oupton@google.com> Reviewed-by: Reiji Watanabe <reijiw@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220503060205.2823727-4-oupton@google.com
2022-05-03KVM: arm64: Don't write to Rt unless sys_reg emulation succeedsOliver Upton1-6/+16
emulate_sys_reg() returns 1 unconditionally, even though a a system register access can fail. Furthermore, kvm_handle_sys_reg() writes to Rt for every register read, regardless of if it actually succeeded. Though this pattern is safe (as params.regval is initialized with the current value of Rt) it is a bit ugly. Indicate failure if the register access could not be emulated and only write to Rt on success. Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220503060205.2823727-3-oupton@google.com
2022-05-03KVM: arm64: Return a bool from emulate_cp()Oliver Upton1-10/+10
KVM indicates success/failure in several ways, but generally an integer is used when conditionally bouncing to userspace is involved. That is not the case from emulate_cp(); just use a bool instead. No functional change intended. Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220503060205.2823727-2-oupton@google.com
2022-05-03x86/entry: Move PUSH_AND_CLEAR_REGS out of error_entry()Lai Jiangshan1-3/+12
The macro idtentry() (through idtentry_body()) calls error_entry() unconditionally even on XENPV. But XENPV needs to only push and clear regs. PUSH_AND_CLEAR_REGS in error_entry() makes the stack not return to its original place when the function returns, which means it is not possible to convert it to a C function. Carve out PUSH_AND_CLEAR_REGS out of error_entry() and into a separate function and call it before error_entry() in order to avoid calling error_entry() on XENPV. It will also allow for error_entry() to be converted to C code that can use inlined sync_regs() and save a function call. [ bp: Massage commit message. ] Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220503032107.680190-4-jiangshanlai@gmail.com
2022-05-03x86/entry: Switch the stack after error_entry() returnsLai Jiangshan1-10/+6
error_entry() calls fixup_bad_iret() before sync_regs() if it is a fault from a bad IRET, to copy pt_regs to the kernel stack. It switches to the kernel stack directly after sync_regs(). But error_entry() itself is also a function call, so it has to stash the address it is going to return to, in %r12 which is unnecessarily complicated. Move the stack switching after error_entry() and get rid of the need to handle the return address. [ bp: Massage commit message. ] Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20220503032107.680190-3-jiangshanlai@gmail.com
2022-05-03arm64: dts: rockchip: rename HDMI ref clock to 'ref' on rk3399Sascha Hauer1-1/+1
The reference clock for the HDMI controller has been renamed to 'ref', the previous 'vpll' name is only left for compatibility in the driver. Rename the clock to the new name. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Link: https://lore.kernel.org/r/20220422072841.2206452-7-s.hauer@pengutronix.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-05-03x86/traps: Use pt_regs directly in fixup_bad_iret()Lai Jiangshan3-14/+12
Always stash the address error_entry() is going to return to, in %r12 and get rid of the void *error_entry_ret; slot in struct bad_iret_stack which was supposed to account for it and pt_regs pushed on the stack. After this, both fixup_bad_iret() and sync_regs() can work on a struct pt_regs pointer directly. [ bp: Rewrite commit message, touch ups. ] Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20220503032107.680190-2-jiangshanlai@gmail.com
2022-05-03ARM: dts: dm81xx: use new 'dma-channels/requests' propertiesKrzysztof Kozlowski2-0/+6
The '#dma-channels' and '#dma-requests' properties were deprecated in favor of these defined by generic dma-common DT bindings. Add new properties while keeping old ones for backwards compatibility. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Message-Id: <20220503065201.51818-7-krzysztof.kozlowski@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: am33xx: use new 'dma-channels/requests' propertiesKrzysztof Kozlowski1-0/+3
The '#dma-channels' and '#dma-requests' properties were deprecated in favor of these defined by generic dma-common DT bindings. Add new properties while keeping old ones for backwards compatibility. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Message-Id: <20220503065201.51818-5-krzysztof.kozlowski@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_CLKSEL1_EMU clocksTony Lindgren1-72/+80
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_CLKSEL_PER clocksTony Lindgren1-60/+68
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_ICLKEN_PER clocksTony Lindgren1-131/+139
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_FCLKEN_PER clocksTony Lindgren2-145/+160
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_FCLKEN_CAM clocksTony Lindgren1-15/+23
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_CLKSEL_DSS clocksTony Lindgren1-17/+25
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_FCLKEN_DSS clocksTony Lindgren3-34/+56
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_CLKOUT_CTRL clocksTony Lindgren1-22/+30
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_CLKSEL1_PLL clocksTony Lindgren1-32/+40
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_CLKSEL_WKUP clocksTony Lindgren2-22/+37
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_ICLKEN_WKUP clocksTony Lindgren2-47/+62
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_FCLKEN_WKUP clocksTony Lindgren3-41/+63
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_CLKSEL_CORE clocksTony Lindgren3-56/+78
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_ICLKEN3_CORE clocksTony Lindgren2-12/+29
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_ICLKEN1_CORE clocksTony Lindgren6-249/+292
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 crypto accelerator clocksTony Lindgren1-35/+42
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CM_FCLKEN1_CORE clocksTony Lindgren6-178/+221
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CONTROL_DEVCONF1 clocksTony Lindgren1-20/+28
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: Group omap3 CONTROL_DEVCONF0 clocksTony Lindgren1-14/+22
The clksel related registers on omap3 cause unique_unit_address and node_name_chars_strict warnings with the W=1 or W=2 make flags enabled. With the clock drivers updated, we can now avoid most of these warnings by grouping the TI component clocks using the TI clksel binding, and with the use of clock-output-names property to avoid non-standard node names for the clocks. Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: am43xx: Add i2c voltage scaling firmware to wkup_m3_ipcDave Gerlach3-0/+9
Add appropriate firmware-name property for all am43xx platforms. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> [dfustini: change property from 'ti,scale-data-fw' to 'firmware-name'] Signed-off-by: Drew Fustini <dfustini@baylibre.com> Message-Id: <20220502021508.1342869-4-dfustini@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: am33xx: Add i2c voltage scaling firmware to wkup_m3_ipcDave Gerlach3-0/+12
Add appropriate firmware-name property for all am33xx platforms. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> [dfustini: change property from 'ti,scale-data-fw' to 'firmware-name'] Signed-off-by: Drew Fustini <dfustini@baylibre.com> Message-Id: <20220502021508.1342869-3-dfustini@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03ARM: dts: am437x-gp-evm: Enable wkup_m3 control of IO isolationDave Gerlach1-0/+4
With this flag wkup_m3 is able to control IO isolation during suspend on the board. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Drew Fustini <dfustini@baylibre.com> Message-Id: <20220502021508.1342869-2-dfustini@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-05-03Backmerge tag 'v5.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-nextDave Airlie190-1119/+1187
Linux 5.18-rc5 There was a build fix for arm I wanted in drm-next, so backmerge rather then cherry-pick. Signed-off-by: Dave Airlie <airlied@redhat.com>
2022-05-02KVM: s390: Fix lockdep issue in vm memopJanis Schoetterl-Glausch1-1/+10
Issuing a memop on a protected vm does not make sense, neither is the memory readable/writable, nor does it make sense to check storage keys. This is why the ioctl will return -EINVAL when it detects the vm to be protected. However, in order to ensure that the vm cannot become protected during the memop, the kvm->lock would need to be taken for the duration of the ioctl. This is also required because kvm_s390_pv_is_protected asserts that the lock must be held. Instead, don't try to prevent this. If user space enables secure execution concurrently with a memop it must accecpt the possibility of the memop failing. Still check if the vm is currently protected, but without locking and consider it a heuristic. Fixes: ef11c9463ae0 ("KVM: s390: Add vm IOCTL for key checked guest absolute memory access") Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Link: https://lore.kernel.org/r/20220322153204.2637400-1-scgl@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-02KVM: VMX: Use vcpu_to_pi_desc() uniformly in posted_intr.cYuan Yao1-1/+1
The helper function, vcpu_to_pi_desc(), is defined to get the posted interrupt descriptor from vcpu. There is one place that doesn't use it, and instead references vmx_vcpu->pi_desc directly. Remove the inconsistency. Signed-off-by: Yuan Yao <yuan.yao@intel.com> Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com> Message-Id: <ee7be7832bc424546fd4f05015a844a0205b5ba2.1646422845.git.isaku.yamahata@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-02KVM: Add max_vcpus field in common 'struct kvm'Sean Christopherson3-9/+6
For TDX guests, the maximum number of vcpus needs to be specified when the TDX guest VM is initialized (creating the TDX data corresponding to TDX guest) before creating vcpu. It needs to record the maximum number of vcpus on VM creation (KVM_CREATE_VM) and return error if the number of vcpus exceeds it Because there is already max_vcpu member in arm64 struct kvm_arch, move it to common struct kvm and initialize it to KVM_MAX_VCPUS before kvm_arch_init_vm() instead of adding it to x86 struct kvm_arch. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com> Message-Id: <e53234cdee6a92357d06c80c03d77c19cdefb804.1646422845.git.isaku.yamahata@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-02KVM: x86: avoid loading a vCPU after .vm_destroy was calledMaxim Levitsky1-7/+3
This can cause various unexpected issues, since VM is partially destroyed at that point. For example when AVIC is enabled, this causes avic_vcpu_load to access physical id page entry which is already freed by .vm_destroy. Fixes: 8221c1370056 ("svm: Manage vcpu load/unload when enable AVIC") Cc: stable@vger.kernel.org Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Message-Id: <20220322172449.235575-2-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-02x86/sev: Fix address space sparse warningBorislav Petkov1-3/+6
Fix: arch/x86/kernel/sev.c:605:16: warning: incorrect type in assignment (different address spaces) arch/x86/kernel/sev.c:605:16: expected struct snp_secrets_page_layout *layout arch/x86/kernel/sev.c:605:16: got void [noderef] __iomem *[assigned] mem Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/202205022233.XgNDR7WR-lkp@intel.com
2022-05-02KVM: x86: replace bitmap_weight with bitmap_empty where appropriateYury Norov1-4/+4
In some places kvm/hyperv.c code calls bitmap_weight() to check if any bit of a given bitmap is set. It's better to use bitmap_empty() in that case because bitmap_empty() stops traversing the bitmap as soon as it finds first set bit, while bitmap_weight() counts all bits unconditionally. Signed-off-by: Yury Norov <yury.norov@gmail.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-05-02powerpc/sstep: Use bitwise instead of arithmetic operator for flagsYang Li1-3/+3
Fix the following coccinelle warnings: ./arch/powerpc/lib/sstep.c:1090:20-21: WARNING: sum of probable bitmasks, consider | ./arch/powerpc/lib/sstep.c:1115:20-21: WARNING: sum of probable bitmasks, consider | ./arch/powerpc/lib/sstep.c:1134:20-21: WARNING: sum of probable bitmasks, consider | Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1613811455-2457-1-git-send-email-yang.lee@linux.alibaba.com
2022-05-02powerpc/8xx: export 'cpm_setbrg' for modulesRandy Dunlap1-0/+1
Fix missing export for a loadable module build: ERROR: modpost: "cpm_setbrg" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined! Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> [chleroy: Changed Fixes: tag] Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210122010819.30986-1-rdunlap@infradead.org
2022-05-02powerpc/perf: Fix symbol undeclared warningWang Wensheng1-2/+2
Build kernel with `C=2`: arch/powerpc/perf/isa207-common.c:24:18: warning: symbol 'isa207_pmu_format_attr' was not declared. Should it be static? arch/powerpc/perf/power9-pmu.c:101:5: warning: symbol 'p9_dd21_bl_ev' was not declared. Should it be static? arch/powerpc/perf/power9-pmu.c:115:5: warning: symbol 'p9_dd22_bl_ev' was not declared. Should it be static? Those symbols are used only in the files that define them so we declare them as static to fix the warnings. Signed-off-by: Wang Wensheng <wangwensheng4@huawei.com> Reviewed-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200923071453.2540-1-wangwensheng4@huawei.com
2022-05-02powerpc/pseries/dlpar: Remove unnecessary cast to kfree()Xu Wang1-1/+1
Remove unnecassary cast in the argument to kfree(). Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200708072228.30776-1-vulab@iscas.ac.cn
2022-05-02ARM: dts: stm32: add support for Protonic PRTT1x boardsOleksij Rempel5-0/+651
This boards are based on STM32MP151AAD3 and use 10BaseT1L for communication. - PRTT1C - 10BaseT1L switch - PRTT1S - 10BaseT1L CO2 sensor board - PRTT1A - 10BaseT1L multi functional controller Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2022-05-02ARM: dts: stm32: stm32mp15-pinctrl: add spi1-1 pinmux groupOleksij Rempel1-0/+15
Add spi1-1 pingroup as preparation for Protonic PRTT1C board. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2022-05-02x86/fpu: Cleanup variable shadowingThomas Gleixner1-1/+1
Addresses: warning: Local variable 'mask' shadows outer variable Remove extra variable declaration and switch the bit mask assignment to use BIT_ULL() while at it. Fixes: 522e92743b35 ("x86/fpu: Deduplicate copy_uabi_from_user/kernel_to_xstate()") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/lkml/202204262032.jFYKit5j-lkp@intel.com
2022-05-02x86/aperfperf: Make it correct on 32bit and UP kernelsThomas Gleixner1-3/+3
The utilization of arch_scale_freq_tick() for CPU frequency readouts is incomplete as it failed to move the function prototype and the define out of the CONFIG_SMP && CONFIG_X86_64 #ifdef. Make them unconditionally available. Fixes: bb6e89df9028 ("x86/aperfmperf: Make parts of the frequency invariance code unconditional") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/lkml/202205010106.06xRBR2C-lkp@intel.com
2022-05-02microblaze: fix typos in commentsJulia Lawall2-2/+2
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/20220430191122.8667-1-Julia.Lawall@inria.fr Signed-off-by: Michal Simek <michal.simek@amd.com>
2022-05-01xtensa: clean up labels in the kernel entry assemblyMax Filippov1-47/+53
Don't use numeric labels for long jumps, use named local labels instead. Avoid conditional label definition. No functional changes. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2022-05-01xtensa: don't leave invalid TLB entry in fast_store_prohibitedMax Filippov1-1/+5
When fast_store_prohibited needs to go to the C-level exception handler it leaves TLB entry that caused page fault in the TLB. If the faulting task gets switched to a different CPU and completes page table update there the TLB entry will get out of sync with the page table which may cause a livelock on access to that page. Invalidate faulting TLB entry on a slow path exit from the fast_store_prohibited. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2022-05-01xtensa: fix declaration of _SecondaryResetVector_text_*Max Filippov1-1/+1
Secondary reset vector is defined, compiled and used when CONFIG_SECONDARY_RESET_VECTOR is enabled, not only on SMP. Make declarations of _SecondaryResetVector_text_* symbols available accordingly. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>