Skip to content

Xr1710g 6.18 integration test sync 20260706 讨论openwrt上游分支一个文件冲突,代码修改方法#3

Draft
jjcszxh wants to merge 79 commits into
YYH2913:xr1710g-6.18-integrationfrom
jjcszxh:xr1710g-6.18-integration-test-sync-20260706
Draft

Xr1710g 6.18 integration test sync 20260706 讨论openwrt上游分支一个文件冲突,代码修改方法#3
jjcszxh wants to merge 79 commits into
YYH2913:xr1710g-6.18-integrationfrom
jjcszxh:xr1710g-6.18-integration-test-sync-20260706

Conversation

@jjcszxh

@jjcszxh jjcszxh commented Jul 6, 2026

Copy link
Copy Markdown

讨论同步openwrt上游分支一个文件冲突,代码修改方法
package/network/config/wifi-scripts/files-ucode/usr/share/ucode/wifi/hostapd.uc

YYH2913 and others added 30 commits July 1, 2026 08:56
This reverts commit baecc5f6a568c31ca34923b6280a1a3d13d57b8a.
Keep NL80211 radio data complete across split wiphy dumps and make iwinfo request split dumps when building txpower lists.

This avoids bogus txpower list values on single-wiphy multi-radio devices.
Refresh mt7996 firmware SKU tables on mac80211 power/channel updates and BSS txpower changes so runtime txpower updates take effect.
Enable the mt7996 firmware SKU and backoff txpower controls and upload the firmware table layout used by the driver.
Apply txpower through active interfaces for single-wiphy multi-radio devices and retry after setup for AP paths that finish channel state later.
Port the W1700K hardware compatibility fixes carried by the reference 6.18 branches.

Increase the Airoha NPU mailbox poll timeout for Eagle firmware init commands, and clear USB_PCIE_SEL during EN7581 PCIe XSI clock setup so PCIe lanes are not left in USB shared mode.

Verified with target/linux clean/prepare on the 6.18 Airoha patch queue.
jonasjelonek and others added 24 commits July 6, 2026 22:36
Split the DCVS setter into two functions, separating mode control from
coefficient setting. The old pattern, combining everything in one
function, was still kept from the SDK but is rather confusing and makes
the function rather complex. Splitting this simplifies it a lot.

Cleanup the DCVS getter, making it consistent with the setters. Though
not used right now, kept for documentation purpose. So at least keep it
in a good style.

Remove the usleep from dcvs_set_adapt(enable=true). There is no lock
flow for DCVS that polls a result after enabling auto-adapt, so no
caller needs the delay. rxcal_init also enables VTH and TAP auto-adapt
via the load_in_init bulk write with no delay, confirming it is not
needed here either.

Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace the nine raw register writes that enable auto-adapt for all six
DCVS channels with a loop over dcvs_set_adapt(), consistent with how
TAP and VTH init was already converted.

Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Split leq_manual() into leq_set_adapt() and leq_set_coef(), separating
mode control from coefficient writes, consistent with the DCVS helpers.
Rename leq_get() to leq_get_coef() and leq_get_bin() to
leq_get_coef_bin() to match. Add error propagation throughout.

Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Split vth_manual() into vth_set_adapt() and vth_set_value(), separating
mode control from value writes, consistent with DCVS and LEQ helpers.
Rename vth_get() to match and switch from an array parameter to
individual pointers. Invert the manual boolean to 'enable' (true means
auto-adapt is running). Add error propagation throughout and demote the
read-out print from pr_info to pr_debug.

Remove the usleep from vth_set_adapt(enable=true). The only caller is
vth_tap0_adapt_lock which already has an explicit msleep(200) to wait
for adaptation to complete, making the embedded 10ms redundant. Delay
belongs at the call site, not baked into the setter.

Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Split tap_manual() into tap_set_adapt() and tap_set_value(), separating
mode control from value writes. Replace manual sign-magnitude bit
manipulation with rtpcs_sign_mag_encode/decode helpers. Update tap_get()
to use individual signed output pointers instead of an array and add
error propagation. Apply stage-then-latch ordering consistently: value
is written before the manual bit is set.

