Re: [PATCH] arm64: dts: altera: move all SoCFPGA device trees from dts/intel

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Silent change to the deployed dtbs_install path for the migrated dtbs.
- [Low] Stale MAINTAINERS entry scopes arch/arm64/boot/dts/intel/ to SoCFPGA maintainers.
--

commit 49f800875761e8815d7059a16da432b877f9c50f
Author: Chiam, Evon <evon.chiam@altera.com>

arm64: dts: altera: move all SoCFPGA device trees from dts/intel

This commit moves all Altera SoCFPGA device trees from dts/intel/ to
dts/altera/, leaving only the Keembay platform files in dts/intel/. The
move involves renaming the files and updating the respective Makefiles.

Link: https://lore.kernel.org/all/cd16fb78-551e-4630-83d6-a44a68e2e411@kernel.org/

>     Move the remaining SoCFPGA DTS/DTSI files from dts/intel/ to dts/altera/
>     to consolidate all Altera SoCFPGA device trees under a single
>     directory. Only the Keembay files remain in dts/intel/.

[Severity: Low]
Does this leave a stale entry in the MAINTAINERS file?

The SoCFPGA architecture entry currently covers F: arch/arm64/boot/dts/intel/.
Since only Keembay files remain there, will this falsely CC SoCFPGA maintainers
on patches modifying Keembay platforms?

> diff --git a/arch/arm64/boot/dts/altera/Makefile b/arch/arm64/boot/dts/altera/Makefile
> index 540bb5ae746b3..8f41349103b80 100644
> --- a/arch/arm64/boot/dts/altera/Makefile
> +++ b/arch/arm64/boot/dts/altera/Makefile
> @@ -1,5 +1,17 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> -dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_stratix10_socdk.dtb \
> +dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \

[Severity: Medium]
Will this implicitly change the deployed path during dtbs_install?

Running make dtbs_install on ARM64 typically mirrors the source vendor
directory structure. Compiling these dtbs from the altera/ Makefile would
shift their target installation directory from intel/ to altera/.

Could this cause bootloaders (like U-Boot) or deployment scripts that have
hardcoded configurations expecting the intel/ vendor prefix to fail to find
the DTB and fail to boot? This seems to contradict the commit message's claim
that "The set of DTBs produced by dtbs_install is unchanged".

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/802bf0d27fbff9b1ddb6b9fc323a1a9f8f050f74.1788512748.git.evon.chiam@altera.com?part=1