summaryrefslogtreecommitdiff
path: root/arch/parisc/kernel/hpmc.S
AgeCommit message (Collapse)Author
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 150Thomas Gleixner
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 42 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190524100845.259718220@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-17parisc: Fix exported address of os_hpmc handlerHelge Deller
In the C-code we need to put the physical address of the hpmc handler in the interrupt vector table (IVA) in order to get HPMCs working. Since on parisc64 function pointers are indirect (in fact they are function descriptors) we instead export the address as variable and not as function. This reverts a small part of commit f39cce654f9a ("parisc: Add cfi_startproc and cfi_endproc to assembly code"). Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> [4.9+]
2018-03-27parisc: Fix HPMC handler by increasing size to multiple of 16 bytesHelge Deller
Make sure that the HPMC (High Priority Machine Check) handler is 16-byte aligned and that it's length in the IVT is a multiple of 16 bytes. Otherwise PDC may decide not to call the HPMC crash handler. Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org
2017-12-17parisc: Align os_hpmc_size on word boundaryHelge Deller
The os_hpmc_size variable sometimes wasn't aligned at word boundary and thus triggered the unaligned fault handler at startup. Fix it by aligning it properly. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v4.14+
2017-06-09parisc: Don't hardcode PSW values in hpmc codeHelge Deller
Signed-off-by: Helge Deller <deller@gmx.de>
2016-10-05parisc: Add cfi_startproc and cfi_endproc to assembly codeHelge Deller
Add ENTRY_CFI() and ENDPROC_CFI() macros for dwarf debug info and convert assembly users to new macros. Signed-off-by: Helge Deller <deller@gmx.de>
2016-10-05parisc: Move hpmc stack into page aligned bss sectionHelge Deller
Do not reserve space in data section for hpmc stack, instead move it into the page aligned bss section. Signed-off-by: Helge Deller <deller@gmx.de>
2013-05-06parisc: fix partly 16/64k PAGE_SIZE bootHelge Deller
This patch fixes partly PAGE_SIZEs of 16K or 64K by adjusting the assembler PTE lookup code and the assembler TEMPALIAS code. Furthermore some data alignments for PAGE_SIZE have been limited to 4K (or less) to not waste too much memory with greater page sizes. As a side note, the palo loader can (currently) only handle up to 10 ELF segments which is fixed with tighter aligning as well. My testings indicated that the ldci command in the sba iommu coding needed adjustment by the PAGE_SHIFT value and that the I/O PDIR Page size was only set to 4K for my machine (C3000). All this fixes partly the boot, but there are still quite some caching problems left. Examples are e.g. the symbios logic driver which is failing: sym0: <896> rev 0x7 at pci 0000:00:0f.0 irq 69 sym0: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking CACHE TEST FAILED: DMA error (dstat=0x81).sym0: CACHE INCORRECTLY CONFIGURED. and the tulip network driver which doesn't seem to work correctly either: Sending BOOTP requests .net eth0: Setting full-duplex based on MII#1 link partner capability of 05e1 ..... timed out! Beside those kernel fixes glibc will need fixes too to be able to handle >4K page sizes. Signed-off-by: Helge Deller <deller@gmx.de>
2009-01-05parisc: export length of os_hpmc vectorKyle McMartin
and use this instead of dealing with exporting start/end and toying with function descriptors. Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-06-13Revert "parisc: fix trivial section name warnings"Kyle McMartin
This reverts commit bd3bb8c15b9a80dbddfb7905b237a4a11a4725b4. Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2008-05-15parisc: fix trivial section name warningsHelge Deller
This trivial patch fixes the following section warnings on PARISC: > WARNING: vmlinux.o (.text.1): unexpected section name. >The (.[number]+) following section name are ld generated and not expected. > Did you forget to use "ax"/"aw" in a .S file? > Note that for example <linux/init.h> contains > section definitions for use in .S files. Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2007-10-18[PARISC] Remove hardcoded uses of PAGE_SIZEKyle McMartin
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2007-06-04[PARISC] Fix kernel panic in check_ivtKyle McMartin
check_ivt had some seriously broken code wrt function pointers on parisc64. Instead of referencing the hpmc code via a function pointer, export symbols and reference it as a const array. Thanks to jda for pointing out the broken 64-bit func ptr handling. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2007-02-17[PARISC] more ENTRY(), ENDPROC(), END() conversionsHelge Deller
Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!