aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2022-05-09ARM: configs: Enable audio on BeagleBone Black in multi_v7_defconfigMark Brown1-0/+2
The BeagleBone Black supports audio over HDMI, using a combination of the DaVinci McASP (used for audio by a very large proportion of DaVinci systems with audio support) and a TDA998x device driving the HDMI link (this is a very widely used driver). Build both drivers as modules in multi_v7_defconfig so they can be more easily included in testing. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220506222646.1671474-1-broonie@kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-09Merge tag 'sunxi-dt-for-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/dtArnd Bergmann1-1/+0
- F1C100 improvements (SPI, MMC, timer, cpu, watchdog) - SPI flash node for licheepi-nano - enabled analogue audio on olinuxino-a64 - GPIO port regulators on teres-i - remove undocumented property from nanopi * tag 'sunxi-dt-for-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: ARM: dts: sunxi: nanopi: Remove input-name property Link: https://lore.kernel.org/r/Yngton59OacOR2ht@kista.localdomain Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-09Merge tag 'ti-k3-dt-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into arm/dtArnd Bergmann9-12/+988
TI K3 device tree updates for v5.19 New Features: J721e: * Enable DSS, DP, HDMI on J721e EVM and SK AM62: * MCAN, MCU GPIO, ECAP APWM, DMA, Etherent and several peripheral on AM62 SK EVM AM64: * Enable Wireless LAN support Fixes: Drop incorrect MCU UART clock rates * tag 'ti-k3-dt-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: arm64: dts: ti: k3-j721e-sk: Enable HDMI arm64: dts: ti: k3-j721e-sk: Enable DisplayPort arm64: dts: ti: k3-j721e-common-proc-board: add DP to j7 evm arm64: dts: ti: k3-j721e-*: add DP & DP PHY arm64: dts: ti: k3-am62: Add SA3UL ranges in cbass_main arm64: dts: ti: k3-am62: Add support for MCAN arm64: dts: ti: k3-am62-mcu: Enable MCU GPIO module arm64: dts: ti: k3-am625-sk: Add ECAP APWM nodes arm64: dts: ti: k3-am625-sk: Enable on board peripherals arm64: dts: ti: k3-am62: Add more peripheral nodes arm64: dts: ti: k3-am642-sk: Enable WLAN connected to SDHCI0 arm64: dts: ti: k3-am64-mcu: remove incorrect UART base clock rates Link: https://lore.kernel.org/r/3dc2011b-eb6d-dcd5-3921-57f6a1cf6d8e@ti.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-09Merge tag 'ti-keystone-dt-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into arm/dtArnd Bergmann5-8/+8
Keystone2 device tree updates for v5.19 * Cleanups for SPI NOR / flash * tag 'ti-keystone-dt-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: ARM: dts: keystone: Fix missing fallback and case in SPI NOR node compatible ARM: dts: keystone: Align SPI NOR node name with dtschema Link: https://lore.kernel.org/r/20220507163435.tcg46cacwqhe7n64@busily Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-09m68k: math-emu: Fix typos in commentsJulia Lawall1-1/+1
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-7-Julia.Lawall@inria.fr Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2022-05-09m68k: Wire up syscall_trace_enter/leave for m68kMichael Schmitz2-9/+2
m68k (other than Coldfire) uses syscall_trace for both trace entry and trace exit. Seccomp support requires separate entry points for trace entry and exit which are already provided for Coldfire. Replace syscall_trace by syscall_trace_enter and syscall_trace_leave in preparation for seccomp support. No regression seen in testing with strace on ARAnyM. Signed-off-by: Michael Schmitz <schmitzmic@gmail.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Link: https://lore.kernel.org/r/20220127074158.25888-2-schmitzmic@gmail.com Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2022-05-09s390/pai: add support for cryptography countersThomas Richter9-7/+784
PMU device driver perf_pai_crypto supports Processor Activity Instrumentation (PAI), available with IBM z16: - maps a full page to lowcore address 0x1500. - uses CR0 bit 13 to turn PAI crypto counting on and off. - creates a sample with raw data on each context switch out when at context switch some mapped counters have a value of nonzero. This device driver only supports CPU wide context, no task context is allowed. Support for counting: - one or more counters can be specified using perf stat -e pai_crypto/xxx/ where xxx stands for the counter event name. Multiple invocation of this command is possible. The counter names are listed in /sys/devices/pai_crypto/events directory. - one special counters can be specified using perf stat -e pai_crypto/CRYPTO_ALL/ which returns the sum of all incremented crypto counters. - one event pai_crypto/CRYPTO_ALL/ is reserved for sampling. No multiple invocations are possible. The event collects data at context switch out and saves them in the ring buffer. Add qpaci assembly instruction to query supported memory mapped crypto counters. It returns the number of counters (no holes allowed in that range). The PAI crypto counter events are system wide and can not be executed in parallel. Therefore some restrictions documented in function paicrypt_busy apply. In particular event CRYPTO_ALL for sampling must run exclusive. Only counting events can run in parallel. PAI crypto counter events can not be created when a CPU hot plug add is processed. This means a CPU hot plug add does not get the necessary PAI event to record PAI cryptography counter increments on the newly added CPU. CPU hot plug remove removes the event and terminates the counting of PAI counters immediately. Co-developed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Link: https://lore.kernel.org/r/20220504062351.2954280-3-tmricht@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-09entry: Rename arch_check_user_regs() to arch_enter_from_user_mode()Sven Schnelle2-4/+4
arch_check_user_regs() is used at the moment to verify that struct pt_regs contains valid values when entering the kernel from userspace. s390 needs a place in the generic entry code to modify a cpu data structure when switching from userspace to kernel mode. As arch_check_user_regs() is exactly this, rename it to arch_enter_from_user_mode(). When entering the kernel from userspace, arch_check_user_regs() is used to verify that struct pt_regs contains valid values. Note that the NMI codepath doesn't call this function. s390 needs a place in the generic entry code to modify a cpu data structure when switching from userspace to kernel mode. As arch_check_user_regs() is exactly this, rename it to arch_enter_from_user_mode(). Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Link: https://lore.kernel.org/r/20220504062351.2954280-2-tmricht@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-05-09arm64: dts: marvell: Update sdhci node names to match schemaChris Packham3-4/+4
Update the node names of the sdhci@ interfaces to be mmc@ to match the node name enforced by the mmc-controller.yaml schema. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-05-09arm64: dts: marvell: espressobin-ultra: enable front USB3 portRobert Marko1-1/+0
Espressobin Ultra has a front panel USB3.0 Type-A port which works just fine so enable it. I dont see a reason why it was disabled in the first place anyway. Fixes: 3404fe15a60f ("arm64: dts: marvell: add DT for ESPRESSObin-Ultra") Signed-off-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-05-09arm64: dts: marvell: espressobin-ultra: add PHY and switch reset pinsRobert Marko1-0/+4
Both the Topaz switch and 88E1512 PHY have their reset and interrupts connected to the SoC. So, define the Topaz and 88E1512 reset pins in the DTS. Defining the interrupt pins wont work as both the 88E1512 and the Topaz switch uses active LOW IRQ signals but the A37xx GPIO controller only supports edge triggers. 88E1512 would require special setup anyway as its INT pin is shared with the LED2 and you first need to configure it as INT. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-05-09arm64: dts: marvell: espressobin-ultra: fix SPI-NOR configRobert Marko1-4/+0
SPI config for the SPI-NOR is incorrect and completely breaking reading/writing to the onboard SPI-NOR. SPI-NOR is connected in the single(x1) IO mode and not in the quad (x4) mode. Also, there is no need to override the max frequency from the DTSI as the mx25u3235f that is used supports 104Mhz. Fixes: 3404fe15a60f ("arm64: dts: marvell: add DT for ESPRESSObin-Ultra") Signed-off-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-05-09arm64: dts: uDPU: correct temperature sensorsRobert Marko1-4/+4
uDPU has a pair of NCT375 temperature sensors, which are TMP75C compatible as far as the driver is concerned. The current LM75 compatible worked as all of the LM75 compatible sensors are backwards compatible with the original part, but it meant that lower resolution and incorrect sample rate was being used. The "lm75" compatible has been deprecated anyway and is meant as fallback in order to keep older DTS-es working. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-05-09arm64: dts: uDPU: update partition tableRobert Marko1-4/+9
Partition currently called "uboot" does not only contain U-boot, but rather it contains TF-A, U-boot and U-boot environment. So, to avoid accidentally deleting the U-boot environment which is located at 0x180000 split the partition. "uboot" is not the correct name as you can't boot these boards with U-boot only, TF-A must be present as well, so rename the "uboot" partition to "firmware". While we are here, describe the NOR node as "spi-flash@0" instead of "m25p80@0" which is the old SPI-NOR driver name. This won't break booting for existing devices as the SoC-s BootROM is not partition aware at all, it will simply try booting from 0x0 of the boot device that is set by bootstrap pins. This will however prevent accidental or automated flashing of just U-boot to the partition. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-05-09orion5x: fix typos in commentsJulia Lawall1-2/+2
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-05-08ARM: dts: sunxi: nanopi: Remove input-name propertyDang Huynh1-1/+0
This property doesn't seem to exist in the documentation nor in source code, but for some reason it is defined in a bunch of device trees. Signed-off-by: Dang Huynh <danct12@riseup.net> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220425064231.243482-1-danct12@riseup.net
2022-05-08Merge tag 'for-5.18/parisc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds15-42/+42
Pull parisc architecture fixes from Helge Deller: "Some reverts of existing patches, which were necessary because of boot issues due to wrong CPU clock handling and cache issues which led to userspace segfaults with 32bit kernels. Dave has a whole bunch of upcoming cache fixes which I then plan to push in the next merge window. Other than that just small updates and fixes, e.g. defconfig updates, spelling fixes, a clocksource fix, boot topology fixes and a fix for /proc/cpuinfo output to satisfy lscpu" * tag 'for-5.18/parisc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: Revert "parisc: Increase parisc_cache_flush_threshold setting" parisc: Mark cr16 clock unstable on all SMP machines parisc: Fix typos in comments parisc: Change MAX_ADDRESS to become unsigned long long parisc: Merge model and model name into one line in /proc/cpuinfo parisc: Re-enable GENERIC_CPU_DEVICES for !SMP parisc: Update 32- and 64-bit defconfigs parisc: Only list existing CPUs in cpu_possible_mask Revert "parisc: Fix patch code locking and flushing" Revert "parisc: Mark sched_clock unstable only if clocks are not syncronized" Revert "parisc: Mark cr16 CPU clocksource unstable on all SMP machines"
2022-05-08Merge tag 'powerpc-5.18-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds5-24/+36
Pull powerpc fixes from Michael Ellerman: - Fix the DWARF CFI in our VDSO time functions, allowing gdb to backtrace through them correctly. - Fix a buffer overflow in the papr_scm driver, only triggerable by hypervisor input. - A fix in the recently added QoS handling for VAS (used for communicating with coprocessors). Thanks to Alan Modra, Haren Myneni, Kajol Jain, and Segher Boessenkool. * tag 'powerpc-5.18-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/papr_scm: Fix buffer overflow issue with CONFIG_FORTIFY_SOURCE powerpc/vdso: Fix incorrect CFI in gettimeofday.S powerpc/pseries/vas: Use QoS credits from the userspace
2022-05-08Merge tag 'x86-urgent-2022-05-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-41/+26
Pull x86 fix from Thomas Gleixner: "A fix and an email address update: - Prevent FPU state corruption. The condition in irq_fpu_usable() grants FPU usage when the FPU is not used in the kernel. That's just wrong as it does not take the fpregs_lock()'ed regions into account. If FPU usage happens within such a region from interrupt context, then the FPU state gets corrupted. That's a long standing bug, which got unearthed by the recent changes to the random code. - Josh wants to use his kernel.org email address" * tag 'x86-urgent-2022-05-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/fpu: Prevent FPU state corruption MAINTAINERS: Update Josh Poimboeuf's email address
2022-05-08Revert "parisc: Increase parisc_cache_flush_threshold setting"Helge Deller1-15/+3
This reverts commit a58e9d0984e8dad53f17ec73ae3c1cc7f8d88151. Triggers segfaults with 32-bit kernels on PA8500 machines. Signed-off-by: Helge Deller <deller@gmx.de>
2022-05-08parisc: Mark cr16 clock unstable on all SMP machinesHelge Deller1-23/+4
The cr16 interval timers are not synchronized across CPUs, even with just one dual-core CPU. This becomes visible if the machines have a longer uptime. Signed-off-by: Helge Deller <deller@gmx.de>
2022-05-08parisc: Fix typos in commentsJulia Lawall6-6/+6
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Helge Deller <deller@gmx.de>
2022-05-08parisc: Change MAX_ADDRESS to become unsigned long longHelge Deller1-1/+1
Dave noticed that for the 32-bit kernel MAX_ADDRESS should be a ULL, otherwise this define would become 0: MAX_ADDRESS (1UL << MAX_ADDRBITS) It has no real effect on the kernel. Signed-off-by: Helge Deller <deller@gmx.de> Noticed-by: John David Anglin <dave.anglin@bell.net>
2022-05-08parisc: Merge model and model name into one line in /proc/cpuinfoHelge Deller1-2/+1
The Linux tool "lscpu" shows the double amount of CPUs if we have "model" and "model name" in two different lines in /proc/cpuinfo. This change combines the model and the model name into one line. Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org
2022-05-08parisc: Re-enable GENERIC_CPU_DEVICES for !SMPHelge Deller1-0/+1
In commit 62773112acc5 ("parisc: Switch from GENERIC_CPU_DEVICES to GENERIC_ARCH_TOPOLOGY") GENERIC_CPU_DEVICES was unconditionally turned off, but this triggers a warning in topology_add_dev(). Turning it back on for the !SMP case avoids this warning. Reported-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Fixes: 62773112acc5 ("parisc: Switch from GENERIC_CPU_DEVICES to GENERIC_ARCH_TOPOLOGY") Signed-off-by: Helge Deller <deller@gmx.de>
2022-05-08parisc: Update 32- and 64-bit defconfigsHelge Deller2-2/+5
Enable CONFIG_CGROUPS=y on 32-bit defconfig for systemd-support, and enable CONFIG_NAMESPACES and CONFIG_USER_NS. Signed-off-by: Helge Deller <deller@gmx.de>
2022-05-08parisc: Only list existing CPUs in cpu_possible_maskHelge Deller1-0/+8
The inventory knows which CPUs are in the system, so this bitmask should be in cpu_possible_mask instead of the bitmask based on CONFIG_NR_CPUS. Reset the cpu_possible_mask before scanning the system for CPUs, and mark each existing CPU as possible during initialization of that CPU. This avoids those warnings later on too: register_cpu_capacity_sysctl: too early to get CPU4 device! Signed-off-by: Helge Deller <deller@gmx.de> Noticed-by: John David Anglin <dave.anglin@bell.net>
2022-05-08Revert "parisc: Fix patch code locking and flushing"Helge Deller1-11/+14
This reverts commit a9fe7fa7d874a536e0540469f314772c054a0323. Leads to segfaults on 32bit kernel. Signed-off-by: Helge Deller <deller@gmx.de>
2022-05-08Revert "parisc: Mark sched_clock unstable only if clocks are not syncronized"Helge Deller2-3/+6
This reverts commit d97180ad68bdb7ee10f327205a649bc2f558741d. It triggers RCU stalls at boot with a 32-bit kernel. Signed-off-by: Helge Deller <deller@gmx.de> Noticed-by: John David Anglin <dave.anglin@bell.net> Cc: stable@vger.kernel.org # v5.15+
2022-05-08Revert "parisc: Mark cr16 CPU clocksource unstable on all SMP machines"Helge Deller1-7/+21
This reverts commit afdb4a5b1d340e4afffc65daa21cc71890d7d589. It triggers RCU stalls at boot with a 32-bit kernel. Signed-off-by: Helge Deller <deller@gmx.de> Noticed-by: John David Anglin <dave.anglin@bell.net> Cc: stable@vger.kernel.org # v5.16+
2022-05-08powerpc/code-patching: Don't call is_vmalloc_or_module_addr() without CONFIG_MODULESChristophe Leroy1-1/+1
If CONFIG_MODULES is not set, there is no point in checking whether text is in module area. This reduced the time needed to activate/deactivate ftrace by more than 10% on an 8xx. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/f3c701cce00a38620788c0fc43ff0b611a268c54.1647962456.git.christophe.leroy@csgroup.eu
2022-05-08powerpc: align address to page boundary in change_page_attr()Christophe Leroy1-0/+1
Aligning address to page boundary allows flush_tlb_kernel_range() to know it's a single page flush and use tlbie instead of tlbia. On 603 we now have the following code in first leg of change_page_attr(): 2c: 55 29 00 3c rlwinm r9,r9,0,0,30 30: 91 23 00 00 stw r9,0(r3) 34: 7c 00 22 64 tlbie r4,r0 38: 7c 00 04 ac hwsync 3c: 38 60 00 00 li r3,0 40: 4e 80 00 20 blr Before we had: 28: 55 29 00 3c rlwinm r9,r9,0,0,30 2c: 91 23 00 00 stw r9,0(r3) 30: 54 89 00 26 rlwinm r9,r4,0,0,19 34: 38 84 10 00 addi r4,r4,4096 38: 7c 89 20 50 subf r4,r9,r4 3c: 28 04 10 00 cmplwi r4,4096 40: 41 81 00 30 bgt 70 <change_page_attr+0x70> 44: 7c 00 4a 64 tlbie r9,r0 48: 7c 00 04 ac hwsync 4c: 38 60 00 00 li r3,0 50: 4e 80 00 20 blr ... 70: 94 21 ff f0 stwu r1,-16(r1) 74: 7c 08 02 a6 mflr r0 78: 90 01 00 14 stw r0,20(r1) 7c: 48 00 00 01 bl 7c <change_page_attr+0x7c> 7c: R_PPC_REL24 _tlbia 80: 80 01 00 14 lwz r0,20(r1) 84: 38 60 00 00 li r3,0 88: 7c 08 03 a6 mtlr r0 8c: 38 21 00 10 addi r1,r1,16 90: 4e 80 00 20 blr Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/6bb118fb2ee89fa3c1f9cf90ed19f88220002cb0.1647877467.git.christophe.leroy@csgroup.eu
2022-05-08powerpc/8xx: Simplify flush_tlb_kernel_range()Christophe Leroy2-1/+13
In the same spirit as commit 63f501e07a85 ("powerpc/8xx: Simplify TLB handling"), simplify flush_tlb_kernel_range() for 8xx. 8xx cannot be SMP, and has 'tlbie' and 'tlbia' instructions, so an inline version of flush_tlb_kernel_range() for 8xx is worth it. With this page, first leg of change_page_attr() is: 2c: 55 29 00 3c rlwinm r9,r9,0,0,30 30: 91 23 00 00 stw r9,0(r3) 34: 7c 00 22 64 tlbie r4,r0 38: 7c 00 04 ac hwsync 3c: 38 60 00 00 li r3,0 40: 4e 80 00 20 blr Before the patch it was: 30: 55 29 00 3c rlwinm r9,r9,0,0,30 34: 91 2a 00 00 stw r9,0(r10) 38: 94 21 ff f0 stwu r1,-16(r1) 3c: 7c 08 02 a6 mflr r0 40: 38 83 10 00 addi r4,r3,4096 44: 90 01 00 14 stw r0,20(r1) 48: 48 00 00 01 bl 48 <change_page_attr+0x48> 48: R_PPC_REL24 flush_tlb_kernel_range 4c: 80 01 00 14 lwz r0,20(r1) 50: 38 60 00 00 li r3,0 54: 7c 08 03 a6 mtlr r0 58: 38 21 00 10 addi r1,r1,16 5c: 4e 80 00 20 blr Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/d2610043419ce3e0e53a85386baf2c3625af5cfb.1647877442.git.christophe.leroy@csgroup.eu
2022-05-08powerpc: Use static call for get_irq()Christophe Leroy1-1/+7
__do_irq() inconditionnaly calls ppc_md.get_irq() That's definitely a hot path. At the time being ppc_md.get_irq address is read every time from ppc_md structure. Replace that call by a static call, and initialise that call after ppc_md.init_IRQ() has set ppc_md.get_irq. Emit a warning and don't set the static call if ppc_md.init_IRQ() is still NULL, that way the kernel won't blow up if for some reason ppc_md.get_irq() doesn't get properly set. With the patch: 00000000 <__SCT__ppc_get_irq>: 0: 48 00 00 20 b 20 <__static_call_return0> <== Replaced by 'b <ppc_md.get_irq>' at runtime ... 00000020 <__static_call_return0>: 20: 38 60 00 00 li r3,0 24: 4e 80 00 20 blr ... 00000058 <__do_irq>: ... 64: 48 00 00 01 bl 64 <__do_irq+0xc> 64: R_PPC_REL24 __SCT__ppc_get_irq 68: 2c 03 00 00 cmpwi r3,0 ... Before the patch: 00000038 <__do_irq>: ... 3c: 3d 20 00 00 lis r9,0 3e: R_PPC_ADDR16_HA ppc_md+0x1c ... 44: 81 29 00 00 lwz r9,0(r9) 46: R_PPC_ADDR16_LO ppc_md+0x1c ... 4c: 7d 29 03 a6 mtctr r9 50: 4e 80 04 21 bctrl 54: 2c 03 00 00 cmpwi r3,0 ... On PPC64 which doesn't implement static calls yet we get: 00000000000000d0 <__do_irq>: ... dc: 00 00 22 3d addis r9,r2,0 dc: R_PPC64_TOC16_HA .data+0x8 ... e4: 00 00 89 e9 ld r12,0(r9) e4: R_PPC64_TOC16_LO_DS .data+0x8 ... f0: a6 03 89 7d mtctr r12 f4: 18 00 41 f8 std r2,24(r1) f8: 21 04 80 4e bctrl fc: 18 00 41 e8 ld r2,24(r1) ... So on PPC64 that's similar to what we get without static calls. But at least until ppc_md.get_irq() is set the call is to __static_call_return0. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/afb92085f930651d8b1063e4d4bf0396c80ebc7d.1647002274.git.christophe.leroy@csgroup.eu
2022-05-08powerpc: Use rol32() instead of opencoding in csum_fold()Christophe Leroy1-7/+8
rol32(x, 16) will do the rotate using rlwinm. No need to open code using inline assembly. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/794337eff7bb803d2c4e67d9eee635390c4c48fe.1646812553.git.christophe.leroy@csgroup.eu
2022-05-08powerpc: Add missing headersChristophe Leroy146-108/+195
Don't inherit headers "by chances" from asm/prom.h, asm/mpc52xx.h, asm/pci.h etc... Include the needed headers, and remove asm/prom.h when it was needed exclusively for pulling necessary headers. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/be8bdc934d152a7d8ee8d1a840d5596e2f7d85e0.1646767214.git.christophe.leroy@csgroup.eu
2022-05-08powerpc: Remove asm/prom.h from all files that don't need itChristophe Leroy79-80/+0
Several files include asm/prom.h for no reason. Clean it up. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> [mpe: Drop change to prom_parse.c as reported by lkp@intel.com] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/7c9b8fda63dcf63e1b28f43e7ebdb95182cbc286.1646767214.git.christophe.leroy@csgroup.eu
2022-05-08um: vector: switch to netif_napi_add_weight()Jakub Kicinski1-1/+2
UM's netdev driver uses a custom napi weight, switch to the new API for setting custom weight. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-08arm64: entry: use stackleak_erase_on_task_stack()Mark Rutland1-1/+1
On arm64 we always call stackleak_erase() on a task stack, and never call it on another stack. We can avoid some redundant work by using stackleak_erase_on_task_stack(), telling the stackleak code that it's being called on a task stack. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Alexander Popov <alex.popov@linux.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Kees Cook <keescook@chromium.org> Cc: Will Deacon <will@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220427173128.2603085-14-mark.rutland@arm.com
2022-05-08arm64: stackleak: fix current_top_of_stack()Mark Rutland1-6/+4
Due to some historical confusion, arm64's current_top_of_stack() isn't what the stackleak code expects. This could in theory result in a number of problems, and practically results in an unnecessary performance hit. We can avoid this by aligning the arm64 implementation with the x86 implementation. The arm64 implementation of current_top_of_stack() was added specifically for stackleak in commit: 0b3e336601b82c6a ("arm64: Add support for STACKLEAK gcc plugin") This was intended to be equivalent to the x86 implementation, but the implementation, semantics, and performance characteristics differ wildly: * On x86, current_top_of_stack() returns the top of the current task's task stack, regardless of which stack is in active use. The implementation accesses a percpu variable which the x86 entry code maintains, and returns the location immediately above the pt_regs on the task stack (above which x86 has some padding). * On arm64 current_top_of_stack() returns the top of the stack in active use (i.e. the one which is currently being used). The implementation checks the SP against a number of potentially-accessible stacks, and will BUG() if no stack is found. The core stackleak_erase() code determines the upper bound of stack to erase with: | if (on_thread_stack()) | boundary = current_stack_pointer; | else | boundary = current_top_of_stack(); On arm64 stackleak_erase() is always called on a task stack, and on_thread_stack() should always be true. On x86, stackleak_erase() is mostly called on a trampoline stack, and is sometimes called on a task stack. Currently, this results in a lot of unnecessary code being generated for arm64 for the impossible !on_thread_stack() case. Some of this is inlined, bloating stackleak_erase(), while portions of this are left out-of-line and permitted to be instrumented (which would be a functional problem if that code were reachable). As a first step towards improving this, this patch aligns arm64's implementation of current_top_of_stack() with x86's, always returning the top of the current task's stack. With GCC 11.1.0 this results in the bulk of the unnecessary code being removed, including all of the out-of-line instrumentable code. While I don't believe there's a functional problem in practice I've marked this as a fix since the semantic was clearly wrong, the fix itself is simple, and other code might rely upon this in future. Fixes: 0b3e336601b82c6a ("arm64: Add support for STACKLEAK gcc plugin") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Alexander Popov <alex.popov@linux.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Kees Cook <keescook@chromium.org> Cc: Will Deacon <will@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220427173128.2603085-2-mark.rutland@arm.com
2022-05-08randstruct: Split randstruct Makefile and CFLAGSKees Cook4-4/+7
To enable the new Clang randstruct implementation[1], move randstruct into its own Makefile and split the CFLAGS from GCC_PLUGINS_CFLAGS into RANDSTRUCT_CFLAGS. [1] https://reviews.llvm.org/D121556 Cc: linux-hardening@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220503205503.3054173-5-keescook@chromium.org
2022-05-08randstruct: Reorganize Kconfigs and attribute macrosKees Cook2-2/+2
In preparation for Clang supporting randstruct, reorganize the Kconfigs, move the attribute macros, and generalize the feature to be named CONFIG_RANDSTRUCT for on/off, CONFIG_RANDSTRUCT_FULL for the full randomization mode, and CONFIG_RANDSTRUCT_PERFORMANCE for the cache-line sized mode. Cc: linux-hardening@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220503205503.3054173-4-keescook@chromium.org
2022-05-07ARM: pxa: convert to multiplatformArnd Bergmann27-90/+37
PXA is now ready to be built into a single kernel with all the other ARMv5 platforms, so change the Kconfig bit to finish it off. The mach/uncompress.h support is the last bit that goes away, getting replaced with the normal DEBUG_LL based approach. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-07ARM: pxa/sa1100: move I/O space to PCI_IOBASEArnd Bergmann4-24/+29
PXA and StrongARM1100 traditionally map their I/O space 1:1 into virtual memory, using a per-bus io_offset that matches the base address of the ioremap mapping. In order for PXA to work in a multiplatform config, this needs to change so I/O space starts at PCI_IOBASE (0xfee00000). Since the pcmcia soc_common support is shared with StrongARM1100, both have to change at the same time. The affected machines are: - Anything with a PCMCIA slot now uses pci_remap_iospace, which is made available to PCMCIA configurations as well, rather than just PCI. The first PCMCIA slot now starts at port number 0x10000. - The Zeus and Viper platforms have PC/104-style ISA buses, which have a static mapping for both I/O and memory space at 0xf1000000, which can no longer work. It does not appear to have any in-tree users, so moving it to port number 0 makes them behave like a traditional PC. - SA1100 does support ISA slots in theory, but all machines that originally enabled this appear to have been removed from the tree ages ago, and the I/O space is never mapped anywhere. - The Nanoengine machine has support for PCI slots, but looks like this never included I/O space, the resources only define the location for memory and config space. With this, the definitions of __io() and IO_SPACE_LIMIT can be simplified, as the only remaining cases are the generic PCI_IOBASE and the custom inb()/outb() macros on RiscPC. S3C24xx still has a custom inb()/outb() in this here, but this is already removed in another branch. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-07ARM: pxa: remove support for MTD_XIPArnd Bergmann2-37/+0
Using MTD-XIP does not work on multiplatform kernels because it requires SoC specific register accesses to be done from low-level flash handling functions in RAM while the rest of the kernel sits in flash. I found no evidence of anyone still actually using this feature, so remove it from PXA to avoid spending a lot of time on actually making it work. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-07ARM: pxa: move mach/*.h to mach-pxa/Arnd Bergmann70-134/+133
None of the headers are included from outside of the mach-pxa directory, so move them all in there. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-07ARM: PXA: fix multi-cpu build of xsc3Arnd Bergmann1-0/+2
On a kernel that includes both ARMv4 and XScale support, the copypage function fails to build with invalid instructions. Since these are only called on an actual XScale processor, annotate the assembly with the correct .arch directive. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-07ARM: pxa: move plat-pxa to drivers/soc/Arnd Bergmann11-1013/+4
There are two drivers in arch/arm/plat-pxa: mfp and ssp. Both of them should ideally not be needed at all, as there are proper subsystems to replace them. OTOH, they are self-contained and can simply be normal SoC drivers, so move them over there to eliminate one more of the plat-* directories. Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> (mach-pxa) Acked-by: Lubomir Rintel <lkundrak@v3.sk> (mach-mmp) Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-07ARM: mmp: rename pxa_register_deviceArnd Bergmann6-82/+82
In a multiplatform kernel that includes both pxa and mmp, we get a link failure from the clash of two pxa_register_device functions. Rename the one in mach-mmp to mmp_register_device, along with with the rename of pxa_device_desc. Acked-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-07ARM: mmp: remove tavorevb board supportArnd Bergmann3-123/+1
There are two tavorevb boards in the kernel, one using a PXA930 chip in mach-pxa, and one using the later PXA910 chip in mach-mmp. They use the same board number, which is generally a bad idea, and in a multiplatform kernel, we can end up with funny link errors like this one resulting from two boards gettting controlled by the same Kconfig symbol: arch/arm/mach-mmp/tavorevb.o: In function `tavorevb_init': tavorevb.c:(.init.text+0x4c): undefined reference to `pxa910_device_uart1' tavorevb.c:(.init.text+0x50): undefined reference to `pxa910_device_gpio' tavorevb.o:(.arch.info.init+0x54): undefined reference to `pxa910_init_irq' tavorevb.o:(.arch.info.init+0x58): undefined reference to `pxa910_timer_init' The mach-pxa TavorEVB seems much more complete than the mach-mmp one that supports only uart, gpio and ethernet. Further, I could find no information about the board on the internet aside from references to the Linux kernel, so I assume this was never available outside of Marvell and can be removed entirely. There is a third board named TavorEVB in the Kconfig description, but this refers to the "TTC_DKB" machine. The two are clearly related, so I change the Kconfig description to just list both names. Cc: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.