01 Oct, 2020
1 commit
-
[ Upstream commit e393fbe6fa27af23f78df6e16a8fd2963578a8c4 ]
Commit 442e14a2c55e ("MIPS: Add 1074K CPU support explicitly.") split
1074K from the 74K as an unique CPU type, while it missed to add the
'CPU_1074K' in __get_cpu_type(). So let's add it back.Fixes: 442e14a2c55e ("MIPS: Add 1074K CPU support explicitly.")
Signed-off-by: Wei Li
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
23 Sep, 2020
3 commits
-
[ Upstream commit b959b97860d0fee8c8f6a3e641d3c2ad76eab6be ]
On A20R machines the interrupt pending bits in cause register need to be
updated by requesting the chipset to do it. This needs to be done to
find the interrupt cause and after interrupt service. In
commit 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
function to do after service update got lost, which caused spurious
interrupts.Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit 564c836fd945a94b5dd46597d6b7adb464092650 ]
Commit 930beb5ac09a ("MIPS: introduce MIPS_L1_CACHE_SHIFT_") forgot
to select the correct MIPS_L1_CACHE_SHIFT for SNI RM. This breaks non
coherent DMA because of a wrong allocation alignment.Fixes: 930beb5ac09a ("MIPS: introduce MIPS_L1_CACHE_SHIFT_")
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit 15e9e35cd1dec2bc138464de6bf8ef828df19235 ]
MIPS defines two kvm types:
#define KVM_VM_MIPS_TE 0
#define KVM_VM_MIPS_VZ 1In Documentation/virt/kvm/api.rst it is said that "You probably want to
use 0 as machine type", which implies that type 0 be the "automatic" or
"default" type. And, in user-space libvirt use the null-machine (with
type 0) to detect the kvm capability, which returns "KVM not supported"
on a VZ platform.I try to fix it in QEMU but it is ugly:
https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg05629.htmlAnd Thomas Huth suggests me to change the definition of kvm type:
https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03281.htmlSo I define like this:
#define KVM_VM_MIPS_AUTO 0
#define KVM_VM_MIPS_VZ 1
#define KVM_VM_MIPS_TE 2Since VZ and TE cannot co-exists, using type 0 on a TE platform will
still return success (so old user-space tools have no problems on new
kernels); the advantage is that using type 0 on a VZ platform will not
return failure. So, the only problem is "new user-space tools use type
2 on old kernels", but if we treat this as a kernel bug, we can backport
this patch to old stable kernels.Signed-off-by: Huacai Chen
Message-Id:
Signed-off-by: Paolo Bonzini
Signed-off-by: Sasha Levin
10 Sep, 2020
3 commits
-
[ Upstream commit bb06748207cfb1502d11b90325eba7f8c44c9f02 ]
In cc97ab235f3f ("MIPS: Simplify FP context initialization), init_fp_ctx
just initialize the fp/msa context, and own_fp_inatomic just restore
FCSR and 64bit FP regs from it, but miss MSACSR and upper MSA regs for
MSA, so MSACSR and MSA upper regs's value from previous task on current
cpu can leak into current task and cause unpredictable behavior when MSA
context not initialized.Fixes: cc97ab235f3f ("MIPS: Simplify FP context initialization")
Signed-off-by: Huang Pei
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit e14f633b66902615cf7faa5d032b45ab8b6fb158 ]
The initialization done by bmips_cpu_setup() typically affects both
threads of a given core, on 7435 which supports 2 cores and 2 threads,
logical CPU number 2 and 3 would not run this initialization.Fixes: 738a3f79027b ("MIPS: BMIPS: Add early CPU initialization code")
Signed-off-by: Florian Fainelli
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit dbfc95f98f0158958d1f1e6bf06d74be38dbd821 ]
When the BMIPS generic cpu-feature-overrides.h file was introduced,
cpu_has_inclusive_caches/MIPS_CPU_INCLUSIVE_CACHES was not set for
BMIPS5000 CPUs. Correct this when we have initialized the MIPS secondary
cache successfully.Fixes: f337967d6d87 ("MIPS: BMIPS: Add cpu-feature-overrides.h")
Signed-off-by: Florian Fainelli
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
03 Sep, 2020
1 commit
-
[ Upstream commit a859647b4e6bfeb192284d27d24b6a0c914cae1d ]
Close "fd" before the return of map_vdso() and close "out_file"
in main().Signed-off-by: Peng Fan
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
26 Aug, 2020
2 commits
-
commit fdfe7cbd58806522e799e2a50a15aee7f2cbb7b6 upstream.
The 'flags' field of 'struct mmu_notifier_range' is used to indicate
whether invalidate_range_{start,end}() are permitted to block. In the
case of kvm_mmu_notifier_invalidate_range_start(), this field is not
forwarded on to the architecture-specific implementation of
kvm_unmap_hva_range() and therefore the backend cannot sensibly decide
whether or not to block.Add an extra 'flags' parameter to kvm_unmap_hva_range() so that
architectures are aware as to whether or not they are permitted to block.Cc:
Cc: Marc Zyngier
Cc: Suzuki K Poulose
Cc: James Morse
Signed-off-by: Will Deacon
Message-Id:
Signed-off-by: Paolo Bonzini
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit b1ce9716f3b5ed3b49badf1f003b9e34b7ead0f9 ]
Use 0 as the align parameter in memblock_find_in_range() is
incorrect when we reserve memory for Crash kernel.The environment as follows:
[ 0.000000] MIPS: machine is loongson,loongson64c-4core-rs780e
...
[ 1.951016] crashkernel=64M@128MThe warning as follows:
[ 0.000000] Invalid memory region reserved for crash kernelAnd the iomem as follows:
00200000-0effffff : System RAM
04000000-0484009f : Kernel code
048400a0-04ad7fff : Kernel data
04b40000-05c4c6bf : Kernel bss
1a000000-1bffffff : pci@1a000000
...The align parameter may be finally used by round_down() or round_up().
Like the following call tree:mips-next: mm/memblock.c
memblock_find_in_range
└── memblock_find_in_range_node
├── __memblock_find_range_bottom_up
│ └── round_up
└── __memblock_find_range_top_down
└── round_down
\#define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1)
\#define round_down(x, y) ((x) & ~__round_mask(x, y))
\#define __round_mask(x, y) ((__typeof__(x))((y)-1))The round_down(or round_up)'s second parameter must be a power of 2.
If the second parameter is 0, it both will return 0.Use 1 as the parameter to fix the bug and the iomem as follows:
00200000-0effffff : System RAM
04000000-0484009f : Kernel code
048400a0-04ad7fff : Kernel data
04b40000-05c4c6bf : Kernel bss
08000000-0bffffff : Crash kernel
1a000000-1bffffff : pci@1a000000
...Signed-off-by: Jinyang He
Reviewed-by: Jiaxun Yang
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
21 Aug, 2020
2 commits
-
commit 0889a67a9e7a56ba39af223d536630b20b877fda upstream.
The ROUT (right channel output of audio codec) was connected to INL
(left channel of audio amplifier) instead of INR (right channel of audio
amplifier).Fixes: 8ddebad15e9b ("MIPS: qi_lb60: Migrate to devicetree")
Cc: stable@vger.kernel.org # v5.3
Signed-off-by: Paul Cercueil
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Greg Kroah-Hartman -
commit 9cce844abf07b683cff5f0273977d5f8d0af94c7 upstream.
Now CPU#0 is not hotpluggable on MIPS, so prevent to create /sys/devices
/system/cpu/cpu0/online which confuses some user-space tools.Cc: stable@vger.kernel.org
Signed-off-by: Huacai Chen
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Greg Kroah-Hartman
19 Aug, 2020
2 commits
-
commit ec0160891e387f4771f953b888b1fe951398e5d9 upstream.
Commit 711419e504eb ("irqdomain: Add the missing assignment of
domain->fwnode for named fwnode") unintentionally caused a dangling pointer
page fault issue on firmware nodes that were freed after IRQ domain
allocation. Commit e3beca48a45b fixed that dangling pointer issue by only
freeing the firmware node after an IRQ domain allocation failure. That fix
no longer frees the firmware node immediately, but leaves the firmware node
allocated after the domain is removed.The firmware node must be kept around through irq_domain_remove, but should be
freed it afterwards.Add the missing free operations after domain removal where where appropriate.
Fixes: e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated")
Signed-off-by: Jon Derrick
Signed-off-by: Thomas Gleixner
Reviewed-by: Andy Shevchenko
Acked-by: Bjorn Helgaas # drivers/pci
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1595363169-7157-1-git-send-email-jonathan.derrick@intel.com
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit e8b9fc10f2615b9a525fce56981e40b489528355 ]
if of_find_device_by_node() succeed, dwc3_octeon_device_init() doesn't have
a corresponding put_device(). Thus add put_device() to fix the exception
handling for this function implementation.Fixes: 93e502b3c2d4 ("MIPS: OCTEON: Platform support for OCTEON III USB controller")
Signed-off-by: Yu Kuai
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
29 Jul, 2020
1 commit
-
[ Upstream commit e3beca48a45b5e0e6e6a4e0124276b8248dcc9bb ]
Quite some non OF/ACPI users of irqdomains allocate firmware nodes of type
IRQCHIP_FWNODE_NAMED or IRQCHIP_FWNODE_NAMED_ID and free them right after
creating the irqdomain. The only purpose of these FW nodes is to convey
name information. When this was introduced the core code did not store the
pointer to the node in the irqdomain. A recent change stored the firmware
node pointer in irqdomain for other reasons and missed to notice that the
usage sites which do the alloc_fwnode/create_domain/free_fwnode sequence
are broken by this. Storing a dangling pointer is dangerous itself, but in
case that the domain is destroyed later on this leads to a double free.Remove the freeing of the firmware node after creating the irqdomain from
all affected call sites to cure this.Fixes: 711419e504eb ("irqdomain: Add the missing assignment of domain->fwnode for named fwnode")
Reported-by: Andy Shevchenko
Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
Acked-by: Marc Zyngier
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/873661qakd.fsf@nanos.tec.linutronix.de
Signed-off-by: Sasha Levin
22 Jul, 2020
1 commit
-
[ Upstream commit 679b2ec8e060ca7a90441aff5e7d384720a41b76 ]
This kernel configuration is basically enabling/disabling sr driver quirks
detection. While these quirks are for fairly rare devices (very old CD
burners, and a glucometer), the additional detection of these models is a
very minimal amount of code.The logic behind the quirks is always built into the sr driver.
This also removes the config from all the defconfig files that are enabling
this already.Link: https://lore.kernel.org/r/20200223191144.726-1-flameeyes@flameeyes.com
Reviewed-by: Jens Axboe
Signed-off-by: Diego Elio Pettenò
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
09 Jul, 2020
2 commits
-
commit fcec538ef8cca0ad0b84432235dccd9059c8e6f8 upstream.
This resolves the hazard between the mtc0 in the change_c0_status() and
the mfc0 in configure_exception_vector(). Without resolving this hazard
configure_exception_vector() could read an old value and would restore
this old value again. This would revert the changes change_c0_status()
did. I checked this by printing out the read_c0_status() at the end of
per_cpu_trap_init() and the ST0_MX is not set without this patch.The hazard is documented in the MIPS Architecture Reference Manual Vol.
III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev
6.03 table 8.1 which includes:Producer | Consumer | Hazard
----------|----------|----------------------------
mtc0 | mfc0 | any coprocessor 0 registerI saw this hazard on an Atheros AR9344 rev 2 SoC with a MIPS 74Kc CPU.
There the change_c0_status() function would activate the DSPen by
setting ST0_MX in the c0_status register. This was reverted and then the
system got a DSP exception when the DSP registers were saved in
save_dsp() in the first process switch. The crash looks like this:[ 0.089999] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.097796] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.107070] Kernel panic - not syncing: Unexpected DSP exception
[ 0.113470] Rebooting in 1 seconds..We saw this problem in OpenWrt only on the MIPS 74Kc based Atheros SoCs,
not on the 24Kc based SoCs. We only saw it with kernel 5.4 not with
kernel 4.19, in addition we had to use GCC 8.4 or 9.X, with GCC 8.3 it
did not happen.In the kernel I bisected this problem to commit 9012d011660e ("compiler:
allow all arches to enable CONFIG_OPTIMIZE_INLINING"), but when this was
reverted it also happened after commit 172dcd935c34b ("MIPS: Always
allocate exception vector for MIPSr2+").Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.")
does similar changes to a different file. I am not sure if there are
more places affected by this problem.Signed-off-by: Hauke Mehrtens
Cc:
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Greg Kroah-Hartman -
commit 03e62fd67d3ab33f39573fc8787d89dc9b4d7255 upstream.
The dt-bindings for the GSWIP describe that the node should be named
"switch". Use the same name in sysctrl.c so the GSWIP driver can
actually find the "gphy0" and "gphy1" clocks.Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: stable@vger.kernel.org
Signed-off-by: Martin Blumenstingl
Acked-by: Hauke Mehrtens
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Greg Kroah-Hartman
22 Jun, 2020
9 commits
-
[ Upstream commit 31e1b3efa802f97a17628dde280006c4cee4ce5e ]
Register "a1" is unsaved in this function,
when CONFIG_TRACE_IRQFLAGS is enabled,
the TRACE_IRQS_OFF macro will call trace_hardirqs_off(),
and this may change register "a1".
The changed register "a1" as argument will be send
to do_fpe() and do_msa_fpe().Signed-off-by: YuanJunQing
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit f33a0b941017b9cb5a4e975af198b855b2f2b455 ]
There is a file descriptor resource leak in elf-entry.c, fix this
by adding fclose() before return and die.Signed-off-by: Kaige Li
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit ed26aacfb5f71eecb20a51c4467da440cb719d66 ]
Loops-per-jiffies is a special number which represents a number of
noop-loop cycles per CPU-scheduler quantum - jiffies. As you
understand aside from CPU-specific implementation it depends on
the CPU frequency. So when a platform has the CPU frequency fixed,
we have no problem and the current udelay interface will work
just fine. But as soon as CPU-freq driver is enabled and the cores
frequency changes, we'll end up with distorted udelay's. In order
to fix this we have to accordinly adjust the per-CPU udelay_val
(the same as the global loops_per_jiffy) number. This can be done
in the CPU-freq transition event handler. We subscribe to that event
in the MIPS arch time-inititalization method.Co-developed-by: Alexey Malahov
Signed-off-by: Alexey Malahov
Signed-off-by: Serge Semin
Reviewed-by: Jiaxun Yang
Cc: Thomas Bogendoerfer
Cc: Paul Burton
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit bbb5946eb545fab8ad8f46bce8a803e1c0c39d47 ]
Indeed according to the MIPS32 Privileged Resource Architecgture the MAAR
pair register address field either takes [12:31] bits for non-XPA systems
and [12:55] otherwise. In any case the current address mask is just
wrong for 64-bit and 32-bits XPA chips. So lets extend it to 59-bits
of physical address value. This shall cover the 64-bits architecture and
systems with XPA enabled, and won't cause any problem for non-XPA 32-bit
systems, since address values exceeding the architecture specific MAAR
mask will be just truncated with setting zeros in the unsupported upper
bits.Co-developed-by: Alexey Malahov
Signed-off-by: Alexey Malahov
Signed-off-by: Serge Semin
Cc: Thomas Bogendoerfer
Cc: Paul Burton
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit 8a0efb8b101665a843205eab3d67ab09cb2d9a8d ]
Commit 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache
errors") adds cm2_causes[] array with map of error type ID and
pointers to the short description string. There is a mistake in
the table, since according to MIPS32 manual CM2_ERROR_TYPE = {17,18}
correspond to INTVN_WR_ERR and INTVN_RD_ERR, while the table
claims they have {0x17,0x18} codes. This is obviously hex-dec
copy-paste bug. Moreover codes {0x18 - 0x1a} indicate L2 ECC errors.Fixes: 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache errors")
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Paul Burton
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: linux-pm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit ff487d41036035376e47972c7c522490b839ab37 ]
LLD failed to link vmlinux with 64bit load address for 32bit ELF
while bfd will strip 64bit address into 32bit silently.
To fix LLD build, we should truncate load address provided by platform
into 32bit for 32bit kernel.Signed-off-by: Jiaxun Yang
Link: https://github.com/ClangBuiltLinux/linux/issues/786
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
Reviewed-by: Fangrui Song
Reviewed-by: Kees Cook
Tested-by: Nathan Chancellor
Cc: Maciej W. Rozycki
Tested-by: Nick Desaulniers
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit 269b3a9ac538c4ae87f84be640b9fa89914a2489 ]
In the current code, if CONFIG_SWIOTLB is set, when failed to get IO TLB
memory from the low pages by plat_swiotlb_setup(), it may lead to the boot
process failed with kernel panic.(1) On the Loongson and SiByte platform
arch/mips/loongson64/dma.c
arch/mips/sibyte/common/dma.c
void __init plat_swiotlb_setup(void)
{
swiotlb_init(1);
}kernel/dma/swiotlb.c
void __init
swiotlb_init(int verbose)
{
...
vstart = memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose))
return;
...
pr_warn("Cannot allocate buffer");
no_iotlb_memory = true;
}phys_addr_t swiotlb_tbl_map_single()
{
...
if (no_iotlb_memory)
panic("Can not allocate SWIOTLB buffer earlier ...");
...
}(2) On the Cavium OCTEON platform
arch/mips/cavium-octeon/dma-octeon.c
void __init plat_swiotlb_setup(void)
{
...
octeon_swiotlb = memblock_alloc_low(swiotlbsize, PAGE_SIZE);
if (!octeon_swiotlb)
panic("%s: Failed to allocate %zu bytes align=%lx\n",
__func__, swiotlbsize, PAGE_SIZE);
...
}Because IO_TLB_DEFAULT_SIZE is 64M, if the rest size of low memory is less
than 64M when call plat_swiotlb_setup(), we can easily reproduce the panic
case.In order to reduce the possibility of kernel panic when failed to get IO
TLB memory under CONFIG_SWIOTLB, it is better to allocate low memory as
small as possible before plat_swiotlb_setup(), so make sparse_init() using
top-down allocation.Reported-by: Juxin Gao
Co-developed-by: Juxin Gao
Signed-off-by: Juxin Gao
Signed-off-by: Tiezhu Yang
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit a2ac81c6ef4018ea49c034ce165bb9ea1cf99f3e ]
Commit 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA
allows") updated the cpu_has_mips* macro to be replaced with a constant
expression where it's possible. By mistake it wasn't done correctly
for cpu_has_mips64r1/cpu_has_mips64r2 macro. They are defined to
be replaced with conditional expression __isa_range_or_flag(), which
means either ISA revision being within the range or the corresponding
CPU options flag was set at the probe stage or both being true at the
same time. But the ISA level value doesn't indicate whether the ISA is
MIPS32 or MIPS64. Due to this if we select MIPS32r1 - MIPS32r5
architectures the __isa_range() macro will activate the
cpu_has_mips64rX flags, which is incorrect. In order to fix the
problem we make sure the 64bits CPU support is enabled by means of
checking the flag cpu_has_64bits aside with proper ISA range and specific
Revision flag being set.Fixes: 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA allows")
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Paul Burton
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin -
[ Upstream commit a44de7497f91834df0b8b6d459e259788ba66794 ]
When ATI Radeon GPU driver has been compiled directly into the kernel
instead of as a module, we should make sure the firmware for the model
(check available ones in /lib/firmware/radeon) is built-in to the kernel
as well, otherwise there exists the following fatal error during GPU init,
change CONFIG_DRM_RADEON=y to CONFIG_DRM_RADEON=m to fix it.[ 1.900997] [drm] Loading RS780 Microcode
[ 1.905077] radeon 0000:01:05.0: Direct firmware load for radeon/RS780_pfp.bin failed with error -2
[ 1.914140] r600_cp: Failed to load firmware "radeon/RS780_pfp.bin"
[ 1.920405] [drm:r600_init] *ERROR* Failed to load firmware!
[ 1.926069] radeon 0000:01:05.0: Fatal error during GPU init
[ 1.931729] [drm] radeon: finishing device.Fixes: 024e6a8b5bb1 ("MIPS: Loongson: Add a Loongson-3 default config file")
Signed-off-by: Tiezhu Yang
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
17 Jun, 2020
2 commits
-
commit 5816c76dea116a458f1932eefe064e35403248eb upstream.
If a CPU support more than 32bit vmbits (which is true for 64bit CPUs),
VPN2_MASK set to fixed 0xffffe000 will lead to a wrong EntryHi in some
functions such as _kvm_mips_host_tlb_inv().The cpu_vmbits definition of 32bit CPU in cpu-features.h is 31, so we
still use the old definition.Cc: Stable
Reviewed-by: Aleksandar Markovic
Signed-off-by: Xing Li
[Huacai: Improve commit messages]
Signed-off-by: Huacai Chen
Message-Id:
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit fe2b73dba47fb6d6922df1ad44e83b1754d5ed4d upstream.
The code in decode_config4() of arch/mips/kernel/cpu-probe.c
asid_mask = MIPS_ENTRYHI_ASID;
if (config4 & MIPS_CONF4_AE)
asid_mask |= MIPS_ENTRYHI_ASIDX;
set_cpu_asid_mask(c, asid_mask);set asid_mask to cpuinfo->asid_mask.
So in order to support variable ASID_MASK, KVM_ENTRYHI_ASID should also
be changed to cpu_asid_mask(&boot_cpu_data).Cc: Stable #4.9+
Reviewed-by: Aleksandar Markovic
Signed-off-by: Xing Li
[Huacai: Change current_cpu_data to boot_cpu_data for optimization]
Signed-off-by: Huacai Chen
Message-Id:
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman
17 Apr, 2020
2 commits
-
commit 792a402c2840054533ef56279c212ef6da87d811 upstream.
There is a potential NULL pointer dereference in case kzalloc()
fails and returns NULL.Fix this by adding a NULL check on *cd*
This bug was detected with the help of Coccinelle.
Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Greg Kroah-Hartman -
commit d191aaffe3687d1e73e644c185f5f0550ec242b5 upstream.
LDDIR/LDPTE is Loongson-3's acceleration for Page Table Walking. If BD
(Base Directory, the 4th page directory) is not enabled, then GDOffset
is biased by BadVAddr[63:62]. So, if GDOffset (aka. BadVAddr[47:36] for
Loongson-3) is big enough, "0b11(BadVAddr[63:62])|BadVAddr[47:36]|...."
can far beyond pg_swapper_dir. This means the pg_swapper_dir may NOT be
accessed by LDDIR correctly, so fix it by set PWDirExt in CP0_PWCtl.Cc:
Signed-off-by: Pei Huang
Signed-off-by: Huacai Chen
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Greg Kroah-Hartman
05 Mar, 2020
1 commit
-
commit bef8e2dfceed6daeb6ca3e8d33f9c9d43b926580 upstream.
Pointer on the memory allocated by 'alloc_progmem()' is stored in
'v->load_addr'. So this is this memory that should be freed by
'release_progmem()'.'release_progmem()' is only a call to 'kfree()'.
With the current code, there is both a double free and a memory leak.
Fix it by passing the correct pointer to 'release_progmem()'.Fixes: e01402b115ccc ("More AP / SP bits for the 34K, the Malta bits and things. Still wants")
Signed-off-by: Christophe JAILLET
Signed-off-by: Paul Burton
Cc: ralf@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
24 Feb, 2020
1 commit
-
[ Upstream commit 72d052e28d1d2363f9107be63ef3a3afdea6143c ]
If kzalloc fails, it should return -ENOMEM, otherwise may trigger a NULL
pointer dereference.Fixes: 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface")
Signed-off-by: Tiezhu Yang
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: Huacai Chen
Cc: Jiaxun Yang
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin
11 Feb, 2020
3 commits
-
commit 16202c09577f3d0c533274c0410b7de05fb0d458 upstream.
Commit 92b34a976348 ("MIPS: boot: add missing targets for vmlinux.*.its")
fixed constant rebuild of *.its files on every make invocation, but due
to typo ("lzmo") it made no sense for vmlinux.lzma.its.Fixes: 92b34a976348 ("MIPS: boot: add missing targets for vmlinux.*.its")
Cc: # v4.19+
Signed-off-by: Alexander Lobakin
[paulburton@kernel.org: s/invokation/invocation/]
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: James Hogan
Cc: Masahiro Yamada
Cc: Rob Herring
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit a53998802e178451701d59d38e36f551422977ba upstream.
quiet_cmd_relocs lacks a whitespace which results in:
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
RELOCS vmlinux
Building modules, stage 2.
MODPOST 64 modulesAfter this patch:
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
RELOCS vmlinux
Building modules, stage 2.
MODPOST 64 modulesTypo is present in kernel tree since the introduction of relocatable
kernel support in commit e818fac595ab ("MIPS: Generate relocation table
when CONFIG_RELOCATABLE"), but the relocation scripts were moved to
Makefile.postlink later with commit 44079d3509ae ("MIPS: Use
Makefile.postlink to insert relocations into vmlinux").Fixes: 44079d3509ae ("MIPS: Use Makefile.postlink to insert relocations into vmlinux")
Cc: # v4.11+
Signed-off-by: Alexander Lobakin
[paulburton@kernel.org: Fixup commit references in commit message.]
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: James Hogan
Cc: Masahiro Yamada
Cc: Rob Herring
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 4f29ad200f7b40fbcf73cd65f95087535ba78380 upstream.
It also lacks a whitespace (copy'n'paste error?) and also messes up the
output:SYSHDR arch/mips/include/generated/uapi/asm/unistd_n32.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_n64.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_o32.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n32.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n64.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_o32.h
WRAP arch/mips/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/mips/include/generated/uapi/asm/ipcbuf.hAfter:
SYSHDR arch/mips/include/generated/uapi/asm/unistd_n32.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_n64.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_o32.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n32.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n64.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_o32.h
WRAP arch/mips/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/mips/include/generated/uapi/asm/ipcbuf.hPresent since day 0 of syscall table generation introduction for MIPS.
Fixes: 9bcbf97c6293 ("mips: add system call table generation support")
Cc: # v5.0+
Signed-off-by: Alexander Lobakin
Signed-off-by: Paul Burton
Cc: Ralf Baechle
Cc: James Hogan
Cc: Masahiro Yamada
Cc: Rob Herring
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
18 Jan, 2020
4 commits
-
[ Upstream commit a4a3893114a41e365274d5fab5d9ff5acc235ff0 ]
__sanitizer_cov_trace_pc() is not linked in and causing link
failure if KCOV_INSTRUMENT is enabled. Fix this by disabling
instrumentation for compressed image.Signed-off-by: Jouni Hogander
Signed-off-by: Paul Burton
Cc: Lukas Bulwahn
Cc: linux-mips@vger.kernel.org
Signed-off-by: Sasha Levin -
[ Upstream commit 7d2aa4bb90f5f6f1b8de8848c26042403f2d7bf9 ]
The libc provides a discovery mechanism for vDSO library and its
symbols. When a symbol is not exposed by the vDSOs the libc falls back
on the system calls.With the introduction of the unified vDSO library on mips this behavior
is not honored anymore by the kernel in the case of gettimeofday().The issue has been noticed and reported due to a dhclient failure on the
CI20 board:root@letux:~# dhclient
../../../../lib/isc/unix/time.c:200: Operation not permitted
root@letux:~#Restore the original behavior fixing gettimeofday() in the vDSO library.
Reported-by: H. Nikolaus Schaller
Tested-by: H. Nikolaus Schaller # CI20 with JZ4780
Signed-off-by: Vincenzo Frascino
Signed-off-by: Paul Burton
Cc: mips-creator-ci20-dev@googlegroups.com
Cc: letux-kernel@openphoenux.org
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin -
[ Upstream commit 3b1313eb32c499d46dc4c3e896d19d9564c879c4 ]
Report L1 caches as shared per core; L2 - per cluster.
This fixes "perf" that went crazy if shared_cpu_map attribute not
reported on sysfs, in form of/sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_list
/sys/devices/system/cpu/cpu*/cache/index*/shared_cpu_mapSigned-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
Signed-off-by: Sasha Levin -
commit e3d765a941f6130fd94e47b2064cfee71f4cbadd upstream.
If number of CPUs are limited by the kernel commandline parameter nr_cpus
assignment of interrupts accourding to numa rules might not be possibe.
As a fallback use one of the online CPUs as interrupt destination.Fixes: 69a07a41d908 ("MIPS: SGI-IP27: rework HUB interrupts")
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: Greg Kroah-Hartman
