- 22 Jan, 2014 33 commits
-
-
Markos Chandras authored
Add support for including VPE and TC ids in /proc/cpuinfo output as appropriate when MT/SMTC is enabled. Reviewed-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Signed-off-by:
John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6065/
-
Leonid Yegoshin authored
Commit 225ae5fd "MIPS: Malta: Fix interupt number of CBUS UART" fixed the IRQ number for the ttyS2 CBUS UART. However, this now conflicts with the GIC IPI1 interrupt in CMP platforms. The Malta interrupt code arbitrarily binds IPIs to INT2 and INT3 and since ttyS2 uses the INT2 IRQ line, closing the device disables the INT2 interrupt and this effectively disables the IPI1 interrupt as well. This patch is mainly a workaround until the Malta code is fixed properly. Signed-off-by:
Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Signed-off-by:
-
Leonid Yegoshin authored
The cacheer register is always implemented in the same way in the MIPS32r2 Imgtec cores so print the ES bit when an cache error occurs. Signed-off-by:
-
Steven J. Hill authored
If GIC is present, then use it to send IPIs between the cores. Using GIC for IPIs is simpler and is usable for multicore systems compared to the existing way of doing IPIs where all VPEs had to be disabled for another VPE to access the Cause register in one of the TCs and enable all the VPEs back. Signed-off-by:
Steven J. Hill <Steven.Hill@imgtec.com> Signed-off-by:
-
Markos Chandras authored
According to Documentation/cpu-hotplug.txt, the cpu_present_mask should contain all the CPUs which are present in the system. Therefore, all the TCs currently present in the system should be marked as 'present' even if they will never be brought online. Signed-off-by:
-
Markos Chandras authored
According to MIPS32 and MIPS64 PRA documents, a value of 7 in IL and DL fields is marked as "Reserved" so panic if the core uses this value in the config1 register. Also simplify the code a little bit. Signed-off-by:
-
Markos Chandras authored
The mips_mt_* symbols are only built and exported if CONFIG_MIPS_MT is enabled. Fixes the following build problem when CONFIG_SMP is enabled but CONFIG_MIPS_MT is not. arch/mips/built-in.o: In function `cmp_prepare_cpus': arch/mips/kernel/smp-cmp.c:197: undefined reference to `mips_mt_set_cpuoptions' Signed-off-by:
-
Ilia Mirkin authored
Fix nvram_read_alpha2 copying too many bytes over the ssb_sprom structure. Also fix the arguments of the read_macaddr, although the code was technically not wrong before due to an extra dereference. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Acked-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Hauke Mehrtens authored
This adds support for vectored interrupt which is supported by the SoC using a MIPS 74K CPU like the BCM4716 and BCM4706. Signed-off-by:
-
Hauke Mehrtens authored
The BCM47XX SoC code missed a cpu-feature-overrides.h header file, this patch adds it. This code supports a long line of SoCs with different features so for some features we still have to rely on the runtime detection. This was crated by checking the features of a BCM4712, BCM4704, BCM5354, BCM4716 and BCM4706 SoC and then tested on these SoCs. There are some SoCs missing but I hope they do not have any more or less features. Signed-off-by:
-
Hauke Mehrtens authored
Move the possible nvram sizes from the stack into the data segment Signed-off-by:
-
Hauke Mehrtens authored
plat_irq_dispatch() is called from asm code, add asmlinkage. Signed-off-by:
-
Hauke Mehrtens authored
The defconfig for bcm47xx contained lots of driver which are not special for these SoCs and missed on the other side some some drivers for parts essential for these SoC and only found on here. The flash, usb and some Ethernet driver were missing. Signed-off-by:
-
Hauke Mehrtens authored
The BCM47xx SoCs have a 8250 serial compatible console at address 0x18000300 and an other at 0x18000400. On most devices 0x18000300 is wired to some pins on the board, we should use that. This is the smae for the AI (bcma) and the SB (ssb) bus, this is some offset on the chip common core. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
-
Hauke Mehrtens authored
bcm47xx only uses the CFE code for early print to a console, but that is also possible with a early print serial 8250 driver. The CFE api init causes hangs somewhere in prom_init_cfe() on some devices like the Buffalo WHR-HP-G54 and the Asus WL-520GU. This was reported in https://dev.openwrt.org/ticket/4061 and https://forum.openwrt.org/viewtopic.php?id=17063 This will remove all the CFE handling code from bcm47xx. Signed-off-by:
-
Hauke Mehrtens authored
Recently the output of "system type" in /proc/cpuinfo was changed to Broadcom BCM4730 (Some sample board), but it is better to just print the SoC name in the "system type" entry. The board name will be added in the machine entry later. Signed-off-by:
-
Jonas Gorski authored
All MIPS cores on BCM63XX identify as Broadcom, not MIPS, so no need to support non-broadcom MIPS CPUs. This also ensures that CPU_BMIPS is always selected. Signed-off-by:
Jonas Gorski <jogo@openwrt.org> Signed-off-by:
-
Jonas Gorski authored
BMIPS32 and BMIPS3300 also need to be available for MIPS32R1, as bcm47xx might not select BMIPS. Signed-off-by:
-
Jonas Gorski authored
Let BCM47XX_SSB select the appropriate BMIPS CPUs enountered on those systems. Signed-off-by:
-
Jonas Gorski authored
Let each supported chip select the appropirate SYS_HAS_CPU_BMIPS* option for its embedded processor, so support will be conditionally included. Signed-off-by:
-
Jonas Gorski authored
Use the return value for guarding further SMP setup. Signed-off-by:
-
Jonas Gorski authored
Add a helper similar to the generic register_XXX_smp_ops() for bmips. Register SMP UP ops in case of BMIPS32/3300. Signed-off-by:
-
Jonas Gorski authored
Codewise there is no difference between these two, so it does not make sense to treat them differently. Also chip families having one of these tend to have the other. Signed-off-by:
-
Jonas Gorski authored
As they are MIPS32 CPUs they do support the prefetch opcode. Signed-off-by:
-
Jonas Gorski authored
All BMIPS CPUs support HIGHMEM, so it should be selected by CPU_BMIPS. Signed-off-by:
-
Jonas Gorski authored
Instead of treating each flavour as an exclusive CPU to select, make BMIPS the only option and let SYS_HAS_CPU_BMIPS* decide for which flavours to include support. Run tested on BMIPS3300 and BMIPS4350, only build tested for BMIPS4380 and BMIPS5000. Signed-off-by:
-
Jonas Gorski authored
Allow building for all bmips cpus at the same time by changing ifdefs to checks for the cpu type, or adding appropriate checks to the assembly. Since BMIPS43XX and BMIPS5000 require different IPI implementations, split the SMP ops into one for each, so the runtime overhead is only at registration time for them. Signed-off-by:
-
Jonas Gorski authored
Add guards around the enum to allow including cpu.h from assembly. Signed-off-by:
-
Jonas Gorski authored
BCM3368 has the same shared TLB as BCM6358. Signed-off-by:
-
Jonas Gorski authored
Signed-off-by:
-
Jonas Gorski authored
Signed-off-by:
-
Jonas Gorski authored
Properly set up the HSSPI clock rate depending on the SoC's PLL rate. Signed-off-by:
-
Jonas Gorski authored
Signed-off-by:
-
- 13 Jan, 2014 4 commits
-
-
Paul Burton authored
CPUs implementing MIPS32 R2 may include a 64-bit FPU, just as MIPS64 CPUs do. In order to preserve backwards compatibility a 64-bit FPU will act like a 32-bit FPU (by accessing doubles from the least significant 32 bits of an even-odd pair of FP registers) when the Status.FR bit is zero, again just like a mips64 CPU. The standard O32 ABI is defined expecting a 32-bit FPU, however recent toolchains support use of a 64-bit FPU from an O32 MIPS32 executable. When an ELF executable is built to use a 64-bit FPU a new flag (EF_MIPS_FP64) is set in the ELF header. With this patch the kernel will check the EF_MIPS_FP64 flag when executing an O32 binary, and set Status.FR accordingly. The addition of O32 64-bit FP support lessens the opportunity for optimisation in the FPU emulator, so a CONFIG_MIPS_O32_FP64_SUPPORT Kconfig option is introduced to allow this support to be disabled for those that don't require it. Inspired by an earlier patch by Leonid Yegoshin, but implemented more cleanly & correctly. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Paul Burton <paul.burton@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/6154/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
These macros are not used anywhere in the kernel. Remove them. Signed-off-by:
-
Steven J. Hill authored
This patch adds support for microMIPS encodings of the mfhc1 & mthc1 instructions introduced in release 2 of the mips32 & mips64 architectures, converting them to their mips32 equivalents for the FPU emulator. Signed-off-by:
-
Leonid Yegoshin authored
This patch adds support for the mfhc1 & mthc1 instructions to the FPU emulator. These instructions were introduced in release 2 of the MIPS32 & MIPS64 architectures and allow access to the most significant 32 bits of a 64-bit FP register. [ralf@linux-mips.org: Fix ifdef hell added by original patch.] Signed-off-by:
-
- 12 Jan, 2014 3 commits
-
-
Linus Torvalds authored
-
Steven Rostedt authored
While running stress tests on adding and deleting ftrace instances I hit this bug: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: selinux_inode_permission+0x85/0x160 PGD 63681067 PUD 7ddbe067 PMD 0 Oops: 0000 [#1] PREEMPT CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20 Hardware name: /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006 task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000 RIP: 0010:[<ffffffff812d8bc5>] [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160 RSP: 0018:ffff88007ddb1c48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840 RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000 RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54 R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000 R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000 FS: 00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0 Call Trace: security_inode_permission+0x1c/0x30 __inode_permission+0x41/0xa0 inode_permission+0x18/0x50 link_path_walk+0x66/0x920 path_openat+0xa6/0x6c0 do_filp_open+0x43/0xa0 do_sys_open+0x146/0x240 SyS_open+0x1e/0x20 system_call_fastpath+0x16/0x1b Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff RIP selinux_inode_permission+0x85/0x160 CR2: 0000000000000020 Investigating, I found that the inode->i_security was NULL, and the dereference of it caused the oops. in selinux_inode_permission(): isec = inode->i_security; rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd); Note, the crash came from stressing the deletion and reading of debugfs files. I was not able to recreate this via normal files. But I'm not sure they are safe. It may just be that the race window is much harder to hit. What seems to have happened (and what I have traced), is the file is being opened at the same time the file or directory is being deleted. As the dentry and inode locks are not held during the path walk, nor is the inodes ref counts being incremented, there is nothing saving these structures from being discarded except for an rcu_read_lock(). The rcu_read_lock() protects against freeing of the inode, but it does not protect freeing of the inode_security_struct. Now if the freeing of the i_security happens with a call_rcu(), and the i_security field of the inode is not changed (it gets freed as the inode gets freed) then there will be no issue here. (Linus Torvalds suggested not setting the field to NULL such that we do not need to check if it is NULL in the permission check). Note, this is a hack, but it fixes the problem at hand. A real fix is to restructure the destroy_inode() to call all the destructor handlers from the RCU callback. But that is a major job to do, and requires a lot of work. For now, we just band-aid this bug with this fix (it works), and work on a more maintainable solution in the future. Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.home Cc: stable@vger.kernel.org Signed-off-by:Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Hugh Dickins authored
We see General Protection Fault on RSI in copy_page_rep: that RSI is what you get from a NULL struct page pointer. RIP: 0010:[<ffffffff81154955>] [<ffffffff81154955>] copy_page_rep+0x5/0x10 RSP: 0000:ffff880136e15c00 EFLAGS: 00010286 RAX: ffff880000000000 RBX: ffff880136e14000 RCX: 0000000000000200 RDX: 6db6db6db6db6db7 RSI: db73880000000000 RDI: ffff880dd0c00000 RBP: ffff880136e15c18 R08: 0000000000000200 R09: 000000000005987c R10: 000000000005987c R11: 0000000000000200 R12: 0000000000000001 R13: ffffea00305aa000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f195752f700(0000) GS:ffff880c7fc20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000093010000 CR3: 00000001458e1000 CR4: 00000000000027e0 Call Trace: copy_user_huge_page+0x93/0xab do_huge_pmd_wp_page+0x710/0x815 handle_mm_fault+0x15d8/0x1d70 __do_page_fault+0x14d/0x840 do_page_fault+0x2f/0x90 page_fault+0x22/0x30 do_huge_pmd_wp_page() tests is_huge_zero_pmd(orig_pmd) four times: but since shrink_huge_zero_page() can free the huge_zero_page, and we have no hold of our own on it here (except where the fourth test holds page_table_lock and has checked pmd_same), it's possible for it to answer yes the first time, but no to the second or third test. Change all those last three to tests for NULL page. (Note: this is not the same issue as trinity's DEBUG_PAGEALLOC BUG in copy_page_rep with RSI: ffff88009c422000, reported by Sasha Levin in https://lkml.org/lkml/2013/3/29/103. I believe that one is due to the source page being split, and a tail page freed, while copy is in progress; and not a problem without DEBUG_PAGEALLOC, since the pmd_same check will prevent a miscopy from being made visible.) Fixes: 97ae1749 ("thp: implement refcounting for huge zero page") Signed-off-by:Hugh Dickins <hughd@google.com> Cc: stable@vger.kernel.org # v3.10 v3.11 v3.12 Signed-off-by:
-
