commit 1c3c909303 broke PAE40. Macro pfn_pte(pfn, prot) creates paddr
from pfn, but the page shift was getting truncated to 32 bits since we lost
the proper cast to 64 bits (for PAE400
Instead of reverting that commit, use a better helper which is 32/64 bits
safe just like ARM implementation.
Fixes: 1c3c909303 ("ARC: mm: fix build breakage with STRICT_MM_TYPECHECKS")
Cc: <stable@vger.kernel.org> #4.4+
Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
[vgupta: massaged changelog]
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Apparenty this is coming in the way of gcc fix which inhibits the usage
of LP_COUNT as a gpr.
Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
- mmap handler for dma ops as generic handler no longer works for us [Alexey]
- Fixes for EZChip platform [Noam]
- Fix RTC clocksource driver build issue
- ARC IRQ handling fixes [Yuriy]
- Revert a recent makefile change which doesn't go well with oldish tools out in the wild
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJYJhV1AAoJEGnX8d3iisJeZZgP/2/nJVi4LTpXYqhpt04yNvCD
Fxwt8KypWfpbd8KDiK+C0OJiFmCa2XAZwAamRBkgtgKreq9/Vq4MYEiQXcYlQkQb
dCmU6T+RmSb15/7N3ZD1xhXB34ktGz1ffjcp8si0LIOkOj5cHQ3Ex4MH/SVQWuRh
VypLOfTJlLS0DoEvo/S4Vk2fBH65dLAWoeBl63J6yAcEdflzkoTmH9QWVzGlHGmi
mZ66/OeD4Rh7GDnrv5BQYLZJwUGQjoV3n4MhchrZ5uVt6UWs56ypi+ZVML/qYS5m
YuCOY7O9ZJ94/XY/pMa7CqEPgNm4ZHN/7DQ32F9X5BemQxZY8/JvUjPsuP42iXol
DfhtA55mNRk6yP0Ku5L2xg64mazyy9HqZnSh2pYpUMePSkcX/AXMrlOWSzFh250s
qkXEpwQgccl4HMA6xarjeQxFZL34lh1N40p3s6PXT6UJwfWOgD2w8Z4qW1jdp7G2
VkblWUN5AVT2YcyBcKgMGG09sLgIXhV40NVO4fvOo4p6qBSYk/yL3YRBKppOt+aQ
EVf6yaUKlpac6D9Ozy1pG5yfcx6wwaT0Iregjsld35WJ8Lvg9tLo0oLJrU0tlyCY
tX6zbgcXXU2y0TPKN1jJQ2u14Pfscfd5DLo1M64COKAGIaPrWYUBxJ0sBhqolq66
gKJwyOWse63H4ZxkEFCP
=hbBv
-----END PGP SIGNATURE-----
Merge tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
Pull ARC fixes from Vineet Gupta:
- mmap handler for dma ops as generic handler no longer works for us
[Alexey]
- Fixes for EZChip platform [Noam]
- Fix RTC clocksource driver build issue
- ARC IRQ handling fixes [Yuriy]
- Revert a recent makefile change which doesn't go well with oldish
tools out in the wild
* tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core
ARC: IRQ: Do not use hwirq as virq and vice versa
ARC: [plat-eznps] set default baud for early console
ARC: [plat-eznps] remove IPI clear from SMP operations
Revert "ARC: build: retire old toggles"
ARC: timer: rtc: implement read loop in "C" vs. inline asm
ARC: change return value of userspace cmpxchg assist syscall
arc: Implement arch-specific dma_map_ops.mmap
ARC: [SMP] avoid overriding present cpumask
ARC: Enable PERF_EVENTS in nSIM driven platforms
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].
Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.
With commit 877417e6ff ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.
However, commit 6e8d666e92 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then. This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle. Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.
I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.
This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives. A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.
Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ARC linux uses 2 distribution modes for common interrupts: round robin
mode (IDU_M_DISTRI_RR) and a simple destination mode (IDU_M_DISTRI_DEST).
The first one is used when more than 1 cores may handle a common interrupt
and the second one is used when only 1 core may handle a common interrupt.
However idu_irq_set_affinity() always sets IDU_M_DISTRI_RR for all affinity
values. But there is no sense in setting of such mode if only 1 core must
handle a common interrupt.
Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
This came up when reviewing code to address missing IRQ affinity
setting in AXS103 platform and/or implementing hierarchical IRQ domains
- smp_ipi_irq_setup() callers pass hwirq but in turn calls
request_percpu_irq() which expects a linux virq. So invoke
irq_find_mapping() to do the conversion
(also explicitify this in code by renaming the args appropriately)
- idu_of_init()/idu_cascade_isr() were similarly using linux virq where
hwirq is expected, so do the conversion using irqd_to_hwirq() helper
Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
[vgupta: made changelog a bit concise a bit]
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
For CONFIG_SERIAL_EARLYCON we need 800MHz for NPS SoC
The early console driver uses BASE_BAUD and not using dtb.
The default of 50MHz is NOT good for NPS SoC.
Signed-off-by: Noam Camus <noamca@mellanox.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Today we register to plat_smp_ops.clear() method which actually
is acking the IPI.
However this is already taking care by our irqchip driver specifically
by the irq_chip.irq_eoi() method.
This is perfect timing where it should be done and no special handling
is needed at plat_smp_ops.clear().
Signed-off-by: Noam Camus <noamca@mellanox.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
This has caused a bunch of build failures at a few sites, with GNU
2015.12 and older as the assembler seems to need -mlock to be able to
grok llock/scond instructions for ARC700 builds.
different places since the
older tools still seem to release
of tools which most people are using seem to trip with the -mlock flag
not being passed.
This reverts commit c300547588.
The current code doesn't even compile as somehow the inline assembly
can't see the register names defined as ARC_RTC_*
I'm pretty sure It worked when I first got it merged, but the tools were
definitely different then.
So better to write this in "C" anyways.
CC: stable@vger.kernel.org #4.2+
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The original syscall only used to return errno to indicate if cmpxchg
succeeded. It was not returning the "previous" value which typical cmpxchg
callers are interested in to build their slowpaths or retry loops.
Given user preemption in syscall return path etc, it is not wise to
check this in userspace afterwards, but should be what kernel actually
observed in the syscall.
So change the syscall interface to always return the previous value and
additionally set Z flag to indicate whether operation succeeded or not
(just like ARM implementation when they used to have this syscall)
The flag approach avoids having to put_user errno which is nice given
the use case for this syscall cares mostly about the "previous" value.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
We used to use generic implementation of dma_map_ops.mmap which is
dma_common_mmap() but that only worked for simpler cached mappings when
vaddr = paddr.
If a driver requests uncached DMA buffer kernel maps it to virtual
address so that MMU gets involved and page uncached status takes into
account. In that case usage of dma_common_mmap() lead to mapping of
vaddr to vaddr for user-space which is obviously wrong. For more detals
please refer to verbose explanation here [1].
So here we implement our own version of mmap() which always deals
with dma_addr and maps underlying memory to user-space properly
(note that DMA buffer mapped to user-space is always uncached
because there's no way to properly manage cache from user-space).
[1] https://lkml.org/lkml/2016/10/26/973
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: <stable@vger.kernel.org> #4.5+
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
At smp_prepare_cpus() we set present cpu mask as part of init
for all CPUs at range [0-max_cpus].
This is done without checking if this mask is already being set.
At platform of eznps this mask is already being initialized at
smp_init_cpus() by using hook plat_smp_ops.init_early_smp().
So to avoid overriding of present cpu mask we check the number of
bits which are set in this mask. At the begin only bit for boot CPU
is set so if number of bits already set is no more than one we can be
assure that there is no overriding of this mask.
Signed-off-by: Noam Camus <noamca@mellanox.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Now when we have properly working performance counters in nSIM
even with interrupt support (fix should be a part of upcoming
nSIM engineering build 2016.12-005) we may enable perf support
by default for all platforms that use nSIM for ARC cores simulation.
Note 1: PCT node was missing for some reason in nsimosci.dts
while all other nSIM-related .dts files already had
PCT node for quite some time, so adding it now.
Note 2: All defconfigs were regenerated with "make savedefconfig"
which led to some clean-ups in nsimosci_hs_smp_defconfig:
CONFIG_FRAMEBUFFER_CONSOLE=y was removed because it is
automatically selected now by DRM.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Now that we have referece to section name string table in
apply_relocate_add(), use it to
- print the name of section being relocated
- print symbol with NULL name (since it refers to a section)
before
| Section to fixup 7000a060
| =========================================================
| rela->r_off | rela->addend | sym->st_value | ADDR | VALUE
| =========================================================
| 1c 0 7000e000 7000a07c 7000e000 []
| 40 0 7000a000 7000a0a0 7000a000 []
after
| Section to fixup .eh_frame @7000a060
| =========================================================
| r_off r_add st_value ADDRESS VALUE
| =========================================================
| 1c 0 7000e000 7000a07c 7000e000 [.init.text]
| 40 0 7000a000 7000a0a0 7000a000 [.exit.text]
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The loop was really needed in .debug_frame regime where wanted make it
as SH_ALLOC so that apply_relocate_add() would process it. That's not
needed for .eh_frame, so we check this in apply_relocate_add() which
gets called for each section.
Note that we need to save reference to "section name strings" section in
module_frob_arch_sections() since apply_relocate_add() doesn't get that
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
These are really ancient toggles and tools no longer require them to be
passed. This paves way for deprecating them in long run.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The motivation is to identify ARC750 vs. ARC770 (we currently print
generic "ARC700").
A given ARC700 release could be 750 or 770, with same ARCNUM (or family
identifier which is unfortunate). The existing arc_cpu_tbl[] kept a single
concatenated string for core name and release which thus doesn't work
for 750 vs. 770 identification.
So split this into 2 tables, one with core names and other with release.
And while we are at it, get rid of the range checking for family numbers.
We just document the known to exist cores running Linux and ditch
others.
With this in place, we add detection of ARC750 which is
- cores 0x33 and before
- cores 0x34 and later with MMUv2
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
This came to light when helping a customer with oldish ARC750 core who
were getting instruction errors because of lack of SWAPE but boot log
was incorrectly printing it as being present
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
On older arc700 cores, some of the features configured were not present
in Build config registers. To print about them at boot, we just use the
Kconfig option i.e. whether linux is built to use them or not.
So yes this seems bogus, but what else can be done. Moreover if linux is
booting with these enabled, then the Kconfig info is a good indicator
anyways.
Over time these "hacks" accumulated in read_arc_build_cfg_regs() as well
as arc_cpu_mumbojumbo(). so refactor and move all of those in a single
place: read_arc_build_cfg_regs(). This causes some code redcution too:
| bloat-o-meter2 arch/arc/kernel/setup.o.0 arch/arc/kernel/setup.o.1
| add/remove: 0/0 grow/shrink: 2/1 up/down: 64/-132 (-68)
| function old new delta
| setup_processor 610 670 +60
| cpuinfo_arc700 76 80 +4
| arc_cpu_mumbojumbo 752 620 -132
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Previously we would not print the case when IOC existed but was not
enabled.
And while at it, reduce one line off boot printing by consolidating
the Peripheral address space and IO-Coherency which in a way
applies to them
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
if user disables IOC from debugger at startup (by clearing @ioc_enable),
@ioc_exists is cleared too. This means boot prints don't capture the
fact that IOC was present but disabled which could be misleading.
So invert how we use @ioc_enable and @ioc_exists and make it more
canonical. @ioc_exists represent whether hardware is present or not and
stays same whether enabled or not. @ioc_enable is still user driven,
but will be auto-disabled if IOC hardware is not present, i.e. if
@ioc_exist=0. This is opposite to what we were doing before, but much
clearer.
This means @ioc_enable is now the "exported" toggle in rest of code such
as dma mapping API.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Older ARC700 cores (ARC750 specifically) lack instructions to implement
atomic r-w-w. This is problematic for userspace libraries such as NPTL
which need atomic primitives. So enable them by providing kernel assist.
This is costly but really the only sane soluton (othern than tight
spinning using the otherwise availiable atomic exchange EX instruciton).
Good thing is there are only a few of these cores running Linux out in
the wild.
This only works on UP systems.
Reviewed-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The cast valid since TASK_SIZE * 2 will never actually cause overflow.
| CC fs/binfmt_elf.o
| In file included from ../include/linux/elf.h:4:0,
| from ../include/linux/module.h:15,
| from ../fs/binfmt_elf.c:12:
| ../fs/binfmt_elf.c: In function load_elf_binar:
| ../arch/arc/include/asm/elf.h:57:29: warning: integer overflow in expression [-Woverflow]
| #define ELF_ET_DYN_BASE (2 * TASK_SIZE / 3)
| ^
| ../fs/binfmt_elf.c:921:16: note: in expansion of macro ELF_ET_DYN_BASE
| load_bias = ELF_ET_DYN_BASE - vaddr;
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
num_possible_cpus() returns how many CPUs may be present on system.
However we want the highest possible CPU number.
This may be differ in a sparsed possible CPUs map.
Such map achived by OF for plat-eznps.
For example if we have:
possible cpus mask 0,3
Then:
num_possible_cpus() is equal 2
while
nr_cpu_ids is equal 4.
Only for value 4 c_start() will provide correct cpuinfo at procfs.
Signed-off-by: Noam Camus <noamc@ezchip.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Add support for lzma compressed uImage.
Support for gzip was already available but could not be enabled because
we were missing CONFIG_HAVE_KERNEL_GZIP in arch/arc/Kconfig.
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The IDU intc is technically part of MCIP (Multi-core IP) hence
historically was only available in a SMP hardware build (and thus only
in a SMP kernel build). Now that hardware restriction has been lifted,
so a UP kernel needs to support it.
This requires breaking mcip.c into parts which are strictly SMP
(inter-core interrupts) and IDU which in reality is just another
intc and thus has no bearing on SMP.
This change allows IDU in UP builds and with a suitable device tree, we
can have the cascaded intc system
ARCv2 core intc <---> ARCv2 IDU intc <---> periperals
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
When doing an nmi backtrace of many cores, most of which are idle, the
output is a little overwhelming and very uninformative. Suppress
messages for cpus that are idling when they are interrupted and just
emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN".
We do this by grouping all the cpuidle code together into a new
.cpuidle.text section, and then checking the address of the interrupted
PC to see if it lies within that section.
This commit suitably tags x86 and tile idle routines, and only adds in
the minimal framework for other architectures.
Link: http://lkml.kernel.org/r/1472487169-14923-5-git-send-email-cmetcalf@mellanox.com
Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm]
Tested-by: Petr Mladek <pmladek@suse.com>
Cc: Aaron Tomlin <atomlin@redhat.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit d9676fa152 ("ARCv2: Enable LOCKDEP"), changed
local_save_flags() to not return raw STATUS32 but encoded in the form
such that it could be fed directly to CLRI/SETI instructions.
However the STATUS32.E[] was not captured correctly as it corresponds to
bits [4:1] in the register and not [3:0]
Fixes: d9676fa152 ("ARCv2: Enable LOCKDEP")
Cc: Evgeny Voevodin <evgeny.voevodin@intel.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Seem like values assigned as absolute number and not and
shift value, i.e. should be 0 for one node (2^0) and 1 for
couple of nodes (2^1)
Signed-off-by: Noam Camus <noamca@mellanox.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
In the end of "arc_init_IRQ" STATUS32.IE flag is going to be affected by
"flag" instruction but "flag" never touches IE flag on ARCv2. So "kflag"
instruction must be used instead of "flag".
Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
Cc: stable@vger.kernel.org #4.2+
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
We used to keep the .exit.* sections as linker would fail in final link
due to references from .debug_frame which itself could not be discardrd
due to the forced "write,alloc" attributes for it.
| LD init/built-in.o
| `.exit.text' referenced in section `.debug_frame' of arch/arc/built-in.o: defined in discarded section `.exit.text' of arch/arc/built-in.o
| Makefile:949: recipe for target 'vmlinux' failed
With .debug_frame now retired, this hack is no longer needed.
kernel binary is now a little bit smaller as well.
closes STAR 9000549913
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
This uses a new set of annoations viz. ENTRY_CFI/END_CFI to enabel cfi
ops generation.
Note that we didn't change the normal ENTRY/EXIT as we don't actually
want unwind info in the trap/exception/interrutp handlers which use
these, as unwinder then gets confused (it keeps recursing vs. stopping).
Semantically these are leaf routines and unwinding should stop when it
hits those routines.
Before
------
28.52% 1.19% 9929 hackbench libuClibc-1.0.17.so [.] __write_nocancel
|
---__write_nocancel
|--8.95%--EV_Trap
| --8.25%--sys_write
| |--3.93%--sock_write_iter
...
|--2.62%--memset <==== [LEAF entry as no unwind info]
^^^^^^
After
-----
29.46% 1.24% 13622 hackbench libuClibc-1.0.17.so [.] __write_nocancel
|
---__write_nocancel
|--9.31%--EV_Trap
| --8.62%--sys_write
| |--4.17%--sock_write_iter
...
|--6.19%--sys_write
| --6.19%--sock_write_iter
| unix_stream_sendmsg
| |--1.62%--sock_alloc_send_pskb
| |--0.89%--sock_def_readable
| |--0.88%--_raw_spin_unlock_irqrestore
| |--0.69%--memset
| | ^^^^^^ <==== [now in proper callframe]
| |
| --0.52%--skb_copy_datagram_from_iter
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
1. detect whether binutils supports the cfi pseudo ops
2. define conditional macros to generate the ops
3. define new ENTRY_CFI/END_CFI to annotate hand asm code.
- Needed because we don't want to emit dwarf info in general ENTRY/END
used by lowest level trap/exception/interrutp handlers as unwinder
gets confused trying to unwind out of them. We want unwinder to
instead stop when it hits onfo those routines
- These provide minimal start/end cfi ops assuming routine doesn't
touch stack memory/regs
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
This essentially removes ENTRY() assembler annotation for this symbol
since it didn't have a pairing END()
This in ahead of introducing cfi pseudo ops in ENTRY/END which expects
paired cfi_startproc/cfi_endproc
| ../arch/arc/kernel/entry.S: Assembler messages:
| ../arch/arc/kernel/entry.S:270: Error: previous CFI entry not closed (missing .cfi_endproc)
| ../scripts/Makefile.build:326: recipe for target 'arch/arc/kernel/entry-arcv2.o' failed
| make[4]: *** [arch/arc/kernel/entry-arcv2.o] Error 1
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
In .debug_frame based unwinding regime, we used to force -gdwarf-2 since
kernel unwinder only claimed to handle dwarf 2. This changed since commit
6d0d506012 ("ARC: dw2 unwind: Don't bail for CIE.version != 1")
which added some support beyond dwarf 2, atleast to handle CIE != 1
The ill-effect of -gdwarf-2 is that it forces generation of .debug_*
sections, which bloats loadable modules .ko files. For the curious, this
doesn't affect vmlinx binary since linker script discards .debug_* but
same discard is not yet implemented for modules.
So it seems we can drop the -gdwarf-2 toggle, which should not be needed
anyways given that we now use .eh_frame based unwinding.
I've verified using GNU 2016.09-engo10 that the actual unwind info is
not different with or w/o this toggle - but the debug_* sections are
gone for good.
before
-----
arc-linux-readelf -S q_proc.ko-unwinding-1-eh_frame-switch | grep debug
[15] .debug_info PROGBITS 00000000 000300 00d08d 00 0 0 1
[16] .rela.debug_info RELA 00000000 0162a0 008844 0c I 29 15 4
[17] .debug_abbrev PROGBITS 00000000 00d38d 0005f8 00 0 0 1
[18] .debug_loc PROGBITS 00000000 00d985 000070 00 0 0 1
[19] .rela.debug_loc RELA 00000000 01eae4 0000c0 0c I 29 18 4
[20] .debug_aranges PROGBITS 00000000 00d9f5 000040 00 0 0 1
[21] .rela.debug_arang RELA 00000000 01eba4 000030 0c I 29 20 4
[22] .debug_ranges PROGBITS 00000000 00da35 000018 00 0 0 1
[23] .rela.debug_range RELA 00000000 01ebd4 000030 0c I 29 22 4
[24] .debug_line PROGBITS 00000000 00da4d 000b5b 00 0 0 1
[25] .rela.debug_line RELA 00000000 01ec04 0000cc 0c I 29 24 4
[26] .debug_str PROGBITS 00000000 00e5a8 007831 01 MS 0 0 1
after
----
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
So finally after almost 8 years of dealing with .debug_frame, we are
finally switching to .eh_frame. The reason being stripped kernel
binaries had non-functional unwinder as .debug_frame was gone.
Also, in general .eh_frame seems more common way of doing unwinding.
This also folds a revert of f52e126cc7 ("ARC: unwind: ensure that
.debug_frame is generated (vs. .eh_frame)") to ensure that we start
getting .eh_frame
Reported-by: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
We used to live with PERF_COUNT_HW_CACHE_REFERENCES and
PERF_COUNT_HW_CACHE_REFERENCES not specified on ARC.
Those events are actually aliases to 2 cache events that we do support
and so this change sets "cache-reference" and "cache-misses" events
in the same way as "L1-dcache-loads" and L1-dcache-load-misses.
And while at it adding debug info for cache events as well as doing a
subtle fix in HW events debug info - config value is much better
represented by hex so we may see not only event index but as well other
control bits set (if they exist).
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Build brekeage since last changes to generic atomic operations.
Added couple of missing macros which are now mandatory
Signed-off-by: Noam Camus <noamca@mellanox.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARCv2 ISA provides 64-bit exclusive load/stores so use them to implement
the 64-bit atomics and elide the spinlock based generic 64-bit atomics
boot tested with atomic64 self-test (and GOD bless the person who wrote
them, I realized my inline assmebly is sloppy as hell)
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
HS release 3.0 provides for even more flexibility in specifying the
volatile address space for mapping peripherals.
With HS 2.1 @start was made flexible / programmable - with HS 3.0 even
@end can be setup (vs. fixed to 0xFFFF_FFFF before).
So add code to reflect that and while at it remove an unused struct
defintion
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Yuriy Kolerov