linux-stable.git/drivers/of/fdt.c, branch linux-6.2.y Linux kernel stable tree Revert "mm: kmemleak: alloc gray object for reserved region with direct map" 2023-02-01T00:44:09+00:00 Isaac J. Manjarres isaacmanjarres@google.com 2023-01-24T23:02:54+00:00 8ef852f1cb426a5812aee700d3b4297aaa426acc This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769. Kmemleak operates by periodically scanning memory regions for pointers to allocated memory blocks to determine if they are leaked or not. However, reserved memory regions can be used for DMA transactions between a device and a CPU, and thus, wouldn't contain pointers to allocated memory blocks, making them inappropriate for kmemleak to scan. Thus, revert this commit. Link: https://lkml.kernel.org/r/20230124230254.295589-1-isaacmanjarres@google.com Fixes: 972fa3a7c17c9 ("mm: kmemleak: alloc gray object for reserved region with direct map") Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Calvin Zhang <calvinzhang.cool@gmail.com> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Cc: <stable@vger.kernel.org> [5.17+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 
This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769.

Kmemleak operates by periodically scanning memory regions for pointers to
allocated memory blocks to determine if they are leaked or not.  However,
reserved memory regions can be used for DMA transactions between a device
and a CPU, and thus, wouldn't contain pointers to allocated memory blocks,
making them inappropriate for kmemleak to scan.  Thus, revert this commit.

Link: https://lkml.kernel.org/r/20230124230254.295589-1-isaacmanjarres@google.com
Fixes: 972fa3a7c17c9 ("mm: kmemleak: alloc gray object for reserved region with direct map")
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Calvin Zhang <calvinzhang.cool@gmail.com>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: <stable@vger.kernel.org>	[5.17+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
of: fdt: Honor CONFIG_CMDLINE* even without /chosen node, take 2 2023-01-05T03:31:59+00:00 Rob Herring robh@kernel.org 2023-01-03T18:00:32+00:00 064e32dc5b03114d0767893fecdaf7b5dfd8c286 I do not read a strict requirement on /chosen node in either ePAPR or in Documentation/devicetree. Help text for CONFIG_CMDLINE and CONFIG_CMDLINE_EXTEND doesn't make their behavior explicitly dependent on the presence of /chosen or the presense of /chosen/bootargs. However the early check for /chosen and bailing out in early_init_dt_scan_chosen() skips CONFIG_CMDLINE handling which is not really related to /chosen node or the particular method of passing cmdline from bootloader. This leads to counterintuitive combinations (assuming CONFIG_CMDLINE_EXTEND=y): a) bootargs="foo", CONFIG_CMDLINE="bar" => cmdline=="foo bar" b) /chosen missing, CONFIG_CMDLINE="bar" => cmdline=="" c) bootargs="", CONFIG_CMDLINE="bar" => cmdline==" bar" Rework early_init_dt_scan_chosen() so that the cmdline config options are always handled. [commit msg written by Alexander Sverdlin] Cc: Alexander Sverdlin <alexander.sverdlin@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Tested-by: Geoff Levand <geoff@infradead.org> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20230103-dt-cmdline-fix-v1-2-7038e88b18b6@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> 
I do not read a strict requirement on /chosen node in either ePAPR or in
Documentation/devicetree. Help text for CONFIG_CMDLINE and
CONFIG_CMDLINE_EXTEND doesn't make their behavior explicitly dependent on
the presence of /chosen or the presense of /chosen/bootargs.

However the early check for /chosen and bailing out in
early_init_dt_scan_chosen() skips CONFIG_CMDLINE handling which is not
really related to /chosen node or the particular method of passing cmdline
from bootloader.

This leads to counterintuitive combinations (assuming
CONFIG_CMDLINE_EXTEND=y):

a) bootargs="foo", CONFIG_CMDLINE="bar" => cmdline=="foo bar"
b) /chosen missing, CONFIG_CMDLINE="bar" => cmdline==""
c) bootargs="", CONFIG_CMDLINE="bar" => cmdline==" bar"

Rework early_init_dt_scan_chosen() so that the cmdline config options are
always handled.

[commit msg written by Alexander Sverdlin]