Remove the usleep from tap_set_adapt(enable=true). Callers already
carry explicit delays: vth_tap0_adapt_lock has msleep(200) and
dfe_taps_adapt has msleep(30) after enabling auto-adapt. The 10ms per
call was redundant and added 40ms to dfe_taps_adapt needlessly.

Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace the raw register writes in rxcal_init with the previously
cleaned-up VTH and TAP helpers. Beyond readability, this also fixes two
latent bugs in the original tap4 initialisation: tap4_even was written
twice (both to PAGE_ANA_10G_EXT 0x01[5:0]) and tap4_odd was never
written at all (PAGE_ANA_10G 0x06[11:6]). Using tap_set_value(sds, 4,
0, 0) writes both fields correctly.

Also apply stage-then-latch ordering to the VTH init: write the value
registers before asserting the manual bit, consistent with the rest of
the calibration lock path.

Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace SDK-style step numbering (1.1.1, 1.1.2, ...) with descriptive
section headers and inline register name comments. This makes it easier
to follow the calibration sequence without cross-referencing the SDK.
Also correct the LEQ acronym expansion and tidy up variable comments.

Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
All calibration and SerDes config code runs in process context, so
busy-waiting with mdelay is unnecessary. Use usleep_range for delays
up to 10ms and msleep for longer ones to yield the CPU instead.

Add explicit linux/delay.h include to document the dependency.

Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Some more cleanup for the calibration cleanup, removing some stray
whitespaces and collapsing subsequent writes in the same registers. The
former aren't helping anymore after the page -> named field conversion.
The latter can be collapsed because there is no reason to keep them
separate and thus, calls can be reduced.

Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Most of the file uses fwnode except for this section. Convert it.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: openwrt#24091
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add support for RTL9313-based Ubiquiti UniFi USW Pro XG 8 PoE switch
with 8x 10G RJ45 and 2x SFP+ ports.

Hardware
========

  - RTL9313 switch SoC
  - 512 MiB RAM
  - 32 MiB SPI-NOR flash
  - 8x 100M/1G/2.5G/5G/10G RJ45 ports via 2x RTL8264B
  - PoE: 8x 802.3bt, 60W per port, 155W total budget
  - 2x 1G/2.5G/10G SFP+ ports
  - Buttons: 1x Reset
  - LEDs:
    - System LED white/blue
    - RGBW LED per port
  - Console: TTL 3.3V, 115200 8N1, populated 4-pin header
    (device must be opened to access header)
  - Etherlighting feature (lighting patterns and color control)
  - Vendor firmware: U-Boot + LEDE-based Ubiquiti OS

MAC address
===========

Single MAC address in EEPROM partition, applied to all ports.

Known issues
============

  - PoE not available, depends on WIP Realtek PSE MCU driver
  - Etherlighting not controllable, driver WIP. Port LEDs for link work
    though. By default, the controller keeps the LEDs in a breathing
    state, gated by the link state delivered by the Realtek SoC.

Disclaimer
==========

Stock firmware uses a dual-bank layout (kernel0/kernel1, ~15 MiB each).
OpenWrt replaces both banks with a single contiguous firmware partition.
Flashing OpenWrt overwrites both stock kernel slots; U-Boot remains
intact and can be used for recovery.

Installation
============

1. Enable SSH on the stock UniFi OS and log in with user account.

(at this stage you may make backups of the flash, just to be sure)

2. Copy the OpenWrt sysupgrade image to /tmp on the switch (e.g. via
   scp).

3. Adjust IMG below to point at the copied file, then run the block as a
   whole. It writes kernel0, splits into kernel1 if the image is larger
   than that slot (otherwise invalidates kernel1 so U-Boot cannot pick
   a stale bank), and reboots:

   IMG=/tmp/openwrt-realtek-rtl931x-ubnt_usw-pro-xg-8-poe-squashfs-sysupgrade.bin
   K0_BLOCKS=$((0xec0000 / 0x10000))

   dd if="$IMG" of=/dev/mtdblock2 bs=64k count=$K0_BLOCKS conv=fsync
   if [ "$(wc -c < "$IMG")" -gt $((0xec0000)) ]; then
       dd if="$IMG" of=/dev/mtdblock3 bs=64k skip=$K0_BLOCKS conv=fsync
   else
       dd if=/dev/zero of=/dev/mtdblock3 bs=64k count=1 conv=fsync
   fi
   sync

   Then reboot the switch, it comes up in OpenWrt after reboot.

   You may also install the image in any other way, just make sure to
   write it to the kernel0 partition and if the image is larger than
   16MiB, write the rest to the kernel1 partition, otherwise invalidate
   it so U-Boot cannot boot from the second bank.

4. It is recommended to modify the bootcmd to speedup the boot and prevent
   any issues due to the dual-boot selection. Since U-Boot by default
   uses bootubnt which does a lot of (unneeded) RTK initialization,
   quite some time passes until Linux is started. Additionally, the
   U-boot logic fiddles with some bits on flash which causes JFFS2
   errors in OpenWrt. While this doesn't seem to cause issues yet, be
   defensive and set the bootcmd to:

     bootm 0xb4150000

   This directly boots the uImage from flash, without doing all the
   initialization. OpenWrt is able to bootstrap the networking completely
   on its own.

It does not matter which bank stock booted from when the dd block
runs: both banks are touched in the same pass (kernel0 written, kernel1
either written or invalidated). With kernel1 invalidated, U-Boot's
internal fallback kicks in and permanently switches to kernel0 on the
next boot, so the device stays on OpenWrt as long as kernel0 is
bootable.

Recovery
========

Since the installation procedure invalidates or partially overwrites
the second bank, recovery requires serial console access (see Hardware
above for pinout).

1. Interrupt U-Boot autoboot by spamming a key during early boot to
   drop into the U-Boot prompt.

2. Bring up networking:

   rtk network on

3. Transfer an OpenWrt initramfs image via TFTP and boot it:

   tftpboot 0x82000000 <server>:<initramfs.bin>
   bootm 0x82000000

4. From the running initramfs OpenWrt, do a sysupgrade to reflash
   OpenWrt or whatever you want to recover. There is no need for the
   complicated procedure from installation since OpenWrt sees the
   firmware partition already as a whole.

Return to stock firmware
========================

There is no fully-supported revert path. The stock firmware blob is a
Ubiquiti UBNT archive (header + parts, see firmware-utils' fw.h) that
embeds a u-boot and a kernel0 uImage payload; only the latter is
relevant when writing back to the kernel partitions.

The snippet below extracts the kernel0 uImage from such a blob by
locating the uImage magic and using the size carried in the uImage
header itself, without parsing any UBNT framing. It is provided as a
best-effort starting point; verify the result before flashing,
otherwise you're on your own:

   BLOB=US3.rtl93xx_7.4.1+X.Y.Z.bin
   OFF=$(grep -aboF $'\x27\x05\x19\x56' "$BLOB" | head -1 | cut -d: -f1)
   SIZE=$(( $(dd if="$BLOB" bs=1 skip=$((OFF + 12)) count=4 2>/dev/null \
               | hexdump -e '1/4 "%u"') + 64 ))
   dd if="$BLOB" of=kernel0.uImage bs=1 skip="$OFF" count="$SIZE"

Once you have a clean uImage, it can be written to the kernel partition
from within OpenWrt. If you adjusted the bootcmd during installation,
make sure to restore it to the default "bootcmd=bootubnt". After a reboot,
Ubiquiti's firmware should boot.

Or, if you did backups of the flash before, just write the backup to the
flash.

Link: openwrt#24010
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The Hasivo S1300WP-8XGT-4S+ is a 12-port managed switch based on the
Realtek RTL9313 (RTL931x) SoC.

Tested on hardware revision v1.02 (manufactured 2026-04).

Specifications:
- SoC: Realtek RTL9313
- RAM: 512 MB
- Flash: 32 MB SPI-NOR
- Ethernet: 8x 10GBASE-T (2x RTL8264 quad PHYs), 4x SFP+ (10G)
- Button: 1x reset
- LEDs: 1x system (green) + per-port link/activity via the SoC LED engine
- RTC: NXP PCF8563
- Management MCU (I2C 0x6F): watchdog, CPU/system temperature and fan
  control (hwmon)
- UART: 38400 8N1 on the internal header

Working: switching on all copper and SFP+ ports, per-port and system
LEDs, reset button, RTC, watchdog, temperature/fan monitoring.

Not supported: PoE (the PD69x0x PSE controllers are on the PCB but not
driven), front-panel USB host.

Installation:
Netboot the initramfs image over TFTP, then run sysupgrade from OpenWrt.
Connect to the serial console (38400 8N1) and interrupt the U-Boot
autoboot to reach the prompt (press Ctrl+C, then z, then h), then boot
the initramfs image from a TFTP server:

  RTL9310# setenv boardmodel RTL9313_12XGE
  RTL9310# rtk network on
  RTL9310# rtk 10g 55 fiber1g
  RTL9310# tftpboot 0x84f00000 openwrt-...-initramfs-kernel.bin
  RTL9310# bootm 0x84f00000

Port 55 is front-panel port 12. Use fiber1g for a 1G SFP, fiber10g for
SFP+, and dac50cm for an SFP/RJ45 module. Once OpenWrt has booted, copy
the sysupgrade image over and flash it with sysupgrade.

MAC addresses:
  The base MAC comes from the U-Boot environment variable "ethaddr" in
  the u-boot-env partition (stock BDINFO). These units ship unprovisioned
  (ethaddr = 00:E0:4C:00:00:00); in that case a random MAC is generated
  and persisted. Per-port LAN MACs are derived sequentially.

    eth0 / label    u-boot-env "ethaddr" (random fallback when unset)
    lan1 .. lan12   base MAC + sequential offset

Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: openwrt#23775
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
This was last attempted to be upstreamed in 2014. Move it to files as
with other local drivers.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: openwrt#24095
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Use the normal macro to remove some duplication.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: openwrt#24095
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Upstream nowadays prefers fwnode instead of of.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: openwrt#24095
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
CONFIG_KERNEL_GZIP does the same thing. It's used elsewhere for a
similar purpose.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: openwrt#24074
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The GCMP-256 pairwise cipher was advertised based only on the BSS htmode
(HE/EHT), without checking whether the driver actually implements it. On
phys that do not support GCMP-256 this makes hostapd reject the
configuration and fail to start.

Query the phy's NL80211 cipher suite list in device_capabilities() and
expose a phy_features.cipher_gcmp256 flag, then only offer GCMP-256 when
the driver advertises the GCMP-256 cipher suite (00-0F-AC:9, 0x000fac09),
mirroring how the HT/VHT feature flags are already gated on the reported
phy capabilities. This covers both the sae/sae-mixed "GCMP-256 CCMP"
pairwise default and the GCMP-256 pairwise cipher in the sae-compat RSNE
Override 2 element.

The "GCMP-256 CCMP" default now keys off driver support alone instead of
the htmode; a follow-up commit reintroduces the per-mode/EHT restriction
via a gcmp256 option.

Fixes: 1f86f4e ("wifi-scripts: ucode: simplify wpa_pairwise default selection")
Fixes: 86b9eec ("wifi-scripts: ucode: add WPA3-Personal Compatibility Mode")
Assisted-by: Claude:claude-opus-4-8
Link: openwrt#24041
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Commit a12cec9 ("wifi-scripts: ucode: advertise SAE-EXT-KEY AKM
alongside SAE") advertised the SAE-EXT-KEY AKM (00-0F-AC:24, SAE using a
group-dependent hash, aka SAE-GDH) by default on every sae, sae-mixed and
sae-compat BSS.

WPA3 Specification v3.5 only makes this AKM mandatory when the BSS enables
EHT or MLO (section 2.5, item 4); for HE and below it is merely
recommended (sections 2.2 and 2.3). In practice the FT-SAE-EXT-KEY AKM
(SAE-EXT-KEY combined with 802.11r), which gets added automatically once
Fast Transition is enabled, keeps some clients from associating (a Samsung
Galaxy Tab S10 FE) or makes them reboot shortly after connecting (a Poco
X6). Plain SAE-EXT-KEY without FT was seen to work on the same tablet, but
its interoperability is not well tested.

Drop the fixed schema default and pick the default from the auth type in
parse_encryption instead. Only default it on where it is both mandatory
and safe to offer: on Compatibility mode (sae-compat) BSSes running an EHT
htmode, which carry it in a separate RSN Override element that legacy
clients ignore. Keep it off for WPA3-Personal (sae) and Transition
(sae-mixed) mode, where it would sit in the main RSNE that a choking
client cannot ignore, and off on non-EHT BSSes. An explicit
'option sae_ext_key 0/1' still overrides this per BSS.

The SAE-EXT-KEY AKM in the sae-compat RSN Override 2 element now keys off
config.sae_ext_key alone; the extra config.rsn_override_pairwise_2 guard
is dropped, decoupling the AKM from the GCMP-256 pairwise cipher so each
follows its own option.

Fixes: a12cec9 ("wifi-scripts: ucode: advertise SAE-EXT-KEY AKM alongside SAE")
Assisted-by: Claude:claude-opus-4-8
Link: openwrt#24041
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Commit 1f86f4e ("wifi-scripts: ucode: simplify wpa_pairwise default
selection") made HE and EHT BSSes default their pairwise cipher to
"GCMP-256 CCMP", and commit 86b9eec ("wifi-scripts: ucode: add
WPA3-Personal Compatibility Mode") always put GCMP-256 into the RSNE
Override 2 element on EHT compatibility-mode BSSes.

WPA3 Specification v3.5 only makes GCMP-256 mandatory when the BSS enables
EHT or MLO (section 2.5, item 5); for HE and below the WPA3 and Wi-Fi
Enhanced Open Deployment Guide v1.1 lists it as recommended, not required.
Advertising it by default causes interoperability problems: several
clients fail to associate when GCMP-256 is offered as a pairwise cipher
and connect again with CCMP only (Nanoleaf devices, a Motorola/Unisoc
phone, a Linux/iwd laptop).

Add a gcmp256 UCI option and, like sae_ext_key, default it on only where
GCMP-256 is both mandatory and safe: on Compatibility mode (sae-compat)
BSSes running an EHT htmode, which carry it in a separate RSNE Override 2
element that legacy clients ignore. It defaults off for WPA3-Personal
(sae) and Transition (sae-mixed) mode and on non-EHT BSSes. An explicit
'option gcmp256 0/1' overrides the default per BSS.

Both GCMP-256 pairwise defaults now key off config.gcmp256 (and, from the
earlier driver-support change, the phy actually implementing the cipher):
the sae/sae-mixed "GCMP-256 CCMP" pairwise cipher and the sae-compat RSNE
Override 2 element. The 'encryption sae+gcmp256' suffix and the wpa3-192
mode still force GCMP-256 as before.

Fixes: 1f86f4e ("wifi-scripts: ucode: simplify wpa_pairwise default selection")
Fixes: 86b9eec ("wifi-scripts: ucode: add WPA3-Personal Compatibility Mode")
Assisted-by: Claude:claude-opus-4-8
Link: openwrt#24041
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The supplicant config generator emitted the phase2 directive as
phase2="auth=${auth}" for every PEAP/TTLS/FAST configuration. That is
wrong whenever the configured inner method is an EAP method: for
auth='EAP-MSCHAPV2' it produced phase2="auth=EAP-MSCHAPV2", which
wpa_supplicant rejects with:

  TLS: Unsupported Phase2 EAP method 'EAP-MSCHAPV2'

breaking WPA-Enterprise clients that use an EAP inner method.

Mirror the shell config generator (hostapd.sh): strip the "EAP-" prefix
and pick the phase2 prefix from the method type, i.e. "autheap=" for a
tunneled EAP method with TTLS and "auth=" for a non-EAP method or a
full "auth=..." spec provided by the user.

Fixes: openwrt#24086
Fixes: c92ded2 ("wifi-scripts: fix EAP STA support in supplicant config generation")
Assisted-by: Claude:claude-opus-4-8
Link: openwrt#24088
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The supplicant config generator emitted the altsubject_match,
domain_match and domain_suffix_match server certificate constraints
through the plain (unquoted) variable list. As these are UCI arrays,
they were rendered space-separated and without quotes, e.g.

  altsubject_match=DNS:a.example.com DNS:b.example.com

wpa_supplicant parses an unquoted string value as a hex blob, so such a
line fails to parse and the constraint is dropped. wpa_supplicant
expects a single quoted, semicolon-separated string:

  altsubject_match="DNS:a.example.com;DNS:b.example.com"

Join these lists with semicolons and emit them as quoted strings.

The inner-tunnel (phase 2) constraints subject_match2, altsubject_match2,
domain_match2 and domain_suffix_match2 were not written to the config at
all; emit them as well. Add the matching inner EAP-TLS options ca_cert2,
client_cert2, private_key2 and private_key2_passwd to the schema so they
validate cleanly.

Fixes: 218f388 ("wifi-scripts: add ucode based scripts")
Assisted-by: Claude:claude-opus-4-8
Link: openwrt#24088
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The shell config generator read the client private key from the UCI
options priv_key / priv_key_pwd (and priv_key2 / priv_key2_pwd for the
inner tunnel). The ucode generator was switched to private_key /
private_key_passwd (matching the wpa_supplicant field names), and LuCI
was updated accordingly, but existing configurations still carry the old
option names.

Such configs silently lose their private key: for an EAP-TLS client this
leaves wpa_supplicant without a client key and authentication fails after
upgrading from 24.10.

The schema already lists priv_key / priv_key_pwd, but as plain strings,
so validate() never migrates them. Declare them (and the missing
priv_key2 / priv_key2_pwd) as aliases of the private_key* options so the
old names keep working.

Fixes: openwrt#22599
Fixes: 218f388 ("wifi-scripts: add ucode based scripts")
Assisted-by: Claude:claude-opus-4-8
Link: openwrt#24088
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.38

Removed upstreamed:
  linux/generic/backport-6.18/300-v7.2-MIPS-smp-report-dying-CPU-to-RCU-in-stop_this_cpu.patch[1]

All other patches automatically rebased via update_kernel.sh

1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.18.38&id=f9b57a0015c241274651f4b36627f56b1b5a8651

Build system: x86/64
Build-tested: x86/64-glibc
Run-tested: x86/64-glibc

Signed-off-by: John Audia <therealgraysky@proton.me>
Link: openwrt#24083
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
jjcszxh and others added 4 commits July 7, 2026 08:56
Signed-off-by: Lucas <juejingchongsheng@gmail.com>
Signed-off-by: Lucas <juejingchongsheng@gmail.com>
Signed-off-by: Lucas <juejingchongsheng@gmail.com>
Signed-off-by: jjcszxh <1003062992@qq.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment