Re: [PATCH v6 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing `idle-state = <6>;` on the PCA9548 I2C mux on `i2c4` breaks asynchronous MCTP traffic.
- [Low] The new board compatible string `facebook,ventura2-rmc` is not documented in the device tree bindings.
--

commit 5d6ee3a97cd79459755cb6b05c8802e4c5d63cab
Author: Kyle Hsieh <kylehsieh1995@gmail.com>

ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC

Add linux device tree entry related to the Meta(Facebook) rmc-node.
The system uses an AT2600 BMC. This node is named "ventura2".

> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> new file mode 100644
> index 0000000000000..1111daa22f73e
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> @@ -0,0 +1,2891 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2023 Facebook Inc.
> +/dts-v1/;
> +
> +#include "aspeed-g6.dtsi"
> +#include <dt-bindings/i2c/i2c.h>
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +
> +/ {
> +	model = "Facebook Ventura2 RMC";
> +	compatible = "facebook,ventura2-rmc", "aspeed,ast2600";

[Severity: Low]
Is this new board compatible string documented in the device tree bindings?
Without documentation (e.g., in
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml), dtbs_check might
fail to validate the device tree.

[ ... ]

> +&i2c4 {
> +	status = "okay";
> +	multi-master;
> +	mctp-controller;
> +	mctp0: mctp@10 {
> +		compatible = "mctp-i2c-controller";
> +		reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
> +	};
> +
> +	i2c-mux@77 {
> +		compatible = "nxp,pca9548";
> +		reg = <0x77>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;

[Severity: High]
Does this PCA9548 multiplexer require an idle-state property?

Channel 1 connects to polled temperature sensors, while channel 6 is marked
with mctp-controller to receive asynchronous MCTP packets. If the mux is left
without an idle-state = <6>; configuration, will it remain physically parked
on channel 1 after routine temperature polling?

If so, could this cause any subsequent asynchronous MCTP traffic arriving on
channel 6 to hit the disabled mux channel and be permanently dropped?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-ventura2_initial_dts-v6-0-375d8e9d7ebf@gmail.com?part=2