diff --git a/news/README.md b/news/README.md
index 88754177a2e73e99e806d2084e385ec776425aa6..630d92c34834ded32b618ecaf514d70b79d7dad6 100644
--- a/news/README.md
+++ b/news/README.md
@@ -5,6 +5,551 @@
 * [2022 年](2022.md)
 * [2023 年 - 上半年](2023-1st-half.md)
 
+## 20231015：第 64 期
+
+### 内核动态
+
+#### 网络设备
+
+**[v2: net-next: Create a binding for the Marvell MV88E6xxx DSA switches](http://lore.kernel.org/netdev/20231014-marvell-88e6152-wan-led-v2-0-7fca08b68849@linaro.org/)**
+
+> This shows the path we could take with this, deprecating the
+> weird external bus thing.
+>
+> I don't know what to do about the irq lines with a pointless
+> type flag that should be onecell:ed.
+>
+
+**[v4: net-next: vxlan: add support for flowlabel inherit](http://lore.kernel.org/netdev/20231014132102.54051-1-alce@lafranque.net/)**
+
+> By default, VXLAN encapsulation over IPv6 sets the flow label to 0, with
+> an option for a fixed value. This commits add the ability to inherit the
+> flow label from the inner packet, like for other tunnel implementations.
+> This enables devices using only L3 headers for ECMP to correctly balance
+> VXLAN-encapsulated IPv6 packets.
+>
+
+**[v6: bpf-next: add BPF_F_PERMANENT flag for sockmap skmsg redirect](http://lore.kernel.org/netdev/20231014121706.967988-1-liujian56@huawei.com/)**
+
+> v5->v6: Modified the description of the helper function.
+> v4->v5: Fix one refcount bug caused by patch1.
+> v3->v4: Change the two helpers's description.
+> 	Let BPF_F_PERMANENT takes precedence over apply/cork_bytes.
+>
+
+**[v1: staging: qlge: Add bool type to qlge_idc_wait()](http://lore.kernel.org/netdev/ZSoxLxs45bIuBrHg@gilbert-PC/)**
+
+> The idea of the break statements in the if/else is so that the loop is
+> exited immediately the value of status is changed. And returned
+> immediately. For if/else conditionals, the block to be executed will
+> always be one of the two. Introduce a bool type variable 's_sig' that
+> evaluates to true when the value of status is changed within the if/else
+> block.
+>
+
+**[v1: net: gve: Do not fully free QPL pages on prefill errors](http://lore.kernel.org/netdev/20231014014121.2843922-1-shailend@google.com/)**
+
+> The prefill function should have only removed the page count bias it
+> added. Fully freeing the page will cause gve_free_queue_page_list to
+> free a page the driver no longer owns.
+>
+
+**[v1: bpf-next: bpf: tcp: Add SYN Cookie generation/validation SOCK_OPS hooks.](http://lore.kernel.org/netdev/20231013220433.70792-1-kuniyu@amazon.com/)**
+
+> Under SYN Flood, the TCP stack generates SYN Cookie to remain stateless
+> for the connection request until a valid ACK is responded to the SYN+ACK.
+>
+> The cookie contains two kinds of host-specific bits, a timestamp and
+> secrets, so only can it be validated by the generator.  It means SYN
+> Cookie consumes network resources between the client and the server;
+> intermediate nodes must remember which nodes to route ACK for the cookie.
+>
+
+**[[net-next PATCH] net: skb_find_text: Ignore patterns extending past 'to'](http://lore.kernel.org/netdev/20231013195113.3663-1-phil@nwl.cc/)**
+
+> Assume that caller's 'to' offset really represents an upper boundary for
+> the pattern search, so patterns extending past this offset are to be
+> rejected.
+>
+
+**[v1: net: stub tcp_gro_complete if CONFIG_INET=n](http://lore.kernel.org/netdev/20231013185502.1473541-1-jacob.e.keller@intel.com/)**
+
+> A few networking drivers including bnx2x, bnxt, qede, and idpf call
+> tcp_gro_complete as part of offloading TCP GRO. The function is only
+> defined if CONFIG_INET is true, since its TCP specific and is meaningless
+> if the kernel lacks IP networking support.
+>
+
+**[v1: net-next: i40e: Add basic devlink support](http://lore.kernel.org/netdev/20231013170755.2367410-1-ivecera@redhat.com/)**
+
+> The series adds initial support for devlink to i40e driver.
+>
+> Patch-set overview:
+> Patch 1: Adds initial devlink support (devlink and port registration)
+> Patch 2: Refactors and split i40e_nvm_version_str()
+> Patch 3: Adds support for 'devlink dev info'
+> Patch 4: Refactors existing helper function to read PBA ID
+> Patch 5: Adds 'board.id' to 'devlink dev info' using PBA ID
+>
+
+**[v1: netfs, afs, cifs: Delegate high-level I/O to netfslib](http://lore.kernel.org/netdev/20231013160423.2218093-1-dhowells@redhat.com/)**
+
+> I have been working on my netfslib helpers to the point that I can run
+> xfstests on AFS to completion (both with write-back buffering and, with a
+> small patch, write-through buffering in the pagecache).  I can also run a
+> certain amount of xfstests on CIFS, though that requires some more
+> debugging.  However, this seems like a good time to post a preview of the
+> patches.
+>
+
+**[v1: net: net/sched: sch_hfsc: safely allow 'rt' inner curves](http://lore.kernel.org/netdev/20231013151057.2611860-1-pctammela@mojatatu.com/)**
+
+> As reported [1] disallowing 'rt' inner curves breaks already existing
+> scripts. Even though it doesn't make sense 'qdisc wise' users have been
+> relying on this behaviour since the qdisc inception.
+>
+
+**[v1: net-next: tg3: Improve PTP TX timestamping logic](http://lore.kernel.org/netdev/20231013135919.408357-1-pavan.chebbi@broadcom.com/)**
+
+> When we are trying to timestamp a TX packet, there may be
+> occasions when the TX timestamp register is still not
+> updated with the latest timestamp even if the timestamp
+> packet descriptor is marked as complete.
+> This usually happens in cases where the system is under
+> stress or flow control is affecting the transmit side.
+>
+
+**[v2: net-next: rswitch: Add PM ops](http://lore.kernel.org/netdev/20231013121936.364678-1-yoshihiro.shimoda.uh@renesas.com/)**
+
+> This patch is based on the latest net-next.git / next branch.
+> After applied this patch with the following patches, the system can
+> enter/exit Suspend to Idle without any error:
+> https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/commit/?h=next&id=aa4c0bbf820ddb9dd8105a403aa12df57b9e5129
+> https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/commit/?h=next&id=1a5361189b7acac15b9b086b2300a11b7aa84c06
+>
+
+**[v5: iwl-next: i40e: add restore default speed when changed PHY doesn't support it](http://lore.kernel.org/netdev/20231013115245.1517606-1-aleksandr.loktionov@intel.com/)**
+
+> Currently, there was no link after plugging a different type of PHY
+> module if user forced previous PHY specific link type/speed before.
+>
+> Add reset link speed settings to the default values for PHY module,
+> if different PHY module is inserted and currently defined user-specified
+> speed is not compatible with this module.
+>
+
+**[v11: net-next: introduce page_pool_alloc() related API](http://lore.kernel.org/netdev/20231013064827.61135-1-linyunsheng@huawei.com/)**
+
+> In [1] & [2] & [3], there are usecases for veth and virtio_net
+> to use frag support in page pool to reduce memory usage, and it
+> may request different frag size depending on the head/tail
+> room space for xdp_frame/shinfo and mtu/packet size. When the
+> requested frag size is large enough that a single page can not
+> be split into more than one frag, using frag support only have
+> performance penalty because of the extra frag count handling
+> for frag support.
+>
+
+**[v1: net-next: xsk: Avoid starving xsk at the end of the list](http://lore.kernel.org/netdev/20231013063332.38189-1-huangjie.albert@bytedance.com/)**
+
+> In the previous implementation, when multiple xsk sockets were
+> associated with a single xsk_buff_pool, a situation could arise
+> where the xsk_tx_list maintained data at the front for one xsk
+> socket while starving the xsk sockets at the back of the list.
+> This could result in issues such as the inability to transmit packets,
+> increased latency, and jitter. To address this problem, we introduced
+> a new variable called tx_budget_cache, which limits each xsk to transmit
+> a maximum of MAX_XSK_TX_BUDGET tx descriptors. This allocation ensures
+> equitable opportunities for subsequent xsk sockets to send tx descriptors.
+> The value of MAX_XSK_TX_BUDGET is temporarily set to 16.
+>
+
+**[v1: bpf-next: bpf: change syscall_nr type to int in struct syscall_tp_t](http://lore.kernel.org/netdev/20231013054219.172920-1-asavkov@redhat.com/)**
+
+> linux-rt-devel tree contains a patch (b1773eac3f29c ("sched: Add support
+> for lazy preemption")) that adds an extra member to struct trace_entry.
+> 
+
+**[v1: net: netlink: Correct offload_xstats size](http://lore.kernel.org/netdev/20231013041448.8229-1-cpaasch@apple.com/)**
+
+> rtnl_offload_xstats_get_size_hw_s_info_one() conditionalizes the
+> size-computation for IFLA_OFFLOAD_XSTATS_HW_S_INFO_USED based on whether
+> or not the device has offload_xstats enabled.
+>
+> However, rtnl_offload_xstats_fill_hw_s_info_one() is adding the u8 for
+> that field uncondtionally.
+>
+
+**[v2: drivers: net: wwan: wwan_core.c: resolved spelling mistake](http://lore.kernel.org/netdev/20231013042304.7881-1-m.muzzammilashraf@gmail.com/)**
+
+> resolved typing mistake from devce to device
+>
+> changes since v1:
+> 	- resolved another typing mistake from concurent to
+> 	  concurrent
+>
+
+**[v6: net-next: I3C MCTP net driver](http://lore.kernel.org/netdev/20231013040628.354323-1-matt@codeconstruct.com.au/)**
+
+> This series adds an I3C transport for the kernel's MCTP network
+> protocol. MCTP is a communication protocol between system components
+> (BMCs, drives, NICs etc), with higher level protocols such as NVMe-MI or
+> PLDM built on top of it (in userspace). It runs over various transports
+> such as I2C, PCIe, or I3C.
+>
+
+**[v1: Create a binding for the Marvell MV88E6xxx DSA switches](http://lore.kernel.org/netdev/20231013-marvell-88e6152-wan-led-v1-0-0712ba99857c@linaro.org/)**
+
+> This shows the path we could take with this, deprecating the
+> weird external bus thing.
+>
+> I don't know what to do about the irq lines with a pointless
+> type flag that should be onecell:ed.
+>
+
+**[v1: net: usb: replace deprecated strncpy with strscpy](http://lore.kernel.org/netdev/20231012-strncpy-drivers-net-usb-sr9800-c-v1-1-5540832c8ec2@google.com/)**
+
+> strncpy() is deprecated for use on NUL-terminated destination strings
+> [1] and as such we should prefer more robust and less ambiguous string
+> interfaces.
+>
+
+**[v1: net: phy: smsc: replace deprecated strncpy with ethtool_sprintf](http://lore.kernel.org/netdev/20231012-strncpy-drivers-net-phy-smsc-c-v1-1-00528f7524b3@google.com/)**
+
+> strncpy() is deprecated for use on NUL-terminated destination strings
+> [1] and as such we should prefer more robust and less ambiguous string
+> interfaces.
+>
+> ethtool_sprintf() is designed specifically for get_strings() usage.
+> Let's replace strncpy in favor of this dedicated helper function.
+>
+
+#### 安全增强
+
+**[v1: ath6kl: replace deprecated strncpy with memcpy](http://lore.kernel.org/linux-hardening/20231013-strncpy-drivers-net-wireless-ath-ath6kl-init-c-v1-1-d69c599b49a9@google.com/)**
+
+> strncpy() is deprecated for use on NUL-terminated destination strings
+> [1] and as such we should prefer more robust and less ambiguous
+> interfaces.
+>
+
+**[v1: qed: replace uses of strncpy](http://lore.kernel.org/linux-hardening/20231011-strncpy-drivers-net-ethernet-qlogic-qed-qed_debug-c-v1-1-60c9ca2d54a2@google.com/)**
+
+> strncpy() is deprecated for use on NUL-terminated destination strings
+> [1] and as such we should prefer more robust and less ambiguous string
+> interfaces.
+>
+
+**[v1: net/mlx5: simplify mlx5_set_driver_version string assignments](http://lore.kernel.org/linux-hardening/20231011-strncpy-drivers-net-ethernet-mellanox-mlx5-core-main-c-v1-1-90fa39998bb2@google.com/)**
+
+> In total, just assigning this version string takes:
+> (1) strncpy()'s
+> (5) strlen()'s
+> (3) strncat()'s
+> (1) snprintf()'s
+> (4) max_t()'s
+>
+> Moreover, `strncpy` is deprecated [1] and `strncat` really shouldn't be
+> used either [2]. With this in mind, let's simply use a single
+> `snprintf`.
+>
+
+**[v4: soc/tegra: fuse: Add ACPI support](http://lore.kernel.org/linux-hardening/20231011093412.7994-1-kkartik@nvidia.com/)**
+
+> This series of patches add ACPI support for Tegra194 and Tegra234 in
+> Tegra fuse and apbmisc drivers. It also adds support for Tegra241
+> which uses ACPI boot.
+>
+
+**[v1: bcachefs: Refactor bkey_i to use a flexible array](http://lore.kernel.org/linux-hardening/20231010235609.work.594-kees@kernel.org/)**
+
+> The memcpy() in bch2_bkey_append_ptr() is operating on an embedded
+> fake flexible array. Instead, make it explicit, and convert the memcpy
+> to target the flexible array instead.  
+>
+
+**[v2: net: dsa: vsc73xx: replace deprecated strncpy with ethtool_sprintf](http://lore.kernel.org/linux-hardening/20231010-strncpy-drivers-net-dsa-vitesse-vsc73xx-core-c-v2-1-ba4416a9ff23@google.com/)**
+
+> `strncpy` is deprecated for use on NUL-terminated destination strings
+> [1] and as such we should prefer more robust and less ambiguous string
+> interfaces.
+>
+> ethtool_sprintf() is designed specifically for get_strings() usage.
+> Let's replace strncpy in favor of this more robust and easier to
+> understand interface.
+>
+
+**[v1: next: atags_proc: Add __counted_by for struct buffer and use struct_size()](http://lore.kernel.org/linux-hardening/ZSVHurzo%2F4aFQcT3@work/)**
+
+> Prepare for the coming implementation by GCC and Clang of the __counted_by
+> attribute. Flexible array members annotated with __counted_by can have
+> their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
+> array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
+> functions).
+>
+
+#### Rust For Linux
+
+**[v4: net-next: Rust abstractions for network PHY drivers](http://lore.kernel.org/rust-for-linux/20231012125349.2702474-1-fujita.tomonori@gmail.com/)**
+
+> This patchset adds Rust abstractions for phylib. It doesn't fully
+> cover the C APIs yet but I think that it's already useful. I implement
+> two PHY drivers (Asix AX88772A PHYs and Realtek Generic FE-GE). Seems
+> they work well with real hardware.
+>
+
+#### BPF
+
+**[v4: bpf-next: Registrating struct_ops types from modules](http://lore.kernel.org/bpf/20231013224304.187218-1-thinker.li@gmail.com/)**
+
+> Given the current constraints of the current implementation,
+> struct_ops cannot be registered dynamically. This presents a
+> significant limitation for modules like coming fuse-bpf, which seeks
+> to implement a new struct_ops type. To address this issue, a new API
+> is introduced that allows the registration of new struct_ops types
+> from modules.
+>
+
+**[v7: bpf-next: Open-coded task_vma iter](http://lore.kernel.org/bpf/20231013204426.1074286-1-davemarchevsky@fb.com/)**
+
+> At Meta we have a profiling daemon which periodically collects
+> information on many hosts. This collection usually involves grabbing
+> stacks (user and kernel) using perf_event BPF progs and later symbolicating
+> them. For user stacks we try to use BPF_F_USER_BUILD_ID and rely on
+> remote symbolication, but BPF_F_USER_BUILD_ID doesn't always succeed. In
+> those cases we must fall back to digging around in /proc/PID/maps to map
+> virtual address to (binary, offset). The /proc/PID/maps digging does not
+> occur synchronously with stack collection, so the process might already
+> be gone, in which case it won't have /proc/PID/maps and we will fail to
+> symbolicate.
+>
+
+**[v1: tools/cgroup: introduce cgroup v2 memory.events listener](http://lore.kernel.org/bpf/20231013184107.28734-1-ddrokosov@salutedevices.com/)**
+
+> This is a simple listener for memory events that handles counter
+> changes in runtime. It can be set up for a specific memory cgroup v2.
+>
+
+**[v2: dwarves: pahole, btf_encoder: support --btf_features](http://lore.kernel.org/bpf/20231013153359.88274-1-alan.maguire@oracle.com/)**
+
+> Currently, the kernel uses pahole version checking as the way to
+> determine which BTF encoding features to request from pahole.  This
+> means that such features have to be tied to a specific version and
+> as new features are added, additional clauses in scripts/pahole-flags.sh
+> have to be added; for example
+>
+
+**[v1: bpf-next: bpf: Avoid unnecessary audit log for CPU security mitigations](http://lore.kernel.org/bpf/20231013083916.4199-1-laoar.shao@gmail.com/)**
+
+> Check cpu_mitigations_off() first to avoid calling capable() if it is off.
+> This can avoid unnecessary audit log.
+>
+
+**[v7: bpf-next: BPF token and BPF FS-based delegation](http://lore.kernel.org/bpf/20231012222810.4120312-1-andrii@kernel.org/)**
+
+> This patch set introduces an ability to delegate a subset of BPF subsystem
+> functionality from privileged system-wide daemon (e.g., systemd or any other
+> container manager) through special mount options for userns-bound BPF FS to
+> a *trusted* unprivileged application. Trust is the key here. This
+> functionality is not about allowing unconditional unprivileged BPF usage.
+> Establishing trust, though, is completely up to the discretion of respective
+> privileged application that would create and mount a BPF FS instance with
+> delegation enabled, as different production setups can and do achieve it
+> through a combination of different means (signing, LSM, code reviews, etc),
+> and it's undesirable and infeasible for kernel to enforce any particular way
+> of validating trustworthiness of particular process.
+>
+
+**[v6: bpf-next: XDP metadata via kfuncs for ice + VLAN hint](http://lore.kernel.org/bpf/20231012170524.21085-1-larysa.zaremba@intel.com/)**
+
+> This series introduces XDP hints via kfuncs [0] to the ice driver.
+>
+> Series brings the following existing hints to the ice driver:
+>  - HW timestamp
+>  - RX hash with type
+>
+> Series also introduces VLAN tag with protocol XDP hint, it now be accessed by
+> XDP and userspace (AF_XDP) programs. They can also be checked with xdp_metadata
+> test and xdp_hw_metadata program.
+>
+
+**[v4: permit write-sealed memfd read-only shared mappings](http://lore.kernel.org/bpf/cover.1697116581.git.lstoakes@gmail.com/)**
+
+> The man page for fcntl() describing memfd file seals states the following
+> about F_SEAL_WRITE:-
+>
+>     Furthermore, trying to create new shared, writable memory-mappings via
+>     mmap(2) will also fail with EPERM.
+>
+> With emphasis on 'writable'. In turns out in fact that currently the kernel
+> simply disallows all new shared memory mappings for a memfd with
+> F_SEAL_WRITE applied, rendering this documentation inaccurate.
+>
+
+**[v2: Improvements to memory use](http://lore.kernel.org/bpf/20231012062359.1616786-1-irogers@google.com/)**
+
+> Fix memory leaks detected by address/leak sanitizer affecting LBR
+> call-graphs, perf mem and BPF offcpu.
+>
+> Make branch_type_stat in callchain_list optional as it is large and
+> not always necessary - in particular it isn't used by perf top.
+>
+> Make the allocations of zstd streams, kernel symbols and event copies
+> lazier in order to save memory in cases like perf record.
+>
+
+**[v1: bpf: Avoid unnecessary -EBUSY from htab_lock_bucket](http://lore.kernel.org/bpf/20231012055741.3375999-1-song@kernel.org/)**
+
+> htab_lock_bucket uses the following logic to avoid recursion:
+>
+> 1. preempt_disable();
+> 2. check percpu counter htab->map_locked[hash] for recursion;
+>    2.1. if map_lock[hash] is already taken, return -BUSY;
+> 3. raw_spin_lock_irqsave();
+>
+
+**[v1: bpf-next: BPF verifier log improvements](http://lore.kernel.org/bpf/20231011223728.3188086-1-andrii@kernel.org/)**
+
+> This patch set fixes ambiguity in BPF verifier log output of SCALAR register
+> in the parts that emit umin/umax, smin/smax, etc ranges. See patch #4 for
+> details.
+>
+> Also, patch #5 fixes an issue with verifier log missing instruction context
+> (state) output for conditionals that trigger precision marking. See details in
+> the patch.
+>
+
+**[v5: bpf-next: Add Open-coded task, css_task and css iters](http://lore.kernel.org/bpf/20231011120857.251943-1-zhouchuyi@bytedance.com/)**
+
+> [-- Warning: decoded text below may be mangled, UTF-8 assumed --]
+>
+> This is version 5 of task, css_task and css iters support.
+>
+> --- Changelog ---
+>
+> Patch 3
+> 4:
+>  * Change the BUILD_BUG_ON check in bpf_iter_task_new and bpf_iter_css_new to avoid
+>    netdev/build_32bit CI error
+>    (https://netdev.bots.linux.dev/static/nipa/790929/13412333/build_32bit/stderr)
+>
+
+**[v1: vhost: virtio-net: support AF_XDP zero copy](http://lore.kernel.org/bpf/20231011092728.105904-1-xuanzhuo@linux.alibaba.com/)**
+
+> ## AF_XDP
+>
+> XDP socket(AF_XDP) is an excellent bypass kernel network framework. The zero
+> copy feature of xsk (XDP socket) needs to be supported by the driver. The
+> performance of zero copy is very good. mlx5 and intel ixgbe already support
+> this feature, This patch set allows virtio-net to support xsk's zerocopy xmit
+> feature.
+>
+
+**[v3: bpf-next: bpf: Detect jumping to reserved code of ld_imm64](http://lore.kernel.org/bpf/20231011-jmp-into-reserved-fields-v3-0-97d2aa979788@gmail.com/)**
+
+> Currently, the verifier rejects a program jumping to reserved code with
+> the log "invalid BPF_LD_IMM" in check_ld_imm(), which in not accurate,
+> because the program does not contain any invalid insns. The root cause
+> is that the verifier does not detect such jump, thus the reserved code
+> is passed to check_ld_imm().
+>
+
+### 周边技术动态
+
+#### Qemu
+
+**[v1: target/riscv: rename ext_i* to ext_zi*](http://lore.kernel.org/qemu-devel/20231012164604.398496-1-dbarboza@ventanamicro.com/)**
+
+> Aside from that, these are the only 4 Z-extension flags that don't use a
+> leading 'z' in their name, so there's also the benefit of making
+> everything equal.
+>
+
+**[v2: riscv, qemu_fw_cfg: Add support for RISC-V architecture](http://lore.kernel.org/qemu-devel/20231012102852.234442-1-bjorn@kernel.org/)**
+
+> Qemu fw_cfg support was missing for RISC-V, which made it hard to do
+> proper vmcore dumps from qemu.
+>
+> Add the missing RISC-V arch-defines.
+>
+> You can now do vmcore dumps from qemu. Add "-device vmcoreinfo" to the
+> qemu command-line. From the qemu monitor:
+>   (qemu) dump-guest-memory vmcore
+>
+> The vmcore can now be used, e.g., with the "crash" utility.
+>
+
+**[v4: target/riscv: Add RISC-V Virtual IRQs and IRQ filtering support](http://lore.kernel.org/qemu-devel/20231012100103.28612-1-rkanwal@rivosinc.com/)**
+
+> This series adds M and HS-mode virtual interrupt and IRQ filtering support.
+> This allows inserting virtual interrupts from M/HS-mode into S/VS-mode
+> using mvien/hvien and mvip/hvip csrs. IRQ filtering is a use case of
+> this change, i-e M-mode can stop delegating an interrupt to S-mode and
+> instead enable it in MIE and receive those interrupts in M-mode and then
+> selectively inject the interrupt using mvien and mvip.
+>
+
+**[v1: riscv-to-apply queue](http://lore.kernel.org/qemu-devel/20231012041051.2572507-1-alistair.francis@wdc.com/)**
+
+> The following changes since commit a51e5124a655b3dad80b36b18547cb1eca2c5eb2:
+>
+>   Merge tag 'pull-omnibus-111023-1' of https://gitlab.com/stsquad/qemu into staging (2023-10-11 09:43:10 -0400)
+>
+> are available in the Git repository at:
+>
+>   https://github.com/alistair23/qemu.git tags/pull-riscv-to-apply-20231012-1
+>
+> for you to fetch changes up to 837570cef237b634eb4c245363470deebea7089d:
+>
+>   target/riscv: Fix vfwmaccbf16.vf (2023-10-12 12:50:13 +1000)
+>
+
+#### Buildroot
+
+**[[branch/2023.02.x] package/openblas: Add support for RISC-V architecture](http://lore.kernel.org/buildroot/20231013062403.83DF7846B2@busybox.osuosl.org/)**
+
+> commit: https://git.buildroot.net/buildroot/commit/?id=91821019604a369af5d236685062f33824cb2f1e
+> branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/2023.02.x
+>
+> OpenBLAS RISC-V 64bit support was added in [1] and was renamed to
+> "RISCV64_GENERIC" in [2]. Those commits were first included in
+> OpenBLAS release v0.3.13. This support can now be enabled. With this
+> commit, we can install the library and packages such as GNU Octave on
+> RISC-V platforms.
+>
+
+**[[branch/2023.08.x] package/openblas: Add support for RISC-V architecture](http://lore.kernel.org/buildroot/20231013062252.DCEED8468E@busybox.osuosl.org/)**
+
+> commit: https://git.buildroot.net/buildroot/commit/?id=252b6ade2c0cfa2ee37ee274547344d64d785367
+> branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/2023.08.x
+>
+> OpenBLAS RISC-V 64bit support was added in [1] and was renamed to
+> "RISCV64_GENERIC" in [2]. Those commits were first included in
+> OpenBLAS release v0.3.13. This support can now be enabled. With this
+> commit, we can install the library and packages such as GNU Octave on
+> RISC-V platforms.
+>
+
+#### U-Boot
+
+**[v1: riscv: andes: Rearrange Andes PLICSW to single-bit-per-hart strategy](http://lore.kernel.org/u-boot/20231012053534.2859887-1-randolph@andestech.com/)**
+
+> Source hart information is not necessary in IPI, so we could
+> use single-bit-per-hart strategy to rearrange PLICSW mapping.
+>
+> Bit 0 of Interrupt Pending Bits is hardwired to 0.
+> Therefore, we use bit 1 to send IPI to hart 0,
+> bit 2 to hart 1, ..., and so on.
+>
+
+**[v2: ufs: Add a PCI UFS controller support](http://lore.kernel.org/u-boot/20231011131552.14665-1-bmeng@tinylab.org/)**
+
+> This adds a PCI UFS controller support and enables the support on
+> QEMU RISC-V for testing.
+>
+> Requiring QEMU v8.2+.
+>
+
 ## 20231010：第 63 期
 
 ### 内核动态