Cc: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Tested-by: Geoff Levand <geoff@infradead.org>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20230103-dt-cmdline-fix-v1-2-7038e88b18b6@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Revert "of: fdt: Honor CONFIG_CMDLINE* even without /chosen node" 2023-01-05T03:31:59+00:00 Rob Herring robh@kernel.org 2023-01-03T18:00:31+00:00 bd0ddcfc83d85bc30c868f2c3457312c7f1ccee2 This reverts commit a7d550f82b445cf218b47a2c1a9c56e97ecb8c7a. Some arches (PPC at least) don't call early_init_dt_scan_nodes(), so moving the cmdline processing there breaks them. Reported-by: Geoff Levand <geoff@infradead.org> Cc: Alexander Sverdlin <alexander.sverdlin@gmail.com> Tested-by: Geoff Levand <geoff@infradead.org> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20230103-dt-cmdline-fix-v1-1-7038e88b18b6@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> 
This reverts commit a7d550f82b445cf218b47a2c1a9c56e97ecb8c7a.

Some arches (PPC at least) don't call early_init_dt_scan_nodes(), so
moving the cmdline processing there breaks them.

Reported-by: Geoff Levand <geoff@infradead.org>
Cc: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Tested-by: Geoff Levand <geoff@infradead.org>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20230103-dt-cmdline-fix-v1-1-7038e88b18b6@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
of/fdt: run soc memory setup when early_init_dt_scan_memory fails 2023-01-04T00:41:01+00:00 Andreas Rammhold andreas@rammhold.de 2022-12-23T11:27:47+00:00 2a12187d5853d9fd5102278cecef7dac7c8ce7ea If memory has been found early_init_dt_scan_memory now returns 1. If it hasn't found any memory it will return 0, allowing other memory setup mechanisms to carry on. Previously early_init_dt_scan_memory always returned 0 without distinguishing between any kind of memory setup being done or not. Any code path after the early_init_dt_scan memory call in the ramips plat_mem_setup code wouldn't be executed anymore. Making early_init_dt_scan_memory the only way to initialize the memory. Some boards, including my mt7621 based Cudy X6 board, depend on memory initialization being done via the soc_info.mem_detect function pointer. Those wouldn't be able to obtain memory and panic the kernel during early bootup with the message "early_init_dt_alloc_memory_arch: Failed to allocate 12416 bytes align=0x40". Fixes: 1f012283e936 ("of/fdt: Rework early_init_dt_scan_memory() to call directly") Cc: stable@vger.kernel.org Signed-off-by: Andreas Rammhold <andreas@rammhold.de> Link: https://lore.kernel.org/r/20221223112748.2935235-1-andreas@rammhold.de Signed-off-by: Rob Herring <robh@kernel.org> 
If memory has been found early_init_dt_scan_memory now returns 1. If
it hasn't found any memory it will return 0, allowing other memory
setup mechanisms to carry on.

Previously early_init_dt_scan_memory always returned 0 without
distinguishing between any kind of memory setup being done or not. Any
code path after the early_init_dt_scan memory call in the ramips
plat_mem_setup code wouldn't be executed anymore. Making
early_init_dt_scan_memory the only way to initialize the memory.

Some boards, including my mt7621 based Cudy X6 board, depend on memory
initialization being done via the soc_info.mem_detect function
pointer. Those wouldn't be able to obtain memory and panic the kernel
during early bootup with the message "early_init_dt_alloc_memory_arch:
Failed to allocate 12416 bytes align=0x40".

Fixes: 1f012283e936 ("of/fdt: Rework early_init_dt_scan_memory() to call directly")
Cc: stable@vger.kernel.org
Signed-off-by: Andreas Rammhold <andreas@rammhold.de>
Link: https://lore.kernel.org/r/20221223112748.2935235-1-andreas@rammhold.de
Signed-off-by: Rob Herring <robh@kernel.org>
of: fdt: Honor CONFIG_CMDLINE* even without /chosen node 2022-12-16T17:22:58+00:00 Alexander Sverdlin alexander.sverdlin@gmail.com 2022-12-11T23:58:17+00:00 a7d550f82b445cf218b47a2c1a9c56e97ecb8c7a I do not read a strict requirement on /chosen node in either ePAPR or in Documentation/devicetree. Help text for CONFIG_CMDLINE and CONFIG_CMDLINE_EXTEND doesn't make their behavior explicitly dependent on the presence of /chosen or the presense of /chosen/bootargs. However the early check for /chosen and bailing out in early_init_dt_scan_chosen() skips CONFIG_CMDLINE handling which is not really related to /chosen node or the particular method of passing cmdline from bootloader. This leads to counterintuitive combinations (assuming CONFIG_CMDLINE_EXTEND=y): a) bootargs="foo", CONFIG_CMDLINE="bar" => cmdline=="foo bar" b) /chosen missing, CONFIG_CMDLINE="bar" => cmdline=="" c) bootargs="", CONFIG_CMDLINE="bar" => cmdline==" bar" Move CONFIG_CMDLINE handling outside of early_init_dt_scan_chosen() so that cases b and c above result in the same cmdline. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/11af73e05bad75e4ef49067515e3214f6d944b3d.camel@gmail.com Signed-off-by: Rob Herring <robh@kernel.org> 
I do not read a strict requirement on /chosen node in either ePAPR or in
Documentation/devicetree. Help text for CONFIG_CMDLINE and
CONFIG_CMDLINE_EXTEND doesn't make their behavior explicitly dependent on
the presence of /chosen or the presense of /chosen/bootargs.

