- 14 8月, 2013 11 次提交
-
-
由 Kevin Hao 提交于
And now the function flush_icache_range() is just a wrapper which only invoke the function __flush_icache_range() directly. So we don't have reason to keep it anymore. Signed-off-by: NKevin Hao <haokexin@gmail.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Kevin Hao 提交于
In function flush_icache_range(), we use cpu_has_feature() to test the feature bit of CPU_FTR_COHERENT_ICACHE. But this seems not optimal for two reasons: a) For ppc32, the function __flush_icache_range() already do this check with the macro END_FTR_SECTION_IFSET. b) Compare with the cpu_has_feature(), the method of using macro END_FTR_SECTION_IFSET will not introduce any runtime overhead. [And while at it, add the missing required isync] -- BenH Signed-off-by: NKevin Hao <haokexin@gmail.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
Although the shared_proc field in the lppaca works today, it is not architected. A shared processor partition will always have a non zero yield_count so use that instead. Create a wrapper so users don't have to know about the details. In order for older kernels to continue to work on KVM we need to set the shared_proc bit. While here, remove the ugly bitfield. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
Fix a sparse warning about force_32bit_msi being a one bit bitfield. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
Address some of the trivial sparse warnings in arch/powerpc. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
plpar_get_term_char is only used once and just adds a layer of complexity to H_GET_TERM_CHAR. plpar_put_term_char isn't used at all so we can remove it. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
Simplify things by putting all the 32bit and 64bit defines together instead of in two spots. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
We always use VMX loads and stores to manage the high 32 VSRs. Remove these unused macros. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
Not having parentheses around a macro is asking for trouble. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
Normally when we haven't implemented an alignment handler for a load or store instruction the process will be terminated. The alignment handler uses the DSISR (or a pseudo one) to locate the right handler. Unfortunately ldbrx and stdbrx overlap lfs and stfs so we incorrectly think ldbrx is an lfs and stdbrx is an stfs. This bug is particularly nasty - instead of terminating the process we apply an incorrect fixup and continue on. With more and more overlapping instructions we should stop creating a pseudo DSISR and index using the instruction directly, but for now add a special case to catch ldbrx/stdbrx. Signed-off-by: NAnton Blanchard <anton@samba.org> Cc: <stable@vger.kernel.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
p_toc is an 8 byte relative offset to the TOC that we place in the text section. This means it is only 4 byte aligned where it should be 8 byte aligned. Add an explicit alignment. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 08 8月, 2013 17 次提交
-
-
由 Catalin Udma 提交于
If CONFIG_E500 is enabled, the compilation flags are updated specifying the target core -mcpu=e5500/e500mc/8540 Also remove -Wa,-me500, being incompatible with -mcpu=e5500/e6500 The assembler option is redundant if the -mcpu= flag is set. The patch fixes the kernel compilation problem for e5500/e6500 when using gcc option -mcpu=e5500/e6500. Signed-off-by: NCatalin Udma <catalin.udma@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Zhenhua Luo 提交于
When using recent udev, the /dev node mount requires CONFIG_DEVTMPFS_MOUNT is enabled in Kernel. The patch enables the option in defconfig of Freescale QorIQ targets. Changed defconfig list: arch/powerpc/configs/85xx/p1023rds_defconfig arch/powerpc/configs/corenet32_smp_defconfig arch/powerpc/configs/corenet64_smp_defconfig arch/powerpc/configs/mpc85xx_smp_defconfig arch/powerpc/configs/mpc85xx_defconfig arch/powerpc/configs/mpc83xx_defconfig Signed-off-by: NZhenhua Luo <zhenhua.luo@freescale.com> [scottwood@freescale.com: added mpc83xx and non-smp mpc85xx] Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Yuanquan Chen 提交于
For Freescale powerpc platform, the PCI-e bus number uses the reassign mode by default. It means the second PCI-e controller's hose->first_busno is the first controller's last bus number adding 1. For some hotpluged device(or controlled by FPGA), the device is linked to PCI-e slot at linux runtime. It needs rescan for the system to add it and driver it to work. It successes to rescan the device linked to the first PCI-e controller's slot, but fails to rescan the device linked to the second PCI-e controller's slot. The cause is that the bus->number is reset to 0, which isn't equal to the hose->first_busno for the second controller checking PCI-e link. So it doesn't really check the PCI-e link status, the link status is always no_link. The device won't be really rescaned. Reset the bus->number to hose->first_busno in the function fsl_pcie_check_link(), it will do the real checking PCI-e link status for the second controller, the device will be rescaned. Signed-off-by: NYuanquan Chen <Yuanquan.Chen@freescale.com> Tested-by: NRojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Kevin Hao 提交于
This function contains all the stuff we need to check if SWIOTLB should be enabled or not. So it is more convenient to enable the SWIOTLB here than later. Signed-off-by: NKevin Hao <haokexin@gmail.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Kevin Hao 提交于
The (1ull << mem_log) is never greater than mem unless mem_log++; Signed-off-by: NKevin Hao <haokexin@gmail.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Kevin Hao 提交于
The function pci_devs_phb_init is invoked more earlier than we really probe the pci controller, so it does nothing at all. And we also don't need the pci_dn stuff for the fsl powerpc64 boards, just remove it. It also seems that we don't support ISA on all the current corenet ds boards. So picking a primary bus seems useless, remove that function too. Signed-off-by: NKevin Hao <haokexin@gmail.com>
-
由 Haijun.Zhang 提交于
Overview of P1020RDB-PD device: - DDR3 2GB - NOR flash 64MB - NAND flash 128MB - SPI flash 16MB - I2C EEPROM 256Kb - eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch - eTSEC2 (SGMII PHY) - eTSEC3 (RGMII PHY) - SDHC - 1 USB ports - TDM ports - PCIe Signed-off-by: NHaijun Zhang <Haijun.Zhang@freescale.com> Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com> Signed-off-by: NXie Xiaobo-R63061 <X.Xie@freescale.com> CC: Scott Wood <scottwood@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Haijun.Zhang 提交于
The p1020rdb-pd has the similar feature as the p1020rdb. Therefore, p1020rdb-pd use the same platform file as the p1/p2 rdb board. Overview of P1020RDB-PD platform: - DDR3 2GB - NOR flash 64MB - NAND flash 128MB - SPI flash 16MB - I2C EEPROM 256Kb - eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch - eTSEC2 (SGMII PHY) - eTSEC3 (RGMII PHY) - SDHC - 2 USB ports - 4 TDM ports - PCIe Signed-off-by: NHaijun Zhang <Haijun.Zhang@freescale.com> Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com> CC: Scott Wood <scottwood@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Laurentiu TUDOR 提交于
At console init, when the kernel tries to flush the log buffer the ePAPR byte-channel based console write fails silently, losing the buffered messages. This happens because The ePAPR para-virtualization init isn't done early enough so that the hcall instruction to be set, causing the byte-channel write hcall to be a nop. To fix, change the ePAPR para-virt init to use early device tree functions and move it in early init. Signed-off-by: NLaurentiu Tudor <Laurentiu.Tudor@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Minghuan Lian 提交于
The original MPIC MSI bank contains 8 registers, MPIC v4.3 MSI bank contains 16 registers, and this patch adds NR_MSI_REG_MAX and NR_MSI_IRQS_MAX to describe the maximum capability of MSI bank. MPIC v4.3 provides MSIIR1 to index these 16 MSI registers. MSIIR1 uses different bits definition than MSIIR. This patch adds ibs_shift and srs_shift to indicate the bits definition of the MSIIR and MSIIR1, so the same code can handle the MSIIR and MSIIR1 simultaneously. Signed-off-by: NMinghuan Lian <Minghuan.Lian@freescale.com> [scottwood@freescale.com: reinstated static on all_avail] Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Minghuan Lian 提交于
For the latest platform T4 and B4, MPIC controller has been updated to v4.3. This patch adds a new file to describe the latest MPIC. The MSI blocks number is increased to four, the registers number of each block is increased to sixteen. MSIIR1 has been added to access these sixteen MSI registers. Signed-off-by: NMinghuan Lian <Minghuan.Lian@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Hongtao Jia 提交于
mpic_get_primary_version() is not defined when not using MPIC. The compile error log like: arch/powerpc/sysdev/built-in.o: In function `fsl_of_msi_probe': fsl_msi.c:(.text+0x150c): undefined reference to `fsl_mpic_primary_get_version' Signed-off-by: NJia Hongtao <hongtao.jia@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Priyanka Jain 提交于
e6500 core performance monitors has the following features: - 6 performance monitor counters - 512 events supported - no threshold events e6500 PMU has more specific events (Data L1 cache misses, Instruction L1 cache misses, etc ) than e500 PMU (which only had Data L1 cache reloads, etc). Where available, the more specific events have been used which will produce slightly different results than e500 PMU equivalents. Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com> Signed-off-by: NLijun Pan <Lijun.Pan@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Lijun Pan 提交于
There are 6 counters in e6500 core instead of 4 in e500 core. Signed-off-by: NLijun Pan <Lijun.Pan@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Catalin Udma 提交于
This change is required after the e6500 perf support has been added. There are 6 counters in e6500 core instead of 4 in e500 core and the MAX_HWEVENTS counter should be changed accordingly from 4 to 6. Added also runtime check for counters overflow. Signed-off-by: NCatalin Udma <catalin.udma@freescale.com> Signed-off-by: NLijun Pan <Lijun.Pan@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Lijun Pan 提交于
Signed-off-by: NLijun Pan <Lijun.Pan@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Ian Campbell 提交于
This file is a common include for B4860 and B4420 but is not a valid DTS itself: DTC arch/powerpc/boot/b4qds.dtb Error: arch/powerpc/boot/dts/b4qds.dts:35.1-2 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [arch/powerpc/boot/b4qds.dtb] Error 1 make: *** [b4qds.dtb] Error 2 I spotted in build tests of device-tree.git, announcement https://lkml.org/lkml/2013/4/24/209, which builds *.dts. Probably no one would do this this in real life on linux.git but it still seems worth fixing. Signed-off-by: NIan Campbell <ian.campbell@citrix.com> Cc: Shaveta Leekha <shaveta@freescale.com> Cc: Minghuan Lian <Minghuan.Lian@freescale.com> Cc: Andy Fleming <afleming@freescale.com> Cc: Poonam Aggrwal <poonam.aggrwal@freescale.com> Cc: Ramneek Mehresh <ramneek.mehresh@freescale.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NScott Wood <scottwood@freescale.com>
-
- 05 8月, 2013 3 次提交
-
-
由 Florian Fainelli 提交于
The hardware interrupt routing for boot CPU != 0 is wrong because it will route all the hardware interrupts to TP0 which is not the one we booted from. Fix this by properly checking which boot CPU we are booting from and updating the right interrupt mask for the boot CPU. This fixes booting on BCM3368 with bmips_smp_emabled = 0. Signed-off-by: NFlorian Fainelli <florian@openwrt.org> Cc: linux-mips@linux-mips.org Cc: blogic@openwrt.org Cc: jogo@openwrt.org Cc: cernekee@gmail.com Patchwork: https://patchwork.linux-mips.org/patch/5650/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
current_cpu_type() is not preemption-safe. If CONFIG_PREEMPT is enabled then mipsxx_reg_setup() can be called from preemptible state. Added get_cpu()/put_cpu() pair to make it preemption-safe. This was found while testing oprofile with CONFIG_DEBUG_PREEMPT enable. /usr/zntestsuite # opcontrol --init /usr/zntestsuite # opcontrol --setup --event=L2_CACHE_ACCESSES:500 --event=L2_CACHE_MISSES:500 --no-vmlinux /usr/zntestsuite # opcontrol --start Using 2.6+ OProfile kernel interface. BUG: using smp_processor_id() in preemptible [00000000] code: oprofiled/1362 caller is mipsxx_reg_setup+0x11c/0x164 CPU: 0 PID: 1362 Comm: oprofiled Not tainted 3.10.4 #18 Stack : 00000006 70757465 00000000 00000000 00000000 00000000 80b173f6 00000037 80b10000 00000000 80b21614 88f5a220 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 89c49c00 89c49c2c 80721254 807b7927 8012c1d0 80b10000 80721254 00000000 00000552 88f5a220 80b1335c 807b78e6 89c49ba8 ... Call Trace: [<801099a4>] show_stack+0x64/0x7c [<80665520>] dump_stack+0x20/0x2c [<803a2250>] debug_smp_processor_id+0xe0/0xf0 [<8052df24>] mipsxx_reg_setup+0x11c/0x164 [<8052cd70>] op_mips_setup+0x24/0x4c [<80529cfc>] oprofile_setup+0x5c/0x12c [<8052b9f8>] event_buffer_open+0x78/0xf8 [<801c3150>] do_dentry_open.isra.15+0x2b8/0x3b0 [<801c3270>] finish_open+0x28/0x4c [<801d49b8>] do_last.isra.41+0x2cc/0xd00 [<801d54a0>] path_openat+0xb4/0x4c4 [<801d5c44>] do_filp_open+0x3c/0xac [<801c4744>] do_sys_open+0x110/0x1f4 [<8010f47c>] stack_done+0x20/0x44 Bug reported and original patch by Jerin Jacob <jerinjacobk@gmail.com>. Signed-off-by: NRalf Baechle <ralf@linux-mips.org> Acked-by: NJerin Jacob <jerinjacobk@gmail.com>
-
由 Markos Chandras 提交于
The PNX8335_PCI_ETHERNET_INT macro is defined in arch/mips/include/asm/mach-pnx833x/irq-mapping.h only if CONFIG_SOC_PNX8335 is selected. Fixes the following randconfig problem: arch/mips/pnx833x/common/platform.c:210:12: error: 'PNX8335_PIC_ETHERNET_INT' undeclared here (not in a function) Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com> Acked-by: NSteven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5585/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 03 8月, 2013 2 次提交
-
-
由 Russell King 提交于
Olof reports that noMMU builds error out with: arch/arm/kernel/signal.c: In function 'setup_return': arch/arm/kernel/signal.c:413:25: error: 'mm_context_t' has no member named 'sigpage' This shows one of the evilnesses of IS_ENABLED(). Get rid of it here and replace it with #ifdef's - and as no noMMU platform can make use of sigpage, depend on CONIFG_MMU not CONFIG_ARM_MPU. Reported-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Unfortunately, I never committed the fix to a nasty oops which can occur as a result of that commit: ------------[ cut here ]------------ kernel BUG at /home/olof/work/batch/include/linux/mm.h:414! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 490 Comm: killall5 Not tainted 3.11.0-rc3-00288-gabe03080 #53 task: e90acac0 ti: e9be8000 task.ti: e9be8000 PC is at special_mapping_fault+0xa4/0xc4 LR is at __do_fault+0x68/0x48c This doesn't show up unless you do quite a bit of testing; a simple boot test does not do this, so all my nightly tests were passing fine. The reason for this is that install_special_mapping() expects the page array to stick around, and as this was only inserting one page which was stored on the kernel stack, that's why this was blowing up. Reported-by: NOlof Johansson <olof@lixom.net> Tested-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 8月, 2013 7 次提交
-
-
由 Russell King 提交于
Commit 8bd26e3a (arm: delete __cpuinit/__CPUINIT usage from all ARM users) caused some code to leak into sections which are discarded through the removal of __CPUINIT annotations. Add appropriate .text annotations to bring these back into the kernel text. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Stephen Boyd 提交于
If one process calls sys_reboot and that process then stops other CPUs while those CPUs are within a spin_lock() region we can potentially encounter a deadlock scenario like below. CPU 0 CPU 1 ----- ----- spin_lock(my_lock) smp_send_stop() <send IPI> handle_IPI() disable_preemption/irqs while(1); <PREEMPT> spin_lock(my_lock) <--- Waits forever We shouldn't attempt to run any other tasks after we send a stop IPI to a CPU so disable preemption so that this task runs to completion. We use local_irq_disable() here for cross-arch consistency with x86. Reported-by: NSundarajan Srinivasan <sundaraj@codeaurora.com> Signed-off-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
If kuser helpers are not provided by the kernel, disable user access to the vectors page. With the kuser helpers gone, there is no reason for this page to be visible to userspace. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Move the signal handlers into a VDSO page rather than keeping them in the vectors page. This allows us to place them randomly within this page, and also map the page at a random location within userspace further protecting these code fragments from ROP attacks. The new VDSO page is also poisoned in the same way as the vector page. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Robert Jennings 提交于
When an associativity level change is found for one thread, the siblings threads need to be updated as well. This is done today for PRRN in stage_topology_update() but is missing for VPHN in update_cpu_associativity_changes_mask(). This patch will correctly update all thread siblings during a topology change. Without this patch a topology update can result in a CPU in init_sched_groups_power() getting stuck indefinitely in a loop. This loop is built in build_sched_groups(). As a result of the thread moving to a node separate from its siblings the struct sched_group will have its next pointer set to point to itself rather than the sched_group struct of the next thread. This happens because we have a domain without the SD_OVERLAP flag, which is correct, and a topology that doesn't conform with reality (threads on the same core assigned to different numa nodes). When this list is traversed by init_sched_groups_power() it will reach the thread's sched_group structure and loop indefinitely; the cpu will be stuck at this point. The bug was exposed when VPHN was enabled in commit b7abef04 (v3.9). Cc: <stable@vger.kernel.org> [v3.9+] Reported-by: NJan Stancek <jstancek@redhat.com> Signed-off-by: NRobert Jennings <rcj@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
We use bit 63 of the event code for userspace to request that the event be counted using EBB (Event Based Branches). Export this value, making it part of the API - though only on processors that support EBB. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
Back in commit 89713ed1 "Add timer, performance monitor and machine check counts to /proc/interrupts" we added a count of PMU interrupts to the output of /proc/interrupts. At the time we named them "CNT" to match x86. However in commit 89ccf465 "Rename 'performance counter interrupt'", the x86 guys renamed theirs from "CNT" to "PMI". Arguably changing the name could break someone's script, but I think the chance of that is minimal, and it's preferable to have a name that 1) is somewhat meaningful, and 2) matches x86. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-