linux-stable.git/drivers/of, branch linux-5.18.y

of/fdt: declared return type does not match actual return type

2022-08-17T12:41:56+00:00

[ Upstream commit 7913145afa51bbed9eaf8e5b4ee55fa9884a71e5 ]

The commit 649cab56de8e (“of: properly check for error returned
by fdt_get_name()”) changed the return value type from bool to int,
but forgot to change the return value simultaneously.

populate_node was only called in unflatten_dt_nodes, and returns
with values greater than or equal to 0 were discarded without further
processing. Considering that return 0 usually indicates success,
return 0 instead of return true.

Fixes: 649cab56de8e (“of: properly check for error returned by fdt_get_name()”)
Signed-off-by: Xu Qiang 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20220801120506.11461-2-xuqiang36@huawei.com
Signed-off-by: Sasha Levin

of: device: Fix missing of_node_put() in of_dma_set_restricted_buffer

2022-08-17T12:41:46+00:00

[ Upstream commit d17e37c41b7ed38459957a5d2968ba61516fd5c2 ]

We should use of_node_put() for the reference 'node' returned by
of_parse_phandle() which will increase the refcount.

Fixes: fec9b625095f ("of: Add plumbing for restricted DMA pool")
Co-authored-by: Miaoqian Lin 
Signed-off-by: Liang He 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20220702014449.263772-1-windhl@126.com
Signed-off-by: Sasha Levin

of: check previous kernel's ima-kexec-buffer against memory bounds

2022-08-17T12:41:18+00:00

[ Upstream commit cbf9c4b9617b6767886a913705ca14b7600c77db ]

Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:

