Make sure that s390 appears to be a big endian machine by defining
this config option.

Without this s390 appears to be little endian as seen by e.g. the
recordmount script: "perl ./scripts/recordmcount.pl "s390" "little"
"64""
This has no practical impact within the script since the endian
variable is only evaluated for mips. However there are already a
couple of common code places which evaluate this config option. None
of them is relevant for s390 currently though.

To avoid any issues in the future (and fix the recordmcount oddity)
add the new config option.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

arch_spin_lock_wait_flags() checks if a spinlock is not held before
trying a compare and swap instruction. If the lock is unlocked it
tries the compare and swap instruction, however if a different cpu
grabbed the lock in the meantime the instruction will fail as
expected.

Subsequently the arch_spin_lock_wait_flags() incorrectly tries to
figure out if the cpu that holds the lock is running. However it is
using the wrong cpu number for this (-1) and then will also yield the
current cpu to the wrong cpu.

Fix this by adding a missing continue statement.

Fixes: 470ada6b ("s390/spinlock: refactor arch_spin_lock_wait[_flags]")
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

This reverts commit c4004b02.

Sadly, my hope that nobody would actually use the special kernel entries
in /proc/iomem were dashed by kexec.  Which reads /proc/iomem explicitly
to find the kernel base address.  Nasty.

Anyway, that means we can't do the sane and simple thing and just remove
the entries, and we'll instead have to mask them out based on permissions.
Reported-by: NZhengyu Zhang <zhezhang@redhat.com>
Reported-by: NDave Young <dyoung@redhat.com>
Reported-by: NFreeman Zhang <freeman.zhang1992@gmail.com>
Reported-by: NEmrah Demir <ed@abdsec.com>
Reported-by: NBaoquan He <bhe@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix the FTRACE function tracer for 32- and 64-bit kernel.
The former code was horribly broken.

Reimplement most coding in assembly and utilize optimizations, e.g. put
mcount() and ftrace_stub() into one L1 cacheline.
Signed-off-by: NHelge Deller <deller@gmx.de>

When we loop over all queued machine check error records to pass them
to the registered notifiers we use llist_for_each_entry(). But the loop
calls gen_pool_free() for the entry in the body of the loop - and then
the iterator looks at node->next after the free.

Use llist_for_each_entry_safe() instead.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Cc: Gong Chen <gong.chen@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/0205920@agluck-desk.sc.intel.com
Link: http://lkml.kernel.org/r/1459929916-12852-4-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>

The website handhelds.org has been down for a long time and is
likely never coming back online.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

My intention was to ioremap a 4-byte register.  Coincidentally enough,
sizeof(SZ_4) equals to SZ_4, but this code is weird anyway.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The ColdFire architecture specific gpio support code registers a sysfs
bus device named "gpio". This clashes with the new generic API device
added in commit 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs").

The old ColdFire sysfs gpio device was never used for anything specific,
and no links or other nodes were created under it. The new API sysfs gpio
device has all the same default sysfs links (device, drivers, etc) and
they are properly populated.

Remove the old ColdFire sysfs gpio registration.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

This ensures that the guest doesn't see XSAVE extensions
(e.g. xgetbv1 or xsavec) that the host lacks.

Cc: stable@vger.kernel.org
Reviewed-by: NRadim Krčmář <rkrcmar@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

An interrupt handler that uses the fpu can kill a KVM VM, if it runs
under the following conditions:
 - the guest's xcr0 register is loaded on the cpu
 - the guest's fpu context is not loaded
 - the host is using eagerfpu

Note that the guest's xcr0 register and fpu context are not loaded as
part of the atomic world switch into "guest mode". They are loaded by
KVM while the cpu is still in "host mode".

Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
interrupt handler will look something like this:

if (irq_fpu_usable()) {
        kernel_fpu_begin();

        [... code that uses the fpu ...]

        kernel_fpu_end();
}

