27 Mar, 2019
3 commits
-
commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
Insert Branch instruction instead of NOP to make sure assembler don't
patch code in forbidden slot. In jump label function, it might
be possible to patch Control Transfer Instructions(CTIs) into
forbidden slot, which will generate Reserved Instruction exception
in MIPS release 6.Signed-off-by: Archer Yan
Reviewed-by: Paul Burton
[paul.burton@mips.com:
- Add MIPS prefix to subject.
- Mark for stable from v4.0, which introduced r6 support, onwards.]
Signed-off-by: Paul Burton
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # v4.0+
Signed-off-by: Greg Kroah-Hartman -
commit 3f0a53bc6482fb09770982a8447981260ea258dc upstream.
This fixes booting with the combination of CONFIG_RELOCATABLE=y
and CONFIG_MIPS_ELF_APPENDED_DTB=y.Sections that appear after the relocation table are not relocated
on system boot (except .bss, which has special handling).With CONFIG_MIPS_ELF_APPENDED_DTB, the dtb is part of the
vmlinux ELF, so it must be relocated together with everything else.Fixes: 069fd766271d ("MIPS: Reserve space for relocation table")
Signed-off-by: Yasha Cherikovsky
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v4.7+
Signed-off-by: Greg Kroah-Hartman -
commit 5f5f67da9781770df0403269bc57d7aae608fecd upstream.
Timekeeping IRQs from CS5536 MFGPT are routed to i8259, which then
triggers the "cascade" IRQ on MIPS CPU. Without IRQF_NO_SUSPEND in
cascade_irqaction, MFGPT interrupts will be masked in suspend mode,
and the machine would be unable to resume once suspended.Previously, MIPS IRQs were not disabled properly, so the original
code appeared to work. Commit a3e6c1eff5 ("MIPS: IRQ: Fix disable_irq on
CPU IRQs") uncovers the bug. To fix it, add IRQF_NO_SUSPEND to
cascade_irqaction.This commit is functionally identical to 0add9c2f1cff ("MIPS:
Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction"), but it forgot
to apply the same fix to Loongson2.Signed-off-by: Yifeng Li
Signed-off-by: Paul Burton
Cc: linux-mips@vger.kernel.org
Cc: Jiaxun Yang
Cc: Huacai Chen
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Greg Kroah-Hartman
24 Mar, 2019
1 commit
-
commit 152482580a1b0accb60676063a1ac57b2d12daf6 upstream.
kvm_arch_memslots_updated() is at this point in time an x86-specific
hook for handling MMIO generation wraparound. x86 stashes 19 bits of
the memslots generation number in its MMIO sptes in order to avoid
full page fault walks for repeat faults on emulated MMIO addresses.
Because only 19 bits are used, wrapping the MMIO generation number is
possible, if unlikely. kvm_arch_memslots_updated() alerts x86 that
the generation has changed so that it can invalidate all MMIO sptes in
case the effective MMIO generation has wrapped so as to avoid using a
stale spte, e.g. a (very) old spte that was created with generation==0.Given that the purpose of kvm_arch_memslots_updated() is to prevent
consuming stale entries, it needs to be called before the new generation
is propagated to memslots. Invalidating the MMIO sptes after updating
memslots means that there is a window where a vCPU could dereference
the new memslots generation, e.g. 0, and incorrectly reuse an old MMIO
spte that was created with (pre-wrap) generation==0.Fixes: e59dbe09f8e6 ("KVM: Introduce kvm_arch_memslots_updated()")
Cc:
Signed-off-by: Sean Christopherson
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman
14 Mar, 2019
2 commits
-
[ Upstream commit 2b424cfc69728224fcb5fad138ea7260728e0901 ]
Patch (b6c7a324df37b "MIPS: Fix get_frame_info() handling of
microMIPS function size.") introduces additional function size
check for microMIPS by only checking insn between ip and ip + func_size.
However, func_size in get_frame_info() is always 0 if KALLSYMS is not
enabled. This causes get_frame_info() to return immediately without
calculating correct frame_size, which in turn causes "Can't analyze
schedule() prologue" warning messages at boot time.This patch removes func_size check, and let the frame_size check run
up to 128 insns for both MIPS and microMIPS.Signed-off-by: Jun-Ru Chang
Signed-off-by: Tony Wu
Signed-off-by: Paul Burton
Fixes: b6c7a324df37b ("MIPS: Fix get_frame_info() handling of microMIPS function size.")
Cc:
Cc:
Cc:
Cc:
Cc:
Cc:
Cc:
Cc:
Signed-off-by: Sasha Levin -
[ Upstream commit 1ca1c87f91d9dc50d6a38e2177b2032996e7901c ]
According to the Schematic, the hardware of ci20 leads to uart3,
but not to uart2. Uart2 is miswritten in the original code.Signed-off-by: Zhou Yanjie
Signed-off-by: Paul Burton
Cc: linux-mips
Cc: linux-kernel
Cc: devicetree@vger.kernel.org
Cc: robh+dt@kernel.org
Cc: ralf@linux-mips.org
Cc: jhogan@kernel.org
Cc: mark.rutland@arm.com
Cc: malat@debian.org
Cc: ezequiel@collabora.co.uk
Cc: ulf.hansson@linaro.org
Cc: syq
Cc: jiaxun.yang
Signed-off-by: Sasha Levin
10 Mar, 2019
1 commit
-
commit 72faa7a773ca59336f3c889e878de81445c5a85c upstream.
The irq_pages is the number of pages for irq stack, but not the
order which is needed by __get_free_pages().
We can use get_order() to calculate the accurate order.Signed-off-by: Liu Xiang
Signed-off-by: Paul Burton
Fixes: fe8bd18ffea5 ("MIPS: Introduce irq_stack")
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # v4.11+
Signed-off-by: Greg Kroah-Hartman
06 Mar, 2019
3 commits
-
commit d1a2930d8a992fb6ac2529449f81a0056e1b98d1 upstream.
The MIPS eBPF JIT calls flush_icache_range() in order to ensure the
icache observes the code that we just wrote. Unfortunately it gets the
end address calculation wrong due to some bad pointer arithmetic.The struct jit_ctx target field is of type pointer to u32, and as such
adding one to it will increment the address being pointed to by 4 bytes.
Therefore in order to find the address of the end of the code we simply
need to add the number of 4 byte instructions emitted, but we mistakenly
add the number of instructions multiplied by 4. This results in the call
to flush_icache_range() operating on a memory region 4x larger than
intended, which is always wasteful and can cause crashes if we overrun
into an unmapped page.Fix this by correcting the pointer arithmetic to remove the bogus
multiplication, and use braces to remove the need for a set of brackets
whilst also making it obvious that the target field is a pointer.Signed-off-by: Paul Burton
Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.")
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: netdev@vger.kernel.org
Cc: bpf@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Daniel Borkmann
Signed-off-by: Greg Kroah-Hartman -
commit 18836b48ebae20850631ee2916d0cdbb86df813d upstream.
The switch to the generic dma ops made dma masks mandatory, breaking
devices having them not set. In case of bcm63xx, it broke ethernet with
the following warning when trying to up the device:[ 2.633123] ------------[ cut here ]------------
[ 2.637949] WARNING: CPU: 0 PID: 325 at ./include/linux/dma-mapping.h:516 bcm_enetsw_open+0x160/0xbbc
[ 2.647423] Modules linked in: gpio_button_hotplug
[ 2.652361] CPU: 0 PID: 325 Comm: ip Not tainted 4.19.16 #0
[ 2.658080] Stack : 80520000 804cd3ec 00000000 00000000 804ccc00 87085bdc 87d3f9d4 804f9a17
[ 2.666707] 8049cf18 00000145 80a942a0 00000204 80ac0000 10008400 87085b90 eb3d5ab7
[ 2.675325] 00000000 00000000 80ac0000 000022b0 00000000 00000000 00000007 00000000
[ 2.683954] 0000007a 80500000 0013b381 00000000 80000000 00000000 804a1664 80289878
[ 2.692572] 00000009 00000204 80ac0000 00000200 00000002 00000000 00000000 80a90000
[ 2.701191] ...
[ 2.703701] Call Trace:
[ 2.706244] [] show_stack+0x58/0x100
[ 2.710840] [] __warn+0xe4/0x118
[ 2.715049] [] warn_slowpath_null+0x48/0x64
[ 2.720237] [] bcm_enetsw_open+0x160/0xbbc
[ 2.725347] [] __dev_open+0xf8/0x16c
[ 2.729913] [] __dev_change_flags+0x100/0x1c4
[ 2.735290] [] dev_change_flags+0x28/0x70
[ 2.740326] [] devinet_ioctl+0x310/0x7b0
[ 2.745250] [] inet_ioctl+0x1f8/0x224
[ 2.749939] [] sock_ioctl+0x30c/0x488
[ 2.754632] [] do_vfs_ioctl+0x740/0x7dc
[ 2.759459] [] ksys_ioctl+0x50/0x94
[ 2.763955] [] syscall_common+0x34/0x58
[ 2.768782] ---[ end trace fb1a6b14d74e28b6 ]---
[ 2.773544] bcm63xx_enetsw bcm63xx_enetsw.0: cannot allocate rx ring 512Fix this by adding appropriate DMA masks for the platform devices.
Fixes: f8c55dc6e828 ("MIPS: use generic dma noncoherent ops for simple noncoherent platforms")
Signed-off-by: Jonas Gorski
Reviewed-by: Christoph Hellwig
Reviewed-by: Florian Fainelli
Signed-off-by: Paul Burton
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: Ralf Baechle
Cc: James Hogan
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Greg Kroah-Hartman -
commit 94ee12b507db8b5876e31c9d6c9d84f556a4b49f upstream.
__cmpxchg_small erroneously uses u8 for load comparison which can
be either char or short. This patch changes the local variable to
u32 which is sufficiently sized, as the loaded value is already
masked and shifted appropriately. Using an integer size avoids
any unnecessary canonicalization from use of non native widths.This patch is part of a series that adapts the MIPS small word
atomics code for xchg and cmpxchg on short and char to RISC-V.Cc: RISC-V Patches
Cc: Linux RISC-V
Cc: Linux MIPS
Signed-off-by: Michael Clark
[paul.burton@mips.com:
- Fix varialble typo per Jonas Gorski.
- Consolidate load variable with other declarations.]
Signed-off-by: Paul Burton
Fixes: 3ba7f44d2b19 ("MIPS: cmpxchg: Implement 1 byte & 2 byte cmpxchg()")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Greg Kroah-Hartman
27 Feb, 2019
3 commits
-
[ Upstream commit 41af167fbc0032f9d7562854f58114eaa9270336 ]
64bit JAZZ builds failed with
linux-next/arch/mips/jazz/jazzdma.c: In function `vdma_init`:
/linux-next/arch/mips/jazz/jazzdma.c:77:30: error: implicit declaration
of function `KSEG1ADDR`; did you mean `CKSEG1ADDR`?
[-Werror=implicit-function-declaration]
pgtbl = (VDMA_PGTBL_ENTRY *)KSEG1ADDR(pgtbl);
^~~~~~~~~
CKSEG1ADDR
/linux-next/arch/mips/jazz/jazzdma.c:77:10: error: cast to pointer from
integer of different size [-Werror=int-to-pointer-cast]
pgtbl = (VDMA_PGTBL_ENTRY *)KSEG1ADDR(pgtbl);
^
In file included from /linux-next/arch/mips/include/asm/barrier.h:11:0,
from /linux-next/include/linux/compiler.h:248,
from /linux-next/include/linux/kernel.h:10,
from /linux-next/arch/mips/jazz/jazzdma.c:11:
/linux-next/arch/mips/include/asm/addrspace.h:41:29: error: cast from
pointer to integer of different size [-Werror=pointer-to-int-cast]
#define _ACAST32_ (_ATYPE_)(_ATYPE32_) /* widen if necessary */
^
/linux-next/arch/mips/include/asm/addrspace.h:53:25: note: in
expansion of macro `_ACAST32_`
#define CPHYSADDR(a) ((_ACAST32_(a)) & 0x1fffffff)
^~~~~~~~~
/linux-next/arch/mips/jazz/jazzdma.c:84:44: note: in expansion of
macro `CPHYSADDR`
r4030_write_reg32(JAZZ_R4030_TRSTBL_BASE, CPHYSADDR(pgtbl));Using correct casts and CKSEG1ADDR when dealing with the pgtbl setup
fixes this.Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin -
[ Upstream commit 565dc8a4f55e491935bfb04866068d21784ea9a4 ]
CONFIG_SERIAL_OF_PLATFORM is needed to get a working console on the OF
boards, enable it in the default config to get a working setup out of
the box.Signed-off-by: Alban Bedel
Signed-off-by: Paul Burton
Cc: linux-mips@vger.kernel.org
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin -
commit 13443154f6cac61d148471ede6d7f1f6b5ea946a upstream.
The function prototype used to call JITed eBPF code (ie. the type of the
struct bpf_prog bpf_func field) returns an unsigned int. The MIPS n64
ABI that MIPS64 kernels target defines that 32 bit integers should
always be sign extended when passed in registers as either arguments or
return values.This means that when returning any value which may not already be sign
extended (ie. of type REG_64BIT or REG_32BIT_ZERO_EX) we need to perform
that sign extension in order to comply with the n64 ABI. Without this we
see strange looking test failures from test_bpf.ko, such as:test_bpf: #65 ALU64_MOV_X:
dst = 4294967295 jited:1 ret -1 != -1 FAIL (1 times)Although the return value printed matches the expected value, this is
only because printf is only examining the least significant 32 bits of
the 64 bit register value we returned. The register holding the expected
value is sign extended whilst the v0 register was set to a zero extended
value by our JITed code, so when compared by a conditional branch
instruction the values are not equal.We already handle this when the return value register is of type
REG_32BIT_ZERO_EX, so simply extend this to also cover REG_64BIT.Signed-off-by: Paul Burton
Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Daniel Borkmann
Signed-off-by: Greg Kroah-Hartman
15 Feb, 2019
5 commits
-
commit 67fc5dc8a541e8f458d7f08bf88ff55933bf9f9d upstream.
When generating vdso-o32.lds & vdso-n32.lds for use with programs
running as compat ABIs under 64b kernels, we previously haven't included
the compiler flags that are supposedly common to all ABIs - ie. those in
the ccflags-vdso variable.This is problematic in cases where we need to provide the -m%-float flag
in order to ensure that we don't attempt to use a floating point ABI
that's incompatible with the target CPU & ABI. For example a toolchain
using current gcc trunk configured --with-fp-32=xx fails to build a
64r6el_defconfig kernel with the following error:cc1: error: '-march=mips1' requires '-mfp32'
make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is
included for the native VDSO .lds & when compiling objects for the
compat VDSOs. This ensures we consistently provide the -msoft-float flag
amongst others, avoiding the problem by ensuring we're agnostic to the
toolchain defaults.Signed-off-by: Paul Burton
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Cc: linux-mips@vger.kernel.org
Cc: Kevin Hilman
Cc: Guenter Roeck
Cc: Maciej W . Rozycki
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman -
commit 8a96669d77897ff3613157bf43f875739205d66d upstream.
On my Yeeloong 8089, I noticed the machine fails to shutdown
properly, and often, the function mach_prepare_reboot() is
unexpectedly executed, thus the machine reboots instead. A
wait loop is needed to ensure the system is in a well-defined
state before going down.In commit 997e93d4df16 ("MIPS: Hang more efficiently on
halt/powerdown/restart"), a general superset of the wait loop for all
platforms is already provided, so we don't need to implement our own.This commit simply removes the unreachable() compiler marco after
mach_prepare_reboot(), thus allowing the execution of machine_hang().
My test shows that the machine is now able to shutdown successfully.Please note that there are two different bugs preventing the machine
from shutting down, another work-in-progress commit is needed to
fix a lockup in cpufreq / i8259 driver, please read Reference, this
commit does not fix that bug.Reference: https://lkml.org/lkml/2019/2/5/908
Signed-off-by: Yifeng Li
Signed-off-by: Paul Burton
Cc: linux-mips@vger.kernel.org
Cc: Huacai Chen
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-kernel@vger.kernel.org
Cc: Aaro Koskinen
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Greg Kroah-Hartman -
commit 0648e50e548d881d025b9419a1a168753c8e2bf7 upstream.
The MIPS VDSO build currently doesn't provide the -msoft-float flag to
the compiler as the kernel proper does. This results in an attempt to
use the compiler's default floating point configuration, which can be
problematic in cases where this is incompatible with the target CPU's
-march= flag. For example decstation_defconfig fails to build using
toolchains in which gcc was configured --with-fp-32=xx with the
following error:LDS arch/mips/vdso/vdso.lds
cc1: error: '-march=r3000' requires '-mfp32'
make[2]: *** [scripts/Makefile.build:379: arch/mips/vdso/vdso.lds] Error 1The kernel proper avoids this error because we build with the
-msoft-float compiler flag, rather than using the compiler's default.
Pass this flag through to the VDSO build so that it too becomes agnostic
to the toolchain's floating point configuration.Note that this is filtered out from KBUILD_CFLAGS rather than simply
always using -msoft-float such that if we switch the kernel to use
-mno-float in the future the VDSO will automatically inherit the change.The VDSO doesn't actually include any floating point code, and its
.MIPS.abiflags section is already manually generated to specify that
it's compatible with any floating point ABI. As such this change should
have no effect on the resulting VDSO, apart from fixing the build
failure for affected toolchains.Signed-off-by: Paul Burton
Reported-by: Kevin Hilman
Reported-by: Guenter Roeck
Tested-by: Kevin Hilman
References: https://lore.kernel.org/linux-mips/1477843551-21813-1-git-send-email-linux@roeck-us.net/
References: https://kernelci.org/build/id/5c4e4ae059b5142a249ad004/logs/
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Cc: Maciej W. Rozycki
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman -
commit dcf300a69ac307053dfb35c2e33972e754a98bce upstream.
Don't set octeon_dma_bar_type if PCI is disabled. This avoids creation
of the MSI irqchip later on, and saves a bit of memory.Signed-off-by: Aaro Koskinen
Signed-off-by: Paul Burton
Fixes: a214720cbf50 ("Disable MSI also when pcie-octeon.pcie_disable on")
Cc: stable@vger.kernel.org # v3.3+
Cc: linux-mips@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 05dc6001af0630e200ad5ea08707187fe5537e6d upstream.
Accordingly to the documentation
---cut---
The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
fields can be cleared by either a reset or by writing the current
value of GCR_ERROR_CAUSE.ERR_TYPE to the
GCR_ERROR_CAUSE.ERR_TYPE register.
---cut---
Do exactly this. Original value of cm_error may be safely written back;
it clears error cause and keeps other bits untouched.Fixes: 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache errors")
Signed-off-by: Vladimir Kondratiev
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v4.3+
Signed-off-by: Greg Kroah-Hartman
13 Feb, 2019
4 commits
-
[ Upstream commit 0b15394475e3bcaf35ca4bf22fc55d56df67224e ]
Testing has shown, that when using mainline U-Boot on MT7688 based
boards, the system may hang or crash while mounting the root-fs. The
main issue here is that mainline U-Boot configures EBase to a value
near the end of system memory. And with CONFIG_CPU_MIPSR2_IRQ_VI
disabled, trap_init() will not allocate a new area to place the
exception handler. The original value will be used and the handler
will be copied to this location, which might already be used by some
userspace application.The MT7688 supports VI - its config3 register is 0x00002420, so VInt
(Bit 5) is set. But without setting CONFIG_CPU_MIPSR2_IRQ_VI this
bit will not be evaluated to result in "cpu_has_vi" being set. This
patch now selects CONFIG_CPU_MIPSR2_IRQ_VI on MT7620/8 which results
trap_init() to allocate some memory for the exception handler.Please note that this issue was not seen with the Mediatek U-Boot
version, as it does not touch EBase (stays at default of 0x8000.0000).
This is strictly also not correct as the kernel (_text) resides
here.Signed-off-by: Stefan Roese
[paul.burton@mips.com: s/beeing/being/]
Signed-off-by: Paul Burton
Cc: John Crispin
Cc: Daniel Schwierzeck
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Signed-off-by: Sasha Levin -
[ Upstream commit 0c901c0566fb4edc2631c3786e5085a037be91f8 ]
Modifty the JZ4740 driver to retrieve card detect and write
protect GPIO pins from GPIO descriptors instead of hard-coded
global numbers. Augment the only board file using this in the
process and cut down on passed in platform data.Preserve the code setting the caps2 flags for CD and WP
as active low or high since the slot GPIO code currently
ignores the gpiolib polarity inversion semantice and uses
the raw accessors to read the GPIO lines, but set the right
polarity flags in the descriptor table for jz4740.Cc: Paul Cercueil
Cc: linux-mips@linux-mips.org
Signed-off-by: Linus Walleij
Acked-by: Paul Burton
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin -
[ Upstream commit 17f6c83fb5ebf7db4fcc94a5be4c22d5a7bfe428 ]
For micro-mips, srlv inside POOL32A encoding space should use 0x50
sub-opcode, NOT 0x90.Some early version ISA doc describes the encoding as 0x90 for both srlv and
srav, this looks to me was a typo. I checked Binutils libopcode
implementation which is using 0x50 for srlv and 0x90 for srav.v1->v2:
- Keep mm_srlv32_op sorted by value.Fixes: f31318fdf324 ("MIPS: uasm: Add srlv uasm instruction")
Cc: Markos Chandras
Cc: Paul Burton
Cc: linux-mips@vger.kernel.org
Acked-by: Jakub Kicinski
Acked-by: Song Liu
Signed-off-by: Jiong Wang
Signed-off-by: Alexei Starovoitov
Signed-off-by: Sasha Levin -
[ Upstream commit 5ec17af7ead09701e23d2065e16db6ce4e137289 ]
The Intel EG20T Platform Controller Hub used on the MIPS Boston
development board supports prefetching memory to optimize DMA transfers.
Unfortunately for unknown reasons this doesn't work well with some MIPS
CPUs such as the P6600, particularly when using an I/O Coherence Unit
(IOCU) to provide cache-coherent DMA. In these systems it is common for
DMA data to be lost, resulting in broken access to EG20T devices such as
the MMC or SATA controllers.Support for a DT property to configure the prefetching was added a while
back by commit 549ce8f134bd ("misc: pch_phub: Read prefetch value from
device tree if passed") but we never added the DT snippet to make use of
it. Add that now in order to disable the prefetching & fix DMA on the
affected systems.Signed-off-by: Paul Burton
Patchwork: https://patchwork.linux-mips.org/patch/21068/
Cc: linux-mips@linux-mips.org
Signed-off-by: Sasha Levin
26 Jan, 2019
1 commit
-
[ Upstream commit e4849aff1e169b86c561738daf8ff020e9de1011 ]
The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
DRAM controller that supports memory amounts of up to 16GiB, and due to
how the address decoder has been wired in the SOC any memory beyond 1GiB
is actually mapped starting from 4GiB physical up, that is beyond the
32-bit addressable limit[1]. Consequently if the maximum amount of
memory has been installed, then it will span up to 19GiB.Many of the evaluation boards we support that are based on one of these
SOCs have their memory soldered and the amount present fits in the
32-bit address range. The BCM91250A SWARM board however has actual DIMM
slots and accepts, depending on the peripherals revision of the SOC, up
to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
I believe this is also the case with the BCM91250C2 LittleSur board.
This means that up to either 3GiB or 7GiB of memory requires 64-bit
addressing to access.I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
accepts at least as much memory, although I have no documentation or
actual hardware available to verify that.Both systems have PCI slots installed for use by any PCI option boards,
including ones that only support 32-bit addressing (additionally the
32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
addressing to 32-bits), and there is no IOMMU available. Therefore for
PCI DMA to work in the presence of memory beyond enable swiotlb for the
affected systems.All the other SOC onchip DMA devices use 40-bit addressing and therefore
can address the whole memory, so only enable swiotlb if PCI support and
support for DMA beyond 4GiB have been both enabled in the configuration
of the kernel.This shows up as follows:
Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
Board type: SiByte BCM91250A (SWARM)
Determined physical RAM map:
memory: 000000000fe7fe00 @ 0000000000000000 (usable)
memory: 000000001ffffe00 @ 0000000080000000 (usable)
memory: 000000000ffffe00 @ 00000000c0000000 (usable)
memory: 0000000087fffe00 @ 0000000100000000 (usable)
software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)in the bootstrap log and removes failures like these:
defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi0: Receive buffer allocation failed
fddi0: Adapter open failed!
IP-Config: Failed to open fddi0
defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi1: Receive buffer allocation failed
fddi1: Adapter open failed!
IP-Config: Failed to open fddi1when memory beyond 4GiB is handed out to devices that can only do 32-bit
addressing.This updates commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need
DMA32.").References:
[1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
"Memory Map", pp. 34-38[2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
Corporation, 18 May 2004, Section 3: "Physical Description",
"Supported DRAM", p. 23Signed-off-by: Maciej W. Rozycki
[paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
Signed-off-by: Paul Burton
Reviewed-by: Christoph Hellwig
Patchwork: https://patchwork.linux-mips.org/patch/21108/
References: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.")
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin
23 Jan, 2019
4 commits
-
commit a214720cbf50cd8c3f76bbb9c3f5c283910e9d33 upstream.
Octeon has an boot-time option to disable pcie.
Since MSI depends on PCI-E, we should also disable MSI also with
this option is on in order to avoid inadvertently accessing PCIe
registers.Signed-off-by: YunQiang Su
Signed-off-by: Paul Burton
Cc: pburton@wavecomp.com
Cc: linux-mips@vger.kernel.org
Cc: aaro.koskinen@iki.fi
Cc: stable@vger.kernel.org # v3.3+
Signed-off-by: Greg Kroah-Hartman -
commit 2b4dba55b04b212a7fd1f0395b41d79ee3a9801b upstream.
This makes SMP on the vrx200 work again, by removing all the MIPS CPU
interrupt specific code and making it fully use the generic MIPS CPU
interrupt controller.The mti,cpu-interrupt-controller from irq-mips-cpu.c now handles the CPU
interrupts and also the IPI interrupts which are used to communication
between the CPUs in a SMP system. The generic interrupt code was
already used before but the interrupt vectors were overwritten again
when we called set_vi_handler() in the lantiq interrupt driver and we
also provided our own plat_irq_dispatch() function which overwrote the
weak generic implementation. Now the code uses the generic handler for
the MIPS CPU interrupts including the IPI interrupts and registers a
handler for the CPU interrupts which are handled by the lantiq ICU with
irq_set_chained_handler() which was already called before.Calling the set_c0_status() function is also not needed any more because
the generic MIPS CPU interrupt already activates the needed bits.Fixes: 1eed40043579 ("MIPS: smp-mt: Use CPU interrupt controller IPI IRQ domain support")
Cc: stable@kernel.org # v4.12
Signed-off-by: Hauke Mehrtens
Signed-off-by: Paul Burton
Cc: jhogan@kernel.org
Cc: ralf@linux-mips.org
Cc: john@phrozen.org
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 321c46b91550adc03054125fa7a1639390608e1a upstream.
So far we never had any device registered for the SoC. This resulted in
some small issues that we kept ignoring like:
1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing)
2) Lack of proper tree in the /sys/devices/
3) mips_dma_alloc_coherent() silently handling empty coherent_dma_maskKernel 4.19 came with a lot of DMA changes and caused a regression on
bcm47xx. Starting with the commit f8c55dc6e828 ("MIPS: use generic dma
noncoherent ops for simple noncoherent platforms") DMA coherent
allocations just fail. Example:
[ 1.114914] bgmac_bcma bcma0:2: Allocation of TX ring 0x200 failed
[ 1.121215] bgmac_bcma bcma0:2: Unable to alloc memory for DMA
[ 1.127626] bgmac_bcma: probe of bcma0:2 failed with error -12
[ 1.133838] bgmac_bcma: Broadcom 47xx GBit MAC driver loadedThe bgmac driver also triggers a WARNING:
[ 0.959486] ------------[ cut here ]------------
[ 0.964387] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 bgmac_enet_probe+0x1b4/0x5c4
[ 0.973751] Modules linked in:
[ 0.976913] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.9 #0
[ 0.982750] Stack : 804a0000 804597c4 00000000 00000000 80458fd8 8381bc2c 838282d4 80481a47
[ 0.991367] 8042e3ec 00000001 804d38f0 00000204 83980000 00000065 8381bbe0 6f55b24f
[ 0.999975] 00000000 00000000 80520000 00002018 00000000 00000075 00000007 00000000
[ 1.008583] 00000000 80480000 000ee811 00000000 00000000 00000000 80432c00 80248db8
[ 1.017196] 00000009 00000204 83980000 803ad7b0 00000000 801feeec 00000000 804d0000
[ 1.025804] ...
[ 1.028325] Call Trace:
[ 1.030875] [] show_stack+0x58/0x100
[ 1.035513] [] __warn+0xe4/0x118
[ 1.039708] [] warn_slowpath_null+0x48/0x64
[ 1.044935] [] bgmac_enet_probe+0x1b4/0x5c4
[ 1.050101] [] bgmac_probe+0x558/0x590
[ 1.054906] [] bcma_device_probe+0x38/0x70
[ 1.060017] [] really_probe+0x170/0x2e8
[ 1.064891] [] __driver_attach+0xa4/0xec
[ 1.069784] [] bus_for_each_dev+0x58/0xb0
[ 1.074833] [] bus_add_driver+0xf8/0x218
[ 1.079731] [] driver_register+0xcc/0x11c
[ 1.084804] [] bgmac_init+0x1c/0x44
[ 1.089258] [] do_one_initcall+0x7c/0x1a0
[ 1.094343] [] kernel_init_freeable+0x150/0x218
[ 1.099886] [] kernel_init+0x10/0x104
[ 1.104583] [] ret_from_kernel_thread+0x14/0x1c
[ 1.110107] ---[ end trace f441c0d873d1fb5b ]---This patch setups a "struct device" (and passes it to the bcma) which
allows fixing all the mentioned problems. It'll also require a tiny bcma
patch which will follow through the wireless tree & its maintainer.Fixes: f8c55dc6e828 ("MIPS: use generic dma noncoherent ops for simple noncoherent platforms")
Signed-off-by: Rafał Miłecki
Signed-off-by: Paul Burton
Acked-by: Hauke Mehrtens
Cc: Christoph Hellwig
Cc: Linus Walleij
Cc: linux-wireless@vger.kernel.org
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Greg Kroah-Hartman -
commit 5a9372f751b5350e0ce3d2ee91832f1feae2c2e5 upstream.
While reading through the sysvipc implementation, I noticed that the n32
semctl/shmctl/msgctl system calls behave differently based on whether
o32 support is enabled or not: Without o32, the IPC_64 flag passed by
user space is rejected but calls without that flag get IPC_64 behavior.As far as I can tell, this was inadvertently changed by a cleanup patch
but never noticed by anyone, possibly nobody has tried using sysvipc
on n32 after linux-3.19.Change it back to the old behavior now.
Fixes: 78aaf956ba3a ("MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.")
Signed-off-by: Arnd Bergmann
Signed-off-by: Paul Burton
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # 3.19+
Signed-off-by: Greg Kroah-Hartman
10 Jan, 2019
8 commits
-
commit 66a4059ba72c23ae74a7c702894ff76c4b7eac1f upstream.
MIPS' asm/mmzone.h includes the machine/platform mmzone.h
unconditionally, but since commit bb53fdf395ee ("MIPS: c-r4k: Add
r4k_blast_scache_node for Loongson-3") is included by asm/rk4cache.h for
all r4k-style configs regardless of CONFIG_NEED_MULTIPLE_NODES.This is problematic when CONFIG_NEED_MULTIPLE_NODES=n because both the
loongson3 & ip27 mmzone.h headers unconditionally define the NODE_DATA
preprocessor macro which is aready defined by linux/mmzone.h, resulting
in the following build error:In file included from ./arch/mips/include/asm/mmzone.h:10,
from ./arch/mips/include/asm/r4kcache.h:23,
from arch/mips/mm/c-r4k.c:33:
./arch/mips/include/asm/mach-loongson64/mmzone.h:48: error: "NODE_DATA" redefined [-Werror]
#define NODE_DATA(n) (&__node_data[(n)]->pglist)In file included from ./include/linux/topology.h:32,
from ./include/linux/irq.h:19,
from ./include/asm-generic/hardirq.h:13,
from ./arch/mips/include/asm/hardirq.h:16,
from ./include/linux/hardirq.h:9,
from arch/mips/mm/c-r4k.c:11:
./include/linux/mmzone.h:907: note: this is the location of the previous definition
#define NODE_DATA(nid) (&contig_page_data)Resolve this by only including the machine mmzone.h when
CONFIG_NEED_MULTIPLE_NODES=y, which also removes the need for the empty
mach-generic version of the header which we delete.Signed-off-by: Paul Burton
Fixes: bb53fdf395ee ("MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3")
Signed-off-by: Greg Kroah-Hartman -
commit db1ce3f5d01d2d6d5714aefba0159d2cb5167a0b upstream.
Commit 4936084c2ee2 ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
introduce a mistake in atomic64_fetch_##op##_relaxed(), because it
forget to delete R10000_LLSC_WAR in the if-condition. So fix it.Fixes: 4936084c2ee2 ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
Signed-off-by: Huacai Chen
Signed-off-by: Paul Burton
Cc: Joshua Kinard
Cc: Ralf Baechle
Cc: Steven J . Hill
Cc: Fuxin Zhang
Cc: Zhangjin Wu
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # 4.19+
Signed-off-by: Greg Kroah-Hartman -
commit edefae94b7b9f10d5efe32dece5a36e9d9ecc29e upstream.
Commit 885872b722b7 ("MIPS: Octeon: Add Octeon III CN7xxx
interface detection") added RGMII interface detection for OCTEON III,
but it results in the following logs:[ 7.165984] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probe
[ 7.173017] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probeThe current RGMII routines are valid only for older OCTEONS that
use GMX/ASX hardware blocks. On later chips AGL should be used,
but support for that is missing in the mainline. Until that is added,
mark the interface as disabled.Fixes: 885872b722b7 ("MIPS: Octeon: Add Octeon III CN7xxx interface detection")
Signed-off-by: Aaro Koskinen
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: Greg Kroah-Hartman -
commit ff4dd232ec45a0e45ea69f28f069f2ab22b4908a upstream.
ASIDs have always been stored as unsigned longs, ie. 32 bits on MIPS32
kernels. This is problematic because it is feasible for the ASID version
to overflow & wrap around to zero.We currently attempt to handle this overflow by simply setting the ASID
version to 1, using asid_first_version(), but we make no attempt to
account for the fact that there may be mm_structs with stale ASIDs that
have versions which we now reuse due to the overflow & wrap around.Encountering this requires that:
1) A struct mm_struct X is active on CPU A using ASID (V,n).
2) That mm is not used on CPU A for the length of time that it takes
for CPU A's asid_cache to overflow & wrap around to the same
version V that the mm had in step 1. During this time tasks using
the mm could either be sleeping or only scheduled on other CPUs.3) Some other mm Y becomes active on CPU A and is allocated the same
ASID (V,n).4) mm X now becomes active on CPU A again, and now incorrectly has the
same ASID as mm Y.Where struct mm_struct ASIDs are represented above in the format
(version, EntryHi.ASID), and on a typical MIPS32 system version will be
24 bits wide & EntryHi.ASID will be 8 bits wide.The length of time required in step 2 is highly dependent upon the CPU &
workload, but for a hypothetical 2GHz CPU running a workload which
generates a new ASID every 10000 cycles this period is around 248 days.
Due to this long period of time & the fact that tasks need to be
scheduled in just the right (or wrong, depending upon your inclination)
way, this is obviously a difficult bug to encounter but it's entirely
possible as evidenced by reports.In order to fix this, simply extend ASIDs to 64 bits even on MIPS32
builds. This will extend the period of time required for the
hypothetical system above to encounter the problem from 28 days to
around 3 trillion years, which feels safely outside of the realms of
possibility.The cost of this is slightly more generated code in some commonly
executed paths, but this is pretty minimal:| Code Size Gain | Percentage
-----------------------|----------------|-------------
decstation_defconfig | +270 | +0.00%
32r2el_defconfig | +652 | +0.01%
32r6el_defconfig | +1000 | +0.01%I have been unable to measure any change in performance of the LMbench
lat_ctx or lat_proc tests resulting from the 64b ASIDs on either
32r2el_defconfig+interAptiv or 32r6el_defconfig+I6500 systems.Signed-off-by: Paul Burton
Suggested-by: James Hogan
References: https://lore.kernel.org/linux-mips/80B78A8B8FEE6145A87579E8435D78C30205D5F3@fzex.ruijie.com.cn/
References: https://lore.kernel.org/linux-mips/1488684260-18867-1-git-send-email-jiwei.sun@windriver.com/
Cc: Jiwei Sun
Cc: Yu Huabing
Cc: stable@vger.kernel.org # 2.6.12+
Cc: linux-mips@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit bec0de4cfad21bd284dbddee016ed1767a5d2823 upstream.
KEXEC needs the new kernel's load address to be aligned on a page
boundary (see sanity_check_segment_list()), but on MIPS the default
vmlinuz load address is only explicitly aligned to 16 bytes.Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
the alignment calculated by calc_vmlinuz_load_addr to 64KB.Signed-off-by: Huacai Chen
Signed-off-by: Paul Burton
Patchwork: https://patchwork.linux-mips.org/patch/21131/
Cc: Ralf Baechle
Cc: James Hogan
Cc: Steven J . Hill
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang
Cc: Zhangjin Wu
Cc: # 2.6.36+
Signed-off-by: Greg Kroah-Hartman -
commit 92aa0718c9fa5160ad2f0e7b5bffb52f1ea1e51a upstream.
This patch is borrowed from ARM64 to ensure pmd_present() returns false
after pmd_mknotpresent(). This is needed for THP.References: 5bb1cc0ff9a6 ("arm64: Ensure pmd_present() returns false after pmd_mknotpresent()")
Reviewed-by: James Hogan
Signed-off-by: Huacai Chen
Signed-off-by: Paul Burton
Patchwork: https://patchwork.linux-mips.org/patch/21135/
Cc: Ralf Baechle
Cc: James Hogan
Cc: Steven J . Hill
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang
Cc: Zhangjin Wu
Cc: # 3.8+
Signed-off-by: Greg Kroah-Hartman -
commit bb53fdf395eed103f85061bfff3b116cee123895 upstream.
For multi-node Loongson-3 (NUMA configuration), r4k_blast_scache() can
only flush Node-0's scache. So we add r4k_blast_scache_node() by using
(CAC_BASE | (node_id << NODE_ADDRSPACE_SHIFT)) instead of CKSEG0 as the
start address.Signed-off-by: Huacai Chen
[paul.burton@mips.com: Include asm/mmzone.h from asm/r4kcache.h for
nid_to_addrbase(). Add asm/mach-generic/mmzone.h
to allow inclusion for all platforms.]
Signed-off-by: Paul Burton
Patchwork: https://patchwork.linux-mips.org/patch/21129/
Cc: Ralf Baechle
Cc: James Hogan
Cc: Steven J . Hill
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang
Cc: Zhangjin Wu
Cc: # 3.15+
Signed-off-by: Greg Kroah-Hartman -
commit adcc81f148d733b7e8e641300c5590a2cdc13bf3 upstream.
Mapping the delay slot emulation page as both writeable & executable
presents a security risk, in that if an exploit can write to & jump into
the page then it can be used as an easy way to execute arbitrary code.Prevent this by mapping the page read-only for userland, and using
access_process_vm() with the FOLL_FORCE flag to write to it from
mips_dsemul().This will likely be less efficient due to copy_to_user_page() performing
cache maintenance on a whole page, rather than a single line as in the
previous use of flush_cache_sigtramp(). However this delay slot
emulation code ought not to be running in any performance critical paths
anyway so this isn't really a problem, and we can probably do better in
copy_to_user_page() anyway in future.A major advantage of this approach is that the fix is small & simple to
backport to stable kernels.Reported-by: Andy Lutomirski
Signed-off-by: Paul Burton
Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot instructions")
Cc: stable@vger.kernel.org # v4.8+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Rich Felker
Cc: David Daney
Signed-off-by: Greg Kroah-Hartman
08 Dec, 2018
2 commits
-
commit c50cbd85cd7027d32ac5945bb60217936b4f7eaf upstream.
When checking for TIF_32BIT_REGS flag, mips_get_syscall_arg() should
use the task specified as its argument instead of the current task.This potentially affects all syscall_get_arguments() users
who specify tasks different from the current.Fixes: c0ff3c53d4f99 ("MIPS: Enable HAVE_ARCH_TRACEHOOK.")
Signed-off-by: Dmitry V. Levin
Signed-off-by: Paul Burton
Patchwork: https://patchwork.linux-mips.org/patch/21185/
Cc: Elvira Khabirova
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Greg Kroah-Hartman -
commit 7d35baa4e9ec4b717bc0e58a39cdb6a1c50f5465 upstream.
In case the nd_sd group is set to the sd-card function, Pins 45 + 46 are
configured as GPIOs. If they are blocked by the sd function, they can't
be used as GPIOs.Reported-by: Kristian Evensen
Signed-off-by: Mathias Kresin
Signed-off-by: Paul Burton
Fixes: f576fb6a0700 ("MIPS: ralink: cleanup the soc specific pinmux data")
Patchwork: https://patchwork.linux-mips.org/patch/21220/
Cc: John Crispin
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Greg Kroah-Hartman
06 Dec, 2018
1 commit
-
commit 8712b27c5723c26400a2b350faf1d6d9fd7ffaad upstream.
The function_graph_enter() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().Have MIPS use the new code, and remove the shadow stack management as well as
having to set up the trace structure.This is needed to prepare for a fix of a design bug on how the curr_ret_stack
is used.Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: linux-mips@linux-mips.org
Cc: stable@kernel.org
Fixes: 03274a3ffb449 ("tracing/fgraph: Adjust fgraph depth before calling trace return callback")
Reviewed-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Greg Kroah-Hartman
27 Nov, 2018
1 commit
-
commit 82fba2df7f7c019627f24c5036dc99f41731d770 upstream.
Re-enable OCTEON USB driver which is needed on older hardware
(e.g. EdgeRouter Lite) for mass storage etc. This got accidentally
deleted when config options were changed for OCTEON2/3 USB.Signed-off-by: Aaro Koskinen
Signed-off-by: Paul Burton
Fixes: f922bc0ad08b ("MIPS: Octeon: cavium_octeon_defconfig: Enable more drivers")
Patchwork: https://patchwork.linux-mips.org/patch/21077/
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 4.14+
Signed-off-by: Greg Kroah-Hartman
21 Nov, 2018
1 commit
-
[ Upstream commit 360fe725f8849aaddc53475fef5d4a0c439b05ae ]
After commit e509bd7da149dc349160 ("genirq: Allow migration of chained
interrupts by installing default action") Loongson-3 fails at here:setup_irq(LOONGSON_HT1_IRQ, &cascade_irqaction);
This is because both chained_action and cascade_irqaction don't have
IRQF_SHARED flag. This will cause Loongson-3 resume fails because HPET
timer interrupt can't be delivered during S3. So we set the irqchip of
the chained irq to loongson_irq_chip which doesn't disable the chained
irq in CP0.Status.Cc: stable@vger.kernel.org
Signed-off-by: Huacai Chen
Signed-off-by: Paul Burton
Patchwork: https://patchwork.linux-mips.org/patch/20434/
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang
Cc: Zhangjin Wu
Cc: Huacai Chen
Signed-off-by: Sasha Levin