- 01 Aug, 2014 7 commits
-
-
James Hogan authored
In mipsxx_pmu_map_raw_event(), set event_id to base_id after the cpu type conditional code to allow that code to override the base_id to use more bits from the config and a higher bit for parity. This will allow cores with up to 512 events between all even/odd counters (an 8-bit event id) such as P5600 to use bit 8 for parity. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7243/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Alex Smith authored
This header defines an exported interface (the register layout used in core dumps and the GP regset accessible with PTRACE_{GET,SET}REGSET), therefore belongs in uapi. Signed-off-by:Alex Smith <alex@alex-smith.me.uk> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7458/Signed-off-by:
-
Alex Smith authored
The struct user definition in this file is not used anywhere (the ELF core dumper does not use that format). Therefore, remove the header and instead enable the asm-generic user.h which is an empty header to satisfy a few generic headers which still try to include user.h. Signed-off-by:
-
Alex Smith authored
Since the core dumper now uses regsets, the old core dump functions are now unused. Remove them. Signed-off-by:
-
Alex Smith authored
In uapi/asm/ptrace.h, a user version of pt_regs is defined wrapped in ifndef __KERNEL__. This structure definition does not match anything used by any kernel API, in particular it does not match the format used by PTRACE_{GET,SET}REGS. Therefore, replace the structure definition with one matching what is used by PTRACE_{GET,SET}REGS. The format used by these is the same for both 32-bit and 64-bit. Also, change the implementation of PTRACE_{GET,SET}REGS to use this new structure definition. The structure is renamed to user_pt_regs when __KERNEL__ is defined to avoid conflicts with the kernel's own pt_regs. Signed-off-by: -
Alex Smith authored
A comment in the O32/32-bit system call code is incorrect since commit 46e12c07 ("MIPS: O32 / 32-bit: Always copy 4 stack arguments."). Remove it. Signed-off-by:
-
Alex Smith authored
On 32-bit/O32, pt_regs has a padding area at the beginning into which the syscall arguments passed via the user stack are copied. 4 arguments totalling 16 bytes are copied to offset 16 bytes into this area, however the area is only 24 bytes long. This means the last 2 arguments overwrite pt_regs->regs[{0,1}]. If a syscall function returns an error, handle_sys stores the original syscall number in pt_regs->regs[0] for syscall restart. signal.c checks whether regs[0] is non-zero, if it is it will check whether the syscall return value is one of the ERESTART* codes to see if it must be restarted. Should a syscall be made that results in a non-zero value being copied off the user stack into regs[0], and then returns a positive (non-error) value that matches one of the ERESTART* error codes, this can be mistaken for requiring a syscall restart. While the possibility for this to occur has always existed, it is made much more likely to occur by commit 46e12c07 ("MIPS: O32 / 32-bit: Always copy 4 stack arguments."), since now every syscall will copy 4 arguments and overwrite regs[0], rather than just those with 7 or 8 arguments. Since that commit, booting Debian under a 32-bit MIPS kernel almost always results in a hang early in boot, due to a wait4 syscall returning a PID that matches one of the ERESTART* codes, which then causes an incorrect restart of the syscall. The problem is fixed by increasing the size of the padding area so that arguments copied off the stack will not overwrite pt_regs->regs[{0,1}]. Signed-off-by:Alex Smith <alex.smith@imgtec.com> Cc: <stable@vger.kernel.org> # v3.13+ Reviewed-by:
Aurelien Jarno <aurelien@aurel32.net> Tested-by:
-
- 30 Jul, 2014 33 commits
-
-
Alex Smith authored
Commit 6a9c001b ("MIPS: Switch ELF core dumper to use regsets.") switched the core dumper to use regsets, however the GP regset code simply makes a direct copy of the kernel's pt_regs, which does not match the original core dump register layout as defined in asm/reg.h. Furthermore, the definition of pt_regs can vary with certain Kconfig variables, therefore the GP regset can never be relied upon to return registers in the same layout. Therefore, this patch changes the GP regset to match the original core dump layout. The layout differs for 32- and 64-bit processes, so separate implementations of the get/set functions are added for the 32- and 64-bit regsets. Signed-off-by:
-
Alex Smith authored
Get rid of the WANT_COMPAT_REG_H test and instead define both the 32- and 64-bit register offset definitions at the same time with MIPS{32,64}_ prefixes, then define the existing EF_* names to the correct definitions for the kernel's bitness. This patch is a prerequisite of the following bug fix patch. Signed-off-by: -
Alex Smith authored
task_user_regset_view() should test for TIF_32BIT_REGS in the flags of the specified task, not of the current task. Signed-off-by:
-
Alex Smith authored
Whenever ptrace attempts to retrieve the FPU implementation register it accesses it through current_cpu_data, which calls smp_processor_id(). Since the code may execute with preemption enabled, this can trigger a warning. Fix this by using boot_cpu_data to get the IR instead. Signed-off-by:
-
Rafał Miłecki authored
So far BCM47XX can only detect amount of HIGHMEM. It still requires adding (registering) and well-testing before enabling by default. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Acked-by:
Hauke Mehrtens <hauke@hauke-m.de> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7396/Signed-off-by:
-
Rafał Miłecki authored
This reverts commit d7a887a7. Function add_temporary_entry is needed by bcm47xx to support highmem. We need to add a temporary entry to check for amount of RAM. The only change made in this revert was replacing (ENTER|EXIT)_CRITICAL. Signed-off-by:
-
Rafał Miłecki authored
Detect more devices and register leds & buttons for them. Signed-off-by:
-
Rafał Miłecki authored
It seems that bcm47xx can handle only 128 MiB of RAM directly. There are few devices with 256 MiB, but Broadcom's SDK uses highmem to handle anything above 128 MiB. Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Reported-by:
Catalin Patulea <cat@vv.carleton.ca> Signed-off-by:
-
Rafał Miłecki authored
Catalin reported that GPIOs used by bcm47xx don't match layout of his WRT54GS V1.0 board. It seems we need to distinguish these 54G* devices. Reported-by:
-
Huacai Chen authored
Since this CONFIG option will be used for both Loongson-3A/3B machines, and not all Loongson-3 machines are produced by Lemote, we rename CONFIG_LEMOTE_MACH3A to CONFIG_LOONGSON_MACH3X. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/7190/Signed-off-by:
-
Huacai Chen authored
Loongson-3 has some specific instructions (MMI/SIMD) in coprocessor 2. COP2 isn't independent because it share COP1 (FPU)'s registers. This patch enable the COP2 usage so user-space programs can use the MMI/SIMD instructions. When COP2 exception happens, we enable both COP1 (FPU) and COP2, only in this way the fp context can be saved and restored correctly. Signed-off-by:
-
Huacai Chen authored
Loongson-3B is a 8-cores processor. In general it looks like there are two Loongson-3A integrated in one chip: 8 cores are separated into two groups (two NUMA node), each node has its own local memory. Of course there are some differences between one Loongson-3B and two Loongson-3A. E.g., the base addresses of IPI registers of each node are not the same; Loongson-3A use ChipConfig register to enable/disable clock, but Loongson-3B use FreqControl register instead. There are two revision of Loongson-3B, the first revision is called as Loongson-3B1000, whose frequency is 1GHz and has a PRid 0x6306, the second revision is called as Loongson-3B1500, whose frequency is 1.5GHz and has a PRid 0x6307. Both revisions has a bug that clock cannot be disabled at runtime, but this will be fixed in future. Signed-off-by:
-
Huacai Chen authored
Enable sys_mbind()/sys_get_mempolicy()/sys_set_mempolicy() for O32, N32, and N64 ABIs. By the way, O32/N32 should use the compat version of sys_migrate_pages()/sys_move_pages(), so fix that. Signed-off-by:
-
Huacai Chen authored
Multiple Loongson-3A chips can be interconnected with HT0-bus. This is a CC-NUMA system that every chip (node) has its own local memory and cache coherency is maintained by hardware. The 64-bit physical memory address format is as follows: 0x-0000-YZZZ-ZZZZ-ZZZZ The high 16 bits should be 0, which means the real physical address supported by Loongson-3 is 48-bit. The "Y" bits is the base address of each node, which can be also considered as the node-id. The "Z" bits is the address offset within a node, which means every node has a 44 bits address space. Macros XPHYSADDR and MAX_PHYSMEM_BITS are modified unconditionally, because many other MIPS CPUs have also extended their address spaces. Signed-off-by:
-
Huacai Chen authored
This patch is prepared for Multi-chip interconnection. Since each chip has a ChipConfig register, LOONGSON_CHIPCFG should be an array. Signed-off-by:
-
Huacai Chen authored
This patch is prepared for Loongson's NUMA support, it offer meaningful sysfs files such as physical_package_id, core_id, core_siblings and thread_siblings in /sys/devices/system/cpu/cpu?/topology. Signed-off-by:
Andreas Herrmann <andreas.herrmann@caviumnetworks.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/7184/Signed-off-by:
-
Huacai Chen authored
On MIPS currently, only the soft limit of cpu count (maxcpus) has its effect, this patch enable the hard limit (nr_cpus) as well. Processor cores which greater than maxcpus and less than nr_cpus can be taken up via cpu hotplug. The code is borrowed from X86. Signed-off-by:
-
Emil Goode authored
We check that the struct vm_area_struct pointer vma is NULL and then dereference it a few lines below. The intent was to make sure vma is not NULL but this is not necessary since the bug pre-dates GIT history and seem to never have caused a problem. The tlb-4k and tlb-8k versions of local_flush_tlb_page() don't bother checking if vma is NULL, also vma is dereferenced before being passed to local_flush_tlb_page(), thus it is safe to remove this NULL check. Signed-off-by:
Emil Goode <emilgoode@gmail.com> Reviewed-by:
Jonas Gorski <jogo@openwrt.org> Acked-by:
Maciej W. Rozycki <macro@linux-mips.org> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: John Crispin <blogic@openwrt.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: kernel-janitors@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7264/Signed-off-by:
-
Paul Burton authored
The dma_cache_wback_inv function performs exactly as is required here, unless the system has coherent I/O in which case it's a no-op. Call the underlying cache writeback functions directly, which is arguably clearer anyway given that the code doesn't actually have anything to do with DMA in a strict sense. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7282/Signed-off-by:
-
Paul Burton authored
When determining the VPE ID of a CPU, make use of the cpu_vpe_id macro which will return 0 in a non-MT kernel build. Most code is already doing so but a couple of places weren't. Fixing this prevents a build failure for non-MT kernels where struct cpuinfo_mips does not contain the vpe_id field: arch/mips/kernel/pm-cps.c: In function 'cps_pm_enter_state': arch/mips/kernel/pm-cps.c:153:51: error: 'struct cpuinfo_mips' has no member named 'vpe_id' vpe_cfg = &core_cfg->vpe_config[current_cpu_data.vpe_id]; arch/mips/kernel/smp-cps.c: In function 'wait_for_sibling_halt': arch/mips/kernel/smp-cps.c:363:33: error: 'struct cpuinfo_mips' has no member named 'vpe_id' unsigned vpe_id = cpu_data[cpu].vpe_id; Signed-off-by: -
Paul Burton authored
When used in a non-MT kernel, the cpu_vpe_id macro never made use of its cpuinfo argument. It doesn't actually need to since it is returning a constant 0. However not using the argument can lead to build failures if the compiler then notices that a variable used as part of the argument is unused. Prevent that problem by "using" the argument as far as the compiler is concerned, whilst still returning 0 as before. Signed-off-by:
-
Paul Burton authored
The pm-cps code can run without a CPC, although will be limited to using only the 2 wait idle states. However the code does check for CPC presence, and in order to work optimally the CPC support is needed. So select it. Signed-off-by:
-
Paul Burton authored
These symbols will not be defined when CONFIG_MIPS_CPS=n, but although the CPS_PM_POWER_GATED state will never be used in that case the compiler doesn't have enough information to figure that out. Add checks which evaluate to a constant false for CONFIG_MIPS_CPS=n cases in order to help the compiler out & eliminate the symbol references. Signed-off-by:
-
Hauke Mehrtens authored
This patch adds detection for the Microsoft MN-700 and the Asus WL500G router. This is based on some old code from OpenWrt. Signed-off-by:
-
Hauke Mehrtens authored
The address prefix 00:90:4C is used by Broadcom in their initial configuration. When a mac address with the prefix 00:90:4C is used all devices from the same series are sharing the same mac address. To prevent mac address collisions we replace them with a mac address based on the base address. To generate such addresses we take the main mac address from et0macaddr and increase it by two for the first wifi device and by 3 for the second one. This matches the printed mac address on the device. The main mac address increased by one is used as wan address by the vendor code. Signed-off-by:
-
Hauke Mehrtens authored
The reboot on the BCM47XX SoCs is done, by setting the watchdog counter to 1 and let it trigger a reboot, when it reaches 0. Some devices with a BCM4705/BCM4785 SoC do not reboot when the counter is set to 1 and decreased to 0 by the hardware. It looks like it works more reliable when we set it to 3. As far as I understand the hardware, this should not make any difference, but I do not have access to any documentation for this SoC. It is still not 100% reliable. Signed-off-by:
-
Atsushi Nemoto authored
Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7216/Signed-off-by:
-
Atsushi Nemoto authored
This pci fixup routine calls __init functions. In general pci fixup routine must not call __init functions, but this pci/isa bridge device is not hotpluggable anyway. Signed-off-by:
-
Atsushi Nemoto authored
Fix wrong code spotted by -Werror=array-bounds: arch/mips/txx9/generic/pci.c:334:23: error: array subscript is above array bounds [-Werror=array-bounds] pci_write_config_byte(dev, regs[i], dat); Signed-off-by:
-
Maciej W. Rozycki authored
This fixes a regression caused by commit bb6c0bd3 [MIPS: SB1: Fix excessive kernel warnings.], that makes `-march=r5000' selected for compilation flags rather than supposed `-march=sb1' with compilers that do not support the ASE selection flags introduced with that change. For example GCC 4.1.2 supports `-mips3d'/`-mno-mips3d' (and obviously `-march=sb1'), however it does not support `-mdmx'/`-mno-mdmx'. As a result the whole selection of flags fails and compilation resorts to using `-march=r5000', meant for really old compilers indeed only. It is always best to pick the flags individually unless we are absolutely sure a set of flags was introduced to the toolchain together (`-march=sb1' and `-mtune=sb1' would be a good example), and this change makes it happen for CONFIG_CPU_SB1. Consequently the flags ultimately selected with GCC 4.1.2 are `-march=sb1 -Wa,--trap -mno-mips3d' Signed-off-by:
-
Maciej W. Rozycki authored
This fixes: {standard input}: Assembler messages: {standard input}:145: Error: opcode not supported on this processor: vr5000 (mips4) `clz $2,$2' {standard input}:920: Error: opcode not supported on this processor: vr5000 (mips4) `clz $7,$9' {standard input}:1797: Error: opcode not supported on this processor: vr5000 (mips4) `clz $7,$7' {standard input}:1851: Error: opcode not supported on this processor: vr5000 (mips4) `clz $7,$7' {standard input}:2831: Error: opcode not supported on this processor: vr5000 (mips4) `clz $7,$7' {standard input}:4209: Error: opcode not supported on this processor: vr5000 (mips4) `clz $7,$7' {standard input}:4329: Error: opcode not supported on this processor: vr5000 (mips4) `clz $2,$2' make[2]: *** [arch/mips/mm/tlbex.o] Error 1 which triggered due to a regression causing the file to be built with `-march=r5000' rather than `-march=sb1', fixed separately. Nevertheless the error should not happen, the other uses of CLZ are appropriately guarded. This change copies the arrangement from one of those other places. Signed-off-by:
-
