aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2020-10-12MIPS: cpu-probe: introduce exclusive R3k CPU probeThomas Bogendoerfer2-1/+178
Running a kernel on a R3k of machine definitly will never see one of the newer CPU cores. And since R3k system usually are low on memory we could save quite some kbytes: text data bss dec hex filename 15070 88 32 15190 3b56 arch/mips/kernel/cpu-probe.o 844 4 16 864 360 arch/mips/kernel/cpu-r3k-probe.o Signed-off-by: Thomas Bogendoerfer <[email protected]>
2020-10-12MIPS: cpu-probe: move fpu probing/handling into its own fileThomas Bogendoerfer4-324/+364
cpu-probe.c has grown when supporting more and more CPUs and there are use cases where probing for all the CPUs isn't useful like running on a R3k system. But still the fpu handling is nearly the same. For sharing put the fpu code into it's own file. Signed-off-by: Thomas Bogendoerfer <[email protected]>
2020-10-12MIPS: replace add_memory_region with memblockThomas Bogendoerfer28-149/+82
add_memory_region was the old interface for registering memory and was already changed to used memblock internaly. Replace it by directly calling memblock functions. Signed-off-by: Thomas Bogendoerfer <[email protected]>
2020-10-12MIPS: Loongson64: Clean up numa.cTiezhu Yang2-31/+4
(1) Replace nid_to_addroffset() with nid_to_addrbase() and then remove the related useless code. (2) Since end_pfn = start_pfn + node_psize, use "node_psize" instead of "end_pfn - start_pfn" to avoid the redundant calculation. (3) After commit 6fbde6b492df ("MIPS: Loongson64: Move files to the top-level directory"), CONFIG_ZONE_DMA32 is always set for Loongson64 due to MACH_LOONGSON64 selects ZONE_DMA32, so no need to use ifdef any more, just remove it. Signed-off-by: Tiezhu Yang <[email protected]> Reviewed-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2020-10-12MIPS: Loongson64: Select SMP in Kconfig to avoid build errorTiezhu Yang2-1/+1
In the current code, CONFIG_SMP can be set as N by user on the Loongson platform, then there exists the following build error under !CONFIG_SMP: CC arch/mips/kernel/asm-offsets.s In file included from ./include/linux/gfp.h:9:0, from ./include/linux/xarray.h:14, from ./include/linux/radix-tree.h:18, from ./include/linux/fs.h:15, from ./include/linux/compat.h:17, from arch/mips/kernel/asm-offsets.c:12: ./include/linux/topology.h: In function 'numa_node_id': ./include/linux/topology.h:119:2: error: implicit declaration of function 'cpu_logical_map' [-Werror=implicit-function-declaration] return cpu_to_node(raw_smp_processor_id()); ^ cc1: some warnings being treated as errors scripts/Makefile.build:117: recipe for target 'arch/mips/kernel/asm-offsets.s' failed make[1]: *** [arch/mips/kernel/asm-offsets.s] Error 1 Select SMP in Kconfig to avoid the above build error and then remove CONFIG_SMP=y in loongson3_defconfig. Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2020-10-12mips: octeon: Add Ubiquiti E200 and E220 boardsMikhail Gusarov1-0/+4
These boards are used in - Ubiquiti EdgeRouter (E200), - Ubiquiti EdgeRouter Pro (E200) and - Ubiquiti Security Gateway Pro 4 (E220). Signed-off-by: Mikhail Gusarov <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2020-10-11um: vector: Add dynamic tap interfaces and scriptingAnton Ivanov1-9/+47
Provide functionality roughly compatible with the existing qemu ifup scripting: * invocation of an ifup script. The interface name is passed as the first and only argument * allocating tap interfaces on the fly if they are not explicitly specified Signed-off-by: Anton Ivanov <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: Clean up stacktrace dumpJohannes Berg1-3/+1
We currently get a few stray newlines, due to the interaction between printk() and the code here. Remove a few explicit newline prints to neaten the output. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: Fix incorrect assumptions about max pid lengthMaciej Żenczykowski1-4/+4
pids are no longer limited to 16-bits, bump to 32-bits, ie. 9 decimal characters. Additionally sizeof("/") already returns 2 - ie. it already accounts for trailing zero. Cc: Jeff Dike <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Anton Ivanov <[email protected]> Cc: Linux UM Mailing List <[email protected]> Signed-off-by: Maciej Żenczykowski <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: Remove dead usage of TIF_IA32Gabriel Krisman Bertazi1-12/+1
This seems like a dead artifact since TIF_IA32 is not even defined as a TI flag for UM. Looking back in git history, it made sense in the old days, but it is apparently not used since UM was split out of the x86 arch/. It is also going away from the x86 tree soon. Also, I think the variable clean up it performs is not needed as 64-bit UML doesn't run 32-bit binaries as far as I can tell, and 32-bit UML has 32-bit ulong. Signed-off-by: Gabriel Krisman Bertazi <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: Remove redundant NULL checkLi Heng1-2/+1
Fix below warnings reported by coccicheck: ./arch/um/drivers/vector_user.c:403:2-7: WARNING: NULL check before some freeing functions is not needed. Fixes: bc8f8e4e6e7a ("um: Add a generic "fd" vector transport") Signed-off-by: Li Heng <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: change sigio_spinlock to a mutexJohannes Berg1-3/+3
Lockdep complains at boot: ============================= [ BUG: Invalid wait context ] 5.7.0-05093-g46d91ecd597b #98 Not tainted ----------------------------- swapper/1 is trying to lock: 0000000060931b98 (&desc[i].request_mutex){+.+.}-{3:3}, at: __setup_irq+0x11d/0x623 other info that might help us debug this: context-{4:4} 1 lock held by swapper/1: #0: 000000006074fed8 (sigio_spinlock){+.+.}-{2:2}, at: sigio_lock+0x1a/0x1c stack backtrace: CPU: 0 PID: 1 Comm: swapper Not tainted 5.7.0-05093-g46d91ecd597b #98 Stack: 7fa4fab0 6028dfd1 0000002a 6008bea5 7fa50700 7fa50040 7fa4fac0 6028e016 7fa4fb50 6007f6da 60959c18 00000000 Call Trace: [<60023a0e>] show_stack+0x13b/0x155 [<6028e016>] dump_stack+0x2a/0x2c [<6007f6da>] __lock_acquire+0x515/0x15f2 [<6007eb50>] lock_acquire+0x245/0x273 [<6050d9f1>] __mutex_lock+0xbd/0x325 [<6050dc76>] mutex_lock_nested+0x1d/0x1f [<6008e27e>] __setup_irq+0x11d/0x623 [<6008e8ed>] request_threaded_irq+0x169/0x1a6 [<60021eb0>] um_request_irq+0x1ee/0x24b [<600234ee>] write_sigio_irq+0x3b/0x76 [<600383ca>] sigio_broken+0x146/0x2e4 [<60020bd8>] do_one_initcall+0xde/0x281 Because we hold sigio_spinlock and then get into requesting an interrupt with a mutex. Change the spinlock to a mutex to avoid that. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: time-travel: Return the sequence number in ACK messagesJohannes Berg1-0/+1
For external time travel, the protocol says to return the incoming sequence number in the ACK message to aid debugging, so do that. Signed-off-by: Johannes Berg <[email protected]> Acked-By: Anton Ivanov <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: time-travel: Fix IRQ handling in time_travel_handle_message()Johannes Berg1-5/+9
As the comment here indicates, we need to do the polling in the idle loop without blocking interrupts, since interrupts can be vhost-user messages that we must process even while in our idle loop. I don't know why I explained one thing and implemented another, but we have indeed observed random hangs due to this, depending on the timing of the messages. Fixes: 88ce64249233 ("um: Implement time-travel=ext") Signed-off-by: Johannes Berg <[email protected]> Acked-By: Anton Ivanov <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: Allow static linking for non-glibc implementationsIgnat Korchagin2-6/+6
It is possible to produce a statically linked UML binary with UML_NET_VECTOR, UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc implementations, which do not rely on NSS, such as musl. Allow static linking in this case. Signed-off-by: Ignat Korchagin <[email protected]> Reviewed-by: Brendan Higgins <[email protected]> Tested-by: Brendan Higgins <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: Some fixes to build UML with muslIgnat Korchagin6-12/+11
musl toolchain and headers are a bit more strict. These fixes enable building UML with musl as well as seem not to break on glibc. Signed-off-by: Ignat Korchagin <[email protected]> Tested-by: Brendan Higgins <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: vector: Use GFP_ATOMIC under spin lockTiezhu Yang1-2/+2
Use GFP_ATOMIC instead of GFP_KERNEL under spin lock to fix possible sleep-in-atomic-context bugs. Fixes: 9807019a62dc ("um: Loadable BPF "Firmware" for vector drivers") Signed-off-by: Tiezhu Yang <[email protected]> Acked-By: Anton Ivanov <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11um: Fix null pointer dereference in vector_user_bpfGaurav Singh1-3/+5
The bpf_prog is being checked for !NULL after uml_kmalloc but later its used directly for example: bpf_prog->filter = bpf and is also later returned upon success. Fix this, do a NULL check and return right away. Signed-off-by: Gaurav Singh <[email protected]> Acked-By: Anton Ivanov <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2020-10-11Merge tag 'spi-nor/for-5.10' of ↵Richard Weinberger263-828/+1341
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into mtd/next SPI NOR core changes: - Support for Winbond w25q64jwm flash - Enable 4K sector support for mx25l12805d SPI NOR controller drivers changes: - intel-spi: - Add Alder Lake-S PCI ID
2020-10-11arm64: dts: fsl-ls1028a-rdb: Specify in-band mode for ENETC port 0Claudiu Manoil1-0/+1
As part of the transition of the enetc ethernet driver from phylib to phylink, the in-band operation mode of the SGMII interface from enetc port 0 needs to be specified explicitly for phylink. Signed-off-by: Claudiu Manoil <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-10-11Merge tag 'x86-urgent-2020-10-11' of ↵Linus Torvalds1-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "Two fixes: - Fix a (hopefully final) IRQ state tracking bug vs MCE handling - Fix a documentation link" * tag 'x86-urgent-2020-10-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Documentation/x86: Fix incorrect references to zero-page.txt x86/mce: Use idtentry_nmi_enter/exit()
2020-10-11Merge tag 'irqchip-5.10' of ↵Thomas Gleixner14-149/+209
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates from Marc Zyngier: Core changes: - Allow irq retriggering to follow a hierarchy - Allow interrupt hierarchies to be trimmed at allocation time - Allow interrupts to be hidden from /proc/interrupts (IPIs) - Introduce stub for set_handle_irq() when !GENERIC_IRQ_MULTI_HANDLER - New per-cpu IPI handling flow Architecture changes: - Move arm/arm64 IPI handling to the core interrupt code, removing the home brewed accounting Driver updates: - New driver for the MStar (and more recently Mediatek) platforms - New driver for the Actions Owl SIRQ controller - New driver for the TI PRUSS infrastructure - Wake-up support for the Qualcomm PDC controller - Primary interrupt controller support for the Designware APB ICTL - Convert the IPI code for GIC, GICv3, hip04, armada-270-xp and bcm2836 to using standard interrupts - Improve GICv3 pseudo-NMI support to deal with both non-secure and secure priorities on arm64 - Convert the GIC/GICv3 drivers to using HW-based irq retrigger - A sprinkling of dev_err_probe() conversion - A set of NVIDIA Tegra fixes for interrupt hierarchy corruption - A reset fix for the Loongson HTVEC driver - A couple of error handling fixes in the TI SCI drivers
2020-10-09s390/uaccess: fix indentationHeiko Carstens1-1/+1
Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2020-10-09s390/uaccess: add default cases for __put_user_fn()/__get_user_fn()Heiko Carstens1-4/+9
Add default cases for __put_user_fn()/__get_user_fn(). This doesn't fix anything since the functions are only called with sane values. However we get rid of smatch warnings: ./arch/s390/include/asm/uaccess.h:143 __get_user_fn() error: uninitialized symbol 'rc'. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2020-10-09s390/kprobes: move insn_page to text segmentHeiko Carstens4-4/+27
Move the in-kernel kprobes insn page to text segment. Rationale: having that page in rw data segment is suboptimal, since as soon as a kprobe is set, this will split the 1:1 kernel mapping for a single page which get new permissions. Note: there is always at least one kprobe present for the kretprobe trampoline; so the mapping will always be split into smaller 4k mappings because of this. Moving the kprobes insn page into text segment makes sure that the page is mapped RO/X in any case, and avoids that the 1:1 mapping is split. The kprobe insn_page is defined as a dummy function which is filled with "br %r14" instructions. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2020-10-09Merge tag 'riscv-for-linus-5.9' of ↵Linus Torvalds2-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: "Two fixes this week: - A fix to actually reserve the device tree's memory. Without this the device tree can be overwritten on systems that don't otherwise reserve it. This issue should only manifest on !MMU systems. - A workaround for a BUG() that triggers when the memory that originally contained initdata is freed and later repurposed. This triggers a BUG() on builds that had HARDENED_USERCOPY enabled" * tag 'riscv-for-linus-5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Fixup bootup failure with HARDENED_USERCOPY RISC-V: Make sure memblock reserves the memory containing DT
2020-10-09kbuild: explicitly specify the build id styleBill Wendling8-8/+8
ld's --build-id defaults to "sha1" style, while lld defaults to "fast". The build IDs are very different between the two, which may confuse programs that reference them. Signed-off-by: Bill Wendling <[email protected]> Acked-by: David S. Miller <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-10-09Merge remote-tracking branch 'asoc/for-5.10' into asoc-nextMark Brown3-0/+51
2020-10-09Revert "arm64: initialize per-cpu offsets earlier"Will Deacon4-19/+11
This reverts commit 353e228eb355be5a65a3c0996c774a0f46737fda. Qian Cai reports that TX2 no longer boots with his .config as it appears that task_cpu() gets instrumented and used before KASAN has been initialised. Although Mark has a proposed fix, let's take the safe option of reverting this for now and sorting it out properly later. Link: https://lore.kernel.org/r/[email protected] Reported-by: Qian Cai <[email protected]> Tested-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-10-09Merge branch 'locking/urgent' into locking/core, to pick up fixesIngo Molnar274-875/+1528
Signed-off-by: Ingo Molnar <[email protected]>
2020-10-09Merge branch 'for-mingo' of ↵Ingo Molnar1-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu Pull v5.10 RCU changes from Paul E. McKenney: - Debugging for smp_call_function(). - Strict grace periods for KASAN. The point of this series is to find RCU-usage bugs, so the corresponding new RCU_STRICT_GRACE_PERIOD Kconfig option depends on both DEBUG_KERNEL and RCU_EXPERT, and is further disabled by dfefault. Finally, the help text includes a goodly list of scary caveats. - New smp_call_function() torture test. - Torture-test updates. - Documentation updates. - Miscellaneous fixes. Signed-off-by: Ingo Molnar <[email protected]>
2020-10-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2-3/+3
Small conflict around locking in rxrpc_process_event() - channel_lock moved to bundle in next, while state lock needs _bh() from net. Signed-off-by: Jakub Kicinski <[email protected]>
2020-10-08seccomp: Move config option SECCOMP to arch/KconfigYiFei Zhu15-216/+33
In order to make adding configurable features into seccomp easier, it's better to have the options at one single location, considering especially that the bulk of seccomp code is arch-independent. An quick look also show that many SECCOMP descriptions are outdated; they talk about /proc rather than prctl. As a result of moving the config option and keeping it default on, architectures arm, arm64, csky, riscv, sh, and xtensa did not have SECCOMP on by default prior to this and SECCOMP will be default in this change. Architectures microblaze, mips, powerpc, s390, sh, and sparc have an outdated depend on PROC_FS and this dependency is removed in this change. Suggested-by: Jann Horn <[email protected]> Link: https://lore.kernel.org/lkml/CAG48ez1YWz9cnp08UZgeieYRhHdqh-ch7aNwc4JRBnGyrmgfMg@mail.gmail.com/ Signed-off-by: YiFei Zhu <[email protected]> [kees: added HAVE_ARCH_SECCOMP help text, tweaked wording] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/9ede6ef35c847e58d61e476c6a39540520066613.1600951211.git.yifeifz2@illinois.edu
2020-10-08Merge tag 'for-linus-5.9b-rc9-tag' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fix from Juergen Gross: "One fix for a regression when booting as a Xen guest on ARM64 introduced probably during the 5.9 cycle. It is very low risk as it is modifying Xen specific code only. The exact commit introducing the bug hasn't been identified yet, but everything was fine in 5.8 and only in 5.9 some configurations started to fail" * tag 'for-linus-5.9b-rc9-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: arm/arm64: xen: Fix to convert percpu address to gfn correctly
2020-10-08arm: disable frequency invariance for CONFIG_BL_SWITCHERIonela Voinescu1-0/+3
big.LITTLE switching complicates the setting of a correct cpufreq-based frequency invariance scale factor due to (as observed in drivers/cpufreq/vexpress-spc-cpufreq.c): - Incorrect current and maximum frequencies as a result of the exposure of a virtual frequency table to the cpufreq core, - Missed updates as a result of asynchronous frequency adjustments caused by frequency changes in other CPU pairs. Given that its functionality is atypical in regards to frequency invariance and this is an old technology, disable frequency invariance for when big.LITTLE switching is configured in to prevent incorrect scale setting. Signed-off-by: Ionela Voinescu <[email protected]> Suggested-by: Dietmar Eggemann <[email protected]> Acked-by: Viresh Kumar <[email protected]> Acked-by: Sudeep Holla <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-08cpufreq,arm,arm64: restructure definitions of arch_set_freq_scale()Ionela Voinescu2-0/+2
Compared to other arch_* functions, arch_set_freq_scale() has an atypical weak definition that can be replaced by a strong architecture specific implementation. The more typical support for architectural functions involves defining an empty stub in a header file if the symbol is not already defined in architecture code. Some examples involve: - #define arch_scale_freq_capacity topology_get_freq_scale - #define arch_scale_freq_invariant topology_scale_freq_invariant - #define arch_scale_cpu_capacity topology_get_cpu_scale - #define arch_update_cpu_topology topology_update_cpu_topology - #define arch_scale_thermal_pressure topology_get_thermal_pressure - #define arch_set_thermal_pressure topology_set_thermal_pressure Bring arch_set_freq_scale() in line with these functions by renaming it to topology_set_freq_scale() in the arch topology driver, and by defining the arch_set_freq_scale symbol to point to the new function for arm and arm64. While there are other users of the arch_topology driver, this patch defines arch_set_freq_scale for arm and arm64 only, due to their existing definitions of arch_scale_freq_capacity. This is the getter function of the frequency invariance scale factor and without a getter function, the setter function - arch_set_freq_scale() has not purpose. Signed-off-by: Ionela Voinescu <[email protected]> Acked-by: Viresh Kumar <[email protected]> Acked-by: Catalin Marinas <[email protected]> Acked-by: Sudeep Holla <[email protected]> (BL_SWITCHER and topology parts) Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-08powerpc/time: Make get_tb() common to PPC32 and PPC64Christophe Leroy1-7/+3
mftbu() is always defined now, so the #ifdef can be removed and replaced by an IS_ENABLED(CONFIG_PPC64) inside the PPC32 version of get_tb(). Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/47e49717d2643169ffcbe5d507f184cf49f0fe95.1601556145.git.christophe.leroy@csgroup.eu
2020-10-08powerpc/time: Make get_tbl() common to PPC32 and PPC64Christophe Leroy1-7/+0
On PPC64, get_tbl() is defined as an alias of get_tb() which return the result of mftb(). That exactly the same as what the PPC32 version does. We don't need two versions. Remove the PPC64 definition of get_tbl() and use the PPC32 version for both. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/a8eaabb87d69534e533ebac805163e08146e05bd.1601556145.git.christophe.leroy@csgroup.eu
2020-10-08powerpc/time: Remove get_tbu()Christophe Leroy1-5/+0
get_tbu() is redundant with mftbu() and is not used anymore. Remove it. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/1746e2d11ea90c3f45877e1fcc6c79ce96cf6b98.1601556145.git.christophe.leroy@csgroup.eu
2020-10-08powerpc/time: Avoid using get_tbl() and get_tbu() internallyChristophe Leroy3-7/+7
get_tbl() is confusing as it returns the content of TBL register on PPC32 but the concatenation of TBL and TBU on PPC64. Use mftb() instead. Do the same with get_tbu() for consistency allthough it's name is less confusing. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/41573406a4eab98838decaa91649086fef1e6119.1601556145.git.christophe.leroy@csgroup.eu
2020-10-08powerpc/time: Make mftb() common to PPC32 and PPC64Christophe Leroy1-10/+4
No need to have two versions that are identical. CONFIG_PPC_CELL is only selected by PPC64 targets. CONFIG_E500 is the only PPC64 target selecting CONFIG_FSL_BOOK3E. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/6bf23ec744aab4ba63506a011f6a145ea35d620d.1601556145.git.christophe.leroy@csgroup.eu
2020-10-08powerpc/time: Rename mftbl() to mftb()Christophe Leroy2-4/+3
On PPC64, we have mftb(). On PPC32, we have mftbl() and an #define mftb() mftbl(). mftb() and mftbl() are equivalent, their purpose is to read the content of SPRN_TRBL, as returned by 'mftb' simplified instruction. binutils seems to define 'mftbl' instruction as an equivalent of 'mftb'. However in both 32 bits and 64 bits documentation, only 'mftb' is defined, and when performing a disassembly with objdump, the displayed instruction is 'mftb' No need to have two ways to do the same thing with different names, rename mftbl() to have only mftb(). Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/94dc68d3d9ef9eb549796d4b938b6ba0305a049b.1601556145.git.christophe.leroy@csgroup.eu
2020-10-08powerpc/32s: Remove #ifdef CONFIG_PPC_BOOK3S_32 in head_book3s_32.SChristophe Leroy1-15/+0
head_book3s_32.S is only built when CONFIG_PPC_BOOK3S_32 is selected. Remove all conditions based on CONFIG_PPC_BOOK3S_32 in the file. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/1b68632425d8866d147aea9005004e4594672211.1601975100.git.christophe.leroy@csgroup.eu
2020-10-08powerpc/32s: Rename head_32.S to head_book3s_32.SChristophe Leroy3-3/+5
Unlike PPC64 which had a single head_64.S, PPC32 are multiple ones. There is the head_32.S, selected by default based on the value of BITS and overridden based on some CONFIG_ values. This leads to thinking that it may be selected by different types of PPC32 platform but indeed it ends up being selected by book3s/32 only. Make that explicit by: - Not doing any default selection based on BITS. - Renaming head_32.S to head_book3s_32.S. - Get head_book3s_32.S selected only by CONFIG_PPC_BOOK3S_32. Signed-off-by: Christophe Leroy <[email protected]> [mpe: Fix head_$(BITS).o reference in arch/powerpc/Makefile] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/319d379f696412681c66a987cc75e6abf8f958d2.1601975100.git.christophe.leroy@csgroup.eu
2020-10-08powerpc/32s: Setup the early hash table at all time.Christophe Leroy4-38/+17
At the time being, an early hash table is set up when CONFIG_KASAN is selected. There is nothing wrong with setting such an early hash table all the time, even if it is not used. This is a statically allocated 256 kB table which lies in the init data section. This makes the code simpler and may in the future allow to setup early IO mappings with fixmap instead of hard coding BATs. Put create_hpte() and flush_hash_pages() in the .ref.text section in order to avoid warning for the reference to early_hash[]. This reference is removed by MMU_init_hw_patch() before init memory is freed. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/b8f8101c368b8a6451844a58d7bd7d83c14cf2aa.1601566529.git.christophe.leroy@csgroup.eu
2020-10-08powerpc/time: Remove ifdef in get_dec() and set_dec()Christophe Leroy3-14/+12
Move SPRN_PIT definition in reg.h. This allows to remove ifdef in get_dec() and set_dec() and makes them more readable. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/3c9a6eb0fc040868ac59be66f338d08fd017668d.1601549945.git.christophe.leroy@csgroup.eu
2020-10-08powerpc: Remove get_tb_or_rtc()Christophe Leroy3-9/+4
601 is gone, get_tb_or_rtc() is equivalent to get_tb(). Replace the former by the later. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/3e8a13ee83418630c753c30cb722ae682d5b2d39.1601362098.git.christophe.leroy@csgroup.eu
2020-10-08powerpc: Remove __USE_RTC()Christophe Leroy2-71/+9
Now that PowerPC 601 is gone, __USE_RTC() is never true. Remove it. That also leads to removing get_rtc() and get_rtcl() Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/4757e1ed21fe1968c761ae081d1f3d790a9673f8.1601362098.git.christophe.leroy@csgroup.eu
2020-10-08powerpc: Tidy up a bit after removal of PowerPC 601.Christophe Leroy2-32/+24
The removal of the 601 left some standalone blocks from former if/else. Drop the { } and re-indent. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/31c4cd093963f22831bf388449056ee045533d3b.1601362098.git.christophe.leroy@csgroup.eu
2020-10-08powerpc: Remove support for PowerPC 601Christophe Leroy17-206/+17
PowerPC 601 has been retired. Remove all associated specific code. CPU_FTRS_PPC601 has CPU_FTR_COHERENT_ICACHE and CPU_FTR_COMMON. CPU_FTR_COMMON is already present via other CPU_FTRS. None of the remaining CPU selects CPU_FTR_COHERENT_ICACHE. So CPU_FTRS_PPC601 can be removed from the possible features, hence can be removed completely. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/60b725d55e21beec3335175c20b77903ff98284f.1601362098.git.christophe.leroy@csgroup.eu
Powered by cgit, Gruvboxed by Blaster4385.