Re: [PATCH v3 2/2] arm64: dts: freescale: add MR-NAVQ95 basic board support

[Laurentiu Mihalcea <laurentiumihalcea111@gmail.com>]

On 9/1/2026 6:27 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] Missing memory node in device tree
> - [Medium] Missing USB controller and Type-C implementation
> --
> 
> commit 3130a84e68bcdc800ca07e4c01ec3d00e67a37c4
> Author: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> 
> arm64: dts: freescale: add MR-NAVQ95 basic board support
> 
> This commit adds basic device tree support for the NXP MR-NAVQ95 board
> based on the i.MX95 SoC. It defines initial aliases, chosen nodes,
> regulators, and various pin configurations.
> 
>>    Add basic support for NXP's MR-NAVQ95 board. This board is designed for
>>    robotics applications (e.g. drones, rovers, humanoids, etc..) and has the
>>    following hardware feats (list is not exhaustive):
>>    
>>    * based on i.MX95 19x19 SoC
>>    * 64GB eMMC
>>    * up to 16GB of LPDDR5 memory
>>    * 1 x USB 2.0 TypeC
>>    * 1 x USB 3.0 TypeC
>>    * 1 x RJ45 port with RTL8211 PHY
> 
> [Severity: Medium]
> The commit message claims hardware features of 1 x USB 2.0 TypeC and 1 x USB 3.0
> TypeC, but looking at the device tree file, it completely omits any USB nodes
> or Type-C definitions. Will this leave the USB ports non-functional in Linux,
> and should they be added to match the hardware description?

This is intentional. USB nodes will be added later on.

> 
>> diff --git a/arch/arm64/boot/dts/freescale/imx95-navq.dts b/arch/arm64/boot/dts/freescale/imx95-navq.dts
>> new file mode 100644
>> index 0000000000000..1366dc2d2bfa4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/imx95-navq.dts
>> @@ -0,0 +1,222 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright 2026 NXP
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "imx95.dtsi"
>> +
>> +/ {
>> +	model = "NXP MR-NAVQ95";
>> +	compatible = "fsl,imx95-navq", "fsl,imx95";
>> +
>> +	aliases {
> 
> [Severity: Medium]
> Should there be a memory node defined here at the root level (e.g.,
> memory@80000000)? Omitting the memory node breaks standard DT conventions for
> root nodes and can cause boot failures if the bootloader expects an existing
> node to update and does not dynamically inject it from scratch.
> 

ACK. To be fixed in V4.