linux-stable.git/arch/arm, branch v5.4.263

arm/xen: fix xen_vcpu_info allocation alignment

2023-12-08T07:44:23+00:00

[ Upstream commit 7bf9a6b46549852a37e6d07e52c601c3c706b562 ]

xen_vcpu_info is a percpu area than needs to be mapped by Xen.
Currently, it could cross a page boundary resulting in Xen being unable
to map it:

[    0.567318] kernel BUG at arch/arm64/xen/../../arm/xen/enlighten.c:164!
[    0.574002] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP

Fix the issue by using __alloc_percpu and requesting alignment for the
memory allocation.

Signed-off-by: Stefano Stabellini 

Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2311221501340.2053963@ubuntu-linux-20-04-desktop
Fixes: 24d5373dda7c ("arm/xen: Use alloc_percpu rather than __alloc_percpu")
Reviewed-by: Juergen Gross 
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin

ARM: 9320/1: fix stack depot IRQ stack filter

2023-11-28T16:50:15+00:00

[ Upstream commit b0150014878c32197cfa66e3e2f79e57f66babc0 ]

Place IRQ handlers such as gic_handle_irq() in the irqentry section even
if FUNCTION_GRAPH_TRACER is not enabled.  Without this, the stack
depot's filter_irq_stacks() does not correctly filter out IRQ stacks in
those configurations, which hampers deduplication and eventually leads
to "Stack depot reached limit capacity" splats with KASAN.

A similar fix was done for arm64 in commit f6794950f0e5ba37e3bbed
("arm64: set __exception_irq_entry with __irq_entry as a default").

Link: https://lore.kernel.org/r/20230803-arm-irqentry-v1-1-8aad8e260b1c@axis.com

Signed-off-by: Vincent Whitchurch 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Sasha Levin

ARM: 9321/1: memset: cast the constant byte to unsigned char

2023-11-20T09:30:12+00:00

[ Upstream commit c0e824661f443b8cab3897006c1bbc69fd0e7bc4 ]

memset() description in ISO/IEC 9899:1999 (and elsewhere) says:

	The memset function copies the value of c (converted to an
	unsigned char) into each of the first n characters of the
	object pointed to by s.

The kernel's arm32 memset does not cast c to unsigned char. This results
in the following code to produce erroneous output:

	char a[128];
	memset(a, -128, sizeof(a));

This is because gcc will generally emit the following code before
it calls memset() :

	mov   r0, r7
	mvn   r1, #127        ; 0x7f
	bl    00000000 

r1 ends up with 0xffffff80 before being used by memset() and the
'a' array will have -128 once in every four bytes while the other
bytes will be set incorrectly to -1 like this (printing the first
8 bytes) :

	test_module: -128 -1 -1 -1
	test_module: -1 -1 -1 -128

The change here is to 'and' r1 with 255 before it is used.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Linus Walleij 
Signed-off-by: Kursad Oney 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Sasha Levin

ARM: dts: qcom: mdm9615: populate vsdcc fixed regulator

2023-11-20T09:30:11+00:00

[ Upstream commit 09f8ee81b6da5f76de8b83c8bfc4475b54e101e0 ]

Fixed regulator put under "regulators" node will not be populated,
unless simple-bus or something similar is used.  Drop the "regulators"
wrapper node to fix this.

Fixes: 2c5e596524e7 ("ARM: dts: Add MDM9615 dtsi")
Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20230924183914.51414-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson 
Signed-off-by: Sasha Levin

Revert "ARM: dts: Move am33xx and am43xx mmc nodes to sdhci-omap driver"

2023-11-08T10:23:42+00:00

This reverts commit d0c69c722ff16ce2481a5e0932c6d5b172109f21 which is
commit 0b4edf111870b83ea77b1d7e16b8ceac29f9f388 upstream.

The reverted commit completely breaks MMC on the AM33xx/AM437x for
multiple reasons:

- The changed compatible strings ti,am335-sdhci and ti,am437-sdhci
  aren't supported on Linux 5.4 at all, so no driver is found
- Even when additionally backporting the support for these compatible
  strings in the sdhci-omap driver, I could not the the MMC interfaces
  to work on our TQMa335x SoM - the interface would time out during card
  initialization for both an eMMC and an SD card.

I did not investigate the cause of the timeouts further, and instead
just reverted the commit - switching to a different MMC driver in a stable
kernel seems like a rather risky change unless it's thoroughly tested,
which has obviously not happened in this case.

The reverted commit is also given as a Stable-dep-of commit 2eb502f496f7
("ARM: dts: am33xx: Fix MMCHS0 dma properties"), however the conflict
resulting when only the one commit is reverted is trivial to resolve,
which leads to working MMC controllers again.

Signed-off-by: Matthias Schiffer 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: ti: omap: Fix noisy serial with overrun-throttle-ms for mapphone

2023-10-25T09:53:22+00:00

[ Upstream commit 5ad37b5e30433afa7a5513e3eb61f69fa0976785 ]

On mapphone devices we may get lots of noise on the micro-USB port in debug
uart mode until the phy-cpcap-usb driver probes. Let's limit the noise by
using overrun-throttle-ms.

Note that there is also a related separate issue where the charger cable
connected may cause random sysrq requests until phy-cpcap-usb probes that
still remains.

Cc: Ivaylo Dimitrov 
Cc: Carl Philipp Klemm 
Cc: Merlijn Wajer 
Cc: Pavel Machek 
Reviewed-by: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

ARM: dts: ti: omap: motorola-mapphone: Fix abe_clkctrl warning on boot

2023-10-10T19:46:39+00:00

[ Upstream commit ac08bda1569b06b7a62c7b4dd00d4c3b28ceaaec ]

Commit 0840242e8875 ("ARM: dts: Configure clock parent for pwm vibra")
attempted to fix the PWM settings but ended up causin an additional clock
reparenting error:

clk: failed to reparent abe-clkctrl:0060:24 to sys_clkin_ck: -22

Only timer9 is in the PER domain and can use the sys_clkin_ck clock source.
For timer8, the there is no sys_clkin_ck available as it's in the ABE
domain, instead it should use syc_clk_div_ck. However, for power
management, we want to use the always on sys_32k_ck instead.

Cc: Ivaylo Dimitrov 
Cc: Carl Philipp Klemm 
Cc: Merlijn Wajer 
Cc: Pavel Machek 
Reviewed-by: Sebastian Reichel 
Fixes: 0840242e8875 ("ARM: dts: Configure clock parent for pwm vibra")
Depends-on: 61978617e905 ("ARM: dts: Add minimal support for Droid Bionic xt875")
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

hw_breakpoint: fix single-stepping when using bpf_overflow_handler

2023-09-23T09:00:03+00:00

[ Upstream commit d11a69873d9a7435fe6a48531e165ab80a8b1221 ]

Arm platforms use is_default_overflow_handler() to determine if the
hw_breakpoint code should single-step over the breakpoint trigger or
let the custom handler deal with it.

Since bpf_overflow_handler() currently isn't recognized as a default
handler, attaching a BPF program to a PERF_TYPE_BREAKPOINT event causes
it to keep firing (the instruction triggering the data abort exception
is never skipped). For example:

  # bpftrace -e 'watchpoint:0x10000:4:w { print("hit") }' -c ./test
  Attaching 1 probe...
  hit
  hit
  [...]
  ^C

(./test performs a single 4-byte store to 0x10000)

This patch replaces the check with uses_default_overflow_handler(),
which accounts for the bpf_overflow_handler() case by also testing
if one of the perf_event_output functions gets invoked indirectly,
via orig_default_handler.

Signed-off-by: Tomislav Novak 
Tested-by: Samuel Gosselin  # arm64
Reviewed-by: Catalin Marinas 
Acked-by: Alexei Starovoitov 
Link: https://lore.kernel.org/linux-arm-kernel/20220923203644.2731604-1-tnovak@fb.com/
Link: https://lore.kernel.org/r/20230605191923.1219974-1-tnovak@meta.com
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

ARM: dts: BCM5301X: Extend RAM to full 256MB for Linksys EA6500 V2

2023-09-23T09:00:01+00:00

[ Upstream commit 91994e59079dcb455783d3f9ea338eea6f671af3 ]

Linksys ea6500-v2 have 256MB of ram. Currently we only use 128MB.
Expand the definition to use all the available RAM.

Fixes: 03e96644d7a8 ("ARM: dts: BCM5301X: Add basic DT for Linksys EA6500 V2")
Signed-off-by: Aleksey Nasibulin 
Signed-off-by: Christian Marangi 
Cc: stable@vger.kernel.org
Acked-by: Rafał Miłecki 
Link: https://lore.kernel.org/r/20230712014017.28123-1-ansuelsmth@gmail.com
Signed-off-by: Florian Fainelli 
Signed-off-by: Sasha Levin

ARM: OMAP2+: Fix -Warray-bounds warning in _pwrdm_state_switch()

2023-09-23T08:59:54+00:00

commit 847fb80cc01a54bc827b02547bb8743bdb59ddab upstream.

If function pwrdm_read_prev_pwrst() returns -EINVAL, we will end
up accessing array pwrdm->state_counter through negative index
-22. This is wrong and the compiler is legitimately warning us
about this potential problem.

Fix this by sanity checking the value stored in variable _prev_
before accessing array pwrdm->state_counter.

Address the following -Warray-bounds warning:
arch/arm/mach-omap2/powerdomain.c:178:45: warning: array subscript -22 is below array bounds of 'unsigned int[4]' [-Warray-bounds]

Link: https://github.com/KSPP/linux/issues/307
Fixes: ba20bb126940 ("OMAP: PM counter infrastructure.")
Cc: stable@vger.kernel.org
Reported-by: kernel test robot 
Link: https://lore.kernel.org/lkml/20230607050639.LzbPn%25lkp@intel.com/
Signed-off-by: Gustavo A. R. Silva 
Message-ID: 
Acked-by: Ard Biesheuvel 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman