[202608] Resolve kernel code-sync conflicts for 288cc3645d5d

config.local/arm64/config.sonic-aspeed

@@ -105,10 +105,10 @@ CONFIG_CRYPTO_DEV_ASPEED=y
 # CONFIG_CRYPTO_DEV_ASPEED_HACE is not set
 # CONFIG_CRYPTO_DEV_ASPEED_RSSS is not set
 # CONFIG_CRYPTO_DEV_ASPEED_ECDSA is not set
+CONFIG_MODVERSIONS=y
 
 ###-> nvidia_aspeed_bmc-start
-CONFIG_MODVERSIONS=y
-CONFIG_MCTP=y
+CONFIG_MTD_PHRAM=y
 CONFIG_CHR_DEV_SG=y
 CONFIG_REALTEK_PHY=m
 CONFIG_USB_USBNET=y
@@ -145,28 +145,20 @@ CONFIG_PSTORE_RAM=y
 CONFIG_LSUSB=y
 CONFIG_USB_ETH_RNDIS=y
 CONFIG_USB_ASPEED=y
-CONFIG_SPI_ASPEED_TXRX=y
 CONFIG_SPI_ASPEED_SMC=y
 CONFIG_SPI_FMC=m
 CONFIG_FIXED_PHY_APPLY=y
 CONFIG_FIXED_PHY_SPEED=100
 CONFIG_FIXED_PHY_FULL_DUPLEX=y
 CONFIG_FTGMAC100_FIXED_PHY_SPEED=100
 CONFIG_FTGMAC100_FIXED_PHY_FULL_DUPLEX=1
-CONFIG_ASPEED_MCTP=y
 CONFIG_JTAG=y
 CONFIG_JTAG_ASPEED=y
-CONFIG_COMMON_CLK_AST2700=y
-CONFIG_AST2700_RTC_OVER_ESPI=y
 CONFIG_AST2700_MBOX=y
 CONFIG_RTL_RGMII_SGMII_3809=y
 CONFIG_HID_CP2112=m
 CONFIG_GPIO_SYSFS=y
-CONFIG_GPIO_ASPEED_SGPIO=y
-CONFIG_ASPEED_LPC_SNOOP=y
-CONFIG_AST2700_ESPI=y
 CONFIG_MISC_DEVICES=y
-CONFIG_ASPEED_UART_ROUTING=y
 CONFIG_FTGMAC100=m
 CONFIG_SENSORS_LM25066=m
 CONFIG_SENSORS_MP2855=m
@@ -194,4 +186,3 @@ CONFIG_NVSW_BMC_HID162=m
 CONFIG_I2C_MUX_REGMAP=y
 CONFIG_PCIE_PME=n
 ###-> nvidia_aspeed_bmc-end
-

patches-sonic/0008-arm64-dts-aspeed-spc6-bmc-ext-phram-env-tpm-i3c-pull.patch

