linux-stable.git/arch, branch v6.0.13

ARM: at91: fix build for SAMA5D3 w/o L2 cache

2022-12-14T10:40:56+00:00

[ Upstream commit 6a3fc8c330d1c1fa3d8773d7d38a7c55c4900dfe ]

The L2 cache is present on the newer SAMA5D2 and SAMA5D4 families, but
apparently not for the older SAMA5D3.

Solves a build-time regression with the following symptom:

sama5.c:(.init.text+0x48): undefined reference to `outer_cache'

Fixes: 3b5a7ca7d252 ("ARM: at91: setup outer cache .write_sec() callback if needed")
Signed-off-by: Peter Rosin 
[claudiu.beznea: delete "At least not always." from commit description]
Signed-off-by: Claudiu Beznea 
Link: https://lore.kernel.org/r/b7f8dacc-5e1f-0eb2-188e-3ad9a9f7613d@axentia.se
Signed-off-by: Sasha Levin

ARM: 9278/1: kfence: only handle translation faults

2022-12-14T10:40:55+00:00

commit 73a0b6ee5d6269f92df43e1d09b3278a2886bf8a upstream.

This is a similar fixup like arm64 does, only handle translation faults
in case of unexpected kfence report when alignment faults on ARM, see
more from commit 0bb1fbffc631 ("arm64: mm: kfence: only handle translation
faults").

Fixes: 75969686ec0d ("ARM: 9166/1: Support KFENCE for ARM")
Signed-off-by: Kefeng Wang 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Greg Kroah-Hartman

KVM: s390: vsie: Fix the initialization of the epoch extension (epdx) field

2022-12-14T10:40:53+00:00

commit 0dd4cdccdab3d74bd86b868768a7dca216bcce7e upstream.

We recently experienced some weird huge time jumps in nested guests when
rebooting them in certain cases. After adding some debug code to the epoch
handling in vsie.c (thanks to David Hildenbrand for the idea!), it was
obvious that the "epdx" field (the multi-epoch extension) did not get set
to 0xff in case the "epoch" field was negative.
Seems like the code misses to copy the value from the epdx field from
the guest to the shadow control block. By doing so, the weird time
jumps are gone in our scenarios.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2140899
Fixes: 8fa1696ea781 ("KVM: s390: Multiple Epoch Facility support")
Signed-off-by: Thomas Huth 
Reviewed-by: Christian Borntraeger 
Acked-by: David Hildenbrand 
Reviewed-by: Claudio Imbrenda 
Reviewed-by: Janosch Frank 
Cc: stable@vger.kernel.org # 4.19+
Link: https://lore.kernel.org/r/20221123090833.292938-1-thuth@redhat.com
Message-Id: <20221123090833.292938-1-thuth@redhat.com>
Signed-off-by: Janosch Frank 
Signed-off-by: Greg Kroah-Hartman

Revert "ARM: dts: imx7: Fix NAND controller size-cells"

2022-12-14T10:40:51+00:00

commit ef19964da8a668c683f1d38274f6fb756e047945 upstream.

This reverts commit 753395ea1e45c724150070b5785900b6a44bd5fb.

It introduced a boot regression on colibri-imx7, and potentially any
other i.MX7 boards with MTD partition list generated into the fdt by
U-Boot.

While the commit we are reverting here is not obviously wrong, it fixes
only a dt binding checker warning that is non-functional, while it
introduces a boot regression and there is no obvious fix ready.

Fixes: 753395ea1e45 ("ARM: dts: imx7: Fix NAND controller size-cells")
Signed-off-by: Francesco Dolcini 
Reviewed-by: Miquel Raynal 
Acked-by: Marek Vasut 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/Y4dgBTGNWpM6SQXI@francesco-nb.int.toradex.com/
Link: https://lore.kernel.org/all/20221205144917.6514168a@xps-13/
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

LoongArch: Fix unsigned comparison with less than zero

2022-12-14T10:40:47+00:00

[ Upstream commit b96e74bb439f096168c78ba3ba1599e0b85cfd73 ]

Eliminate the following coccicheck warning:

./arch/loongarch/kernel/unwind_prologue.c:84:5-13: WARNING: Unsigned
expression compared with zero: frame_ra < 0

Signed-off-by: KaiLong Wang 
Signed-off-by: Huacai Chen 
Signed-off-by: Sasha Levin

LoongArch: Set _PAGE_DIRTY only if _PAGE_MODIFIED is set in {pmd,pte}_mkwrite()

2022-12-14T10:40:47+00:00

[ Upstream commit 54e6cd42a183b602e3627ad3aaeeed44f7443e67 ]

Set _PAGE_DIRTY only if _PAGE_MODIFIED is set in {pmd,pte}_mkwrite().
Otherwise, _PAGE_DIRTY silences the TLB modify exception and make us
have no chance to mark a pmd/pte dirty (_PAGE_MODIFIED) for software.

Reviewed-by: Guo Ren 
Signed-off-by: Huacai Chen 
Signed-off-by: Sasha Levin

LoongArch: Combine acpi_boot_table_init() and acpi_boot_init()

2022-12-14T10:40:47+00:00

[ Upstream commit 538eafc6deae12fbac5f277b89aa139b812bca49 ]

Combine acpi_boot_table_init() and acpi_boot_init() since they are very
simple, and we don't need to check the return value of acpi_boot_init().

Signed-off-by: Huacai Chen 
Signed-off-by: Sasha Levin

LoongArch: Makefile: Use "grep -E" instead of "egrep"

2022-12-14T10:40:47+00:00

[ Upstream commit 83f638bca0ccd94942bc3c4eb9bcec24dd8a1cf9 ]

The latest version of grep claims the egrep is now obsolete so the build
now contains warnings that look like:
	egrep: warning: egrep is obsolescent; using grep -E

Fix this up by changing the LoongArch Makefile to use "grep -E" instead.

Signed-off-by: Tiezhu Yang 
Signed-off-by: Huacai Chen 
Signed-off-by: Sasha Levin

ARM: dts: rockchip: disable arm_global_timer on rk3066 and rk3188

2022-12-14T10:40:46+00:00

[ Upstream commit da74858a475782a3f16470907814c8cc5950ad68 ]

The clock source and the sched_clock provided by the arm_global_timer
on Rockchip rk3066a/rk3188 are quite unstable because their rates
depend on the CPU frequency.

Recent changes to the arm_global_timer driver makes it impossible to use.

On the other side, the arm_global_timer has a higher rating than the
ROCKCHIP_TIMER, it will be selected by default by the time framework
while we want to use the stable Rockchip clock source.

Keep the arm_global_timer disabled in order to have the
DW_APB_TIMER (rk3066a) or ROCKCHIP_TIMER (rk3188) selected by default.

Signed-off-by: Johan Jonker 
Link: https://lore.kernel.org/r/f275ca8d-fd0a-26e5-b978-b7f3df815e0a@gmail.com
Signed-off-by: Heiko Stuebner 
Signed-off-by: Sasha Levin

ARM: 9266/1: mm: fix no-MMU ZERO_PAGE() implementation

2022-12-14T10:40:46+00:00

[ Upstream commit 340a982825f76f1cff0daa605970fe47321b5ee7 ]

Actually in no-MMU SoCs(i.e. i.MXRT) ZERO_PAGE(vaddr) expands to
```
virt_to_page(0)
```
that in order expands to:
```
pfn_to_page(virt_to_pfn(0))
```
and then virt_to_pfn(0) to:
```
        ((((unsigned long)(0) - PAGE_OFFSET) >> PAGE_SHIFT) +
         PHYS_PFN_OFFSET)
```
where PAGE_OFFSET and PHYS_PFN_OFFSET are the DRAM offset(0x80000000) and
PAGE_SHIFT is 12. This way we obtain 16MB(0x01000000) summed to the base of
DRAM(0x80000000).
When ZERO_PAGE(0) is then used, for example in bio_add_page(), the page
gets an address that is out of DRAM bounds.
So instead of using fake virtual page 0 let's allocate a dedicated
zero_page during paging_init() and assign it to a global 'struct page *
empty_zero_page' the same way mmu.c does and it's the same approach used
in m68k with commit dc068f462179 as discussed here[0]. Then let's move
ZERO_PAGE() definition to the top of pgtable.h to be in common between
mmu.c and nommu.c.

[0]: https://lore.kernel.org/linux-m68k/2a462b23-5b8e-bbf4-ec7d-778434a3b9d7@google.com/T/#m1266ceb63
ad140743174d6b3070364d3c9a5179b

Signed-off-by: Giulio Benetti 
Reviewed-by: Arnd Bergmann 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Sasha Levin