05 Aug, 2020
4 commits
-
commit 4a601da92c2a782e5c022680d476104586b74994 upstream.
The current pin muxing scheme muxes GPIO_1 pad for USB_OTG_ID
because of which when card is inserted, usb otg is enumerated
and the card is never detected.[ 64.492645] cfg80211: failed to load regulatory.db
[ 64.492657] imx-sdma 20ec000.sdma: external firmware not found, using ROM firmware
[ 76.343711] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 76.349742] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 2
[ 76.388862] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[ 76.396650] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08
[ 76.405412] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 76.412763] usb usb2: Product: EHCI Host Controller
[ 76.417666] usb usb2: Manufacturer: Linux 5.8.0-rc1-next-20200618 ehci_hcd
[ 76.424623] usb usb2: SerialNumber: ci_hdrc.0
[ 76.431755] hub 2-0:1.0: USB hub found
[ 76.435862] hub 2-0:1.0: 1 port detectedThe TRM mentions GPIO_1 pad should be muxed/assigned for card detect
and ENET_RX_ER pad for USB_OTG_ID for proper operation.This patch fixes pin muxing as per TRM and is tested on a
i.Core 1.5 MX6 DL SOM.[ 22.449165] mmc0: host does not support reading read-only switch, assuming write-enable
[ 22.459992] mmc0: new high speed SDHC card at address 0001
[ 22.469725] mmcblk0: mmc0:0001 EB1QT 29.8 GiB
[ 22.478856] mmcblk0: p1 p2Fixes: 6df11287f7c9 ("ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support")
Cc: stable@vger.kernel.org
Signed-off-by: Michael Trimarchi
Signed-off-by: Suniel Mahesh
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman -
commit c696afd331be1acb39206aba53048f2386b781fc upstream.
Commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") fixed the
phy-mode for fec1, but missed to fix it for the fec2 node.Fix fec2 to also use "rgmii-id" as the phy-mode.
Cc:
Fixes: 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")
Signed-off-by: Fabio Estevam
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman -
commit d36f260718d83928e6012247a7e1b9791cdb12ff upstream.
Commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") fixed the
phy-mode for fec1, but missed to fix it for the fec2 node.Fix fec2 to also use "rgmii-id" as the phy-mode.
Cc:
Fixes: 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")
Signed-off-by: Fabio Estevam
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman -
commit eec13b42d41b0f3339dcf0c4da43734427c68620 upstream.
Unprivileged memory accesses generated by the so-called "translated"
instructions (e.g. LDRT) in kernel mode can cause user watchpoints to fire
unexpectedly. In such cases, the hw_breakpoint logic will invoke the user
overflow handler which will typically raise a SIGTRAP back to the current
task. This is futile when returning back to the kernel because (a) the
signal won't have been delivered and (b) userspace can't handle the thing
anyway.Avoid invoking the user overflow handler for watchpoints triggered by
kernel uaccess routines, and instead single-step over the faulting
instruction as we would if no overflow handler had been installed.Cc:
Fixes: f81ef4a920c8 ("ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework")
Reported-by: Luis Machado
Tested-by: Luis Machado
Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman
29 Jul, 2020
11 commits
-
commit de2b41be8fcccb2f5b6c480d35df590476344201 upstream.
On x86-32 the idt_table with 256 entries needs only 2048 bytes. It is
page-aligned, but the end of the .bss..page_aligned section is not
guaranteed to be page-aligned.As a result, objects from other .bss sections may end up on the same 4k
page as the idt_table, and will accidentially get mapped read-only during
boot, causing unexpected page-faults when the kernel writes to them.This could be worked around by making the objects in the page aligned
sections page sized, but that's wrong.Explicit sections which store only page aligned objects have an implicit
guarantee that the object is alone in the page in which it is placed. That
works for all objects except the last one. That's inconsistent.Enforcing page sized objects for these sections would wreckage memory
sanitizers, because the object becomes artificially larger than it should
be and out of bound access becomes legit.Align the end of the .bss..page_aligned and .data..page_aligned section on
page-size so all objects places in these sections are guaranteed to have
their own page.[ tglx: Amended changelog ]
Signed-off-by: Joerg Roedel
Signed-off-by: Thomas Gleixner
Reviewed-by: Kees Cook
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20200721093448.10417-1-joro@8bytes.org
Signed-off-by: Greg Kroah-Hartman -
commit be6577af0cef934ccb036445314072e8cb9217b9 upstream.
Stalls are quite frequent with recent kernels. I enabled
CONFIG_SOFTLOCKUP_DETECTOR and I caught the following stall:watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [cc1:22803]
CPU: 0 PID: 22803 Comm: cc1 Not tainted 5.6.17+ #3
Hardware name: 9000/800/rp3440
IAOQ[0]: d_alloc_parallel+0x384/0x688
IAOQ[1]: d_alloc_parallel+0x388/0x688
RP(r2): d_alloc_parallel+0x134/0x688
Backtrace:
[] __lookup_slow+0xa4/0x200
[] walk_component+0x288/0x458
[] path_lookupat+0x88/0x198
[] filename_lookup+0xa0/0x168
[] user_path_at_empty+0x64/0x80
[] vfs_statx+0x104/0x158
[] __do_sys_lstat64+0x44/0x80
[] sys_lstat64+0x20/0x38
[] syscall_exit+0x0/0x14The code was stuck in this loop in d_alloc_parallel:
4037d414: 0e 00 10 dc ldd 0(r16),ret0
4037d418: c7 fc 5f ed bb,< ret0,1f,4037d414
4037d41c: 08 00 02 40 nopThis is the inner loop of bit_spin_lock which is called by hlist_bl_unlock in
d_alloc_parallel:static inline void bit_spin_lock(int bitnum, unsigned long *addr)
{
/*
* Assuming the lock is uncontended, this never enters
* the body of the outer loop. If it is contended, then
* within the inner loop a non-atomic test is used to
* busywait with less bus contention for a good time to
* attempt to acquire the lock bit.
*/
preempt_disable();
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
while (unlikely(test_and_set_bit_lock(bitnum, addr))) {
preempt_enable();
do {
cpu_relax();
} while (test_bit(bitnum, addr));
preempt_disable();
}
#endif
__acquire(bitlock);
}After consideration, I realized that we must be losing bit unlocks.
Then, I noticed that we missed defining atomic64_set_release().
Adding this define fixes the stalls in bit operations.Signed-off-by: Dave Anglin
Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 38b7c2a3ffb1fce8358ddc6006cfe5c038ff9963 ]
While digging through the recent mmiowb preemption issue it came up that
we aren't actually preventing IO from crossing a scheduling boundary.
While it's a bit ugly to overload smp_mb__after_spinlock() with this
behavior, it's what PowerPC is doing so there's some precedent.Signed-off-by: Palmer Dabbelt
Signed-off-by: Sasha Levin -
[ Upstream commit 81e96851ea32deb2c921c870eecabf335f598aeb ]
The clang integrated assembler requires the 'cmp' instruction to
have a length prefix here:arch/x86/math-emu/wm_sqrt.S:212:2: error: ambiguous instructions require an explicit suffix (could be 'cmpb', 'cmpw', or 'cmpl')
cmp $0xffffffff,-24(%ebp)
^Make this a 32-bit comparison, which it was clearly meant to be.
Signed-off-by: Arnd Bergmann
Signed-off-by: Thomas Gleixner
Reviewed-by: Nick Desaulniers
Link: https://lkml.kernel.org/r/20200527135352.1198078-1-arnd@arndb.de
Signed-off-by: Sasha Levin -
[ Upstream commit 5afc78551bf5d53279036e0bf63314e35631d79f ]
Rather than open-code test_tsk_thread_flag() at each callsite, simply
replace the couple of offenders with calls to test_tsk_thread_flag()
directly.Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin -
[ Upstream commit ed3e98e919aaaa47e9d9f8a40c3f6f4a22577842 ]
Instead, expose the key via the input framework, as SW_MACHINE_COVER
The chip-detect GPIO is actually detecting if the cover is closed.
Technically it's possible to use the SD card with open cover. The
only downside is risk of battery falling out and user being able
to physically remove the card.The behaviour of SD card not being available when the device is
open is unexpected and creates more problems than it solves. There
is a high chance, that more people accidentally break their rootfs
by opening the case without physically removing the card.Reviewed-by: Sebastian Reichel
Acked-by: Tony Lindgren
Signed-off-by: Merlijn Wajer
Link: https://lore.kernel.org/r/20200612125402.18393-3-merlijn@wizzup.org
Signed-off-by: Dmitry Torokhov
Signed-off-by: Sasha Levin -
[ Upstream commit 4237c625304b212a3f30adf787901082082511ec ]
The audio codec on the GW551x routes to ssi1. It fixes audio capture on
the device.Cc: stable@vger.kernel.org
Fixes: 3117e851cef1 ("ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x")
Signed-off-by: Tim Harvey
Signed-off-by: Shawn Guo
Signed-off-by: Sasha Levin -
[ Upstream commit e52928e8d5c1c4837a0c6ec2068beea99defde8b ]
According to Documentation/devicetree/bindings/sound/simple-card.txt
the 'simple-audio-card,dai-link' may be omitted when the card has
only one DAI link, which is the case here.Get rid of 'simple-audio-card,dai-link' in order to fix the following
build warning with W=1:arch/arm/boot/dts/imx6qdl-gw551x.dtsi:109.32-121.5: Warning (unit_address_vs_reg): /sound-digital/simple-audio-card,dai-link@0: node has a unit name, but no reg property
Cc: Tim Harvey
Signed-off-by: Fabio Estevam
Signed-off-by: Shawn Guo
Signed-off-by: Sasha Levin -
[ 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 -
[ Upstream commit 0d5ab144429e8bd80889b856a44d56ab4a5cd59b ]
Increment *pos in the cpuinfo_op.next to fix the following warning
triggered by cat /proc/cpuinfo:seq_file: buggy .next function c_next did not update position index
Signed-off-by: Max Filippov
Signed-off-by: Sasha Levin -
[ Upstream commit 73f9941306d5ce030f3ffc7db425c7b2a798cf8e ]
Building xtensa kernel with gcc-10 produces the following warnings:
arch/xtensa/kernel/xtensa_ksyms.c:90:15: warning: conflicting types
for built-in function ‘__sync_fetch_and_and_4’;
expected ‘unsigned int(volatile void *, unsigned int)’
[-Wbuiltin-declaration-mismatch]
arch/xtensa/kernel/xtensa_ksyms.c:96:15: warning: conflicting types
for built-in function ‘__sync_fetch_and_or_4’;
expected ‘unsigned int(volatile void *, unsigned int)’
[-Wbuiltin-declaration-mismatch]Fix declarations of these functions to avoid the warning.
Signed-off-by: Max Filippov
Signed-off-by: Sasha Levin
22 Jul, 2020
25 commits
-
commit baedb87d1b53532f81b4bd0387f83b05d4f7eb9a upstream.
Setting interrupt affinity on inactive interrupts is inconsistent when
hierarchical irq domains are enabled. The core code should just store the
affinity and not call into the irq chip driver for inactive interrupts
because the chip drivers may not be in a state to handle such requests.X86 has a hacky workaround for that but all other irq chips have not which
causes problems e.g. on GIC V3 ITS.Instead of adding more ugly hacks all over the place, solve the problem in
the core code. If the affinity is set on an inactive interrupt then:- Store it in the irq descriptors affinity mask
- Update the effective affinity to reflect that so user space has
a consistent view
- Don't call into the irq chip driverThis is the core equivalent of the X86 workaround and works correctly
because the affinity setting is established in the irq chip when the
interrupt is activated later on.Note, that this is only effective when hierarchical irq domains are enabled
by the architecture. Doing it unconditionally would break legacy irq chip
implementations.For hierarchial irq domains this works correctly as none of the drivers can
have a dependency on affinity setting in inactive state by design.Remove the X86 workaround as it is not longer required.
Fixes: 02edee152d6e ("x86/apic/vector: Ignore set_affinity call for inactive interrupts")
Reported-by: Ali Saidi
Signed-off-by: Thomas Gleixner
Tested-by: Ali Saidi
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200529015501.15771-1-alisaidi@amazon.com
Link: https://lkml.kernel.org/r/877dv2rv25.fsf@nanos.tec.linutronix.de
Signed-off-by: Greg Kroah-Hartman -
commit 15956689a0e60aa0c795174f3c310b60d8794235 upstream.
Although we zero the upper bits of x0 on entry to the kernel from an
AArch32 task, we do not clear them on the exception return path and can
therefore expose 64-bit sign extended syscall return values to userspace
via interfaces such as the 'perf_regs' ABI, which deal exclusively with
64-bit registers.Explicitly clear the upper 32 bits of x0 on return from a compat system
call.Cc:
Cc: Mark Rutland
Cc: Keno Fischer
Cc: Luis Machado
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit ac2081cdc4d99c57f219c1a6171526e0fa0a6fff upstream.
Although the arm64 single-step state machine can be fast-forwarded in
cases where we wish to generate a SIGTRAP without actually executing an
instruction, this has two major limitations outside of simply skipping
an instruction due to emulation.1. Stepping out of a ptrace signal stop into a signal handler where
SIGTRAP is blocked. Fast-forwarding the stepping state machine in
this case will result in a forced SIGTRAP, with the handler reset to
SIG_DFL.2. The hardware implicitly fast-forwards the state machine when executing
an SVC instruction for issuing a system call. This can interact badly
with subsequent ptrace stops signalled during the execution of the
system call (e.g. SYSCALL_EXIT or seccomp traps), as they may corrupt
the stepping state by updating the PSTATE for the tracee.Resolve both of these issues by injecting a pseudo-singlestep exception
on entry to a signal handler and also on return to userspace following a
system call.Cc:
Cc: Mark Rutland
Tested-by: Luis Machado
Reported-by: Keno Fischer
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 3a5a4366cecc25daa300b9a9174f7fdd352b9068 upstream.
Luis reports that, when reverse debugging with GDB, single-step does not
function as expected on arm64:| I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP
| request by GDB won't execute the underlying instruction. As a consequence,
| the PC doesn't move, but we return a SIGTRAP just like we would for a
| regular successful PTRACE_SINGLESTEP request.The underlying problem is that when the CPU register state is restored
as part of a reverse step, the SPSR.SS bit is cleared and so the hardware
single-step state can transition to the "active-pending" state, causing
an unexpected step exception to be taken immediately if a step operation
is attempted.In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate
accessible by the GPR regset, but it's a bit late for that now. Instead,
simply prevent userspace from configuring the bit to a value which is
inconsistent with the TIF_SINGLESTEP state for the task being traced.Cc:
Cc: Mark Rutland
Cc: Keno Fischer
Link: https://lore.kernel.org/r/1eed6d69-d53d-9657-1fc9-c089be07f98c@linaro.org
Reported-by: Luis Machado
Tested-by: Luis Machado
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit b710d27bf72068b15b2f0305d825988183e2ff28 upstream.
Early secure guest boot hits the below crash while booting with
vcpus numbers aligned with page boundary for PAGE size of 64k
and LPPACA size of 1k i.e 64, 128 etc.Partition configured for 64 cpus.
CPU maps initialized for 1 thread per core
------------[ cut here ]------------
kernel BUG at arch/powerpc/kernel/paca.c:89!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeriesThis is due to the BUG_ON() for shared_lppaca_total_size equal to
shared_lppaca_size. Instead the code should only BUG_ON() if we have
exceeded the total_size, which indicates we've overflowed the array.Fixes: bd104e6db6f0 ("powerpc/pseries/svm: Use shared memory for LPPACA structures")
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Satheesh Rajendran
Reviewed-by: Laurent Dufour
Reviewed-by: Thiago Jung Bauermann
[mpe: Reword change log to clarify we're fixing not removing the check]
Signed-off-by: Michael Ellerman
Link: https://lore.kernel.org/r/20200619070113.16696-1-sathnaga@linux.vnet.ibm.com
Signed-off-by: Greg Kroah-Hartman -
commit 192b6a780598976feb7321ff007754f8511a4129 upstream.
Even if the IAMR value denies execute access, the current code returns
true from pkey_access_permitted() for an execute permission check, if
the AMR read pkey bit is cleared.This results in repeated page fault loop with a test like below:
#define _GNU_SOURCE
#include
#include
#include
#include
#include#include
#include
#include
#include
#include#ifdef SYS_pkey_mprotect
#undef SYS_pkey_mprotect
#endif#ifdef SYS_pkey_alloc
#undef SYS_pkey_alloc
#endif#ifdef SYS_pkey_free
#undef SYS_pkey_free
#endif#undef PKEY_DISABLE_EXECUTE
#define PKEY_DISABLE_EXECUTE 0x4#define SYS_pkey_mprotect 386
#define SYS_pkey_alloc 384
#define SYS_pkey_free 385#define PPC_INST_NOP 0x60000000
#define PPC_INST_BLR 0x4e800020
#define PROT_RWX (PROT_READ | PROT_WRITE | PROT_EXEC)static int sys_pkey_mprotect(void *addr, size_t len, int prot, int pkey)
{
return syscall(SYS_pkey_mprotect, addr, len, prot, pkey);
}static int sys_pkey_alloc(unsigned long flags, unsigned long access_rights)
{
return syscall(SYS_pkey_alloc, flags, access_rights);
}static int sys_pkey_free(int pkey)
{
return syscall(SYS_pkey_free, pkey);
}static void do_execute(void *region)
{
/* jump to region */
asm volatile(
"mtctr %0;"
"bctrl"
: : "r"(region) : "ctr", "lr");
}static void do_protect(void *region)
{
size_t pgsize;
int i, pkey;pgsize = getpagesize();
pkey = sys_pkey_alloc(0, PKEY_DISABLE_EXECUTE);
assert (pkey > 0);/* perform mprotect */
assert(!sys_pkey_mprotect(region, pgsize, PROT_RWX, pkey));
do_execute(region);/* free pkey */
assert(!sys_pkey_free(pkey));}
int main(int argc, char **argv)
{
size_t pgsize, numinsns;
unsigned int *region;
int i;/* allocate memory region to protect */
pgsize = getpagesize();
region = memalign(pgsize, pgsize);
assert(region != NULL);
assert(!mprotect(region, pgsize, PROT_RWX));/* fill page with NOPs with a BLR at the end */
numinsns = pgsize / sizeof(region[0]);
for (i = 0; i < numinsns - 1; i++)
region[i] = PPC_INST_NOP;
region[i] = PPC_INST_BLR;do_protect(region);
return EXIT_SUCCESS;
}The fix is to only check the IAMR for an execute check, the AMR value
is not relevant.Fixes: f2407ef3ba22 ("powerpc: helper to validate key-access permissions of a pte")
Cc: stable@vger.kernel.org # v4.16+
Reported-by: Sandipan Das
Signed-off-by: Aneesh Kumar K.V
[mpe: Add detail to change log, tweak wording & formatting]
Signed-off-by: Michael Ellerman
Link: https://lore.kernel.org/r/20200712132047.1038594-1-aneesh.kumar@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman -
commit 0cac21b02ba5f3095fd2dcc77c26a25a0b2432ed upstream.
With the current 8KB stack size there are frequent overflows in a 64-bit
configuration. We may split IRQ stacks off in the future, but this fixes a
number of issues right now.Signed-off-by: Andreas Schwab
Reviewed-by: Anup Patel
[Palmer: mention irqstack in the commit text]
Fixes: 7db91e57a0ac ("RISC-V: Task implementation")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt
Signed-off-by: Greg Kroah-Hartman -
commit ff5b89c2858f28006f9f9c0a88c55a679488192c upstream.
Add phy-mode property required by phylink on gmac2
Fixes: b8fc9f30821e ("net: ethernet: mediatek: Add basic PHYLINK support")
Signed-off-by: Sean Wang
Link: https://lore.kernel.org/r/70e3eff31ecd500ed4862d9de28325a4dbd15105.1583648927.git.sean.wang@mediatek.com
Signed-off-by: Matthias Brugger
Signed-off-by: Greg Kroah-Hartman -
commit 5714ee50bb4375bd586858ad800b1d9772847452 upstream.
This fixes a regression encountered while running the
gdb.base/corefile.exp test in GDB's test suite.In my testing, the typo prevented the sw_reserved field of struct
fxregs_state from being output to the kernel XSAVES area. Thus the
correct mask corresponding to XCR0 was not present in the core file for
GDB to interrogate, resulting in the following behavior:[kev@f32-1 gdb]$ ./gdb -q testsuite/outputs/gdb.base/corefile/corefile testsuite/outputs/gdb.base/corefile/corefile.core
Reading symbols from testsuite/outputs/gdb.base/corefile/corefile...
[New LWP 232880]warning: Unexpected size of section `.reg-xstate/232880' in core file.
With the typo fixed, the test works again as expected.
Signed-off-by: Kevin Buettner
Fixes: 9e4636545933 ("copy_xstate_to_kernel(): don't leave parts of destination uninitialized")
Cc: Al Viro
Cc: Dave Airlie
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 681a5c71fb829fc2193e3bb524af41525477f5c3 ]
Fix dtschema validator warnings like:
intc@fffc1000: $nodename:0:
'intc@fffc1000' does not match '^interrupt-controller(@[0-9a-f,]+)*$'Fixes: 78cd6a9d8e15 ("arm64: dts: Add base stratix 10 dtsi")
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Dinh Nguyen
Signed-off-by: Sasha Levin -
[ Upstream commit d7adfe5ffed9faa05f8926223086b101e14f700d ]
Fix dtschema validator warnings like:
l2-cache@fffff000: $nodename:0:
'l2-cache@fffff000' does not match '^(cache-controller|cpu)(@[0-9a-f,]+)*$'Fixes: 475dc86d08de ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC")
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Dinh Nguyen
Signed-off-by: Sasha Levin -
[ Upstream commit 2a4117df9b436a0e4c79d211284ab2097bcd00dc ]
Got following d_can probe errors with kernel 5.8-rc1 on am437x
[ 10.730822] CAN device driver interface
Starting Wait for Network to be Configured...
[ OK ] Reached target Network.
[ 10.787363] c_can_platform 481cc000.can: probe failed
[ 10.792484] c_can_platform: probe of 481cc000.can failed with error -2
[ 10.799457] c_can_platform 481d0000.can: probe failed
[ 10.804617] c_can_platform: probe of 481d0000.can failed with error -2actually, Tony has fixed this issue on am335x with the patch [3]
Since am437x has the same clock structure with am335x
[1][2], so reuse the code from Tony Lindgren's patch [3] to fix it.[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
Integration
[3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on
am335x")Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to read revision")
Signed-off-by: dillon min
[tony@atomide.com: aligned commit message a bit for readability]
Signed-off-by: Tony Lindgren
Signed-off-by: Sasha Levin -
[ Upstream commit b2037dafcf082cd24b88ae9283af628235df36e1 ]
When starting at 744MHz, the Mali 450 core crashes on S805X based boards:
lima d00c0000.gpu: IRQ ppmmu3 not found
lima d00c0000.gpu: IRQ ppmmu4 not found
lima d00c0000.gpu: IRQ ppmmu5 not found
lima d00c0000.gpu: IRQ ppmmu6 not found
lima d00c0000.gpu: IRQ ppmmu7 not found
Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.2+ #492
Hardware name: Libre Computer AML-S805X-AC (DT)
pstate: 40000005 (nZcv daif -PAN -UAO)
pc : lima_gp_init+0x28/0x188
...
Call trace:
lima_gp_init+0x28/0x188
lima_device_init+0x334/0x534
lima_pdev_probe+0xa4/0xe4
...
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000bReverting to a safer 666Mhz frequency on the S805X that doesn't use the
GP0 PLL makes it more stable.Fixes: fd47716479f5 ("ARM64: dts: add S805X based P241 board")
Fixes: 0449b8e371ac ("arm64: dts: meson: add libretech aml-s805x-ac board")
Signed-off-by: Neil Armstrong
Signed-off-by: Kevin Hilman
Link: https://lore.kernel.org/r/20200618132737.14243-1-narmstrong@baylibre.com
Signed-off-by: Sasha Levin -
[ Upstream commit 95ca6f06dd4827ff63be5154120c7a8511cd9a41 ]
The peripheral clock of the RNG is missing for gxl while it is present
for gxbb.Fixes: 1b3f6d148692 ("ARM64: dts: meson-gx: add clock CLKID_RNG0 to hwrng node")
Signed-off-by: Jerome Brunet
Signed-off-by: Kevin Hilman
Reviewed-by: Neil Armstrong
Link: https://lore.kernel.org/r/20200617125346.1163527-1-jbrunet@baylibre.com
Signed-off-by: Sasha Levin -
[ Upstream commit a81bcfb6ac20cdd2e8dec3da14c8bbe1d18f6321 ]
When high load on the DWC3 SuperSpeed port, the controller crashes with:
[ 221.141621] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
[ 221.157631] xhci-hcd xhci-hcd.0.auto: Host halt failed, -110
[ 221.157635] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
[ 221.159901] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
[ 221.159961] hub 2-1.1:1.0: hub_ext_port_status failed (err = -22)
[ 221.160076] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
[ 221.165946] usb 2-1.1-port1: cannot reset (err = -22)Setting the parkmode_disable_ss_quirk quirk fixes the issue.
Reported-by: Tim
Signed-off-by: Neil Armstrong
Signed-off-by: Kevin Hilman
Cc: Jianxin Pan
CC: Dongjin Kim
Link: https://lore.kernel.org/r/20200221091532.8142-4-narmstrong@baylibre.com
Signed-off-by: Sasha Levin -
[ 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 -
[ Upstream commit bb1a0e87e1c54cd884e9b92b1cec06b186edc7a0 ]
On SAM9X60 2 nop operations has to be introduced after setting
WAITMODE bit in CKGR_MOR.Signed-off-by: Claudiu Beznea
Signed-off-by: Alexandre Belloni
Link: https://lore.kernel.org/r/1579522208-19523-9-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Sasha Levin -
[ Upstream commit 4601832f40501efc3c2fd264a5a69bd1ac17d520 ]
The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in commit afe518400bdb ("iommu/omap: fix boot issue on
remoteprocs with AMMU/Unicache").NOTE:
1. RET is not a valid target power domain state on DRA7 platforms,
and IPU power domain is normally programmed for OFF. The IPU1
still fails to boot though, and an unclearable l3_noc error is
thrown currently on 4.14 kernel without this fix. This behavior
is slightly different from previous 4.9 LTS kernel.
2. The fix is currently applied only to IPU1 on DRA7xx SoC, as the
other affected processors on OMAP4/OMAP5/DRA7 are in domains
that are not entering RET. IPU2 on DRA7 is in CORE power domain
which is only programmed for ON power state. The fix can be easily
scaled if these domains do hit RET in the future.
3. The issue was not seen on current DRA7 platforms if any of the
DSP remote processors were booted and using one of the GPTimers
5, 6, 7 or 8 on previous 4.9 LTS kernel. This was due to the
errata fix for i874 implemented in commit 1cbabcb9807e ("ARM:
DRA7: clockdomain: Implement timer workaround for errata i874")
which keeps the IPU1 power domain from entering RET when the
timers are active. But the timer workaround did not make any
difference on 4.14 kernel, and an l3_noc error was seen still
without this fix.Signed-off-by: Suman Anna
Signed-off-by: Tony Lindgren
Signed-off-by: Sasha Levin -
[ Upstream commit 2f14101a1d760db72393910d481fbf7768c44530 ]
Errata Title:
i879: DSP MStandby requires CD_EMU in SW_WKUPDescription:
The DSP requires the internal emulation clock to be actively toggling
in order to successfully enter a low power mode via execution of the
IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
other prerequisites and software sequence are followed.Workaround:
The emulation clock to the DSP is free-running anytime CCS is connected
via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.Implementation:
This patch implements this workaround by denying the HW_AUTO mode
for the EMU clockdomain during the power-up of any DSP processor
and re-enabling the HW_AUTO mode during the shutdown of the last
DSP processor (actually done during the enabling and disabling of
the respective DSP MDMA MMUs). Reference counting has to be used to
manage the independent sequencing between the multiple DSP processors.This switching is done at runtime rather than a static clockdomain
flags value to meet the target power domain state for the EMU power
domain during suspend.Note that the DSP MStandby behavior is not consistent across all
boards prior to this fix. Please see commit 45f871eec6c0 ("ARM:
OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs") for
details.Signed-off-by: Suman Anna
Signed-off-by: Tony Lindgren
Signed-off-by: Sasha Levin -
[ Upstream commit e4c4b540e1e6c21ff8b987e92b2bd170ee006a94 ]
IOMMU driver will be using ti-sysc bus driver for power management control
going forward, and the pdata quirks are not needed for anything anymore.Signed-off-by: Tero Kristo
Signed-off-by: Tony Lindgren
Signed-off-by: Sasha Levin -
[ Upstream commit 5679b28142193a62f6af93249c0477be9f0c669b ]
Commit f7b93d42945c ("arm64/alternatives: use subsections for replacement
sequences") moved the alternatives replacement sequences into subsections,
in order to keep the as close as possible to the code that they replace.Unfortunately, this broke the logic in branch_insn_requires_update,
which assumed that any branch into kernel executable code was a branch
that required updating, which is no longer the case now that the code
sequences that are patched in are in the same section as the patch site
itself.So the only way to discriminate branches that require updating and ones
that don't is to check whether the branch targets the replacement sequence
itself, and so we can drop the call to kernel_text_address() entirely.Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences")
Reported-by: Alexandru Elisei
Signed-off-by: Ard Biesheuvel
Tested-by: Alexandru Elisei
Link: https://lore.kernel.org/r/20200709125953.30918-1-ardb@kernel.org
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin -
[ Upstream commit f7b93d42945cc71e1346dd5ae07c59061d56745e ]
When building very large kernels, the logic that emits replacement
sequences for alternatives fails when relative branches are present
in the code that is emitted into the .altinstr_replacement section
and patched in at the original site and fixed up. The reason is that
the linker will insert veneers if relative branches go out of range,
and due to the relative distance of the .altinstr_replacement from
the .text section where its branch targets usually live, veneers
may be emitted at the end of the .altinstr_replacement section, with
the relative branches in the sequence pointed at the veneers instead
of the actual target.The alternatives patching logic will attempt to fix up the branch to
point to its original target, which will be the veneer in this case,
but given that the patch site is likely to be far away as well, it
will be out of range and so patching will fail. There are other cases
where these veneers are problematic, e.g., when the target of the
branch is in .text while the patch site is in .init.text, in which
case putting the replacement sequence inside .text may not help either.So let's use subsections to emit the replacement code as closely as
possible to the patch site, to ensure that veneers are only likely to
be emitted if they are required at the patch site as well, in which
case they will be in range for the replacement sequence both before
and after it is transported to the patch site.This will prevent alternative sequences in non-init code from being
released from memory after boot, but this is tolerable given that the
entire section is only 512 KB on an allyesconfig build (which weighs in
at 500+ MB for the entire Image). Also, note that modules today carry
the replacement sequences in non-init sections as well, and any of
those that target init code will be emitted into init sections after
this change.This fixes an early crash when booting an allyesconfig kernel on a
system where any of the alternatives sequences containing relative
branches are activated at boot (e.g., ARM64_HAS_PAN on TX2)Signed-off-by: Ard Biesheuvel
Cc: Suzuki K Poulose
Cc: James Morse
Cc: Andre Przywara
Cc: Dave P Martin
Link: https://lore.kernel.org/r/20200630081921.13443-1-ardb@kernel.org
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin -
[ Upstream commit c43e55796dd4d13f4855971a4d7970ce2cd94db4 ]
After pulling 5.7.0 (linux-next merge), mcf5441x mmu boot was
hanging silently.memblock_add() seems not appropriate, since using MAX_NUMNODES
as node id, while memblock_add_node() sets up memory for node id 0.Signed-off-by: Angelo Dureghello
Signed-off-by: Mike Rapoport
Signed-off-by: Greg Ungerer
Signed-off-by: Sasha Levin -
[ Upstream commit d63bd8c81d8ab64db506ffde569cc8ff197516e2 ]
The m68k nommu setup code didn't register the beginning of the physical
memory with memblock because it was anyway occupied by the kernel. However,
commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than
zone sizes") changed zones initialization to use memblock.memory to detect
the zone extents and this caused inconsistency between zone PFNs and the
actual PFNs:BUG: Bad page state in process swapper pfn:20165
page:41fe0ca0 refcount:0 mapcount:1 mapping:00000000 index:0x0 flags: 0x0()
raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000
page dumped because: nonzero mapcount
CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-00001-g3a38f8a60c65-dirty #1
Stack from 404c9ebc:
404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4
00020165 00000000 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21
00000000 40088a12 41fe0ca0 41fe0ca4 0000020a 00000000 00000001 402ca000
00000000 41fe0ca0 41fd2c10 41fd2c10 00000000 00000000 402b2388 00000001
400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 00000001 41fd2c04
41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0 ffffffff
Call Trace:
[] 0x40088470
[] 0x40088504
[] 0x40088a12
[] 0x402ca000
[] 0x400a0934Adjust the memory registration with memblock to include the beginning of
the physical memory and make sure that the area occupied by the kernel is
marked as reserved.Signed-off-by: Mike Rapoport
Signed-off-by: Greg Ungerer
Signed-off-by: Sasha Levin -
[ Upstream commit 7ad816762f9bf89e940e618ea40c43138b479e10 ]
Previously, kernel floating point code would run with the MXCSR control
register value last set by userland code by the thread that was active
on the CPU core just before kernel call. This could affect calculation
results if rounding mode was changed, or a crash if a FPU/SIMD exception
was unmasked.Restore MXCSR to the kernel's default value.
[ bp: Carve out from a bigger patch by Petteri, add feature check, add
FNINIT call too (amluto). ]Signed-off-by: Petteri Aimonen
Signed-off-by: Borislav Petkov
Link: https://bugzilla.kernel.org/show_bug.cgi?id=207979
Link: https://lkml.kernel.org/r/20200624114646.28953-2-bp@alien8.de
Signed-off-by: Sasha Levin
