Allow usage of scratch register for current pgd even when
MIPS_PGD_C0_CONTEXT is not configured. MIPS_PGD_C0_CONTEXT is set
for 64r2 platforms to indicate availability of Xcontext for saving
cpuid, thus freeing Context to be used for saving PGD. This option
was also tied to using a scratch register for storing PGD.
This commit will allow usage of scratch register to store the current
pgd if one can be allocated for the platform, even when
MIPS_PGD_C0_CONTEXT is not set. The cpuid will be kept in the CP0
Context register in this case.
The code to store the current pgd for the TLB miss handler is now
generated in all cases. When scratch register is available, the PGD
is also stored in the scratch register.
Signed-off-by: Jayachandran C <jchandra@broadcom.com>
Cc: linux-mips@linux-mips.org
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Patchwork: https://patchwork.linux-mips.org/patch/5906/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
There is no reliable way to tell R4000/R4400 SC and MC variations apart,
however simple heuristic should give good results. Only the MC version
supports coherent caching so we can rely on such a mode having been set
for KSEG0 by the power-on firmware to reliably indicate an MC processor.
SC processors reportedly hang on coherent cached memory accesses and Linux
is linked to a cached load address so the firmware has to use the correct
caching mode to download the kernel image in a cached mode successfully.
OTOH if the firmware chooses to use either the non-coherent cached or the
uncached mode for KSEG0 on an MC processor, then the SC variant will be
reported, just as we currently do, so no regression here.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Jonas Gorski <jogo@openwrt.org>
Cc: MIPS Mailing List <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/5882/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This change complements commits d0da7c002f7b2a93582187a9e3f73891a01d8ee4
[MIPS: DEC: Convert to new irq_chip functions] and
5359b938c0 [MIPS: DECstation I/O ASIC DMA
interrupt handling fix] and implements automatic handling of the two
classes of DMA interrupts the I/O ASIC implements, informational and
errors.
Informational DMA interrupts do not stop the transfer and use the
`handle_edge_irq' handler that clears the request right away so that
another request may be recorded while the previous is being handled.
DMA error interrupts stop the transfer and require a corrective action
before DMA can be reenabled. Therefore they use the `handle_fasteoi_irq'
handler that only clears the request on the way out. Because MIPS
processor interrupt inputs, one of which the I/O ASIC's interrupt
controller is cascaded to, are level-triggered it is recommended that
error DMA interrupt action handlers are registered with the IRQF_ONESHOT
flag set so that they are run with the interrupt line masked.
This change removes the export of clear_ioasic_dma_irq that now does not
have to be called by device drivers to clear interrupts explicitly
anymore. Originally these interrupts were cleared in the .end handler of
the `irq_chip' structure, before it was removed.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5874/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
There is currently no corresponding ELF program header for the "text"
loadable segment which is confusing for some bootloader out there such
as CFE because it expects to find a program header matching the segment
it is trying to load. The Linux kernel ELF binary "vmlinux" has a
similar program header for the text segment so we just mimic this here
too.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Cc: james.hogan@imgtec.com
Patchwork: https://patchwork.linux-mips.org/patch/5827/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When CONFIG_SYS_SUPPORTS_ZBOOT is not enabled, we will still try to
build the decompressor code in arch/mips/boot/compressed as a
dependency for producing the vmlinuz target and this will result in
the following build failure:
OBJCOPY arch/mips/boot/compressed/vmlinux.bin
arch/mips/boot/compressed/decompress.c: In function 'decompress_kernel':
arch/mips/boot/compressed/decompress.c:105:2: error: implicit
declaration of function 'decompress'
make[1]: *** [arch/mips/boot/compressed/decompress.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [vmlinuz] Error 2
This is a genuine build failure because we have no implementation for
the decompress() function body since no kernel compression method
defined in CONFIG_KERNEL_(GZIP,BZIP2...) has been enabled.
arch/mips/Makefile already guards the install target for the "vmlinuz"
binary with a proper ifdef CONFIG_SYS_SUPPORTS_ZBOOT, we now also do the
same if we attempt to do a "make vmlinuz" and show that
CONFIG_SYS_SUPPORTS_ZBOOT is not enabled.
[ralf@linux-mips.org: Cleanup the makefile rule as suggested by James
Hogan.]
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Cc: richard@nod.at
Patchwork: https://patchwork.linux-mips.org/patch/5817/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Currently when using an initrd on a MIPS system the start of the bootmem
region of memory is set to the larger of the end of the kernel bss region
(_end) or the end of the initrd. In a typical memory layout where the
initrd is at some address above the kernel image this means that the start
of the bootmem region will be the end of the initrd. But when we are done
processing/loading the initrd we have no way to reclaim the memory region
it occupied, and we lose a large chunk of now otherwise empty RAM from our
final running system.
The bootmem code is designed to allow this initrd to be reserved (and the
code in finalize_initrd() currently does this). When the initrd is finally
processed/loaded its reserved memory is freed.
Fix the setting of the start of the bootmem map to be the end of the kernel.
[ralf@linux-mips.org: fold in the fix of Ashok Kumar <ashoks@broadcom.com>.]
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1574/
Cc: Ashok Kumar <ashoks@broadcom.com>
Patchwork: https://patchwork.linux-mips.org/patch/5883/
Patchwork: https://patchwork.linux-mips.org/patch/6028/
Patchwork: https://patchwork.linux-mips.org/patch/6064/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Panic() is going to add a \n itself and it's annoying if a panic message rolls
of the screen on a device with no scrollback.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Some BCM5354 SoCs are running at 200MHz, but it is not possible to read
the clock from a register like it is done on some other SoC in ssb and
bcma. These devices should have a clkfreq nvram configuration value set
to 200, read it and set the clock to the correct value.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5842/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The CMP code is only designed to work with SMP configurations.
Fixes multiple build problems on certain randconfigs:
In file included from arch/mips/kernel/smp-cmp.c:34:0:
arch/mips/include/asm/smp.h:28:0:
error: "raw_smp_processor_id" redefined [-Werror]
In file included from include/linux/sched.h:30:0,
from arch/mips/kernel/smp-cmp.c:22:
include/linux/smp.h:135:0: note: this is the location of the
previous definition
In file included from arch/mips/kernel/smp-cmp.c:34:0:
arch/mips/include/asm/smp.h:57:20:
error: redefinition of 'smp_send_reschedule'
In file included from include/linux/sched.h:30:0,
from arch/mips/kernel/smp-cmp.c:22:
include/linux/smp.h:179:20: note: previous
definition of 'smp_send_reschedule' was here
In file included from arch/mips/kernel/smp-cmp.c:34:0:
arch/mips/include/asm/smp.h: In function 'smp_send_reschedule':
arch/mips/include/asm/smp.h:61:8:
error: dereferencing pointer to incomplete type
[...]
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/5812/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
In commit 15ef17f622
(tty: ar933x_uart: use the clk API to get the uart
clock), the AR933x UART driver for has been converted
to get the uart clock rate via the clock API and it
does not use the platform data anymore.
Remove the ar933x_uart_platform.h header file and get
rid of the superfluous variable and initialization code
in platform setup.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5832/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
struct of_irq and struct of_phandle_args are exactly the same structure.
This patch makes the kernel use of_phandle_args everywhere. This in
itself isn't a big deal, but it makes some follow-on patches simpler.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Acked-by: Michal Simek <monstr@monstr.eu>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The OF irq handling code has been overloading the term 'map' to refer to
both parsing the data in the device tree and mapping it to the internal
linux irq system. This is probably because the device tree does have the
concept of an 'interrupt-map' function for translating interrupt
references from one node to another, but 'map' is still confusing when
the primary purpose of some of the functions are to parse the DT data.
This patch renames all the of_irq_map_* functions to of_irq_parse_*
which makes it clear that there is a difference between the parsing
phase and the mapping phase. Kernel code can make use of just the
parsing or just the mapping support as needed by the subsystem.
The patch was generated mechanically with a handful of sed commands.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Acked-by: Michal Simek <monstr@monstr.eu>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Conflicts:
drivers/net/usb/qmi_wwan.c
include/net/dst.h
Trivial merge conflicts, both were overlapping changes.
Signed-off-by: David S. Miller <davem@davemloft.net>
Correct common misspelling of "identify" as "indentify" throughout
the kernel
Signed-off-by: Maxime Jayat <maxime@artisandeveloppeur.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Now when the main kvm code relying on these defines has been moved to
the x86 specific part of the world, we can get rid of these.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Pull gcc "asm goto" miscompilation workaround from Ingo Molnar:
"This is the fix for the GCC miscompilation discussed in the following
lkml thread:
[x86] BUG: unable to handle kernel paging request at 00740060
The bug in GCC has been fixed by Jakub and the fix will be part of the
GCC 4.8.2 release expected to be released next week - so the quirk's
version test checks for <= 4.8.1.
The quirk is only added to compiler-gcc4.h and not to the higher level
compiler.h because all asm goto uses are behind a feature check"
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
compiler/gcc4: Add quirk for 'asm goto' miscompilation bug
Merge Linux v3.12-rc4 to fix a conflict and also to refresh the tree
before applying more scheduler patches.
Conflicts:
arch/avr32/include/asm/Kbuild
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Commit 1400eb6 (MIPS: r4k,octeon,r2300: stack protector: change canary
per task) was merged in v3.11 and introduced assembly in the MIPS resume
functions to update the value of the current canary in
__stack_chk_guard. However it used PTR_L resulting in a load of the
canary value, instead of PTR_LA to construct its address. The value is
intended to be random but is then treated as an address in the
subsequent LONG_S (store).
This was observed to cause a fault and panic:
CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
Oops[#1]:
...
$24 : 139fea20 1e1f7cb6
...
Call Trace:
[<8000cc0c>] resume+0xac/0x118
[<8034f2a4>] __schedule+0x5f8/0x78c
[<8034f4e0>] schedule_preempt_disabled+0x20/0x2c
[<80348eec>] rest_init+0x74/0x84
[<804dc990>] start_kernel+0x43c/0x454
Code: 3c18804b 8f184030 8cb901f8 <af190000> 00c0e021 8cb002f0 8cb102f4 8cb202f8 8cb302fc
This can also be forced by modifying
arch/mips/include/asm/stackprotector.h so that the default
__stack_chk_guard value is more likely to be a bad (or unaligned)
pointer.
Fix it to use PTR_LA instead, to load the address of the canary value,
which the LONG_S can then use to write into it.
Reported-by: bobjones (via #mipslinux on IRC)
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Gregory Fong <gregory.0xf0@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/6026/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
