Re: [PATCH v9 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
Kyle Hsieh <[email protected]>
| Newsgroups | org.kernel.vger.linux-kernel,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.ozlabs.lists.linux-aspeed |
|---|---|
| Message-ID | <CAF7HswN1ZzwjfXjG2hV5tEkVZkZYp0CiVNSo_9A4m3tsqQp_Bg@mail.gmail.com> |
Hi Tan, Thanks for the review. On Fri, Aug 21, 2026 at 2:04 AM Tan Siewert <[email protected]> wrote: > > Hi Kyle, > > > Ventura2 is a Rack Management Controller. It is a modular > > device designed to manage liquid cooling systems and monitor hardware > > states within an IT rack. The system uses an AST2600 BMC for management. > > > > RMCv2 serves several critical roles: > > - Detects liquid leakage at both tray and rack levels. > > - Communicates with and controls liquid cooling equipment. > > - Manages leakage events and executes system recovery protocols. > > > > Key hardware features include: > > - An extensive I2C and IO expander topology to support comprehensive > > sensor monitoring and backward compatibility with legacy trays. > > - MCTP over I2C support for asynchronous device communications. > > - A dual-flash design for BMC firmware redundancy. > > > > Signed-off-by: Kyle Hsieh <[email protected]> > > *snip* > > > 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 000000000000..f1273ca31bf8 > > --- /dev/null > > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts > > @@ -0,0 +1,3005 @@ > > +// 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> > > + > > +/ { > > + compatible = "facebook,ventura2-rmc", "aspeed,ast2600"; > > + model = "Facebook Ventura2 RMC"; > > + > > + aliases { > > + /* > > + * Pre-allocate I2C bus aliases for userspace predictability. > > + * Several I2C channels are intentionally left empty in this > > + * DTS as they are strictly reserved for future hardware > > + * feature expansions and add-on boards that will interface > > + * with these busses. > > + */ > > + /* > > + * i2c switch 0-0077, pca9548, 8 child channels assigned > > + * with bus number 16-23. > > + */ > > This alignment is one of the things that seem to be a false-positive for > dt-check-style in strict mode (value-whitespace). See [0] where Krzysztof said > that it may report false-positives, and "Review and investigate warnings from > 'strict' mode, but do not fix them automatically without thinking". > > @Krzysztof wdyt about this one? You're right, and this is a regression I introduced in v9. In v8 these comment blocks used the standard kernel style. While running dt-check-style, I applied the strict-mode output too mechanically and dropped the space before '*' in all 38 comment blocks in the file. I will restore to the standard style in v10. > > > + i2c16 = &i2c0mux0ch0; > > + i2c17 = &i2c0mux0ch1; > > + i2c18 = &i2c0mux0ch2; > > + i2c19 = &i2c0mux0ch3; > > + i2c20 = &i2c0mux0ch4; > > + i2c21 = &i2c0mux0ch5; > > + i2c22 = &i2c0mux0ch6; > > + i2c23 = &i2c0mux0ch7; > > *snip* > > > + spi { > > + compatible = "spi-gpio"; > > + #address-cells = <1>; > > + cs-gpios = <&gpio0 ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>; > > + miso-gpios = <&gpio0 ASPEED_GPIO(Z, 5) GPIO_ACTIVE_HIGH>; > > + mosi-gpios = <&gpio0 ASPEED_GPIO(Z, 4) GPIO_ACTIVE_HIGH>; > > + num-chipselects = <1>; > > + sck-gpios = <&gpio0 ASPEED_GPIO(Z, 3) GPIO_ACTIVE_HIGH>; > > + #size-cells = <0>; > > Shouldn't #address-cells and #size-cells be ordered together? If reported by > dt-check-style as issue, then it might be a false-positive. I will put the two properties back together in v10. Like the comment alignment above, I'll list this as a strict-mode warning I'm not acting on. > > > + > > + tpm@0 { > > + compatible = "infineon,slb9670", "tcg,tpm_tis-spi"; > > + reg = <0>; > > + spi-max-frequency = <33000000>; > > + }; > > + }; > > +}; > > + > > +&adc0 { > > + pinctrl-0 = > > + <&pinctrl_adc0_default &pinctrl_adc1_default > > + &pinctrl_adc2_default &pinctrl_adc3_default > > + &pinctrl_adc4_default &pinctrl_adc5_default > > + &pinctrl_adc6_default &pinctrl_adc7_default>; > > + pinctrl-names = "default"; > > + vref-supply = <&p1v8_bmc_aux>; > > + > > + status = "okay"; > > +}; > > + > > +&adc1 { > > + pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc10_default>; > > + pinctrl-names = "default"; > > + vref-supply = <&p2v5_bmc_aux>; > > + > > + status = "okay"; > > +}; > > + > > +&ehci0 { > > + status = "okay"; > > +}; > > + > > +&ehci1 { > > + status = "okay"; > > +}; > > + > > +&fmc { > > + status = "okay"; > > + > > + flash@0 { > > + label = "bmc"; > > + spi-max-frequency = <50000000>; > > + m25p,fast-read; > > + > > + status = "okay"; > > + #include "openbmc-flash-layout-128.dtsi" > > + }; > > + > > + flash@1 { > > + label = "alt-bmc"; > > + spi-max-frequency = <50000000>; > > + m25p,fast-read; > > + > > + status = "okay"; > > Missing '#include "openbmc-flash-layout-128-alt.dtsi"'? I will add it in v10. > > > + }; > > +}; > > *snip* > > > +&mac2 { > > + phy-mode = "rmii"; > > + pinctrl-0 = <&pinctrl_rmii3_default>; > > + pinctrl-names = "default"; > > + > > + status = "okay"; > > + > > + /* > > + * The Marvell 88E6393X is initialized at boot via EEPROM > > + * configuration and hardware straps. > > + * The BMC connects via an RMII fixed-link; link parameters are fixed > > + * by board design. > > + */ > > This kind of writing gives me the suspicion that it was written with assistance > by an LLM, but I might be wrong. > > Either way, if you have used AI assistance for your series (or only for this > patch), even if you have only used it for the commit message, then you must > declare it via the "Assisted-by" trailer [1][2]. You're right; I used an AI assistant to write this comment. I'll add the Assisted-by trailer in v10. > > > + fixed-link { > > + full-duplex; > > + speed = <100>; > > + }; > > +}; > > + > > +&mac3 { > > + pinctrl-0 = <&pinctrl_rmii4_default>; > > + pinctrl-names = "default"; > > + use-ncsi; > > + > > + status = "okay"; > > +}; > > + > > +&peci0 { > > + status = "okay"; > > +}; > > You mentioned that this is a rack management controller. Does it really require > PECI? It does. Ventura2 can be populated with a COM Express module, and &peci0, &kcs3 and &lpc_ctrl describe that path, so I'd like to keep them. I will add a comment in v10 explaining this, so it's clear from the DTS itself. For the record, the v5 changelog claimed &peci0 had been removed. That was incorrect; the node was never actually dropped. Apologies for the confusion that may have caused when reading through the series. > > > + > > +&sgpiom0 { > > + bus-frequency = <100000>; > > + gpio-line-names = > > + /*"input pin","output pin"*/ > > + /*A0 - A7*/ > > + "power-chassis-good","FM_PLD_HEARTBEAT_LVC3_R", > > + "host0-ready","R_BMC_PTH_RST_BTN_L", > > + "CONTROL_VT2_SUPPLY1_CLOSE","FM_MDIO_SW_SEL_PLD", > > + "CONTROL_VT2_SUPPLY2_CLOSE","FM_88E6393X_BIN_UPDATE_EN_N", > > + "CONTROL_VT2_SUPPLY3_CLOSE","Sequence_TransFR_Alert", > > Why's "Sequence_TransFR_Alert" written in camelcase? An oversight; it should be consistent with the surrounding names. I will renamed to "SEQUENCE_TRANSFR_ALERT" in v10. Thanks again for the thorough review. Kyle Hsieh