diff --git a/news/README.md b/news/README.md index 24f6e10a11195ae9cffd32afd52379aa9d100b66..fd63b700f1e9f4760f928aa1cc296726413eef3c 100644 --- a/news/README.md +++ b/news/README.md @@ -4,6 +4,1044 @@ * [2022 年](2022.md) +## 20230402：第 40 期 + +### 内核动态 + +#### RISC-V 架构支持 + +**[v1: RISC-V: KVM: Allow Zbb extension for Guest/VM](http://lore.kernel.org/linux-riscv/20230401112730.2105240-1-apatel@ventanamicro.com/)** + +> We extend the KVM ISA extension ONE_REG interface to allow KVM +> user space to detect and enable Zbb extension for Guest/VM. +> + +**[v7: Basic clock, reset & device tree support for StarFive JH7110 RISC-V SoC](http://lore.kernel.org/linux-riscv/20230401111934.130844-1-hal.feng@starfivetech.com/)** + +> This patch series adds basic clock, reset & DT support for StarFive +> JH7110 SoC. +> +> @Stephen and @Conor, I have made this series start with the shared +> dt-bindings, so it will be easier to merge. +> + +**[v4: Use dma_default_coherent for devicetree default coherency](http://lore.kernel.org/linux-riscv/20230401091531.47412-1-jiaxun.yang@flygoat.com/)** + +> This series split out second half of my previous series +> "v1: MIPS DMA coherence fixes". +> +> It intends to use dma_default_coherent to determine the default coherency of +> devicetree probed devices instead of hardcoding it with Kconfig options. +> + +**[v1: riscv: dts: nezha-d1: Add memory](http://lore.kernel.org/linux-riscv/20230331182727.4062790-1-evan@rivosinc.com/)** + +> Add memory info for the D1 Nezha, which seems to be required for it to +> boot with the stock firmware. Note that this hardcodes 1GB, which is +> not technically correct as they also make models with different amounts +> of RAM. Is the firmware supposed to populate this? +> + +**[v4: RISC-V KVM ONE_REG interface for SBI](http://lore.kernel.org/linux-riscv/20230331174542.2067560-1-apatel@ventanamicro.com/)** + +> This series first does few cleanups/fixes (PATCH1 to PATCH5) and adds +> ONE-REG interface for customizing the SBI interface visible to the +> Guest/VM. +> +> The testing of this series has been done with KVMTOOL changes in +> riscv_sbi_imp_v1 branch at: +> https://github.com/avpatel/kvmtool.git +> + +**[v10: function_graph: Support recording and printing the return value of function](http://lore.kernel.org/linux-riscv/cover.1680265828.git.pengdonglin@sangfor.com.cn/)** + +> When using the function_graph tracer to analyze system call failures, +> it can be time-consuming to analyze the trace logs and locate the kernel +> function that first returns an error. This change aims to simplify the +> process by recording the function return value to the 'retval' member of +> 'ftrace_graph_ent' and printing it when outputing the trace log. +> + +**[v7: RISC-V non-coherent function pointer based CMO + non-coherent DMA support for AX45MP](http://lore.kernel.org/linux-riscv/20230330204217.47666-1-prabhakar.mahadev-lad.rj@bp.renesas.com/)** + +> On the Andes AX45MP core, cache coherency is a specification option so it +> may not be supported. In this case DMA will fail. To get around with this +> issue this patch series does the below: +> +> 1] Andes alternative ports is implemented as errata which checks if the IOCP +> is missing and only then applies to CMO errata. One vendor specific SBI EXT +> (ANDES_SBI_EXT_IOCP_SW_WORKAROUND) is implemented as part of errata. +> + +**[v1: dt-bindings: move cache controller bindings to a cache directory](http://lore.kernel.org/linux-riscv/20230330173255.109731-1-conor@kernel.org/)** + +> There's a bunch of bindings for (mostly l2) cache controllers +> scattered to the four winds, move them to a common directory. +> I renamed the freescale l2cache.txt file, as while that might make sense +> when the parent dir is fsl, it's confusing after the move. +> The two Marvell bindings have had a "marvell," prefix added to match +> their compatibles. +> + +**[v15: Microchip Soft IP corePWM driver](http://lore.kernel.org/linux-riscv/20230330071203.286972-1-conor.dooley@microchip.com/)** + +> Uwe & I had a long back and forth about period calculations on v13, +> my ultimate conclusion being that, after some testing of the "corrected" +> calculation in hardware, the original calculation was correct. +> I think we had gotten sucked into discussion the calculation of the +> period itself, when we were in fact trying to calculate a bound on the +> period instead. That discussion is here: +> https://lore.kernel.org/linux-pwm/Y+ow8tfAHo1yv1XL@wendy/ +> + +**[v8: RISC-V Hibernation Support](http://lore.kernel.org/linux-riscv/20230330064321.1008373-1-jeeheng.sia@starfivetech.com/)** + +> This series adds RISC-V Hibernation/suspend to disk support. +> Low level Arch functions were created to support hibernation. +> swsusp_arch_suspend() relies code from __cpu_suspend_enter() to write +> cpu state onto the stack, then calling swsusp_save() to save the memory +> image. +> + +**[v1: iommu: PGTABLE_LPAE is also for RISCV](http://lore.kernel.org/linux-riscv/20230330060105.29460-1-rdunlap@infradead.org/)** + +> On riscv64, linux-next-20233030 (and for several days earlier), +> there is a kconfig warning: +> +> WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE_LPAE +> Depends on [n]: IOMMU_SUPPORT [=y] && (ARM || ARM64 || COMPILE_TEST [=n]) && !GENERIC_ATOMIC64 [=n] +> Selected by [y]: +> - IPMMU_VMSA [=y] && IOMMU_SUPPORT [=y] && (ARCH_RENESAS [=y] || COMPILE_TEST [=n]) && !GENERIC_ATOMIC64 [=n] +> + +**[v1: DT header disentangling, part 1](http://lore.kernel.org/linux-riscv/20230329-dt-cpu-header-cleanups-v1-0-581e2605fe47@kernel.org/)** + +> This is the first of a series of clean-ups to disentangle the DT +> includes. There's a decade plus old comment in of_device.h: +> +> #include /* temporary until merge */ +> + +**[v1: Add TDM audio on StarFive JH7110](http://lore.kernel.org/linux-riscv/20230329153320.31390-1-walker.chen@starfivetech.com/)** + +> This patchset adds TDM audio driver for the StarFive JH7110 SoC. The +> first patch adds device tree binding for TDM module. The second patch +> adds tdm driver support for JH7110 SoC. The last patch adds device node +> of tdm and sound card to JH7110 dts. +> + +**[v4: Implement GCM ghash using Zbc and Zbkb extensions](http://lore.kernel.org/linux-riscv/20230329140642.2186644-1-heiko.stuebner@vrull.eu/)** + +> This was originally part of my vector crypto series, but was part +> of a separate openssl merge request implementing GCM ghash as using +> non-vector extensions. +> + +**[v2: riscv: Dump user opcode bytes on fatal faults](http://lore.kernel.org/linux-riscv/20230329082950.726-1-cuiyunhui@bytedance.com/)** + +> We encountered such a problem that when the system starts to execute +> init, init exits unexpectedly with error message: "unhandled signal 4 +> code 0x1 ...". +> +> We are more curious about which instruction execution caused the +> exception. After dumping it through show_opcodes(), we found that it +> was caused by a floating-point instruction. +> + +**[v2: riscv: Introduce KASLR](http://lore.kernel.org/linux-riscv/20230329052926.69632-1-alexghiti@rivosinc.com/)** + +> The following KASLR implementation allows to randomize the kernel mapping: +> +> - virtually: we expect the bootloader to provide a seed in the device-tree +> - physically: only implemented in the EFI stub, it relies on the firmware to +> provide a seed using EFI_RNG_PROTOCOL. arm64 has a similar implementation +> hence the patch 3 factorizes KASLR related functions for riscv to take +> advantage. +> + +**[v9: riscv: Allow to downgrade paging mode from the command line](http://lore.kernel.org/linux-riscv/20230329050951.66085-1-alexghiti@rivosinc.com/)** + +> This new version gets rid of the limitation that prevented KASAN kernels +> to use the newly introduced parameters. +> +> While looking into KASLR, I fell onto commit aacd149b6238 ("arm64: head: +> avoid relocating the kernel twice for KASLR"): it allows to use the fdt +> functions very early in the boot process with KASAN enabled by simply +> compiling a new version of those functions without instrumentation. +> + +**[v9: Introduce 64b relocatable kernel](http://lore.kernel.org/linux-riscv/20230329045329.64565-1-alexghiti@rivosinc.com/)** + +> After multiple attempts, this patchset is now based on the fact that the +> 64b kernel mapping was moved outside the linear mapping. +> +> The first patch allows to build relocatable kernels but is not selected +> by default. That patch is a requirement for KASLR. +> The second and third patches take advantage of an already existing powerpc +> script that checks relocations at compile-time, and uses it for riscv. +> + +**[v2: -next: support allocating crashkernel above 4G explicitly on riscv](http://lore.kernel.org/linux-riscv/20230328115150.2700016-1-chenjiahao16@huawei.com/)** + +> On riscv, the current crash kernel allocation logic is trying to +> allocate within 32bit addressible memory region by default, if +> failed, try to allocate without 4G restriction. +> +> In need of saving DMA zone memory while allocating a relatively large +> crash kernel region, allocating the reserved memory top down in +> high memory, without overlapping the DMA zone, is a mature solution. +> Hence this patchset introduces the parameter option crashkernel=X,[high,low]. +> + +**[v18: RISC-V IPI Improvements](http://lore.kernel.org/linux-riscv/20230328035223.1480939-1-apatel@ventanamicro.com/)** + +> This series aims to improve IPI support in Linux RISC-V in following ways: +> 1) Treat IPIs as normal per-CPU interrupts instead of having custom RISC-V +> specific hooks. This also makes Linux RISC-V IPI support aligned with +> other architectures. +> 2) Remote TLB flushes and icache flushes should prefer local IPIs instead +> of SBI calls whenever we have specialized hardware (such as RISC-V AIA +> IMSIC and RISC-V SWI) which allows S-mode software to directly inject +> IPIs without any assistance from M-mode runtime firmware. +> + +**[v17: -next: riscv: Add vector ISA support](http://lore.kernel.org/linux-riscv/20230327164941.20491-1-andy.chiu@sifive.com/)** + +> This patchset is implemented based on vector 1.0 spec to add vector support +> in riscv Linux kernel. There are some assumptions for this implementations. +> +> 1. We assume all harts has the same ISA in the system. +> 2. We disable vector in both kernel andy user space [1] by default. Only +> enable an user's vector after an illegal instruction trap where it +> actually starts executing vector (the first-use trap [2]). +> 3. We detect "riscv,isa" to determine whether vector is support or not. +> + +**[v1: dma-mapping: unify support for cache flushes](http://lore.kernel.org/linux-riscv/20230327121317.4081816-1-arnd@kernel.org/)** + +> After a long discussion about adding SoC specific semantics for when +> to flush caches in drivers/soc/ drivers that we determined to be +> fundamentally flawed[1], I volunteered to try to move that logic into +> architecture-independent code and make all existing architectures do +> the same thing. +> + +**[v1: riscv/fault: Dump user opcode bytes on fatal faults](http://lore.kernel.org/linux-riscv/20230327115642.1610-1-cuiyunhui@bytedance.com/)** + +> We encountered such a problem(logs are below). We are more curious about +> which instruction execution caused the exception. After dumping it +> through show_opcodes(), we found that it was caused by a floating-point +> instruction. +> +> In this way, we found the problem: in the system bringup , it is +> precisely that we have not enabled the floating point function. +> + +#### 进程调度 + +**[v1: sched: Introduce per-mm/cpu concurrency id state](http://lore.kernel.org/lkml/20230330230911.228720-1-mathieu.desnoyers@efficios.com/)** + +> Keep track of the currently allocated mm_cid for each mm/cpu rather than +> freeing them immediately. This eliminates most atomic ops when context +> switching back and forth between threads belonging to different memory +> spaces in multi-threaded scenarios (many processes, each with many +> threads). +> + +**[v1: sched/deadline: cpuset: Rework DEADLINE bandwidth restoration](http://lore.kernel.org/lkml/20230329125558.255239-1-juri.lelli@redhat.com/)** + +> Qais reported [1] that iterating over all tasks when rebuilding root +> domains for finding out which ones are DEADLINE and need their bandwidth +> correctly restored on such root domains can be a costly operation (10+ +> ms delays on suspend-resume). He proposed we skip rebuilding root +> domains for certain operations, but that approach seemed arch specific +> and possibly prone to errors, as paths that ultimately trigger a rebuild +> might be quite convoluted (thanks Qais for spending time on this!). +> + +**[v1: perf sched: sync task state macros with kernel](http://lore.kernel.org/lkml/20230329035203.6194-1-zegao2021@gmail.com/)** + +> commit 8ef9925b02c2 ("sched/debug: Add explicit TASK_PARKED printing") +> changes some task state macros, this patch makes perf-sched in sync +> + +**[v1: sched: EEVDF using latency-nice](http://lore.kernel.org/lkml/20230328092622.062917921@infradead.org/)** + +> Many changes since last time; most notably it now fully replaces CFS and uses +> lag based placement for migrations. Smaller changes include: +> +> - uses scale_load_down() for avg_vruntime; I measured the max delta to be +> 44 +> bits on a system/cgroup based kernel build. +> - fixed a bunch of reweight / cgroup placement issues +> - adaptive placement strategy for smaller slices +> - rename se->lag to se->vlag +> + +**[v3: sched: print parent comm in sched_show_task()](http://lore.kernel.org/lkml/20230328034438.GA8421@didi-ThinkCentre-M930t-N000/)** + +> Knowing who the parent is might be useful for debugging. +> For example, we can sometimes resolve kernel hung tasks by stopping +> the person who begins those hung tasks. +> With the parent's name printed in sched_show_task(), +> it might be helpful to let people know which "service" should be operated. +> Also, we move the parent info to a following new line. +> It would be better to solve the situation when the task +> is not alive and we could not get information about the parent. +> + +**[v1: sched/cputime: Make cputime_adjust() more accurate](http://lore.kernel.org/lkml/20230328024827.12187-1-maxing.lan@bytedance.com/)** + +> In the current algorithm of cputime_adjust(), the accumulated stime and +> utime are used to divide the accumulated rtime. When the value is very +> large, it is easy for the stime or utime not to be updated. It can cause +> sys or user utilization to be zero for long time. +> + +**[v2: selftests: sched: Add more core schedule prctl calls](http://lore.kernel.org/lkml/20230327201855.121821-1-ivan.orlov0322@gmail.com/)** + +> The core sched kselftest makes prctl calls only with correct +> parameters. This patch will extend this test with more core +> schedule prctl calls with wrong parameters to increase code +> coverage. +> + +**[v1: sched: Introduce mm_cid runqueue cache](http://lore.kernel.org/lkml/20230327195318.137094-1-mathieu.desnoyers@efficios.com/)** + +> Introduce a per-runqueue cache containing { mm, mm_cid } entries. +> Keep track of the recently allocated mm_cid for each mm rather than +> freeing them immediately. This eliminates most atomic ops when +> context switching back and forth between threads belonging to +> + +**[v1: sched/fair: Make tg->load_avg per node](http://lore.kernel.org/lkml/20230327053955.GA570404@ziqianlu-desk2/)** + +> When using sysbench to benchmark Postgres in a single docker instance +> with sysbench's nr_threads set to nr_cpu, it is observed there are times +> update_cfs_group() and update_load_avg() shows noticeable overhead on +> cpus of one node of a 2sockets/112core/224cpu Intel Sapphire Rapids: +> + +**[GIT PULL: sched/urgent for v6.3-rc4](http://lore.kernel.org/lkml/20230326130354.GDZCBCum4r9MJ8thhi@fat_crate.local/)** + +> please pull an urgent sched fix for 6.3. +> +> Thx. +> + +**[v1: sched/topology: add for_each_numa_cpu() macro](http://lore.kernel.org/lkml/20230325185514.425745-1-yury.norov@gmail.com/)** + +> for_each_cpu() is widely used in kernel, and it's beneficial to create +> a NUMA-aware version of the macro. +> +> Recently added for_each_numa_hop_mask() works, but switching existing +> codebase to it is not an easy process. +> + +#### 内存管理 + +**[v3: Providing mount in memfd_restricted() syscall](http://lore.kernel.org/linux-mm/cover.1680306489.git.ackerleytng@google.com/)** + +> This patchset builds upon the memfd_restricted() system call that was +> discussed in the ‘KVM: mm: fd-based approach for supporting KVM’ patch +> series, at +> https://lore.kernel.org/lkml/20221202061347.1070246-1-chao.p.peng@linux.intel.com/T/ +> + +**[v3: splice, net: Replace sendpage with sendmsg(MSG_SPLICE_PAGES)](http://lore.kernel.org/linux-mm/20230331160914.1608208-1-dhowells@redhat.com/)** + +> I've been looking at how to make pipes handle the splicing in of multipage +> folios and also looking to see if I could implement a suggestion from Willy +> that pipe_buffers could perhaps hold a list of pages (which could make +> splicing simpler - an entire splice segment would go in a single +> pipe_buffer). +> + +**[v5: userfaultfd: convert userfaultfd functions to use folios](http://lore.kernel.org/linux-mm/20230331093937.945725-1-zhangpeng362@huawei.com/)** + +> This patch series converts several userfaultfd functions to use folios. +> +> Change log: +> + +**[v3: Ignore non-LRU-based reclaim in memcg reclaim](http://lore.kernel.org/linux-mm/20230331070818.2792558-1-yosryahmed@google.com/)** + +> Upon running some proactive reclaim tests using memory.reclaim, we +> noticed some tests flaking where writing to memory.reclaim would be +> successful even though we did not reclaim the requested amount fully. +> Looking further into it, I discovered that *sometimes* we over-report +> the number of reclaimed pages in memcg reclaim. +> + +**[v1: memcg: Set memory min, low, high values along with max](http://lore.kernel.org/linux-mm/20230330202232.355471-1-shaun.tancheff@gmail.com/)** + +> memcg-v1 does not expose memory min, low, and high. +> +> These values should to be set to reasonable non-zero values +> when max is set. +> +> This patch sets them to 10%, 20% and 80% respective to max. +> + +**[v3: memcg: avoid flushing stats atomically where possible](http://lore.kernel.org/linux-mm/20230330191801.1967435-1-yosryahmed@google.com/)** + +> rstat flushing is an expensive operation that scales with the number of +> cpus and the number of cgroups in the system. The purpose of this series +> is to minimize the contexts where we flush stats atomically. +> + +**[v1: selftests/mm: Split / Refactor userfault test](http://lore.kernel.org/linux-mm/20230330155707.3106228-1-peterx@redhat.com/)** + +> [Sorry for the test case bomb] +> +> This patchset splits userfaultfd.c into two tests: +> +> - uffd-stress: the "vanilla", old and powerful stress test +> - uffd-unit-tests: all the unit tests will be moved here +> +> This is on my todo list for a long time but I never did it for real. The +> uffd test is growing into a small and cute monster. I start to notice it's +> going harder to maintain such a test and make it useful. +> + +**[v2: bio: check return values of bio_add_page](http://lore.kernel.org/linux-mm/cover.1680172791.git.johannes.thumshirn@wdc.com/)** + +> We have two functions for adding a page to a bio, __bio_add_page() which is +> used to add a single page to a freshly created bio and bio_add_page() which is +> used to add a page to an existing bio. +> +> While __bio_add_page() is expected to succeed, bio_add_page() can fail. +> +> This series converts the callers of bio_add_page() which can easily use +> __bio_add_page() to using it and checks the return of bio_add_page() for +> callers that don't work on a freshly created bio. +> +> Lastly it marks bio_add_page() as __must_check so we don't have to go again +> and audit all callers. +> + +**[v1: mm: ksm: support hwpoison for ksm page](http://lore.kernel.org/linux-mm/20230330074501.205092-1-xialonglong1@huawei.com/)** + +> Currently, ksm does not support hwpoison. As ksm is being used more widely +> for deduplication at the system level, container level, and process level, +> supporting hwpoison for ksm has become increasingly important. However, ksm +> pages were not processed by hwpoison in 2009 [1]. +> + +**[v1: kmemleak-test: Optimize kmemleak_test.c build flow](http://lore.kernel.org/linux-mm/20230330060904.292975-1-gehao@kylinos.cn/)** + +> Now kmemleak-test.c is moved to samples directory, +> if CONFIG_DEBUG_KMEMLEAK_TEST=m,but CONFIG_SAMPLES +> is not set,it will be meaningless. +> +> So we will remove CONFIG_DEBUG_KMEMLEAK_TEST and +> add CONFIG_SAMPLE_KMEMLEAK which in samples directory +> to control kmemleak-test.c build or not +> + +**[v3: regmap: Add basic maple tree register cache](http://lore.kernel.org/linux-mm/20230325-regcache-maple-v3-0-23e271f93dc7@kernel.org/)** + +> The current state of the art for sparse register maps is the +> rbtree cache. This works well for most applications but isn't +> always ideal for sparser register maps since the rbtree can get +> deep, requiring a lot of walking. Fortunately the kernel has a +> data structure intended to address this very problem, the maple +> tree. Provide an initial implementation of a register cache +> based on the maple tree to start taking advantage of it. +> + +**[v12: Memory poison recovery in khugepaged collapsing](http://lore.kernel.org/linux-mm/20230329151121.949896-1-jiaqiyan@google.com/)** + +> Memory DIMMs are subject to multi-bit flips, i.e. memory errors. +> As memory size and density increase, the chances of and number of +> memory errors increase. The increasing size and density of server +> RAM in the data center and cloud have shown increased uncorrectable +> memory errors. There are already mechanisms in the kernel to recover +> from uncorrectable memory errors. This series of patches provides +> the recovery mechanism for the particular kernel agent khugepaged +> when it collapses memory pages. +> + +#### 文件系统 + +**[v1: fs: consolidate duplicate dt_type helpers](http://lore.kernel.org/linux-fsdevel/20230330104144.75547-1-jlayton@kernel.org/)** + +> There are three copies of the same dt_type helper sprinkled around the +> tree. Convert them to use the common fs_umode_to_dtype function instead, +> which has the added advantage of properly returning DT_UNKNOWN when +> given a mode that contains an unrecognized type. +> + +**[v2: fs: consolidate dt_type() helper definitions](http://lore.kernel.org/linux-fsdevel/20230330000157.297698-1-jlayton@kernel.org/)** + +> There are 4 functions named dt_type() in the kernel. There is also the +> S_DT macro in fs_types.h. +> +> Replace the S_DT macro with a static inline named dt_type, and have all +> of the existing copies call that instead. The v9fs helper is renamed to +> distinguish it from the others. +> + +**[v8: Implement copy offload support](http://lore.kernel.org/linux-fsdevel/20230327084103.21601-1-anuj20.g@samsung.com/)** + +> The patch series covers the points discussed in November 2021 virtual +> call [LSF/MM/BFP TOPIC] Storage: Copy Offload [0]. +> We have covered the initial agreed requirements in this patchset and +> further additional features suggested by community. +> Patchset borrows Mikulas's token based approach for 2 bdev +> implementation. +> + +**[v1: zonefs: Always invalidate last cache page on append write](http://lore.kernel.org/linux-fsdevel/20230329055823.1677193-1-damien.lemoal@opensource.wdc.com/)** + +> When a direct append write is executed, the append offset may correspond +> to the last page of an inode which might have been cached already by +> buffered reads, page faults with mmap-read or non-direct readahead. +> To ensure that the on-disk and cached data is consistant for such last +> cached page, make sure to always invalidate it in +> zonefs_file_dio_append(). This invalidation will always be a no-op when +> the device block size is equal to the page size (e.g. 4K). +> + +#### 网络设备 + +**[v1: bpf-next: Add FOU support for externally controlled ipip devices](http://lore.kernel.org/netdev/cover.1680379518.git.cehrig@cloudflare.com/)** + +> This patch set adds support for using FOU or GUE encapsulation with +> an ipip device operating in collect-metadata mode and a set of kfuncs +> for controlling encap parameters exposed to a BPF tc-hook. +> +> BPF tc-hooks allow us to read tunnel metadata (like remote IP addresses) +> in the ingress path of an externally controlled tunnel interface via +> the bpf_skb_get_tunnel_{key,opt} bpf-helpers. Packets can then be +> redirected to the same or a different externally controlled tunnel +> interface by overwriting metadata via the bpf_skb_set_tunnel_{key,opt} +> helpers and a call to bpf_redirect. This enables us to redirect packets +> between tunnel interfaces - and potentially change the encapsulation +> type - using only a single BPF program. +> + +**[v1: net-next: ice: lower CPU usage with GNSS](http://lore.kernel.org/netdev/20230401172659.38508-1-mschmidt@redhat.com/)** + +> This series lowers the CPU usage of the ice driver when using its +> provided /dev/gnss*. +> +> Intel engineers, in addition to reviewing the patches for correctness, +> please also consider my doubts expressed in the descriptions of patches +> 1 and 2. There may be better solutions possible. +> + +**[v1: net: ethernet: mtk_eth_soc: use be32 type to store be32 values](http://lore.kernel.org/netdev/20230401-mtk_eth_soc-sparse-v1-1-84e9fc7b8eab@kernel.org/)** + +> Perhaps there is a nicer way to handle this but the code +> calls for converting an array of host byte order 32bit values +> to big endian 32bit values: an ipv6 address to be pretty printed. +> +> Use a sparse-friendly array of be32 to store these values. +> +> Also make use of the cpu_to_be32_array helper rather +> than open coding the conversion. +> + +**[v3: Add EMAC3 support for sa8540p-ride (devicetree/clk bits)](http://lore.kernel.org/netdev/20230331215804.783439-1-ahalaney@redhat.com/)** + +> This is a forward port / upstream refactor of code delivered +> downstream by Qualcomm over at [0] to enable the DWMAC5 based +> implementation called EMAC3 on the sa8540p-ride dev board. +> + +**[v3: net-next: Add EMAC3 support for sa8540p-ride](http://lore.kernel.org/netdev/20230331214549.756660-1-ahalaney@redhat.com/)** + +> This is a forward port / upstream refactor of code delivered +> downstream by Qualcomm over at [0] to enable the DWMAC5 based +> implementation called EMAC3 on the sa8540p-ride dev board. +> + +**[v5: bpf: XDP-hints: API change for RX-hash kfunc bpf_xdp_metadata_rx_hash](http://lore.kernel.org/netdev/168028882260.4030852.1100965689789226162.stgit@firesoul/)** + +> Current API for bpf_xdp_metadata_rx_hash() returns the raw RSS hash value, +> but doesn't provide information on the RSS hash type (part of 6.3-rc). +> +> This patchset proposal is to change the function call signature via adding +> a pointer value argument for providing the RSS hash type. +> + +**[v1: iproute2-next: tc: m_tunnel_key: support code for "nofrag" tunnels](http://lore.kernel.org/netdev/c43213bed30edfa0d6fa1b084e4d48c26417edc9.1680281221.git.dcaratti@redhat.com/)** + +> add control plane for setting TCA_TUNNEL_KEY_NO_FRAG flag on +> act_tunnel_key actions. +> + +**[v1: net-next: mlxsw: Use static trip points for transceiver modules](http://lore.kernel.org/netdev/cover.1680272119.git.petrm@nvidia.com/)** + +> Ido Schimmel writes: +> +> See patch #1 for motivation and implementation details. +> +> Patches #2-#3 are simple cleanups as a result of the changes in the +> first patch. +> + +**[v1: iproute2: ip-xfrm: accept "allow" as action in ip xfrm policy setdefault](http://lore.kernel.org/netdev/dc8c3fcd81a212e47547ae59ee6857ce25048ddd.1680268153.git.sd@queasysnail.net/)** + +> The help text claims that setdefault takes ACTION values, ie block | +> allow. In reality, xfrm_str_to_policy takes block | accept. +> +> We could also fix that by changing the help text/manpage, but then +> it'd be frustrating to have multiple ACTION with similar values used +> in different subcommands. +> + +**[v1: net-next: net: phy: introduce phy_reg_field interface](http://lore.kernel.org/netdev/20230331123259.567627-1-radu-nicolae.pirea@oss.nxp.com/)** + +> Some PHYs can be heavily modified between revisions, and the addresses of +> the registers are changed and the register fields are moved from one +> register to another. +> +> To integrate more PHYs in the same driver with the same register fields, +> but these register fields were located in different registers at +> + +**[v1: net-next: ice: allow matching on metadata](http://lore.kernel.org/netdev/20230331105747.89612-1-michal.swiatkowski@linux.intel.com/)** + +> This patchset is intended to improve the usability of the switchdev +> slow path. Without matching on a metadata values slow path works +> based on VF's MAC addresses. It causes a problem when the VF wants +> to use more than one MAC address (e.g. when it is in trusted mode). +> + +**[v6: net-next: sfc: support unicast PTP](http://lore.kernel.org/netdev/20230331111404.17256-1-ihuguet@redhat.com/)** + +> Unicast PTP was not working with sfc NICs. +> +> The reason was that these NICs don't timestamp all incoming packets, +> but instead they only timestamp packets of the queues that are selected +> for that. Currently, only one RX queue is configured for timestamp: the +> RX queue of the PTP channel. The packets that are put in the PTP RX +> queue are selected according to firmware filters configured from the +> driver. +> + +**[v1: net-next: net: stmmac: publish actual MTU restriction](http://lore.kernel.org/netdev/20230331092344.268981-1-vinschen@redhat.com/)** + +> Apart from devices setting the max MTU value from device tree, +> the initialization functions in many drivers use a default value +> of JUMBO_LEN. +> +> However, that doesn't reflect reality. The stmmac_change_mtu +> function restricts the MTU to the size of a single queue in the TX +> FIFO. +> + +**[v1: net-next: net: stmmac: allow ethtool action on PCI devices if device is down](http://lore.kernel.org/netdev/20230331092341.268964-1-vinschen@redhat.com/)** + +> So far stmmac is only able to handle ethtool commands if the device +> is UP. However, PCI devices usually just have to be in the active +> state for ethtool commands. +> + +**[v2: net: dsa: mv88e6xxx: Reset mv88e6393x force WD event bit](http://lore.kernel.org/netdev/20230331084014.1144597-1-gustav.ekelund@axis.com/)** + +> The force watchdog event bit is not cleared during SW reset in the +> mv88e6393x switch. This is a different behavior compared to mv886390 which +> clears the force WD event bit as advertised. This causes a force WD event +> to be handled over and over again as the SW reset following the event never +> clears the force WD event bit. +> + +**[v1: qlcnic: check pci_reset_function result](http://lore.kernel.org/netdev/20230331080605.42961-1-den-plotnikov@yandex-team.ru/)** + +> Static code analyzer complains to unchecked return value. +> It seems that pci_reset_function return something meaningful +> only if "reset_methods" is set. +> Even if reset_methods isn't used check the return value to avoid +> possible bugs leading to undefined behavior in the future. +> + +**[v1: net: vsock/vmci: convert VMCI error code to -ENOMEM on send](http://lore.kernel.org/netdev/2c3aeeac-2fcb-16f6-41cd-c0ca4e6a6d3e@sberdevices.ru/)** + +> This adds conversion of VMCI specific error code to general -ENOMEM. It +> is needed, because af_vsock.c passes error value returned from transport +> to the user, which does not expect to get VMCI_ERROR_* values. +> + +**[v2: net: qrtr: Do not do DEL_SERVER broadcast after DEL_CLIENT](http://lore.kernel.org/netdev/1680248937-16617-1-git-send-email-quic_srichara@quicinc.com/)** + +> On the remote side, when QRTR socket is removed, af_qrtr will call +> qrtr_port_remove() which broadcasts the DEL_CLIENT packet to all neighbours +> including local NS. NS upon receiving the DEL_CLIENT packet, will remove +> the lookups associated with the node:port and broadcasts the DEL_SERVER +> packet. +> + +#### 安全增强 + +**[v1: LoongArch: Add kernel address sanitizer support](http://lore.kernel.org/linux-hardening/20230328111714.2056-1-zhangqing@loongson.cn/)** + +> 1/8 of kernel addresses reserved for shadow memory. But for LoongArch, +> There are a lot of holes between different segments and valid address +> space(256T available) is insufficient to map all these segments to kasan +> shadow memory with the common formula provided by kasan core, saying +> addr >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET +> + +**[[RFC/RFT,V2] CFI: Add support for gcc CFI in aarch64](http://lore.kernel.org/linux-hardening/20230325085416.95191-1-ashimida.1990@gmail.com/)** + +> Based on Sami's patch[1], this patch makes the corresponding kernel +> configuration of CFI available when compiling the kernel with the gcc[2]. +> + +#### 异步 IO + +**[v6: io_uring/ublk: add generic IORING_OP_FUSED_CMD](http://lore.kernel.org/io-uring/20230330113630.1388860-1-ming.lei@redhat.com/)** + +> Hello Jens and Guys, +> +> Add generic fused command, which can include one primary command and multiple +> secondary requests. This command provides one safe way to share resource between +> primary command and secondary requests, and primary command is always +> completed after all secondary requests are done, and resource lifetime +> is bound with primary command. +> + +**[v5: io_uring/ublk: add IORING_OP_FUSED_CMD](http://lore.kernel.org/io-uring/20230328150958.1253547-1-ming.lei@redhat.com/)** + +> Hello Jens, +> +> Add IORING_OP_FUSED_CMD, it is one special URING_CMD, the 1st SQE(primary) is +> one 64byte URING_CMD, and the 2nd 64byte SQE(secondary) is another normal +> 64byte OP. The primary command provides device/file io buffer and +> submits OP represented by the secondary SQE using the provided buffer. This way +> solves ublk zero copy problem easily, since io buffer shares same lifetime with +> the primary command. +> + +**[v1: io_uring/poll: clear single/double poll flags on poll arming](http://lore.kernel.org/io-uring/61e3fefd-0a99-5916-c049-9143d3342379@kernel.dk/)** + +> Unless we have at least one entry queued, then don't call into +> io_poll_remove_entries(). Normally this isn't possible, but if we +> retry poll then we can have ->nr_entries cleared again as we're +> setting it up. If this happens for a poll retry, then we'll still have +> at least REQ_F_SINGLE_POLL set. io_poll_remove_entries() then thinks +> it has entries to remove. +> + +#### Rust For Linux + +**[v4: Rust pin-init API for pinned initialization of structs](http://lore.kernel.org/rust-for-linux/20230331215053.585759-1-y86-dev@protonmail.com/)** + +> This is the fourth version of the pin-init API. See [1] for v3. +> +> The tree at [2] contains these patches applied on top of 6.3-rc1. +> The Rust-doc documentation of the pin-init API can be found at [3]. +> +> These patches are a long way coming, since I held a presentation on +> safe pinned initialization at Kangrejos [4]. And my discovery of this +> problem was almost a year ago [5]. +> + +**[v2: rust: error: Add missing wrappers to convert to/from kernel error codes](http://lore.kernel.org/rust-for-linux/20230224-rust-error-v2-0-3900319812da@asahilina.net/)** + +> This series is part of the set of dependencies for the drm/asahi +> Apple M1/M2 GPU driver. +> +> It adds a bunch of missing wrappers in kernel::error, which are useful +> to convert to/from kernel error codes. Since these will be used by many +> abstractions coming up soon, I think it makes sense to merge them as +> soon as possible instead of bundling them with the first user. Hence, +> they have allow() tags to silence dead code warnings. These can be +> removed as soon as the first user is in the kernel crate. +> + +**[v1: rust: Add uapi crate](http://lore.kernel.org/rust-for-linux/20230329-rust-uapi-v1-0-ee78f2933726@asahilina.net/)** + +> In general, direct bindgen bindings for C kernel APIs are not intended +> to be used by drivers outside of the `kernel` crate. However, some +> drivers do need to interact directly with UAPI definitions to implement +> userspace APIs. +> + +#### BPF + +**[v2: bpf-next: bpf: optimize hashmap lookups when key_size is divisible by 4](http://lore.kernel.org/bpf/20230401200602.3275-1-aspsk@isovalent.com/)** + +> The BPF hashmap uses the jhash() hash function. There is an optimized version +> of this hash function which may be used if hash size is a multiple of 4. Apply +> this optimization to the hashmap in a similar way as it is done in the bloom +> filter map. +> + +**[v3: bpf-next: Prepare veristat for packaging](http://lore.kernel.org/bpf/20230331222405.3468634-1-andrii@kernel.org/)** + +> This patch set relicenses veristat.c to dual GPL-2.0/BSD-2 license and +> prepares it to be mirrored to Github at libbpf/veristat repo. +> +> Few small issues in the source code are fixed, found during Github sync +> preparetion. +> + +**[v2: bpf-next: Enable RCU semantics for task kptrs](http://lore.kernel.org/bpf/20230331195733.699708-1-void@manifault.com/)** + +> In commit 22df776a9a86 ("tasks: Extract rcu_users out of union"), the +> 'refcount_t rcu_users' field was extracted out of a union with the +> 'struct rcu_head rcu' field. This allows us to use the field for +> refcounting struct task_struct with RCU protection, as the RCU callback +> no longer flips rcu_users to be nonzero after the callback is scheduled. +> + +**[v10: evm: Do HMAC of multiple per LSM xattrs for new inodes](http://lore.kernel.org/bpf/20230331123221.3273328-1-roberto.sassu@huaweicloud.com/)** + +> One of the major goals of LSM stacking is to run multiple LSMs side by side +> without interfering with each other. The ultimate decision will depend on +> individual LSM decision. +> + +**[v1: bpf-next: veristat: change guess for __sk_buff from CGROUP_SKB to SCHED_CLS](http://lore.kernel.org/bpf/20230330190115.3942962-1-andrii@kernel.org/)** + +> SCHED_CLS seems to be a better option as a default guess for freplace +> programs that have __sk_buff as a context type. +> + +**[[PATCH bpf RFC-V3 0/5] XDP-hints: API change for RX-hash kfunc bpf_xdp_metadata_rx_hash](http://lore.kernel.org/bpf/168019602958.3557870.9960387532660882277.stgit@firesoul/)** + +> Notice targeted 6.3-rc kernel via bpf git tree. +> +> Current API for bpf_xdp_metadata_rx_hash() returns the raw RSS hash value, +> but doesn't provide information on the RSS hash type (part of 6.3-rc). +> + +**[v5: bpf-next: bpf: Add socket destroy capability](http://lore.kernel.org/bpf/20230330151758.531170-1-aditi.ghag@isovalent.com/)** + +> This patch adds the capability to destroy sockets in BPF. We plan to use +> the capability in Cilium to force client sockets to reconnect when their +> remote load-balancing backends are deleted. The other use case is +> on-the-fly policy enforcement where existing socket connections prevented +> by policies need to be terminated. +> + +**[v2: bpf-next: kallsyms: move module-related functions under correct configs](http://lore.kernel.org/bpf/20230330102001.2183693-1-vmalik@redhat.com/)** + +> Functions for searching module kallsyms should have non-empty +> definitions only if CONFIG_MODULES=y and CONFIG_KALLSYMS=y. Until now, +> only CONFIG_MODULES check was used for many of these, which may have +> caused complilation errors on some configs. +> +> This patch moves all relevant functions under the correct configs. +> + +**[v1: bpf-next: bpf: Improve verifier for cond_op and spilled loop index variables](http://lore.kernel.org/bpf/20230330055600.86870-1-yhs@fb.com/)** + +> LLVM commit [1] introduced hoistMinMax optimization like +> (i < VIRTIO_MAX_SGS) && (i < out_sgs) +> to +> upper = MIN(VIRTIO_MAX_SGS, out_sgs) +> ... i < upper ... +> and caused the verification failure. Commit [2] workarounded the issue by +> adding some bpf assembly code to prohibit the above optimization. +> This patch improved verifier such that verification can succeed without +> the above workaround. +> + +**[v1: bpf-next: Teach verifier to determine necessary log buffer size](http://lore.kernel.org/bpf/20230330041642.1118787-1-andrii@kernel.org/)** + +> My imagination is failing me on how to succinctly name this feature and patch +> set, but the point here is to perform internal accounting of what should be +> the necessary size of user-supplied log buffer such as to fit entire log +> contents without truncation, thus avoiding -ENOSPC. +> + +**[v2: bpf-next: xsk: Support UMEM chunk_size > PAGE_SIZE](http://lore.kernel.org/bpf/20230329180502.1884307-1-kal.conley@dectris.com/)** + +> The main purpose of this patchset is to add AF_XDP support for UMEM +> chunk sizes > PAGE_SIZE. This is enabled for UMEMs backed by HugeTLB +> pages. +> + +**[[PATCH bpf RFC-V2 0/5] XDP-hints: API change for RX-hash kfunc bpf_xdp_metadata_rx_hash](http://lore.kernel.org/bpf/168010726310.3039990.2753040700813178259.stgit@firesoul/)** + +> Notice targeted 6.3-rc kernel via bpf git tree. +> +> Current API for bpf_xdp_metadata_rx_hash() returns the raw RSS hash value, +> but doesn't provide information on the RSS hash type (part of 6.3-rc). +> +> This patchset proposal is to use the return value from +> bpf_xdp_metadata_rx_hash() to provide the RSS hash type. +> + +**[v2: bpf-next: Allow BPF TCP CCs to write app_limited](http://lore.kernel.org/bpf/20230329073558.8136-1-bobankhshen@gmail.com/)** + +> This series allow BPF TCP CCs to write app_limited of struct +> tcp_sock. A built-in CC or one from a kernel module is already +> able to write to app_limited of struct tcp_sock. Until now, +> a BPF CC doesn't have write access to this member of struct +> tcp_sock. +> + +**[v2: bpf-next: BPF verifier rotating log](http://lore.kernel.org/bpf/20230328235610.3159943-1-andrii@kernel.org/)** + +> This patch set changes BPF verifier log behavior to behave as a rotating log, +> by default. If user-supplied log buffer is big enough to contain entire +> verifier log output, there is no effective difference. But where previously +> user supplied too small log buffer and would get -ENOSPC error result and the +> beginning part of the verifier log, now there will be no error and user will +> get ending part of verifier log filling up user-supplied log buffer. Which +> is, in absolute majority of cases, is exactly what's useful, relevant, and +> what users want and need, as the ending of the verifier log is containing +> details of verifier failure and relevant state that got us to that failure. So +> this rotating mode is made default, but for some niche advanced debugging +> scenarios it's possible to request old behavior by specifying additional +> BPF_LOG_FIXED (8) flag. +> + +**[v2: memcg: make rstat flushing irq and sleep](http://lore.kernel.org/bpf/20230328221644.803272-1-yosryahmed@google.com/)** + +> Patches 1 and 2 are cleanups requested during reviews of prior versions +> of this series. +> +> Patch 3 makes sure we never try to flush from within an irq context, and +> patch 4 adds a WARN_ON_ONCE() to make sure we catch any violations. +> + +**[v1: Allow BPF TCP CCs to write app_limited](http://lore.kernel.org/bpf/20230328132035.50839-1-bobankhshen@gmail.com/)** + +> This series allow BPF TCP CCs to write app_limited of struct +> tcp_sock. A built-in CC or one from a kernel module is already +> able to write to app_limited of struct tcp_sock. Until now, +> a BPF CC doesn't have write access to this member of struct +> tcp_sock. +> + +**[v2: bpf-next: selftests/bpf: Rewrite two infinite loops in bound check cases](http://lore.kernel.org/bpf/20230329011048.1721937-1-xukuohai@huaweicloud.com/)** + +> The two infinite loops in bound check cases added by commit +> increased the execution time of test_verifier from about 6 seconds to +> about 9 seconds. Rewrite these two infinite loops to finite loops to get +> rid of this extra time cost. +> + +**[v1: net-next: virtio_net: refactor xdp codes](http://lore.kernel.org/bpf/20230328120412.110114-1-xuanzhuo@linux.alibaba.com/)** + +> Due to historical reasons, the implementation of XDP in virtio-net is relatively +> chaotic. For example, the processing of XDP actions has two copies of similar +> code. Such as page, xdp_page processing, etc. +> +> The purpose of this patch set is to refactor these code. Reduce the difficulty +> of subsequent maintenance. Subsequent developers will not introduce new bugs +> because of some complex logical relationships. +> + +**[v1: net-next: bpf, net: support redirecting to ifb with bpf](http://lore.kernel.org/bpf/20230328115105.13553-1-laoar.shao@gmail.com/)** + +> In our container environment, we are using EDT-bpf to limit the egress +> bandwidth. EDT-bpf can be used to limit egress only, but can't be used +> to limit ingress. Some of our users also want to limit the ingress +> bandwidth. But after applying EDT-bpf, which is based on clsact qdisc, +> it is impossible to limit the ingress bandwidth currently, due to some +> reasons, +> 1). We can't add ingress qdisc +> The ingress qdisc can't coexist with clsact qdisc as clsact has both +> ingress and egress handler. So our traditional method to limit ingress +> bandwidth can't work any more. +> 2). We can't redirect ingress packet to ifb with bpf +> By trying to analyze if it is possible to redirect the ingress packet to +> ifb with a bpf program, we find that the ifb device is not supported by +> bpf redirect yet. +> + +**[v2: loongarch/bpf: Skip speculation barrier opcode, which caused ltp testcase bpf_prog02 to fail](http://lore.kernel.org/bpf/20230328071335.2664966-1-guodongtai@kylinos.cn/)** + +> Here just skip the opcode(BPF_ST | BPF_NOSPEC) that has no couterpart to the loongarch. +> +> To verify, use ltp testcase: +> +> Without this patch: +> $ ./bpf_prog02 +> ... ... +> bpf_common.c:123: TBROK: Failed verification: ??? (524) +> + +**[v1: bpf-next: verifier/xdp_direct_packet_access.c converted to inline assembly](http://lore.kernel.org/bpf/20230328020813.392560-1-eddyz87@gmail.com/)** + +> verifier/xdp_direct_packet_access.c automatically converted to inline +> assembly using [1]. +> +> This is a leftover from [2], the last patch in a batch was blocked by +> mail server for being too long. This patch-set splits it in two: +> - one to add migrated test to progs/ +> - one to remove old test from verifier/ +> + +**[v1: bpf: tcp: Use sock_gen_put instead of sock_put in bpf_iter_tcp](http://lore.kernel.org/bpf/20230328004232.2134233-1-martin.lau@linux.dev/)** + +> While reviewing the udp-iter batching patches, notice the bpf_iter_tcp +> calling sock_put() is incorrect. It should call sock_gen_put instead +> because bpf_iter_tcp is iterating the ehash table which has the +> req sk and tw sk. This patch replaces all sock_put with sock_gen_put +> in the bpf_iter_tcp codepath. +> + +### 周边技术动态 + +#### Qemu + +**[v2: riscv: Add support for the Zfa extension](http://lore.kernel.org/qemu-devel/20230331182824.4104580-1-christoph.muellner@vrull.eu/)** + +> This patch introduces the RISC-V Zfa extension, which introduces +> additional floating-point extensions: +> * fli (load-immediate) with pre-defined immediates +> * fminm/fmaxm (like fmin/fmax but with different NaN behaviour) +> * fround/froundmx (round to integer) +> * fcvtmod.w.d (Modular Convert-to-Integer) +> * fmv* to access high bits of float register bigger than XLEN +> * Quiet comparison instructions (fleq/fltq) +> + +**[v1: target/riscv: Set opcode to env->bins for illegal/virtual instruction fault](http://lore.kernel.org/qemu-devel/20230330034636.44585-1-liweiwei@iscas.ac.cn/)** + +> decode_save_opc() will not work for generate_exception(), since 0 is passed +> to riscv_raise_exception() as pc in helper_raise_exception(), and bins will +> not be restored in this case. +> + +**[v6: target/riscv: rework CPU extensions validation](http://lore.kernel.org/qemu-devel/20230329200856.658733-1-dbarboza@ventanamicro.com/)** + +> This series contains changes proposed by Weiwei Li in v5. +> +> All patches are acked. +> + +#### U-Boot + +**[v2: Add ethernet driver for StarFive JH7110 SoC](http://lore.kernel.org/u-boot/20230329102720.25439-1-yanhong.wang@starfivetech.com/)** + +> This series adds ethernet support for the StarFive JH7110 RISC-V SoC. +> The series includes PHY and MAC drivers. The PHY model is +> YT8531 (from Motorcomm Inc), and the MAC version is dwmac-5.20 +> (from Synopsys DesignWare). +> +> The implementation of the phy driver is ported from linux, but it +> has been adjusted for the u-boot framework. +> + +**[v3: Add StarFive JH7110 PCIe drvier support](http://lore.kernel.org/u-boot/20230329100143.10724-1-minda.chen@starfivetech.com/)** + +> The PCIe driver depends on gpio, pinctrl, clk and reset driver to do init. +> The PCIe dts configuation includes all these setting. +> +> The PCIe drivers codes has been tested on the VisionFive V2 boards. +> The test devices includes M.2 NVMe SSD and Realtek 8169 Ethernet adapter. +> + +**[v5: Basic StarFive JH7110 RISC-V SoC support](http://lore.kernel.org/u-boot/20230329034224.26545-1-yanhong.wang@starfivetech.com/)** + +> This series of patches base on the latest branch/master, and add support +> for the StarFive JH7110 RISC-V SoC and VisionFive V2 board. In order for +> this to be achieved, the respective DT nodes have been added, and the +> required defconfigs have been added to the boards' defconfig. What is more, +> the basic required DM drivers have been added, such as reset, clock, pinctrl, +> uart, ram etc. +> + ## 20230326：第 39 期 ### 内核动态