Nexthop sync 6.12.94 update - #29
Open
chander-nexthop wants to merge 224 commits into
Open
chander-nexthop wants to merge 224 commits into
chander-nexthop wants to merge 224 commits into
Conversation
As part of the Bullseye upgrade, upgrade to the 5.10.40 kernel. At this point, 28 patches apply (some of them required some changes) onto the kernel. Others require more changes. All patches, however, need to be refreshed, so that the line numbers match the current version of source code. Also update our build script to commit changes to *.maintscript and *.bug-presubj files, these are generated files and get changed because of our abiname change. Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
…ave-buster Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Dynamic write_max support for optoe driver Signed-off-by: Prince George <prgeor@microsoft.com>
…el deadlock but causes one (sonic-net#231) Patch 0028-thermal-Fix-deadlock-in-thermal-thermal_zone_device_.patch was incorrectly generated. It is supposed to backport Linux commit torvalds/linux@163b00c, but the commit was already backported to the stable series in v4.19.89, so included in Linux v.19.152 currently used by SONiC. Instead, the incorrect patch reverts the first hunk of the commit. So, remove it. For the old patch, guess there was some mistake has been made while generating the patch. Instead of applying the fix to the code, it's generated in a opposite way, the content of the wrong patch is reverting the first part of the patch, so it can still building but make the fix incomplete. Regression tests have been performed against these patches on the Mellanox platform, no issue found.
Current mtd driver supports reading mtd partition information from command line and dts file, but cannot read partition information from ACPI files. Added code to support new partition type "acpipart" to default_mtd_part_types structure. This partition type can be used to configure mtd partition data in ACPI tables. Signed-off-by: Madhava Reddy Siddareddygari <msiddare@cisco.com>
…#232) The x86 platform did not allow configuring the maximum number of GPIOs supported, although the ARM platform did. For cisco-8000 platform, each FPGA gpio IP block can support 1K pins. Distributed chassis with Route processor and Fabric card can have 10 such IP blocks, along with additional pins through i2c gpio extenders. This patch supports configurable number of GPIO's at kernel config time similar to ARM platform. Signed-off-by: Madhava Reddy Siddareddygari <msiddare@cisco.com>
Current mdio-mux does not support reading configuration from ACPI tables cisco-8000 platform configures mdio phy config through ACPI tables. Added support in the mdio-mux driver to read from ACPI. Signed-off-by: Madhava Reddy Siddareddygari <msiddare@cisco.com>
Signed-off-by: Kebo Liu <kebol@nvidia.com>
…ncy-settin.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
Signed-off-by: Kebo Liu <kebol@nvidia.com>
…6-realm.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
….patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…astructure.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…-enforceme.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…ord-addres.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…r.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…-creation-.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…-variable.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…-assignmen.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…-assignmen.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…argument-t.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…reshold-fi.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…esholds-us.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…ule-temper.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
…sholds-usi.patch Signed-off-by: Kebo Liu <kebol@nvidia.com>
Signed-off-by: Kebo Liu <kebol@nvidia.com>
) Current m25p80 spi nor driver does not support ACPI table match. Configuration done through ACPI tables is not recognized by driver. Cisco 8000 platform cofigures NOR flash partition information through APCI table which is not recognized by m25p80. Added support in m25p80 to perform ACPI table match. Signed-off-by: Madhava Reddy Siddareddygari <msiddare@cisco.com>
…sonic-net#235) Data path devices are powered off by default, they will not be visible at BIOS stage and memory for these devices is not reserved. By default, no address space would be reserved on the bridges for these unpowered devices. When they were powered up, they could fail to initialize because there was no appropriately aligned window available for a given BAR. This patch will reserve address space for data path devices that are behind PCIe bridge, so that when devices are available PCIe subsystem will be assign the address within the specified range. Signed-off-by: Madhava Reddy Siddareddygari <msiddare@cisco.com>
…c-net#540) This PR adds three Linux kernel patches required to enable EVPN VXLAN Multihoming in SONiC. These kernel enhancements provide the necessary infrastructure for: 1. NDA_FLAGS_EXT with NTF_EXT_MH_PEER_SYNC - Extended FDB flags for multi-homing peer synchronization across EVPN-MH peers. 2. Protocol field in bridge FDB - Distinguishes control plane (zebra) vs data plane (hw) learned MACs for proper EVPN-MH state management. 3. NTF_EXT_VALIDATED for externally validated neighbors - Prevents kernel from invalidating neighbor entries managed by the control plane during ES link transitions. These patches are essential for implementing the EVPN-MH feature as described in the [EVPN VXLAN Multihoming HLD](https://github.com/sonic-net/SONiC/blob/master/doc/vxlan/EVPN/EVPN_VxLAN_Multihoming.md). NOTE: The file 0003-neighbor-Add-NTF_EXT_VALIDATED-flag-for-externally-v.patch has been committed upstream to the Linux kernel master branch. See torvalds/linux@03dc03f Add kernel patches for EVPN VXLAN Multihoming: extended FDB flags (NTF_EXT_MH_PEER_SYNC), protocol field for bridge FDB entries, and extern_valid flag for externally validated neighbor entries Co-authored-by: Barry Friedman (friedman) <friedman@cisco.com> Co-authored-by: Tamer Ahmed <tamerahmed@microsoft.com> Signed-off-by: Tamer Ahmed <tamerahmed@microsoft.com>
- Add AST2700 A1 board: aspeed-nvidia-spc6-a1-bmc (+ core dtsi, Makefile DTB entry). - Add AST2700 A2 board: aspeed-nvidia-spc6-bmc (+ core dtsi, nvidia-ast27xx-irot/sunda fragments, Makefile DTB entry). - List both patches in patches-sonic/series (aspeed section). Signed-off-by: Oleksandr Ivantsiv <oivantsiv@nvidia.com> Co-authored-by: Saikrishna Arcot <sarcot@microsoft.com>
**What I did** Set the kernel compile-time default for Transparent Huge Pages (THP) from always to madvise by adding CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y in `config.local/featureset-sonic/config` **Why I did it** With CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, khugepaged continuously promotes 4KB pages to 2MB huge pages in the background. On memory-constrained network switches this has several negative effects: - Memory fragmentation: Once promoted, huge pages cannot be partially reclaimed. Even when applications free most of their memory, scattered live objects pin entire 2MB pages, preventing the kernel from reclaiming unused memory. - Allocator inefficiency: Userspace allocators (e.g., jemalloc) use MADV_DONTNEED to return memory to the kernel, but this is ineffective on sub-ranges of huge pages, causing a persistent gap between application-level and kernel-level memory accounting. - Process exit latency: Tearing down large THP-backed address spaces under memory pressure can cause threads to block in do_exit(), triggering hung task watchdog timeouts. Setting the default to madvise ensures THP is only used when applications explicitly opt in via madvise(MADV_HUGEPAGE). This is the recommended setting for latency-sensitive and embedded networking workloads (consistent with guidance by other linux distributions for similar environments). **How I verified it** - Built the kernel with updated kconfig and booted on a SONiC switch - Confirmed: `cat /sys/kernel/mm/transparent_hugepage/enabled` is set as follows: `always [madvise] never` **Details if related** Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
* Include the i2c-xiic driver and add kernel patches Cherry-pick the i2c-xiic upstream patches and pull in the one PM-runtime devm helper they depend on, since v6.12.41 predates it. Patches added (in series order, each cherry-picked from upstream; v6.12.41 lacks 73db799bf5ef so 0006 is needed by 0010 and 0013): - 0006-PM-runtime-Add-new-devm-functions.patch (stable 69a837b75edc / mainline 73db799bf5ef, in v6.12.55+) Adds devm_pm_runtime_set_active_enabled() and devm_pm_runtime_get_noresume(). Link: https://lore.kernel.org/r/20250327195928.680771-3-csokas.bence@prolan.hu - 0007-i2c-xiic-Relocate-xiic_i2c_runtime_suspend-and-xiic_.patch Link: https://lore.kernel.org/r/20241210095242.1982770-2-manikanta.guntupalli@amd.com - 0008-i2c-xiic-Add-atomic-transfer-support.patch Link: https://lore.kernel.org/r/20241210095242.1982770-3-manikanta.guntupalli@amd.com - 0009-i2c-i2c-xiic-Replace-dev_err-with-dev_err_probe-in-p.patch Link: https://lore.kernel.org/r/20250415183447.396277-10-e.zanda1@gmail.com - 0010-i2c-xiic-switch-to-devres-managed-APIs.patch Link: https://lore.kernel.org/r/20260223-i2c-xiic-v12-1-b6c9ce4e4f3c@nexthop.ai - 0011-i2c-xiic-remove-duplicate-error-message.patch Link: https://lore.kernel.org/r/20260223-i2c-xiic-v12-2-b6c9ce4e4f3c@nexthop.ai - 0012-i2c-xiic-switch-to-generic-device-property-accessors.patch Link: https://lore.kernel.org/r/20260223-i2c-xiic-v12-3-b6c9ce4e4f3c@nexthop.ai - 0013-i2c-xiic-cosmetic-cleanup.patch Link: https://lore.kernel.org/r/20260223-i2c-xiic-v12-4-b6c9ce4e4f3c@nexthop.ai - 0014-i2c-xiic-cosmetic-use-resource-format-specifier-in-d.patch Link: https://lore.kernel.org/r/20260223-i2c-xiic-v12-5-b6c9ce4e4f3c@nexthop.ai - 0015-i2c-xiic-use-numbered-adapter-registration.patch Link: https://lore.kernel.org/r/20260223-i2c-xiic-v12-6-b6c9ce4e4f3c@nexthop.ai - 0016-i2c-xiic-skip-input-clock-setup-on-non-OF-systems.patch Link: https://lore.kernel.org/r/20260223-i2c-xiic-v12-7-b6c9ce4e4f3c@nexthop.ai Also enable CONFIG_I2C_XILINX=m in config.local/amd64/config.sonic so the driver is actually built into the SONIC kernel. Resolves [sonic-net#543](sonic-net#543) Resolves [sonic-net#544](sonic-net#544) Signed-off-by: domingo-nexthop <domingo@nexthop.ai> * rename patch number Signed-off-by: domingo-nexthop <domingo@nexthop.ai> * revert whitespace changes Signed-off-by: domingo-nexthop <domingo@nexthop.ai> --------- Signed-off-by: domingo-nexthop <domingo@nexthop.ai>
…700 (sonic-net#569) Signed-off-by: Chandrasekaran Swaminathan <chander@nexthop.ai>
Signed-off-by: jumao <junhong.mao@nokia.com>
…t#576) Added three downstream patches that extend Linux drop_monitor (net/core/drop_monitor.c): * 0003-drop_monitor-Allow-running-multiple-instances-of-dropwatch.patch - reference-count software and hardware drop tracing so more than one dropwatch client can enable tracing without tripping “already enabled” errors; monitoring state is derived from those refcounts. * 0004-drop_monitor-Send-hardware-drop-notifications-to-the.patch - multicast hardware drop notifications to the correct network namespace. * 0005-drop_monitor-Do-not-block-a-configuration-change-if-it-is-a.patch - consolidate config handling so a no-op config (unchanged alert mode, trunc length, queue length) succeeds even while monitoring is active; real changes still return -EBUSY while monitoring. On multi-ASIC SONIC, multiple drop monitor subscribers need to configure/subscribe without fighting the global "trace already on" / "HW monitoring already enabled" state. Hardware drops are tied to a device's netns; sending HW notifications only in the initial netns is wrong for per-ASIC namespaces. Allowing idempotent config while monitoring avoids unnecessary -EBUSY when different applications resend the same parameters. These patches will not be upstreamed. Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com>
) We need this patch to fix a soft lockup in the Linux kernel on Arista modular chassis in the 202511 branch. During PCIe hot-plug events, uncorrectable errors can be reported and AER recovery for the tg3 device is initiated by the AER kernel driver. The tg3_io_error_detected function is the AER error recovery handler. From tg3_io_error_detected, we call tg3_netif_stop->tg3_napi_disable-> napi_disable and return PCI_ERS_RESULT_NEED_RESET on non-fatal error. We expect that during AER recovery tg3_io_slot_reset and tg3_io_resume will be called. But AER error recovery can fail. For example, when one of PCIe devices on the same bus reports PCI_ERS_RESULT_NO_AER_DRIVER. As a result, tg3_io_slot_reset and tg3_io_resume are not called, PCIe device is disabled and NAPI is disabled (pci_disable_device and napi_disable are called from tg3_io_error_detected). Then we can try to disable PCIe link and napi_disable will be called again: napi_disable+0x1b/0x1b0 tg3_napi_disable+0x89/0xa0 [tg3] tg3_netif_stop+0x37/0xe3 [tg3] tg3_stop+0x30/0x160 [tg3] tg3_close+0x2a/0x60 [tg3] __dev_close_many+0xad/0x130 dev_close_many+0xb2/0x190 unregister_netdevice_many_notify+0x19d/0xa00 unregister_netdevice_queue+0xf8/0x140 unregister_netdev+0x1c/0x30 tg3_remove_one+0xaa/0x150 [tg3] pci_device_remove+0x42/0xb0 device_release_driver_internal+0x19c/0x200 pci_stop_bus_device+0x85/0xb0 pci_stop_bus_device+0x2c/0xb0 pci_stop_bus_device+0x2c/0xb0 pci_stop_and_remove_bus_device+0x12/0x20 pciehp_unconfigure_device+0x9f/0x160 pciehp_disable_slot+0x67/0x100 pciehp_handle_presence_or_link_change+0x77/0x350 This is not expected by napi_disable and a thread can be locked in napi_disable forever. We have pcierr_recovery to cover a similar issue, but for fatal errors. We cannot reuse this flag because it is reset in tg3_io_resume, but it is not called when AER recovery fails. Similarly, if an AER error is reported and tg3_io_error_detected calls pci_disable_device, a subsequent device removal via tg3_remove_one or tg3_shutdown will call pci_disable_device again for the already-disabled device. Add a napi_enabled flag to struct tg3 to track whether napi_enable has been called. Guard tg3_napi_disable() so it returns early if NAPI was not previously enabled. Also guard pci_disable_device() calls in tg3_remove_one() and tg3_shutdown() with pci_is_enabled() to avoid disabling an already-disabled device. Fixes: b45aa2f6192e ("tg3: Add EEH support") Link: https://lore.kernel.org/netdev/20260527115535.1686932-1-yurypm@arista.com/ Signed-off-by: Yury Murashka <yurypm@arista.com>
…NC_I2C (sonic-net#550) * regmap-i2c: add SMBus byte/word reg16 bus for adapters lacking I2C_FUNC_I2C Add a regmap-i2c bus type that supports 16-bit register addressing on adapters that have SMBUS_BYTE_DATA and SMBUS_WORD_DATA but lack I2C_FUNC_I2C and I2C_FUNC_SMBUS_I2C_BLOCK (e.g. AMD PIIX4 on AMD SP5/EPYC platforms, including Cisco 8000 series routers). This fixes at24 EEPROM probe failures on PIIX4: at24 3-0055: probe with driver at24 failed with error -524 The fix lives in the regmap-i2c core (per upstream review feedback from Bartosz Golaszewski and Mark Brown) so all drivers benefit from the fallback, not just at24. [ upstream bad4bd28abf4 ] Signed-off-by: Nishanth Sampath Kumar <nissampa@cisco.com> * regmap-i2c: fix sparse warning in regmap_smbus_word_write_reg16 i2c_smbus_write_word_data() expects a plain u16, but cpu_to_le16() returns __le16 (a sparse-restricted endian type). SMBus already defines byte ordering internally, so replace cpu_to_le16() with a plain (u16) cast. Fixes: bad4bd28abf4 ("regmap-i2c: add SMBus byte/word reg16 bus for adapters lacking I2C_FUNC_I2C") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605161621.mY5zFh4D-lkp@intel.com/ [ upstream 19a5211cda12 ] Signed-off-by: Nishanth Sampath Kumar <nissampa@cisco.com> --------- Signed-off-by: Nishanth Sampath Kumar <nissampa@cisco.com>
…et#580) This reverts commit 7a36b901a6eb0e9945341db71ed3c45c7721cfa9. After upgrading from Debian bookworm to trixie on modular systems, the kdump kernel started hitting a soft lockup while capturing a crash dump. The issue is reproducible by triggering a panic in the production kernel with: echo c | sudo tee /proc/sysrq-trigger Once the kdump kernel boots, CPU0 gets stuck in the ACPI SCI handling path and the soft lockup watchdog eventually panics the kdump kernel, so no vmcore is produced. The trace below was obtained by adding the following to the kdump command line: debug=1, loglevel=7, softlockup_all_cpu_backtrace=1 and softlockup_panic=1: watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [irq/9-acpi:39] CPU: 0 UID: 0 PID: 39 Comm: irq/9-acpi Not tainted 6.12.41+deb13-sonic-amd64 saiarcot895#1 Debian 6.12.41-1 Hardware name: Intel Camelback Mountain CRB, BIOS Aboot-norcal7-7.1.6-generic-22971530 06/30/2021 RIP: 0010:acpi_os_read_port+0x30/0xa0 Call Trace: <TASK> acpi_hw_gpe_read+0x61/0x80 acpi_ev_detect_gpe+0x74/0x180 acpi_ev_gpe_detect+0xe1/0x130 acpi_ev_sci_xrupt_handler+0x1d/0x40 acpi_irq+0x1c/0x40 irq_thread_fn+0x23/0x60 irq_thread+0x1b3/0x2f0 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> Kernel panic - not syncing: softlockup: hung tasks Comparing the bookworm and trixie kernels, the SCI handler was moved from a hardirq handler to a threaded handler by the commit being reverted. Moving to a threaded IRQ regressed kdump on this hardware; reverting that commit restores the previous hardirq-based SCI handling and the kdump kernel completes the crash dump without triggering the soft lockup watchdog. Signed-off-by: Mohan Yelugoti <ymd@arista.com>
* Add noaer_recovery pci kernel boot option AER error recovery is part of the AER error handling subsystem in the Linux kernel. AER is enabled by default in the SONiC Linux kernel. The default Linux behavior is incompatible with Arista chassis hardware architecture. Enabling AER recovery on large modular systems with a complex PCIe tree could cause unexpected behavior and side effects. It would be nice to have an option to disable AER recovery on some chassis. Add pci=noaer_recovery kernel boot option to disable AER error recovery when an uncorrectable error is reported. Signed-off-by: Yury Murashka <yurypm@arista.com> * Add nodpc pci kernel boot option PCI DPC (Downstream Port Containment) is enabled by default in the SONiC Linux kernel. DPC support can be advertised by PCIe devices, but it might not be fully supported in the firmware. The default Linux behavior is incompatible with Arista chassis hardware architecture. Enabling DPC could cause unexpected behavior and side effects. It would be nice to have an option to disable DPC on some chassis. Add pci=nodpc kernel boot option to disable PCI DPC. Signed-off-by: Yury Murashka <yurypm@arista.com> --------- Link: https://lore.kernel.org/linux-pci/20260602105558.1799563-1-yurypm@arista.com/T/#t Signed-off-by: Yury Murashka <yurypm@arista.com>
The target platform uses INA238 power monitoring devices. The current kernel configuration does not build the INA238 driver, which prevents the sensors from being exposed through the Linux hwmon framework. This change enables CONFIG_SENSORS_INA238 in SONiC. Validation: - Platform: Micas M2-6951-64HC-CP - Kernel: 6.12.41+deb13-sonic-amd64 Driver probe log: root@sonic:/home/admin# dmesg | grep ina238 [ 23.824230] ina238 57-0040: power monitor ina238 (Rshunt = 10000 uOhm, gain = 4) [ 23.824238] i2c i2c-57: new_device: Instantiated device ina238 at 0x40 [ 23.837771] ina238 58-0041: power monitor ina238 (Rshunt = 10000 uOhm, gain = 4) [ 23.837779] i2c i2c-58: new_device: Instantiated device ina238 at 0x41 Hwmon interface: ``` root@sonic:/sys/bus/i2c/devices/57-0040/hwmon/hwmon30# ls curr1_input in0_input in0_max_alarm in0_min_alarm in1_max in1_min name power1_input power1_max_alarm temp1_input temp1_max_alarm device in0_max in0_min in1_input in1_max_alarm in1_min_alarm power power1_max subsystem temp1_max uevent root@sonic:/sys/bus/i2c/devices/57-0040/hwmon/hwmon30# cat name ina238 root@sonic:/sys/bus/i2c/devices/57-0040/hwmon/hwmon30# cat in0_input 3 root@sonic:/sys/bus/i2c/devices/57-0040/hwmon/hwmon30# cat in1_input 54434 root@sonic:/sys/bus/i2c/devices/57-0040/hwmon/hwmon30# cat curr1_input 360 root@sonic:/sys/bus/i2c/devices/57-0040/hwmon/hwmon30# cat power1_input 19555200 root@sonic:/sys/bus/i2c/devices/57-0040/hwmon/hwmon30# cat temp1_input 37750 ``` Signed-off-by: RayWang-micas <ray@micasnetworks.com>
What: Integrates HW-MGMT 7.0060.1047 kernel patches (mlxreg LED sysfs color, nvsw-bmc I2C mux owner protection, mlxreg-io max attrs 128→250, NXP PCF85053A RTC driver, Realtek PHY polling reset) plus sonic-aspeed BMC patches (MCTP transports incl. IRoT/SPI/VRoT, Aspeed JTAG) and enables the corresponding BMC Kconfig in config.sonic-aspeed. Why: Bring the SONiC kernel up to HW-MGMT 7.0060.1047, adding new platform/BMC support and fixing random PHY init failures. How: Adds patches-sonic patches applied during kernel build, wires JTAG into drivers/Kconfig + drivers/Makefile, and turns on MCTP/IRoT/JTAG kernel config options for sonic-aspeed. Testing: All Azure.sonic-linux-kernel builds green (vs-amd64 secure boot on/off, vs-arm64, vs-armhf, pensando-arm64); DCO and EasyCLA passing. Note: several patches carry Upstream-Status: Pending (not yet upstreamed). Signed-off-by: Daniel Isakov <disakov@nvidia.com>
…et#568) As discussed in the SONiC-BMC work group meeting yesterday I am submitting the script that I use to generate the patch file to add support for AST 2700 to the SONiC Linux Kernel. The script by default will create the patch based on the current top-of-tree in aspeed-master-v6.12. This can be overridded by running the script with the env var ASPEED_TAG, ex "ASPEED_TAG=v00.07.02 ./scripts/generate-aspeed-patch.sh" * 1. Remove unwanted config option - SSP is not yet supported in aspeed 2700 2. Script to generate the patch that adds support for Aspeed AST2700 SOC. The script will generate the patch in WORK_DIR/aspeed-ast2700-support-new.patch This needs to be moved to patches-sonic/aspeed-ast2700-support.patch. Signed-off-by: Chandrasekaran Swaminathan <chander@nexthop.ai> * Harden aspeed patch generator and series file update - Updated patch series file to move ASPEED patches at the end - Move inline smart_merge Python out of the bash heredoc into scripts/smart_merge.py; bash invokes it via $SMART_MERGE. - Replace the hard-coded "head -228" cap with a break at the "###-> aspeed" marker so the patch-application loop stays correct as patches-sonic/series evolves. - Warn patches listed after "###-> aspeed-end" with a note that they may need regeneration if they touch files also modified by the regenerated aspeed patch. Signed-off-by: Chinmoy Dey <chinmoy@nexthop.ai> * script enhancement, series file update and cache support - WORK_DIR now honors ${TMPDIR:-/tmp}. - KERNEL_VERSION read via sed (handles ?= / := / += / =). - SONiC kernel tarball is cached across runs; only the extracted $SONIC_SRC tree is wiped and re-extracted each time. - progress lines now label the "size on disk" figure explicitly. (Re-applied during rebase onto upstream/master; this content previously lived in the upstream-merge commit that the rebase linearized away.) Signed-off-by: Chinmoy Dey <chinmoy@nexthop.ai> --------- Signed-off-by: Chandrasekaran Swaminathan <chander@nexthop.ai> Signed-off-by: Chinmoy Dey <chinmoy@nexthop.ai> Co-authored-by: Chinmoy Dey <chinmoy@nexthop.ai>
…ic-net#586) Added device tree support for the Micas M2-W6950-128OC BMC platform: - New `micas-m2-w6950-128oc.dts` containing the complete Aspeed AST2700 hardware description for Micas BMC - New `aspeed-g7-alt-flash-layout-64.dtsi` defining alternate flash partition layout (including u-boot, kernel, rootfs, and other partitions) - Updated `arch/arm64/boot/dts/aspeed/Makefile` to add compilation rule for micas-m2-w6950-128oc.dtb Signed-off-by: luka-micas <luka@micasnetworks.com> Co-authored-by: Saikrishna Arcot <sarcot@microsoft.com>
…onic-net#587) Following is added in this patch to improve the eMMC - 1. Patch AspeedTech-BMC Linux Kernel "mmc: sdhci-of-aspeed: Optimize tuning mechanism" (v6.12) AspeedTech-BMC/linux@5fa88b1 2. Patch AspeedTech-BMC Linux Kernel "mmc: sdhci-of-aspeed: Improve CMD6 timing" (v6.18) AspeedTech-BMC/linux@e353214 3. Update arista goldfinch dts to increase drive strength and use 8-bit data for eMMC On few bmc units we faced eMMC issues resulting it in not being initialized properly during bootup: ``` $ sudo dmesg | grep -i mmc [ 4.499887] mmc0: SDHCI controller on 12090100.sdhci [12090100.sdhci] using ADMA 64-bit [ 4.720956] mmc0: mmc_select_hs200 failed, error -110 [ 4.731344] mmc0: error -110 whilst initialising MMC card [ 5.039620] mmc0: mmc_select_hs200 failed, error -110 [ 5.045306] mmc0: error -110 whilst initialising MMC card [ 5.328407] mmc0: mmc_select_hs200 failed, error -110 [ 5.334089] mmc0: error -110 whilst initialising MMC card [ 5.665417] mmc0: mmc_select_hs200 failed, error -110 [ 5.672118] mmc0: error -110 whilst initialising MMC card [ 5.683391] mmc0: Failed to initialize a non-removable card ``` Built and booted up with the changes and saw no mmc related dmesg logs: ``` $ sudo dmesg | grep -i mmc [ 3.249624] mmc0: SDHCI controller on 12090100.sdhci [12090100.sdhci] using ADMA 64-bit [ 3.471941] mmc0: new HS200 MMC card at address 0001 [ 3.480883] mmcblk0: mmc0:0001 TS0A32 9.71 GiB [ 3.494901] mmcblk0: p1 [ 3.500625] mmcblk0boot0: mmc0:0001 TS0A32 4.00 MiB [ 3.512853] mmcblk0boot1: mmc0:0001 TS0A32 4.00 MiB [ 3.522829] mmcblk0rpmb: mmc0:0001 TS0A32 4.00 MiB, chardev (238:0) ```
Added support for Cadence Sdhci eMMC controller for octeon platform. - This includes enabling the Cadence SD6 controller, HS400/HS400ES modes, ACPI integration, PHY delay tuning, and multiple fixes for timing, tuning, and controller corner cases. - Also updated the OTX2 mailbox interface version and related structures. Octeon platforms require specific controller handling and tuning for reliable high-speed eMMC operation. Existing driver support lacked MMC Controller-specific configurations, resulting in instability and incorrect operation in HS400-class modes. Additionally, mailbox structure updates were needed to align kernel and application interfaces How I verified it ----------------- - Booted Octeon platform with updated driver - Verified eMMC enumeration and initialisation - Tested HS400 / HS400ES mode transitions - Validated tuning execution and value population - Verified mailbox compatibility with updated structure - These patches are not to be upstreamed. - There are parallel threads in Progress to give sd6hc support, which needs to be evaluated first: https://lkml.org/lkml/2026/5/11/2580 Signed-off-by: Renjithkumar Raveendran Nair <renjithkumar@gmail.com>
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Stop advertising update interrupts for the armada38x RTC driver. SONiC switched to chrony, which enables RTC update interrupts via the RTC_UIE_ON ioctl. On the armada38x RTC driver, big skew in time can lead to pinning the CPU and triggering the RCU stall and reboot. We clear the RTC_FEATURE_UPDATE_INTERRUPT at probe time, so RTC_UIE_ON no longer takes the native periodic-timer path and instead routes to the UIE emulation path (commit dbd69ff). --------- Signed-off-by: fountzou <ioannis.fountzoulas@nokia.com> Signed-off-by: Ioannis Fountzoulas <ioannis.fountzoulas@nokia.com>
Aspeed patches are disabled as of right now. Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Based on community feedback, this PR restores the original aspeed-ast2700-support.patch merged in sonic-net#522. The update to kernel-6.12 v00.07.02[1] has been split into 2 patches based on aspeed specific changes and vendor independent changes. The two new patches for 00.07.02 update will be applied as incremental patches on top of the original Aspeed kernel patch. [1] sonic-net#557 --------- Signed-off-by: Roger Liao <roger@nexthop.ai>
pci_aer_clear_nonfatal_status() is not called when AER recovery fails. A PCIe switch can report an AER error with the 0000:00:00.0 AER error source address (if the multi-error flag is not set). In this case, the AER driver rescans the whole bus and tries to find a device reporting the AER error. find_source_device() is called. When the AER error source is 0, is_error_source() returns 'true' for any device with a reported AER error. When is_error_source() reports 'true', the AER driver checks the e_info->multi_error_valid flag and stops iterating in find_device_iter(). Therefore, the error is reported only for the first device on the bus. Then, the AER driver initiates AER recovery. If AER recovery fails, AER error cleanup is not called for the devices. When any device on the same bus reports a new AER error, the bus rescan process is repeated, and the AER error is reported for the same first device with the uncleaned AER error. This is a side effect of an AER recovery failure. We should not be left with stale errors. We can either perform error cleanup in the kernel immediately after a failure, or we can leave the devices as-is and let user-space code recover the system/PCIe tree. The current Linux kernel leaves the devices as-is, which leads to visible side effects in the absence of user-space monitoring. Add a kernel boot parameter pci=aer_clear_on_recovery_failure to enable AER error cleanup for cases where recovery fails. This prevents stale errors from causing incorrect device identification on subsequent AER error events. The kernel boot parameter allows enabling this functionality on demand. By default, it is disabled, because there could be software that expects to see the device in an unchanged state when AER recovery fails. The patch was discussed with Linux maintainers here[1] They prefer to fix the reason for the issue - AER recovery failure. Proposed fix introduces new crashes in the SONiC Linux kernel during AER error recovery and cannot be used as-is. We are planning to enable the new functionality only for Arista devices. [1] https://lore.kernel.org/linux-pci/CAPzpGcRCTCZtaX1EVaJNZ103THZKsoszZduY7=gwfYdcrMo-SQ@mail.gmail.com/
…sonic-net#603) What: Adds patches-sonic/aspeed-spi-txrx-fix-full-duplex-capture.patch and registers it in patches-sonic/series after aspeed-ast2700-support.patch. Why: The Aspeed SPI driver did not correctly support full-duplex operations; the patch fixes RX capture during full-duplex transfers. How: Captures RX during the TX loop whenever an rx buffer is present and restricts the separate read burst to pure reads; behaviour is unchanged for write-only, read-only, and shared-buffer full-duplex (e.g. TPM) transfers. Testing: CI green (all checks pass). Patch also accepted upstream by Aspeed for a future release. Signed-off-by: Chandrasekaran Swaminathan <chander@nexthop.ai>
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Swap the MAC pinctrl configurations as per latest spec. Signed-off-by: Natarajan Subbiramani <natarajan.subbiramani@nokia.com>
…nic-net#607) Backport stable commit 5938fb0e3285 ("platform/x86: int0002: Remove IRQF_ONESHOT from request_irq()", upstream f6bc712877f2) on top of the revert of 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI"). The INT0002 GPIO IRQ is typically shared with the ACPI SCI. With the SCI back on a plain IRQF_SHARED request_irq(), INT0002 must drop IRQF_ONESHOT or probe fails with a flags mismatch. Signed-off-by: Connor Roos <croos@nvidia.com>
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Bring in changes from sonic-net#601 - Aspeed AST2700 patch regeneration to Aspeed tag v7.04 (shared-kernel and non-aspeed dependency splits updated to 6.12.94-00.07.04), additional SPC6 BMC DTS, ftgmac100 SGMII, and USB EHCI AST2700 patches. - HW-MGMT 7.0070.1013 integration and associated BMC Kconfig enablement. - Nexthop B27 / Nokia H6-128 DTS updates and Arista Goldfinch DTS refresh. - New PMBus device support (Delta Q54SN120A1/Q54SW120A7, Renesas RAA2289). - Aspeed patch-generation tooling: aspeed_content_scan.py, split-aspeed-patch.py, and reworked generate-aspeed-patch.sh. - Context-only rebases of the Arista AER and Aspeed SPI full-duplex patches so the full series applies cleanly on 6.12.94. - config.local: enable CONFIG_NCSI_OEM_CMD_KEEP_PHY, WATCHDOG_HANDLE_ BOOT_ENABLED, MTD_PHRAM, and SENSORS_Q54SJ108A2. Signed-off-by: Chandrasekaran Swaminathan <chander@nexthop.ai>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.