However the early check for /chosen and bailing out in
early_init_dt_scan_chosen() skips CONFIG_CMDLINE handling which is not
really related to /chosen node or the particular method of passing cmdline
from bootloader.

This leads to counterintuitive combinations (assuming
CONFIG_CMDLINE_EXTEND=y):

a) bootargs="foo", CONFIG_CMDLINE="bar" => cmdline=="foo bar"
b) /chosen missing, CONFIG_CMDLINE="bar" => cmdline==""
c) bootargs="", CONFIG_CMDLINE="bar" => cmdline==" bar"

Move CONFIG_CMDLINE handling outside of early_init_dt_scan_chosen() so that
cases b and c above result in the same cmdline.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/11af73e05bad75e4ef49067515e3214f6d944b3d.camel@gmail.com
Signed-off-by: Rob Herring <robh@kernel.org>
Merge tag 'devicetree-for-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux 2022-10-10T20:13:51+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-10-10T20:13:51+00:00 706eacadd5c5cc13510ba69eea2917c2ce5ffa99 Pull devicetree updates from Rob Herring: "DT core: - Fix node refcounting in of_find_last_cache_level() - Constify device_node in of_device_compatible_match() - Fix 'dma-ranges' handling in bus controller nodes - Fix handling of initrd start > end - Improve error reporting in of_irq_init() - Taint kernel on DT unittest running - Use strscpy instead of strlcpy - Add a build target, dt_compatible_check, to check for compatible strings used in kernel sources against compatible strings in DT schemas. - Handle DT_SCHEMA_FILES changes when rebuilding DT bindings: - LED bindings for MT6370 PMIC - Convert Mediatek mtk-gce mailbox, MIPS CPU interrupt controller, mt7621 I2C, virtio,pci-iommu, nxp,tda998x, QCom fastrpc, qcom,pdc, and arm,versatile-sysreg to DT schema format - Add nvmem cells to u-boot,env schema - Add more LED_COLOR_ID definitions - Require 'opp-table' uses to be a node - Various schema fixes to match QEMU 'virt' DT usage - Tree wide dropping of redundant 'Device Tree Binding' in schema titles - More (unevaluated|additional)Properties fixes in schema child nodes - Drop various redundant minItems equal to maxItems" * tag 'devicetree-for-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (62 commits) of: base: Shift refcount decrement in of_find_last_cache_level() dt-bindings: leds: Add MediaTek MT6370 flashlight dt-bindings: leds: mt6370: Add MediaTek MT6370 current sink type LED indicator dt-bindings: mailbox: Convert mtk-gce to DT schema of: base: make of_device_compatible_match() accept const device node of: Fix "dma-ranges" handling for bus controllers of: fdt: Remove unused struct fdt_scan_status dt-bindings: display: st,stm32-dsi: Handle data-lanes in DSI port node dt-bindings: timer: Add power-domains for TI timer-dm on K3 dt: Add a check for undocumented compatible strings in kernel kbuild: take into account DT_SCHEMA_FILES changes while checking dtbs dt-bindings: interrupt-controller: migrate MIPS CPU interrupt controller text bindings to YAML dt-bindings: i2c: migrate mt7621 text bindings to YAML dt-bindings: power: gpcv2: correct patternProperties dt-bindings: virtio: Convert virtio,pci-iommu to DT schema dt-bindings: timer: arm,arch_timer: Allow dual compatible string dt-bindings: arm: cpus: Add kryo240 compatible dt-bindings: display: bridge: nxp,tda998x: Convert to json-schema dt-bindings: nvmem: u-boot,env: add basic NVMEM cells dt-bindings: remoteproc: qcom,adsp: enforce smd-edge schema ... 
Pull devicetree updates from Rob Herring:
 "DT core:

   - Fix node refcounting in of_find_last_cache_level()

   - Constify device_node in of_device_compatible_match()

   - Fix 'dma-ranges' handling in bus controller nodes

   - Fix handling of initrd start > end

   - Improve error reporting in of_irq_init()

   - Taint kernel on DT unittest running

   - Use strscpy instead of strlcpy

   - Add a build target, dt_compatible_check, to check for compatible
     strings used in kernel sources against compatible strings in DT
     schemas.

   - Handle DT_SCHEMA_FILES changes when rebuilding

  DT bindings:

   - LED bindings for MT6370 PMIC

   - Convert Mediatek mtk-gce mailbox, MIPS CPU interrupt controller,
     mt7621 I2C, virtio,pci-iommu, nxp,tda998x, QCom fastrpc, qcom,pdc,
     and arm,versatile-sysreg to DT schema format

   - Add nvmem cells to u-boot,env schema

   - Add more LED_COLOR_ID definitions

   - Require 'opp-table' uses to be a node

   - Various schema fixes to match QEMU 'virt' DT usage

   - Tree wide dropping of redundant 'Device Tree Binding' in schema
     titles

   - More (unevaluated|additional)Properties fixes in schema child nodes

   - Drop various redundant minItems equal to maxItems"