As long as the guest's fpu is not loaded and the host is using eager
fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
returns true). The interrupt handler proceeds to use the fpu with
the guest's xcr0 live.

kernel_fpu_begin() saves the current fpu context. If this uses
XSAVE[OPT], it may leave the xsave area in an undesirable state.
According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
xcr0[i] == 0 following an XSAVE.

kernel_fpu_end() restores the fpu context. Now if any bit i in
XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
fault is trapped and SIGSEGV is delivered to the current process.

Only pre-4.2 kernels appear to be vulnerable to this sequence of
events. Commit 653f52c3 ("kvm,x86: load guest FPU context more eagerly")
from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.

This patch fixes the bug by keeping the host's xcr0 loaded outside
of the interrupts-disabled region where KVM switches into guest mode.

Cc: stable@vger.kernel.org
Suggested-by: NAndy Lutomirski <luto@amacapital.net>
Signed-off-by: NDavid Matlack <dmatlack@google.com>
[Move load after goto cancel_injection. - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

kvm-unit-tests complained about the PFEC is not set properly, e.g,:
test pte.rw pte.d pte.nx pde.p pde.rw pde.pse user fetch: FAIL: error code 15
expected 5
Dump mapping: address: 0x123400000000
------L4: 3e95007
------L3: 3e96007
------L2: 2000083

It's caused by the reason that PFEC returned to guest is copied from the
PFEC triggered by shadow page table

This patch fixes it and makes the logic of updating errcode more clean
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
[Do not assume pfec.p=1. - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Update the comment to reflect the changes of commit 0de79858 (parisc: Use
generic extable search and sort routines).
Signed-off-by: NHelge Deller <deller@gmx.de>

Handling exceptions from modules never worked on parisc.
It was just masked by the fact that exceptions from modules
don't happen during normal use.

When a module triggers an exception in get_user() we need to load the
main kernel dp value before accessing the exception_data structure, and
afterwards restore the original dp value of the module on exit.
Noticed-by: NMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org

The kernel module testcase (lib/test_user_copy.c) exhibited a kernel
crash on parisc if the parameters for copy_from_user were reversed
("illegal reversed copy_to_user" testcase).

Fix this potential crash by checking the fault handler if the faulting
address is in the exception table.
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>

We want to avoid the kernel module loader to create function pointers
for the kernel fixup routines of get_user() and put_user(). Changing
the external reference from function type to int type fixes this.

This unbreaks exception handling for get_user() and put_user() when
called from a kernel module.
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org

Commit 0de79858 (parisc: Use generic extable search and sort routines)
changed the exception tables to use 32bit relative offsets.

This patch now adds support to the kernel module loader to handle such
R_PARISC_PCREL32 relocations for 32- and 64-bit modules.
Signed-off-by: NHelge Deller <deller@gmx.de>

It was reported that a kernel with CONFIG_ARM_PATCH_IDIV=y stopped
booting when compiled with the upcoming gcc 6.  Turns out that turning
a function address into a writable array is undefined and gcc 6 decided
it was OK to omit the store to the first word of the function while
still preserving the store to the second word.

Even though gcc 6 is now fixed to behave more coherently, it is a
mystery that gcc 4 and gcc 5 actually produce wanted code in the kernel.
And in fact the reduced test case to illustrate the issue does indeed
break with gcc < 6 as well.

In any case, let's guard the kernel against undefined compiler behavior
by hiding the nature of the array location as suggested by gcc
developers.

Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128Signed-off-by: NNicolas Pitre <nico@linaro.org>
Reported-by: NMarcin Juszkiewicz <mjuszkiewicz@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: stable@vger.kernel.org # v4.5
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Wire up the preadv2 and pwritev2 syscalls for ARM.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Some processors use the Interrupt Response Time Limit (IRTL) MSR value
to describe the maximum IRQ response time latency for deep
package C-states.  (Though others have the register, but do not use it)
Lets print it out to give insight into the cases where it is used.

IRTL begain in SNB, with PC3/PC6/PC7, and HSW added PC8/PC9/PC10.
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

As mentioned in LTP's README.ARC:
------------->8------------
 Requirements for the environment

* Linux must be built with support of loop block devices. Thus it's
  necessary to enable these Linux kernel options:
  CONFIG_BLK_DEV
  CONFIG_BLK_DEV_LOOP
------------->8------------
enabling loop block devices.

That among other things lead to additional 10 fatal signals
appearing during LTP run.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

This reverts commit 667a490b.

This is needed to get ethernet(stmmac) working in 4.6-rc2 on axs103.

4.5 needed this fix, but apprently stmmac has gained some fixes which
warrant reversal of this.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

During mmaping of frame-buffer pages to user-space
fb_protect() is called to set proper page settings.

In case of ARC we need to mark pages that are mmaped to
user as uncached because of 2 reasons:
 * Huge amount of data if passing through data cache will
   thrash cache a lot making cache almost useless for other
   less traffic hungry processes.
 * Data written by user in FB will be immediately available for
   hardware (such as PGU etc) without requirements to flush data
   cache regularly.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Commit 5f8fc432 ("PCI: Include pci/pcie/Kconfig directly from
pci/Kconfig") in linux-next changed drivers/pci/Kconfig to include
drivers/pci/pcie/Kconfig itself, so that architectures do not need
to source both files themselves. ARC just recently gained PCI support
through commit 6b3fb77998dd ("ARC: Add PCI support"), but this change
was based on the old behaviour of the Kconfig files. This makes
Kconfig now spit out the following warnings:

drivers/pci/pcie/Kconfig:61:warning: choice value used outside its choice group
drivers/pci/pcie/Kconfig:67:warning: choice value used outside its choice group
drivers/pci/pcie/Kconfig:74:warning: choice value used outside its choice group

This change updates the Kconfig file for ARC, dropping the now
unnecessary 'source' statement, which makes the warning disappear.
Signed-off-by: NAndreas Ziegler <andreas.ziegler@fau.de>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Let's see if anybody even notices.  I doubt anybody uses this, and it
does expose addresses that should be randomized, so let's just remove
the code.  It's old and traditional, and it used to be cute, but we
should have removed this long ago.

If it turns out anybody notices and this breaks something, we'll have to
revert this, and maybe we'll end up using other approaches instead
(using %pK or similar).  But removing unnecessary code is always the
preferred option.
Noted-by: NEmrah Demir <ed@abdsec.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 1e947bad ("arm64: KVM: Skip HYP setup when already running
in HYP") re-organized the hyp init code and ended up leaving the CPU
hotplug and PM notifier even if hyp mode initialization fails.

Since KVM is not yet supported with ACPI, the above mentioned commit
breaks CPU hotplug in ACPI boot.

This patch fixes teardown_hyp_mode to properly unregister both CPU
hotplug and PM notifiers in the teardown path.

Fixes: 1e947bad ("arm64: KVM: Skip HYP setup when already running in HYP")
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>

We always thought that 40bits of PA range would be the minimum people
would actually build. Anything less is terrifyingly small.

Turns out that we were both right and wrong. Nobody has ever built
such a system, but the ARM Foundation Model has a PARange set to 36bits.
Just because we can. Oh well. Now, the KVM API explicitely says that
we offer a 40bit PA space to the VM, so we shouldn't run KVM on
the Foundation Model at all.

That being said, this patch offers a less agressive alternative, and
loudly warns about the configuration being unsupported. You'll still
be able to run VMs (at your own risks, though).

This is just a workaround until we have a proper userspace API where
we report the PARange to userspace.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>

When a vCPU runs on a nohz_full core, the hrtimer used by
the lapic emulation code can be migrated to another core.
When this happens, it's possible to observe milisecond
latency when delivering timer IRQs to KVM guests.

The huge latency is mainly due to the fact that
apic_timer_fn() expects to run during a kvm exit. It
sets KVM_REQ_PENDING_TIMER and let it be handled on kvm
entry. However, if the timer fires on a different core,
we have to wait until the next kvm exit for the guest
to see KVM_REQ_PENDING_TIMER set.

This problem became visible after commit 9642d18e. This
commit changed the timer migration code to always attempt
to migrate timers away from nohz_full cores. While it's
discussable if this is correct/desirable (I don't think
it is), it's clear that the lapic emulation code has
a requirement on firing the hrtimer in the same core
where it was started. This is achieved by making the
hrtimer pinned.

Lastly, note that KVM has code to migrate timers when a
vCPU is scheduled to run in different core. However, this
forced migration may fail. When this happens, we can have
the same problem. If we want 100% correctness, we'll have
to modify apic_timer_fn() to cause a kvm exit when it runs
on a different core than the vCPU. Not sure if this is
possible.

Here's a reproducer for the issue being fixed:

 1. Set all cores but core0 to be nohz_full cores
 2. Start a guest with a single vCPU
 3. Trace apic_timer_fn() and kvm_inject_apic_timer_irqs()

You'll see that apic_timer_fn() will run in core0 while
kvm_inject_apic_timer_irqs() runs in a different core. If
you get both on core0, try running a program that takes 100%
of the CPU and pin it to core0 to force the vCPU out.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

commit 1e133ab2 ("s390/mm: split arch/s390/mm/pgtable.c") dropped
some changes from commit a3a92c31 ("KVM: s390: fix mismatch
between user and in-kernel guest limit") - this breaks KVM for some
memory sizes (kvm-s390: failed to commit memory region) like
exactly 2GB.

Cc: Dominik Dingel <dingel@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Mostly direct substitution with occasional adjustment or removing
outdated comments.
Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
ago with promise that one day it will be possible to implement page
cache with bigger chunks than PAGE_SIZE.

This promise never materialized.  And unlikely will.

We have many places where PAGE_CACHE_SIZE assumed to be equal to
PAGE_SIZE.  And it's constant source of confusion on whether
PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
especially on the border between fs and mm.

Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
breakage to be doable.

Let's stop pretending that pages in page cache are special.  They are
not.

The changes are pretty straight-forward:

 - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;

 - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;

 - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};

 - page_cache_get() -> get_page();

 - page_cache_release() -> put_page();

This patch contains automated changes generated with coccinelle using
script below.  For some reason, coccinelle doesn't patch header files.
I've called spatch for them manually.

The only adjustment after coccinelle is revert of changes to
PAGE_CAHCE_ALIGN definition: we are going to drop it later.

There are few places in the code where coccinelle didn't reach.  I'll
fix them manually in a separate patch.  Comments and documentation also
will be addressed with the separate patch.

virtual patch

@@
expression E;
@@
- E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E

@@
expression E;
@@
- E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E

@@
@@
- PAGE_CACHE_SHIFT
+ PAGE_SHIFT

@@
@@
- PAGE_CACHE_SIZE
+ PAGE_SIZE

@@
@@
- PAGE_CACHE_MASK
+ PAGE_MASK

@@
expression E;
@@
- PAGE_CACHE_ALIGN(E)
+ PAGE_ALIGN(E)

@@
expression E;
@@
- page_cache_get(E)
+ get_page(E)

@@
expression E;
@@
- page_cache_release(E)
+ put_page(E)
Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make sure it's the microMIPS rather than MIPS16 ISA before emulating
microMIPS RDHWR.  Mostly needed as an optimisation for configurations
where `cpu_has_mmips' is hardcoded to 0 and also a good measure in case
we add further microMIPS instructions to emulate in the future, as the
corresponding MIPS16 encoding is ADDIUSP, not supposed to trap.
Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12282/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The SUN GISB arbiter was added with the wrong compatible string, leading to
using the wrong register layout, use the correct compatible string for this
chip: brcm,bcm7435-gisb-arb.

Fixes: 8394968be4c7 ("MIPS: BMIPS: Add BCM7435 dtsi")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Cc: blogic@openwrt.org
Cc: cernekee@gmail.com
Cc: jogo@openwrt.org
Cc: jaedon.shin@gmail.com
Cc: pgynther@google.com
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12285/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

When an unsupported reloc is encountered in a module, we currently
blindly branch to whatever would be at its entry in the reloc handler
function pointer arrays. This may be NULL, or if the unsupported reloc
has a type greater than that of the supported reloc with the highest
type then we'll dereference some value after the function pointer array
& branch to that. The result is at best a kernel oops.

Fix this by checking that the reloc type has an entry in the function
pointer array (ie. is less than the number of items in the array) and
that the handler is non-NULL, returning an error code to fail the module
load if no handler is found.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12432/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Current ath79 clock.c code does not read reference clock and
pll setup from devicetree. The ar724x_clocks_init() function
recreates the clocks from scratch so devicetree clock
information is dropped. After adding the code which picked up
reference clock from devicetree I have found
that kernel does not boot anymore. The SPI and UART drivers
can't get clk; here are the bootlog error messages:

    of_serial: probe of 18020000.uart failed with error -22
    ath79-spi: probe of 1f000000.spi failed with error -22

The problem is that clock code assumes that reference clock
name is "ref" but current dts-file uses another name: "oscillator".

This patch fixes the problem by changing external oscillator
dt node name to "ref".

Please note that there is an alternative solution for the problem:

    > --- a/arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts
    > +++ b/arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts
    > @@ -16,6 +16,7 @@
    >
    >         extosc: oscillator {
    >                 compatible = "fixed-clock";
    > +               clock-output-names = "ref";
    >                 #clock-cells = <0>;
    >                 clock-frequency = <40000000>;
    >         };
Signed-off-by: NAntony Pavlov <antonynpavlov@gmail.com>
Cc: Alban Bedel <albeu@free.fr>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-clk@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12874/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The reference clock on ar913x is at 40MHz and not 5MHz. The current
implementation use the wrong reference rate because it doesn't take
the PLL divider in account. But if we fix the code to use the divider
it becomes identical with the implementation for ar724x, so just drop
the broken ar913x implementation.
Signed-off-by: NAlban Bedel <albeu@free.fr>
Tested-by: NAntony Pavlov <antonynpavlov@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12871/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

According to the AR7242 datasheet section 2.8, AR724X CPUs use a 40MHz
input clock as the REF_CLK instead of 5MHz.

The correct CPU PLL calculation procedure is as follows:
CPU_PLL = (FB * REF_CLK) / REF_DIV / 2.

This patch is compatible with the current calculation procedure with
default FB and REF_DIV values.

Tested on AR7240, AR7241 and AR7242.
Signed-off-by: NWeijie Gao <hackpascal@gmail.com>
Signed-off-by: Alban Bedel <albeu@free.fr> (Fixed the commit log message)
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12870/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NAntony Pavlov <antonynpavlov@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Cc: Alban Bedel <albeu@free.fr>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12869/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Follow our own rules set in <asm/siginfo.h> for SIGTRAP signals issued
from `do_watch' and `do_trap_or_bp' by setting the signal code to
TRAP_HWBKPT and TRAP_BRKPT respectively, for Watch exceptions and for
those Breakpoint exceptions whose originating BREAK instruction's code
does not have a special meaning.  Keep Trap exceptions unaffected as
these are not debug events.

No existing user software is expected to examine signal codes for these
signals as SI_KERNEL has been always used here.  This change makes the
MIPS port more like other Linux ports, which reduces the complexity and
provides for performance improvement in GDB.
Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
Cc: Pedro Alves <palves@redhat.com>
Cc: Luis Machado <lgustavo@codesourcery.com>
Cc: linux-mips@linux-mips.org
Cc: gdb@sourceware.org
Patchwork: https://patchwork.linux-mips.org/patch/12758/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>