$ sudo kexec --initrd initrd vmlinux --append='mem=16G'


 BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
 Faulting instruction address: 0xc000000000837974
 Oops: Kernel access of bad area, sig: 11 [#1]

 NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 Call Trace:
 [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
 [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
 Instruction dump:
 f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
 7c0802a6 fb610198 7c9b2378 f80101d0  2c090001 40820614 e9240010
 ---[ end trace 0000000000000000 ]---

Fix this issue by checking returned PFN range of previous kernel's
ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.

Fixes: 467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous kernel")
Cc: Frank Rowand 
Cc: Prakhar Srivastava 
Cc: Lakshmi Ramasubramanian 
Cc: Thiago Jung Bauermann 
Cc: Rob Herring 
Cc: Ritesh Harjani 
Cc: Robin Murphy 
Signed-off-by: Vaibhav Jain 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20220531041446.3334259-1-vaibhav@linux.ibm.com
Signed-off-by: Sasha Levin

of: overlay: do not break notify on NOTIFY_{OK|STOP}

2022-06-09T08:30:02+00:00

[ Upstream commit 5f756a2eaa4436d7d3dc1e040147f5e992ae34b5 ]

We should not break overlay notifications on NOTIFY_{OK|STOP}
otherwise we might break on the first fragment. We should only stop
notifications if a *real* errno is returned by one of the listeners.

Fixes: a1d19bd4cf1fe ("of: overlay: pr_err from return NOTIFY_OK to overlay apply/remove")
Signed-off-by: Nuno Sá 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20220420130205.89435-1-nuno.sa@analog.com
Signed-off-by: Sasha Levin

of/fdt: Ignore disabled memory nodes

2022-06-09T08:29:45+00:00

[ Upstream commit df5cd369876114f91f9ae60658fea80acfb15890 ]

When we boot a machine using a devicetree, the generic DT code goes
through all nodes with a 'device_type = "memory"' property, and collects
all memory banks mentioned there. However it does not check for the
status property, so any nodes which are explicitly "disabled" will still
be added as a memblock.
This ends up badly for QEMU, when booting with secure firmware on
arm/arm64 machines, because QEMU adds a node describing secure-only
memory:
===================
	secram@e000000 {
		secure-status = "okay";
		status = "disabled";
		reg = <0x00 0xe000000 0x00 0x1000000>;
		device_type = "memory";
	};
===================

The kernel will eventually use that memory block (which is located below
the main DRAM bank), but accesses to that will be answered with an
SError:
===================
[    0.000000] Internal error: synchronous external abort: 96000050 [#1] PREEMPT SMP
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc6-00014-g10c8acb8b679 #524
[    0.000000] Hardware name: linux,dummy-virt (DT)
[    0.000000] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    0.000000] pc : new_slab+0x190/0x340
[    0.000000] lr : new_slab+0x184/0x340
[    0.000000] sp : ffff80000a4b3d10
....
==================
The actual crash location and call stack will be somewhat random, and
depend on the specific allocation of that physical memory range.

As the DT spec[1] explicitly mentions standard properties, add a simple
check to skip over disabled memory nodes, so that we only use memory
that is meant for non-secure code to use.

That fixes booting a QEMU arm64 VM with EL3 enabled ("secure=on"), when
not using UEFI. In this case the QEMU generated DT will be handed on
to the kernel, which will see the secram node.
This issue is reproducible when using TF-A together with U-Boot as
firmware, then booting with the "booti" command.

When using U-Boot as an UEFI provider, the code there [2] explicitly
filters for disabled nodes when generating the UEFI memory map, so we
are safe.
EDK/2 only reads the first bank of the first DT memory node [3] to learn
about memory, so we got lucky there.

[1] https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter3-devicenodes.rst#memory-node (after the table)
[2] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/fdtdec.c#L1061-1063
[3] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/PrePi/FdtParser.c

Reported-by: Ross Burton 
Signed-off-by: Andre Przywara 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20220517101410.3493781-1-andre.przywara@arm.com
Signed-off-by: Sasha Levin

of: Support more than one crash kernel regions for kexec -s

2022-06-09T08:29:40+00:00

[ Upstream commit 8af6b91f58341325bf74ecb0389ddc0039091d84 ]

When "crashkernel=X,high" is used, there may be two crash regions:
high=crashk_res and low=crashk_low_res. But now the syscall
kexec_file_load() only add crashk_res into "linux,usable-memory-range",
this may cause the second kernel to have no available dma memory.

Fix it like kexec-tools does for option -c, add both 'high' and 'low'
regions into the dtb.

Signed-off-by: Zhen Lei 
Acked-by: Rob Herring 
Acked-by: Baoquan He 
Link: https://lore.kernel.org/r/20220506114402.365-6-thunder.leizhen@huawei.com
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

Merge tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2022-03-28T19:27:35+00:00

Pull char/misc and other driver updates from Greg KH:
 "Here is the big set of char/misc and other small driver subsystem
  updates for 5.18-rc1.

  Included in here are merges from driver subsystems which contain:

   - iio driver updates and new drivers

   - fsi driver updates

   - fpga driver updates

   - habanalabs driver updates and support for new hardware

   - soundwire driver updates and new drivers

   - phy driver updates and new drivers

   - coresight driver updates

   - icc driver updates

  Individual changes include:

   - mei driver updates

   - interconnect driver updates

   - new PECI driver subsystem added

   - vmci driver updates

   - lots of tiny misc/char driver updates

  All of these have been in linux-next for a while with no reported
  problems"

* tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (556 commits)
  firmware: google: Properly state IOMEM dependency
  kgdbts: fix return value of __setup handler
  firmware: sysfb: fix platform-device leak in error path
  firmware: stratix10-svc: add missing callback parameter on RSU
  arm64: dts: qcom: add non-secure domain property to fastrpc nodes
  misc: fastrpc: Add dma handle implementation
  misc: fastrpc: Add fdlist implementation
  misc: fastrpc: Add helper function to get list and page
  misc: fastrpc: Add support to secure memory map
  dt-bindings: misc: add fastrpc domain vmid property
  misc: fastrpc: check before loading process to the DSP
  misc: fastrpc: add secure domain support
  dt-bindings: misc: add property to support non-secure DSP
  misc: fastrpc: Add support to get DSP capabilities
  misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP
  misc: fastrpc: separate fastrpc device from channel context
  dt-bindings: nvmem: brcm,nvram: add basic NVMEM cells
  dt-bindings: nvmem: make "reg" property optional
  nvmem: brcm_nvram: parse NVRAM content into NVMEM cells
  nvmem: dt-bindings: Fix the error of dt-bindings check
  ...

Merge tag 'devicetree-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

2022-03-26T18:41:53+00:00

Pull devicetree updates from Rob Herring:

 - Add Krzysztof Kozlowski as co-maintainer for DT bindings providing
   much needed help.

 - DT schema validation now takes DTB files as input rather than
   intermediate YAML files. This decouples the validation from the
   source level syntax information. There's a bunch of schema fixes as a
   result of switching to DTB based validation which exposed some errors
   and incomplete schemas and examples.

 - Kbuild improvements to explicitly warn users running 'make
   dt_binding_check' on missing yamllint

 - Expand DT_SCHEMA_FILES kbuild variable to take just a partial
   filename or path instead of the full path to 1 file.

 - Convert various bindings to schema format: mscc,vsc7514-switch,
   multiple GNSS bindings, ahci-platform, i2c-at91, multiple UFS
   bindings, cortina,gemini-sata-bridge, cortina,gemini-ethernet, Atmel
   SHA, Atmel TDES, Atmel AES, armv7m-systick, Samsung Exynos display
   subsystem, nuvoton,npcm7xx-timer, samsung,s3c2410-i2c, zynqmp_dma,
   msm/mdp4, rda,8810pl-uart

 - New schemas for u-boot environment variable partition, TI clksel

 - New compatible strings for Renesas RZ/V2L SoC

 - Vendor prefixes for Xen, HPE, deprecated Synopsys, deprecated
   HiSilicon

 - Add/fix schemas for QEMU Arm 'virt' machine

 - Drop unused of_alias_get_alias_list() function

 - Add a script to check DT unittest EXPECT message output. Pass
   messages also now print by default at PR_INFO level to help test
   automation.

* tag 'devicetree-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (96 commits)
  dt-bindings: kbuild: Make DT_SCHEMA_LINT a recursive variable
  dt-bindings: nvmem: add U-Boot environment variables binding
  dt-bindings: ufs: qcom: Add SM6350 compatible string
  dt-bindings: dmaengine: sifive,fu540-c000: include generic schema
  dt-bindings: gpio: pca95xx: drop useless consumer example
  Revert "of: base: Introduce of_alias_get_alias_list() to check alias IDs"
  dt-bindings: virtio,mmio: Allow setting devices 'dma-coherent'
  dt-bindings: gnss: Add two more chips
  dt-bindings: gnss: Rewrite sirfstar binding in YAML
  dt-bindings: gnss: Modify u-blox to use common bindings
  dt-bindings: gnss: Rewrite common bindings in YAML
  dt-bindings: ata: ahci-platform: Add rk3568-dwc-ahci compatible
  dt-bindings: ata: ahci-platform: Add power-domains property
  dt-bindings: ata: ahci-platform: Convert DT bindings to yaml
  dt-bindings: kbuild: Use DTB files for validation
  dt-bindings: kbuild: Pass DT_SCHEMA_FILES to dt-validate
  dt-bindings: Add QEMU virt machine compatible
  dt-bindings: arm: Convert QEMU fw-cfg to DT schema
  dt-bindings: i2c: at91: Add SAMA7G5 compatible strings list
  dt-bindings: i2c: convert i2c-at91 to json-schema
  ...

cma: factor out minimum alignment requirement

2022-03-22T22:57:05+00:00

Patch series "mm: enforce pageblock_order < MAX_ORDER".

Having pageblock_order >= MAX_ORDER seems to be able to happen in corner
cases and some parts of the kernel are not prepared for it.

For example, Aneesh has shown [1] that such kernels can be compiled on
ppc64 with 64k base pages by setting FORCE_MAX_ZONEORDER=8, which will
run into a WARN_ON_ONCE(order >= MAX_ORDER) in comapction code right
during boot.

We can get pageblock_order >= MAX_ORDER when the default hugetlb size is
bigger than the maximum allocation granularity of the buddy, in which
case we are no longer talking about huge pages but instead gigantic
pages.

Having pageblock_order >= MAX_ORDER can only make alloc_contig_range()
of such gigantic pages more likely to succeed.

Reliable use of gigantic pages either requires boot time allcoation or
CMA, no need to overcomplicate some places in the kernel to optimize for
corner cases that are broken in other areas of the kernel.

This patch (of 2):

Let's enforce pageblock_order < MAX_ORDER and simplify.

Especially patch #1 can be regarded a cleanup before:
	[PATCH v5 0/6] Use pageblock_order for cma and alloc_contig_range
	alignment. [2]

[1] https://lkml.kernel.org/r/87r189a2ks.fsf@linux.ibm.com
[2] https://lkml.kernel.org/r/20220211164135.1803616-1-zi.yan@sent.com

Link: https://lkml.kernel.org/r/20220214174132.219303-2-david@redhat.com
Signed-off-by: David Hildenbrand 
Reviewed-by: Zi Yan 
Acked-by: Rob Herring 
Cc: Aneesh Kumar K.V 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Frank Rowand 
Cc: Michael S. Tsirkin 
Cc: Christoph Hellwig 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: Minchan Kim 
Cc: Vlastimil Babka 
Cc: John Garry via iommu 

Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Revert "of: base: Introduce of_alias_get_alias_list() to check alias IDs"

2022-03-21T16:35:29+00:00

This reverts commit b1078c355d76769b5ddefc67d143fbd9b6e52c05.

The single user of of_alias_get_alias_list(),
drivers/tty/serial/xilinx_uartps.c, has since been refactored and no
longer needs this function. It also contained a Smatch checker warning:

 drivers/of/base.c:2038 of_alias_get_alias_list()
 warn: passing negative bit value 's32min-(-2),0-s32max' to 'set_bit()'

Reported-by: Dan Carpenter 
Signed-off-by: Rob Herring