* tag 'devicetree-for-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (62 commits)
  of: base: Shift refcount decrement in of_find_last_cache_level()
  dt-bindings: leds: Add MediaTek MT6370 flashlight
  dt-bindings: leds: mt6370: Add MediaTek MT6370 current sink type LED indicator
  dt-bindings: mailbox: Convert mtk-gce to DT schema
  of: base: make of_device_compatible_match() accept const device node
  of: Fix "dma-ranges" handling for bus controllers
  of: fdt: Remove unused struct fdt_scan_status
  dt-bindings: display: st,stm32-dsi: Handle data-lanes in DSI port node
  dt-bindings: timer: Add power-domains for TI timer-dm on K3
  dt: Add a check for undocumented compatible strings in kernel
  kbuild: take into account DT_SCHEMA_FILES changes while checking dtbs
  dt-bindings: interrupt-controller: migrate MIPS CPU interrupt controller text bindings to YAML
  dt-bindings: i2c: migrate mt7621 text bindings to YAML
  dt-bindings: power: gpcv2: correct patternProperties
  dt-bindings: virtio: Convert virtio,pci-iommu to DT schema
  dt-bindings: timer: arm,arch_timer: Allow dual compatible string
  dt-bindings: arm: cpus: Add kryo240 compatible
  dt-bindings: display: bridge: nxp,tda998x: Convert to json-schema
  dt-bindings: nvmem: u-boot,env: add basic NVMEM cells
  dt-bindings: remoteproc: qcom,adsp: enforce smd-edge schema
  ...
of: fdt: Remove unused struct fdt_scan_status 2022-09-29T22:29:19+00:00 Yuan Can yuancan@huawei.com 2022-09-27T13:37:39+00:00 17005609548f1f0204cbfc988b325533470e585c After commit bba04d965d06("of/fdt: remove unused of_scan_flat_dt_by_path"), no one use struct fdt_scan_status, so remove it. Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Link: https://lore.kernel.org/r/20220927133739.98493-1-yuancan@huawei.com Signed-off-by: Rob Herring <robh@kernel.org> 
After commit bba04d965d06("of/fdt: remove unused of_scan_flat_dt_by_path"), no
one use struct fdt_scan_status, so remove it.

Signed-off-by: Yuan Can <yuancan@huawei.com>
Reviewed-by: Frank Rowand <frank.rowand@sony.com>
Link: https://lore.kernel.org/r/20220927133739.98493-1-yuancan@huawei.com
Signed-off-by: Rob Herring <robh@kernel.org>
of/fdt: Don't calculate initrd size from DT if start > end 2022-09-09T13:11:46+00:00 Marek Bykowski marek.bykowski@gmail.com 2022-09-09T02:33:57+00:00 d5e3050c0feb8bf7b9a75482fafcc31b90257926 If the properties 'linux,initrd-start' and 'linux,initrd-end' of the chosen node populated from the bootloader, eg. U-Boot, are so that start > end, then the phys_initrd_size calculated from end - start is negative that subsequently gets converted to a high positive value for being unsigned long long. Then, the memory region with the (invalid) size is added to the bootmem and attempted being paged in paging_init() that results in the kernel fault. For example, on the FVP ARM64 system I'm running, the U-Boot populates the 'linux,initrd-start' with 8800_0000 and 'linux,initrd-end' with 0. The phys_initrd_size calculated is then ffff_ffff_7800_0000 (= 0 - 8800_0000 = -8800_0000 + ULLONG_MAX + 1). paging_init() then attempts to map the address 8800_0000 + ffff_ffff_7800_0000 and oops'es as below. It should be stressed, it is generally a fault of the bootloader's with the kernel relying on it, however we should not allow the bootloader's misconfiguration to lead to the kernel oops. Not only the kernel should be bullet proof against it but also finding the root cause of the paging fault spanning over the bootloader, DT, and kernel may happen is not so easy. Unable to handle kernel paging request at virtual address fffffffefe43c000 Mem abort info: ESR = 0x96000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000007 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000 [fffffffefe43c000] pgd=0000000080de9003, pud=0000000080de9003 Unable to handle kernel paging request at virtual address ffffff8000de9f90 Mem abort info: ESR = 0x96000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000 [ffffff8000de9f90] pgd=0000000000000000, pud=0000000000000000 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.51-yocto-standard #1 Hardware name: FVP Base (DT) pstate: 60000085 (nZCv daIf -PAN -UAO) pc : show_pte+0x12c/0x1b4 lr : show_pte+0x100/0x1b4 sp : ffffffc010ce3b30 x29: ffffffc010ce3b30 x28: ffffffc010ceed80 x27: fffffffefe43c000 x26: fffffffefe43a028 x25: 0000000080bf0000 x24: 0000000000000025 x23: ffffffc010b8d000 x22: ffffffc010e3d000 x23: ffffffc010b8d000 x22: ffffffc010e3d000 x21: 0000000080de9000 x20: ffffff7f80000f90 x19: fffffffefe43c000 x18: 0000000000000030 x17: 0000000000001400 x16: 0000000000001c00 x15: ffffffc010cef1b8 x14: ffffffffffffffff x13: ffffffc010df1f40 x12: ffffffc010df1b70 x11: ffffffc010ce3b30 x10: ffffffc010ce3b30 x9 : 00000000ffffffc8 x8 : 0000000000000000 x7 : 000000000000000f x6 : ffffffc010df16e8 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff x2 : 0000000000000000 x1 : 0000008080000000 x0 : ffffffc010af1d68 Call trace: show_pte+0x12c/0x1b4 die_kernel_fault+0x54/0x78 __do_kernel_fault+0x11c/0x128 do_translation_fault+0x58/0xac do_mem_abort+0x50/0xb0 el1_da+0x1c/0x90 __create_pgd_mapping+0x348/0x598 paging_init+0x3f0/0x70d0 setup_arch+0x2c0/0x5d4 start_kernel+0x94/0x49c Code: 92748eb5 900052a0 9135a000 cb010294 (f8756a96)  Signed-off-by: Marek Bykowski <marek.bykowski@gmail.com> Link: https://lore.kernel.org/r/20220909023358.76881-1-marek.bykowski@gmail.com Signed-off-by: Rob Herring <robh@kernel.org> 
If the properties 'linux,initrd-start' and 'linux,initrd-end' of
the chosen node populated from the bootloader, eg. U-Boot, are so that
start > end, then the phys_initrd_size calculated from end - start is
negative that subsequently gets converted to a high positive value for
being unsigned long long. Then, the memory region with the (invalid)
size is added to the bootmem and attempted being paged in paging_init()
that results in the kernel fault.

For example, on the FVP ARM64 system I'm running, the U-Boot populates
the 'linux,initrd-start' with 8800_0000 and 'linux,initrd-end' with 0.
The phys_initrd_size calculated is then ffff_ffff_7800_0000
(= 0 - 8800_0000 = -8800_0000 + ULLONG_MAX + 1). paging_init() then
attempts to map the address 8800_0000 + ffff_ffff_7800_0000 and oops'es
as below.

It should be stressed, it is generally a fault of the bootloader's with
the kernel relying on it, however we should not allow the bootloader's
misconfiguration to lead to the kernel oops. Not only the kernel should be
bullet proof against it but also finding the root cause of the paging
fault spanning over the bootloader, DT, and kernel may happen is not so
easy.

  Unable to handle kernel paging request at virtual address fffffffefe43c000
  Mem abort info:
    ESR = 0x96000007
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
  Data abort info:
    ISV = 0, ISS = 0x00000007
    CM = 0, WnR = 0
  swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000
  [fffffffefe43c000] pgd=0000000080de9003, pud=0000000080de9003
  Unable to handle kernel paging request at virtual address ffffff8000de9f90
  Mem abort info:
    ESR = 0x96000005
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
  Data abort info:
    ISV = 0, ISS = 0x00000005
    CM = 0, WnR = 0
  swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000
  [ffffff8000de9f90] pgd=0000000000000000, pud=0000000000000000
  Internal error: Oops: 96000005 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.51-yocto-standard #1
  Hardware name: FVP Base (DT)
  pstate: 60000085 (nZCv daIf -PAN -UAO)
  pc : show_pte+0x12c/0x1b4
  lr : show_pte+0x100/0x1b4
  sp : ffffffc010ce3b30
  x29: ffffffc010ce3b30 x28: ffffffc010ceed80
  x27: fffffffefe43c000 x26: fffffffefe43a028
  x25: 0000000080bf0000 x24: 0000000000000025
  x23: ffffffc010b8d000 x22: ffffffc010e3d000
  x23: ffffffc010b8d000 x22: ffffffc010e3d000
  x21: 0000000080de9000 x20: ffffff7f80000f90
  x19: fffffffefe43c000 x18: 0000000000000030
  x17: 0000000000001400 x16: 0000000000001c00
  x15: ffffffc010cef1b8 x14: ffffffffffffffff
  x13: ffffffc010df1f40 x12: ffffffc010df1b70
  x11: ffffffc010ce3b30 x10: ffffffc010ce3b30
  x9 : 00000000ffffffc8 x8 : 0000000000000000
  x7 : 000000000000000f x6 : ffffffc010df16e8
  x5 : 0000000000000000 x4 : 0000000000000000
  x3 : 00000000ffffffff x2 : 0000000000000000
  x1 : 0000008080000000 x0 : ffffffc010af1d68
  Call trace:
   show_pte+0x12c/0x1b4
   die_kernel_fault+0x54/0x78
   __do_kernel_fault+0x11c/0x128
   do_translation_fault+0x58/0xac
   do_mem_abort+0x50/0xb0
   el1_da+0x1c/0x90
   __create_pgd_mapping+0x348/0x598
   paging_init+0x3f0/0x70d0
   setup_arch+0x2c0/0x5d4
   start_kernel+0x94/0x49c
  Code: 92748eb5 900052a0 9135a000 cb010294 (f8756a96) 

Signed-off-by: Marek Bykowski <marek.bykowski@gmail.com>
Link: https://lore.kernel.org/r/20220909023358.76881-1-marek.bykowski@gmail.com
Signed-off-by: Rob Herring <robh@kernel.org>
of: move from strlcpy with unused retval to strscpy 2022-08-22T20:01:26+00:00 Wolfram Sang wsa+renesas@sang-engineering.com 2022-08-18T21:00:53+00:00 7a12dd077e5207d72fadaabf7d4520bd3af84082 Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220818210054.7157-1-wsa+renesas@sang-engineering.com 
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.

Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220818210054.7157-1-wsa+renesas@sang-engineering.com
of: fdt: fix off-by-one error in unflatten_dt_nodes() 2022-08-16T17:29:57+00:00 Sergey Shtylyov s.shtylyov@omp.ru 2022-08-13T20:34:16+00:00 2f945a792f67815abca26fa8a5e863ccf3fa1181 Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflatten_dt_nodes() which makes it possible to overflow the nps[] buffer... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/7c354554-006f-6b31-c195-cdfe4caee392@omp.ru 
Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")
forgot to fix up the depth check in the loop body in unflatten_dt_nodes()
which makes it possible to overflow the nps[] buffer...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.

Fixes: 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/7c354554-006f-6b31-c195-cdfe4caee392@omp.ru