@@ -0,0 +1,160 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Dvir Zaguri <dzaguri@nvidia.com>
+Date: Sun, 31 May 2026 10:15:00 +0300
+Subject: [PATCH 6.12 1/1] arm64: dts: aspeed: spc6-bmc: phram-env, TPM init,
+ GPIO expander reset, I3C pull-ups
+
+Extend arch/arm64/boot/dts/aspeed/aspeed-nvidia-spc6-bmc.dts
+(AST2700-A2 SPC6 CPU BMC) with four downstream fixes taken from
+the OpenBMC Switch-26.05-1_br branch. Only the kernel DTS hunks
+from each commit are taken; the matching userspace / U-Boot /
+kconfig changes live in their own layers and are out of scope.
+
+  51f092d656fbe81d704036246fad43a186d008fb
+  "L1 Switch: SPC6 AST2700 BMC: move recovery counter to phram-env"
+  Dmitrijs Novikovs <dnovikovs@nvidia.com>, May 12 2026
+
+    * Reserve a 4 KiB phram region (phram_env @ 0x4_237ff000), one
+      page below bmc-dev0, inside reserved-memory. fw_env now points
+      at /dev/mtd/by-name/phram-env so the recovery counter and the
+      rest of the U-Boot env survive warm boots.
+
+  2c97dad11108b1ceaedadd0762f3ef342b06abe9
+  "L1 Switch: SPC6 AST2700 BMC: fix TPM GPIO init"
+  Sergejs Hatinecs <shatinecs@nvidia.com>, May 28 2026
+
+    * Add two gpio-hogs (spi-buf-oe, spi-tpm-buf-oe) on the i2c5
+      pcal6524 (exp0) to drive GP_BMC_SPI_BUF_OE_L (pin 4) and
+      GP_BMC_SPI_TPM_BUF_OE_L (pin 5) low at gpiochip registration,
+      enabling the SPI and SPI/TPM level shifters before any SPI
+      probe touches the bus.
+    * Add a private buf-en-link-gpios property on tpm@1 pointing at
+      the same two exp0 pins. The property is intentionally NOT
+      consumed by any driver -- it exists solely as an fw_devlink
+      ordering hint so tpm@1 cannot probe until exp0 has probed and
+      its hogs have run. This kills the "no TPM found" race between
+      the i2c5 and spi0 buses.
+
+  d406755fdf8bd1421095b6470bc1ca47e35697b6
+  "L1 Switch: SPC6 AST2700 BMC: fix GPIO expander"
+  Sergejs Hatinecs <shatinecs@nvidia.com>, May 29 2026
+
+    * Add reset-gpios to the i2c5 pcal6524 (exp0) pointing at
+      GP_BMC_GPIO_EXP_RESET_L (gpio1 bank S, line 0, active-low),
+      so the pcal6524 driver pulse-resets the expander at probe and
+      starts it in a known state. Without this the expander could
+      stay wedged from a previous boot, breaking the SPI/TPM buffer
+      hogs, the mdio2 PHY reset (driven through &exp0 10) and the
+      WP / MUX-select lines that ride on the same expander.
+
+  2e6c7a8a27033a696505425384d8f5551aa86a36
+  "L1 Switch: SPC6 AST2700: Enable I3C internal pull-ups via DT"
+  Dmitrijs Novikovs <dnovikovs@nvidia.com>, May 15 2026
+
+    * Add internal-pullup = <1> to &i3c1 so the SoC drives the I3C
+      bus pull-ups and the controller comes up at boot without the
+      previous late user-space bind workaround.
+
+Signed-off-by: Dvir Zaguri <dzaguri@nvidia.com>
+---
+ .../boot/dts/aspeed/aspeed-nvidia-spc6-bmc.dts     | 59 ++++++++++++++++++++++
+ 1 file changed, 59 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/aspeed/aspeed-nvidia-spc6-bmc.dts b/arch/arm64/boot/dts/aspeed/aspeed-nvidia-spc6-bmc.dts
+--- a/arch/arm64/boot/dts/aspeed/aspeed-nvidia-spc6-bmc.dts
++++ b/arch/arm64/boot/dts/aspeed/aspeed-nvidia-spc6-bmc.dts
+@@ -29,6 +29,15 @@
+ 		ranges;
+
+ 		#include "ast2700-reserved-mem.dtsi"
++
++		// (before bmc-dev0 @0x423800000).
++		// Persistent phram region for fw_env variables across warm boots.
++		phram_env: phram-env@4237ff000 {
++			compatible = "phram";
++			label = "phram-env";
++			reg = <0x00000004 0x237ff000 0x0 0x00001000>;
++			no-map;
++		};
+ 	};
+ };
+
+@@ -55,6 +64,30 @@
+ 		compatible = "st,st33htpm-spi", "infineon,slb9670", "tcg,tpm_tis-spi";
+ 		reg = <1>;
+ 		spi-max-frequency = <10000000>;
++		/*
++		 * NOTE: this property is NOT consumed by any driver. Stock
++		 * tpm_tis_spi (and all other drivers matching the compatibles
++		 * above) does not call gpiod_get() for this name. That is
++		 * intentional -- the SPI/TPM level shifters are enabled by the
++		 * gpio-hogs on exp0 (see below), not by this device.
++		 *
++		 * It is kept purely as an fw_devlink ordering hint: any property
++		 * whose name ends in "-gpios" is parsed by the DT core to build
++		 * a supplier/consumer link. The phandle to exp0 therefore makes
++		 * exp0 a supplier of tpm@1, so tpm@1 is not probed until the
++		 * pcal6524 has probed and its hogs have run. Without this hint
++		 * there is no ordering between the i2c5 and spi0 buses, and the
++		 * TPM could be accessed before the buffers are enabled (races to
++		 * "no TPM found"). Do not delete it.
++		 *
++		 * The property name is deliberately a private one
++		 * ("buf-en-link-gpios") that no upstream driver consumes. If
++		 * the property were called "enable-gpios" and a future kernel
++		 * added gpiod_get(dev, "enable", ...) to tpm_tis_spi, it would
++		 * collide with the hogs and fail -EBUSY.
++		 */
++		buf-en-link-gpios = <&exp0 4 GPIO_ACTIVE_LOW>,
++				    <&exp0 5 GPIO_ACTIVE_LOW>;
+ 	};
+ };
+
+@@ -243,6 +276,7 @@
+ 		#gpio-cells = <2>;
+ 		#address-cells = <1>;
+ 		#size-cells = <0>;
++		reset-gpios = <&gpio1 ASPEED_GPIO(S, 0) GPIO_ACTIVE_LOW>; /*GPIO_BMC_GPIO_EXP_RESET_L*/
+
+ 		gpio-line-names =
+ 			"RSRVD_0", "GP_EROT_RST_IN_L",
+@@ -257,6 +291,30 @@
+ 			"RSRVD_7", "GP_PROD_CS_FLASH0_EN",
+ 			"RSRVD_8", "GP_PROD_CS_FLASH1_EN",
+ 			"RSRVD_9", "RSRVD_10";
++		/*
++		 * Enable the SPI/TPM level shifters at gpiochip registration,
++		 * i.e. during this node's probe -- before tpm@1 (ordered after
++		 * us via the buf-en-link-gpios phandle above) touches
++		 * the bus.
++		 *
++		 * POLARITY: these nets are active-low (..._OE_L), so physical low
++		 * enables the buffer. In a gpio-hog, output-low/output-high are
++		 * LOGICAL values and are inverted by GPIO_ACTIVE_LOW. Therefore
++		 * "output-high" = logical 1 = physical low = buffer ENABLED.
++		 * Using "output-low" here would drive the pin high and DISABLE
++		 * the buffers -- the opposite of what we want.
++		 */
++		spi-buf-oe {
++			gpio-hog;
++			gpios = <4 GPIO_ACTIVE_LOW>;	/* GP_BMC_SPI_BUF_OE_L     */
++			output-high;			/* -> physical low -> enabled */
++		};
++
++		spi-tpm-buf-oe {
++			gpio-hog;
++			gpios = <5 GPIO_ACTIVE_LOW>;	/* GP_BMC_SPI_TPM_BUF_OE_L */
++			output-high;			/* -> physical low -> enabled */
++		};
+ 	};
+ };
+
+@@ -463,5 +521,6 @@
+ 	status = "okay";
+ 	pinctrl-names = "default";
+ 	i3c-scl-hz = <12500000>;
++	internal-pullup = <1>;
+ 	mctp-controller;
+ };
+-- 
+2.34.1