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

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

ARM: dts: BCM53573: Fix Ethernet info for Luxul devices

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

[ Upstream commit 44ad8207806973f4e4f7d870fff36cc01f494250 ]

Both Luxul's XAP devices (XAP-810 and XAP-1440) are access points that
use a non-default design. They don't include switch but have a single
Ethernet port and BCM54210E PHY connected to the Ethernet controller's
MDIO bus.

Support for those devices regressed due to two changes:

1. Describing MDIO bus with switch
After commit 9fb90ae6cae7 ("ARM: dts: BCM53573: Describe on-SoC BCM53125
rev 4 switch") Linux stopped probing for MDIO devices.

2. Dropping hardcoded BCM54210E delays
In commit fea7fda7f50a ("net: phy: broadcom: Fix RGMII delays
configuration for BCM54210E") support for other PHY modes was added but
that requires a proper "phy-mode" value in DT.

Both above changes are correct (they don't need to be reverted or
anything) but they need this fix for DT data to be correct and for Linux
to work properly.

Fixes: 9fb90ae6cae7 ("ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch")
Signed-off-by: Rafał Miłecki 
Link: https://lore.kernel.org/r/20230713111145.14864-1-zajec5@gmail.com
Signed-off-by: Florian Fainelli 
Signed-off-by: Sasha Levin