* Re: [PATCH v6 07/10] ACPI: APEI: introduce GHES helper
From: Ahmed Tiba @ 2026-06-19 15:45 UTC (permalink / raw)
To: Julian Braha, Rafael J. Wysocki, Tony Luck, Borislav Petkov,
Hanjun Guo, Mauro Carvalho Chehab, Shuai Xue, Len Brown,
Saket Dumbre, Davidlohr Bueso, Jonathan Cameron, Dave Jiang,
Alison Schofield, Vishal Verma, Ira Weiny, Dan Williams,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan
Cc: linux-kernel, linux-acpi, acpica-devel, linux-cxl, devicetree,
linux-edac, linux-doc, Dmitry.Lamerov
In-Reply-To: <58f7163f-2fce-41e9-bc35-d1d8e6f4a298@gmail.com>
On 17/06/2026 18:17, Julian Braha wrote:
> Hi Ahmed,
>
> On 6/17/26 14:54, Ahmed Tiba wrote:
>
>> +config GHES_CPER_HELPERS
>> + bool
>> + select UEFI_CPER
>
> This config option should probably also depend on ACPI (could just move
> it into the if ACPI..endif block), or at least have a comment that
> selector options ensure ACPI is enabled.
>
> - Julian Braha
GHES_CPER_HELPERS is intended for both the ACPI GHES path and the DT
firmware-first provider, so I do not want to tie it to ACPI.
Best regards,
Ahmed
^ permalink raw reply
* Re: [PATCH v6 00/10] ACPI: APEI: share GHES CPER helpers and add DT FFH provider
From: Ahmed Tiba @ 2026-06-19 15:41 UTC (permalink / raw)
To: Borislav Petkov
Cc: Rafael J. Wysocki, Tony Luck, Hanjun Guo, Mauro Carvalho Chehab,
Shuai Xue, Len Brown, Saket Dumbre, Davidlohr Bueso,
Jonathan Cameron, Dave Jiang, Alison Schofield, Vishal Verma,
Ira Weiny, Dan Williams, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan, linux-kernel,
linux-acpi, acpica-devel, linux-cxl, devicetree, linux-edac,
linux-doc, Dmitry.Lamerov
In-Reply-To: <20260618164807.GAajQhR9J_00j4LxaC@fat_crate.local>
On 18/06/2026 17:48, Borislav Petkov wrote:
> On Wed, Jun 17, 2026 at 02:54:38PM +0100, Ahmed Tiba wrote:
>> This is v6 of the GHES refactor series. Compared to v5, it addresses
>> the latest review comments and tightens the DT CPER provider and
>> related helper wiring.
>
> Sashiko has comments:
>
> https://sashiko.dev/#/patchset/20260617-topics-ahmtib01-ras_ffh_arm_internal_review-v6-0-91f725174aa0%40arm.com
>
I will address the issues introduced by this series. Pre-existing
behaviour is carried forward unchanged.
Best regards,
Ahmed
^ permalink raw reply
* Re: [PATCH v4 3/5] rpmsg: virtio_rpmsg_bus: get buffer size from config space
From: Shah, Tanmay @ 2026-06-19 15:31 UTC (permalink / raw)
To: Arnaud POULIQUEN, tanmay.shah, andersson, mathieu.poirier, corbet,
skhan
Cc: linux-remoteproc, linux-doc, linux-kernel
In-Reply-To: <1c39fbbc-83d9-4ad2-bf79-fc2f64fe6e44@foss.st.com>
On 6/19/2026 2:45 AM, Arnaud POULIQUEN wrote:
>
>
> On 6/18/26 18:31, Shah, Tanmay wrote:
>>
>>
>> On 6/18/2026 3:32 AM, Arnaud POULIQUEN wrote:
>>>
>>>
>>> On 6/17/26 19:41, Shah, Tanmay wrote:
>>>>
>>>>
>>>> On 6/17/2026 4:15 AM, Arnaud POULIQUEN wrote:
>>>>> Hi Tanmay,
>>>>>
>>>>> On 6/15/26 22:20, Tanmay Shah wrote:
>>>>>> 512 bytes isn't always suitable for all case, let firmware
>>>>>> maker decide the best value from resource table.
>>>>>> enable by VIRTIO_RPMSG_F_BUFSZ feature bit.
>>>>>>
>>>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>>>> ---
>>>>>>
>>>>>> Changes in v4: squash to virtio rpmsg config patch
>>>>>> - Introduce new patch to modify rpmsg.rst documentation
>>>>>> - check version is always 1.
>>>>>> - check size field is same as size of struct virtio_rpmsg_config
>>>>>> - introduce alignment field
>>>>>> - check alignment field is power of 2
>>>>>> - check tx and rx buf size is aligned with alignment passed
>>>>>> in the
>>>>>> structure
>>>>>>
>>>>>> Changes in v3:
>>>>>> - change version field from u16 to u8
>>>>>> - introduce size field in the rpmsg_virtio_config structure
>>>>>> - check version field is set to any non-zero value.
>>>>>> - check size field is not 0.
>>>>>> - Remove field for private config, as not needed for now.
>>>>>> - add documentation of rpmsg_virtio_config structure
>>>>>>
>>>>>> drivers/rpmsg/virtio_rpmsg_bus.c | 129 +++++++++++++++++++++++
>>>>>> +-----
>>>>>> include/linux/rpmsg/virtio_rpmsg.h | 50 +++++++++++
>>>>>> 2 files changed, 160 insertions(+), 19 deletions(-)
>>>>>> create mode 100644 include/linux/rpmsg/virtio_rpmsg.h
>>>>>>
>>>>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/
>>>>>> virtio_rpmsg_bus.c
>>>>>> index 99df1ae07055..a59925f870a4 100644
>>>>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>>> @@ -15,11 +15,13 @@
>>>>>> #include <linux/idr.h>
>>>>>> #include <linux/jiffies.h>
>>>>>> #include <linux/kernel.h>
>>>>>> +#include <linux/log2.h>
>>>>>> #include <linux/module.h>
>>>>>> #include <linux/mutex.h>
>>>>>> #include <linux/rpmsg.h>
>>>>>> #include <linux/rpmsg/byteorder.h>
>>>>>> #include <linux/rpmsg/ns.h>
>>>>>> +#include <linux/rpmsg/virtio_rpmsg.h>
>>>>>> #include <linux/scatterlist.h>
>>>>>> #include <linux/slab.h>
>>>>>> #include <linux/sched.h>
>>>>>> @@ -39,7 +41,8 @@
>>>>>> * @tx_bufs: kernel address of tx buffers
>>>>>> * @num_rx_buf: total number of rx buffers
>>>>>> * @num_tx_buf: total number of tx buffers
>>>>>> - * @buf_size: size of one rx or tx buffer
>>>>>> + * @rx_buf_size: size of one rx buffer
>>>>>> + * @tx_buf_size: size of one tx buffer
>>>>>> * @last_tx_buf: index of last tx buffer used
>>>>>> * @bufs_dma: dma base addr of the buffers
>>>>>> * @tx_lock: protects svq and tx_bufs, to allow concurrent
>>>>>> senders.
>>>>>> @@ -59,7 +62,8 @@ struct virtproc_info {
>>>>>> void *rx_bufs, *tx_bufs;
>>>>>> unsigned int num_rx_buf;
>>>>>> unsigned int num_tx_buf;
>>>>>> - unsigned int buf_size;
>>>>>> + unsigned int rx_buf_size;
>>>>>> + unsigned int tx_buf_size;
>>>>>> int last_tx_buf;
>>>>>> dma_addr_t bufs_dma;
>>>>>> struct mutex tx_lock;
>>>>>> @@ -68,9 +72,6 @@ struct virtproc_info {
>>>>>> wait_queue_head_t sendq;
>>>>>> };
>>>>>> -/* The feature bitmap for virtio rpmsg */
>>>>>> -#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service
>>>>>> notifications */
>>>>>> -
>>>>>> /**
>>>>>> * struct rpmsg_hdr - common header for all rpmsg messages
>>>>>> * @src: source address
>>>>>> @@ -128,7 +129,7 @@ struct virtio_rpmsg_channel {
>>>>>> * processor.
>>>>>> */
>>>>>> #define MAX_RPMSG_NUM_BUFS (256)
>>>>>> -#define MAX_RPMSG_BUF_SIZE (512)
>>>>>> +#define DEFAULT_RPMSG_BUF_SIZE (512)
>>>>>> /*
>>>>>> * Local addresses are dynamically allocated on-demand.
>>>>>> @@ -444,7 +445,7 @@ static void *get_a_tx_buf(struct virtproc_info
>>>>>> *vrp)
>>>>>> /* either pick the next unused tx buffer */
>>>>>> if (vrp->last_tx_buf < vrp->num_tx_buf)
>>>>>> - ret = vrp->tx_bufs + vrp->buf_size * vrp->last_tx_buf++;
>>>>>> + ret = vrp->tx_bufs + vrp->tx_buf_size * vrp->last_tx_buf++;
>>>>>> /* or recycle a used one */
>>>>>> else
>>>>>> ret = virtqueue_get_buf(vrp->svq, &len);
>>>>>> @@ -514,7 +515,7 @@ static int rpmsg_send_offchannel_raw(struct
>>>>>> rpmsg_device *rpdev,
>>>>>> * messaging), or to improve the buffer allocator, to support
>>>>>> * variable-length buffer sizes.
>>>>>> */
>>>>>> - if (len > vrp->buf_size - sizeof(struct rpmsg_hdr)) {
>>>>>> + if (len > vrp->tx_buf_size - sizeof(struct rpmsg_hdr)) {
>>>>>> dev_err(dev, "message is too big (%d)\n", len);
>>>>>> return -EMSGSIZE;
>>>>>> }
>>>>>> @@ -647,7 +648,7 @@ static ssize_t virtio_rpmsg_get_mtu(struct
>>>>>> rpmsg_endpoint *ept)
>>>>>> struct rpmsg_device *rpdev = ept->rpdev;
>>>>>> struct virtio_rpmsg_channel *vch =
>>>>>> to_virtio_rpmsg_channel(rpdev);
>>>>>> - return vch->vrp->buf_size - sizeof(struct rpmsg_hdr);
>>>>>> + return vch->vrp->tx_buf_size - sizeof(struct rpmsg_hdr);
>>>>>> }
>>>>>> static int rpmsg_recv_single(struct virtproc_info *vrp, struct
>>>>>> device *dev,
>>>>>> @@ -673,7 +674,7 @@ static int rpmsg_recv_single(struct virtproc_info
>>>>>> *vrp, struct device *dev,
>>>>>> * We currently use fixed-sized buffers, so trivially
>>>>>> sanitize
>>>>>> * the reported payload length.
>>>>>> */
>>>>>> - if (len > vrp->buf_size ||
>>>>>> + if (len > vrp->rx_buf_size ||
>>>>>> msg_len > (len - sizeof(struct rpmsg_hdr))) {
>>>>>> dev_warn(dev, "inbound msg too big: (%d, %d)\n", len,
>>>>>> msg_len);
>>>>>> return -EINVAL;
>>>>>> @@ -706,7 +707,7 @@ static int rpmsg_recv_single(struct virtproc_info
>>>>>> *vrp, struct device *dev,
>>>>>> dev_warn_ratelimited(dev, "msg received with no
>>>>>> recipient\n");
>>>>>> /* publish the real size of the buffer */
>>>>>> - rpmsg_sg_init(&sg, msg, vrp->buf_size);
>>>>>> + rpmsg_sg_init(&sg, msg, vrp->rx_buf_size);
>>>>>> /* add the buffer back to the remote processor's
>>>>>> virtqueue */
>>>>>> err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL);
>>>>>> @@ -820,10 +821,13 @@ static int rpmsg_probe(struct virtio_device
>>>>>> *vdev)
>>>>>> struct virtproc_info *vrp;
>>>>>> struct virtio_rpmsg_channel *vch = NULL;
>>>>>> struct rpmsg_device *rpdev_ns, *rpdev_ctrl;
>>>>>> + u16 rpmsg_buf_align = 0;
>>>>>> void *bufs_va;
>>>>>> int err = 0, i;
>>>>>> size_t total_buf_space;
>>>>>> bool notify;
>>>>>> + u8 version;
>>>>>> + u16 size;
>>>>>> vrp = kzalloc_obj(*vrp);
>>>>>> if (!vrp)
>>>>>> @@ -855,9 +859,90 @@ static int rpmsg_probe(struct virtio_device
>>>>>> *vdev)
>>>>>> else
>>>>>> vrp->num_tx_buf = MAX_RPMSG_NUM_BUFS;
>>>>>> - vrp->buf_size = MAX_RPMSG_BUF_SIZE;
>>>>>> + /*
>>>>>> + * If VIRTIO_RPMSG_F_BUFSZ feature is supported, then configure
>>>>>> buf
>>>>>> + * size from virtio device config space from the resource table.
>>>>>> + * If the feature is not supported, then assign default buf
>>>>>> size.
>>>>>> + */
>>>>>> + if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_BUFSZ)) {
>>>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>>>> + version, &version);
>>>>>> +
>>>>>> + /* for now we support only v1 */
>>>>>> + if (version != RPMSG_VDEV_CONFIG_V1) {
>>>>>> + dev_err(&vdev->dev,
>>>>>> + "unsupported vdev config version %u\n", version);
>>>>>> + err = -EINVAL;
>>>>>> + goto vqs_del;
>>>>>> + }
>>>>>> +
>>>>>> + /* size of the config space must match */
>>>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>>>> + size, &size);
>>>>>> + if (size != sizeof(struct virtio_rpmsg_config)) {
>>>>>> + dev_err(&vdev->dev, "invalid size of vdev config %u\n",
>>>>>> + size);
>>>>>> + err = -EINVAL;
>>>>>> + goto vqs_del;
>>>>>> + }
>>>>>> - total_buf_space = (vrp->num_rx_buf + vrp->num_tx_buf) * vrp-
>>>>>>> buf_size;
>>>>>> + /*
>>>>>> + * Optional alignment applied to each buffer size and to
>>>>>> the TX
>>>>>> + * buffer base address (e.g. to align buffers on a cache
>>>>>> line).
>>>>>> + * It must be a power of two; zero means no extra alignment.
>>>>>> + */
>>>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>>>> + rpmsg_buf_align, &rpmsg_buf_align);
>>>>>> + if (rpmsg_buf_align && !is_power_of_2(rpmsg_buf_align)) {
>>>>>> + dev_err(&vdev->dev,
>>>>>> + "bad vdev config: rpmsg_buf_align %u is not a power
>>>>>> of two\n",
>>>>>> + rpmsg_buf_align);
>>>>>> + err = -EINVAL;
>>>>>> + goto vqs_del;
>>>>>> + }
>>>>>> +
>>>>>> + /* note: tx and rx are defined from remote view */
>>>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>>>> + txbuf_size, &vrp->rx_buf_size);
>>>>>> + virtio_cread(vdev, struct virtio_rpmsg_config,
>>>>>> + rxbuf_size, &vrp->tx_buf_size);
>>>>>> +
>>>>>> + /* The buffers must hold at least the rpmsg header */
>>>>>> + if (vrp->rx_buf_size < sizeof(struct rpmsg_hdr) ||
>>>>>> + vrp->tx_buf_size < sizeof(struct rpmsg_hdr)) {
>>>>>> + dev_err(&vdev->dev,
>>>>>> + "bad vdev config: rx buf sz = %u, tx buf sz = %u\n",
>>>>>> + vrp->rx_buf_size, vrp->tx_buf_size);
>>>>>> + err = -EINVAL;
>>>>>> + goto vqs_del;
>>>>>> + }
>>>>>> +
>>>>>> + /*
>>>>>> + * The buffer size must be aligned to the provided
>>>>>> alignment for
>>>>>> + * so that the start address of tx bufs can be aligned.
>>>>>> + */
>>>>>
>>>>> 'tx' to remove as it also concerns Rx buffers
>>>>>
>>>>
>>>> Ack.
>>>>
>>>>>
>>>>> What about removing this check to manage alignment during buffer
>>>>> allocation?
>>>>>
>>>>> For example, if the alignment is on a 64-bit address and the tx_buffer
>>>>> and rx_buffer sizes are 40 bytes, 48 bytes can be allocated in memory
>>>>> for each buffer, and the virtio descriptor can be filled with aligned
>>>>> addresses.
>>>>>
>>>>> In other words, the rpmsg_buf_align field contains the alignment
>>>>> constraint from the remote processor. If the Linux kernel wants to
>>>>> impose another alignment constraint, it must test or update
>>>>> rpmsg_buf_align, but it must not impose alignment on the buffer size.
>>>>>
>>>>>
>>>>
>>>> This part I don't understand. `rpmsg_buf_align` is alignment for only
>>>> single buffer size. The linux kernel is checking that single rx buf
>>>> size
>>>> and tx buf size is aligned with `rpmsg_buf_align` as firmware has
>>>> claimed.
>>>>
>>>> For reference the openamp-system-reference PR:
>>>> https://github.com/OpenAMP/openamp-system-reference/pull/106/changes
>>>>
>>>> .vdev_config = {
>>>> .version = 1,
>>>> .reserved = 0,
>>>> .size = (uint16_t)(sizeof(struct rpmsg_virtio_config) -
>>>> sizeof(bool)),
>>>> .alignment = RPMSG_BUF_ALIGN,
>>>> .reserved1 = 0,
>>>> /* Tx for host */
>>>> .h2r_buf_size = metal_align_up(4096, RPMSG_BUF_ALIGN),
>>>> /* Rx for host */
>>>> .r2h_buf_size = metal_align_up(4096, RPMSG_BUF_ALIGN),
>>>> },
>>>>
>>>> IIUC, The linux kernel is not really supposed to modify
>>>> `rpmsg_buf_align`. It only uses it to check that firmware has assigned
>>>> correct size of single rx and tx buffer.
>>>>
>>>>
>>>> When the linux kernel uses dma_alloc_coherent() API it aligns total
>>>> buffer size with page size. That is different than single tx buf size
>>>> and single rx buf size. The total buf size alignment to page size is
>>>> irrelevant to `rpmsg_buf_align` field.
>>>>
>>>> Please let me know if I am missing something or didn't understand your
>>>> comment. I prefer that `rpmsg_buf_align` should be only modified by the
>>>> firmware and not the linux kernel.
>>>
>>>
>>> Sorry it was unclear, let try to reexplain my suggestion:
>>>
>>> Two alignment constraints can apply:
>>> - The remote processor can require an alignment through
>>> vdev_config::alignment.
>>> - The main processor, which runs Linux or another operating system (OS),
>>> can require a different alignment, for example, for cache alignment.
>>> In current Linux implementation no constraint in Linux.
>>> nevertheless I would be in favor of taking into account such future
>>> constraint without imposing constraint on the buffer sizes.
>>
>> Is this ever going to be ture? Is it ever possible that Linux and remote
>> has different cache alignment? IIUC, both will be using same cache and
>> so same alignment will be applicable. That is why only signle alignment
>> is required.
>
> Some remote processors, for example, some Arm Cortex-M33, do not
> integrate cache. Even if cache exists, cache can be enabled on one
> processor, but not on the other.
>
Okay, how about introducing two alignment in that case?
vdev_config::rpmsg_buf_align_remote, and vdev_config::rpmsg_buf_align_host ?
If remote doesn't have cache, then remote alignment will be 0, and the
*_host alignment can be applied. The rsc_table can provide both, and the
*_host will take priority over *_remote.
>>
>>> Based on that in short term the local 'rpmsg_buf_align' would still
>>> computed
>>> only from vdev_config::alignment (not update of vdev_config::alignment).
>>>
>>> virtio_cread(vdev, struct virtio_rpmsg_config,
>>> rpmsg_buf_align, &rpmsg_buf_align);
>>>
>>> Then you could use use ALIGN() helper:
>>>
>>> unsigned int rx_buf_align_size = ALIGN(vrp->rx_buf_size,
>>> rpmsg_buf_align);
>>> unsigned int tx_buf_align_size = ALIGN(vrp->tx_buf_size,
>>> rpmsg_buf_align);
>>>
>>
>> This is where I have different opinion. Instead of Linux using ALIGN()
>> macro, can we expect that firmware must assign the aligned buffer size
>> with vdev_config::rpmsg_buf_align? And so Linux will fail if the buffer
>> size is not aligned already from the firmware side. That is why I had
>> introduced checks instead of doing alignment by linux.
>>
>>> total_buf_space = (vrp->num_rx_buf * rx_buf_align_size) +
>>> (vrp->num_tx_buf * tx_buf_align_size);
>>>
>>> vrp->tx_bufs = bufs_va + vrp->num_rx_buf * rx_buf_align_size;
>>>
>>> Apply the same rule to cpu_addr in the vring descriptor:
>>>
>>> void *cpu_addr = vrp->rx_bufs + i * rx_buf_align_size;
>>>
>>> rpmsg_sg_init(&sg, cpu_addr, vrp->rx_buf_size);
>>>
>>> With this approach, the buffer addresses remain aligned
>>> independently of vdev_config::Rxbuf_size and vdev_config::txbuf_size.
>>> Don't hesitate if it is still not clear!
>>
>> How they remain aligned independent of tx/rx_buf_size? tx_bufs address
>> is still calculated based on rx_buf_align_size, so its alignment still
>> depends on rx_buf_align_size which is derived using
>> vdev_config::rpmsg_buf_align.>
>> I think we are trying to achive the same thing, but implementation is
>> differnt. We just need to decide where the alignment should be done?
>>
>> Either on the linux side? Or in the firmware resource table?
>>
>> I prefer that the firmware should already provide aligned buffer size,
>> and Linux should only check it. If alignment is not done, then simply
>> fail with error. That way, firmware also knows the correct size of the
>> buffer. If Linux does the alignment, then the firmware is not aware of
>> the correct size that is used by the linux.
>>
>> I am open to move the alignment operation to the linux side with the
>> reasonable justification.
>
> That remains a suggestion. My main concern with the implementation is
> that RPMsg size should depend only on the max playlod size needed, not
> also on the memory alignment.
Okay, I think this is a good reason to apply alignment on the linux
side. If I understand correctly, the rpmsg buffer size will be used as
it is from the rsc table, but vdev_config::alignment will be used only
to decide the start address of the next buffer. If that is the
intention, then I agree, and I will refactor the patch accordingly.
>
> If this constraint is kept, it must be imposed on all other non-Linux
> solutions. Otherwise, the remote implementation depends on the main
> processor implementation.
>
> From my POV, It would be preferable not to impose such constraint when
> possible.
>
Okay.
> Thanks,
> Arnaud
>
>>
>> Thank You,
>> Tanmay
>>
>>>>
>>>>
>>>>>> + if (rpmsg_buf_align &&
>>>>>> + (!IS_ALIGNED(vrp->rx_buf_size, rpmsg_buf_align) ||
>>>>>> + !IS_ALIGNED(vrp->tx_buf_size, rpmsg_buf_align))) {
>>>>>> + dev_err(&vdev->dev,
>>>>>> + "bad vdev config: buf sizes (rx %u, tx %u) not
>>>>>> aligned to %u\n",
>>>>>> + vrp->rx_buf_size, vrp->tx_buf_size,
>>>>>> + rpmsg_buf_align);
>>>>>> + err = -EINVAL;
>>>>>> + goto vqs_del;
>>>>>> + }
>>>>>> +
>>>>>> + dev_dbg(&vdev->dev,
>>>>>> + "vdev config: ver=%u, align=0x%x, rx sz = 0x%x, tx sz =
>>>>>> 0x%x\n",
>>>>>> + version, rpmsg_buf_align, vrp->rx_buf_size,
>>>>>> + vrp->tx_buf_size);
>>>>>> + } else {
>>>>>> + vrp->rx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
>>>>>> + vrp->tx_buf_size = DEFAULT_RPMSG_BUF_SIZE;
>>>>>> + }
>>>>>> +
>>>>>> + total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size) +
>>>>>> + (vrp->num_tx_buf * vrp->tx_buf_size);
>>>>>> /* allocate coherent memory for the buffers */
>>>>>> bufs_va = dma_alloc_coherent(vdev->dev.parent,
>>>>>> @@ -874,15 +959,20 @@ static int rpmsg_probe(struct virtio_device
>>>>>> *vdev)
>>>>>> /* first part of the buffers is dedicated for RX */
>>>>>> vrp->rx_bufs = bufs_va;
>>>>>> - /* and second part is dedicated for TX */
>>>>>> - vrp->tx_bufs = bufs_va + vrp->num_rx_buf * vrp->buf_size;
>>>>>> + /*
>>>>>> + * Here buf_va is aligned to a page. Also rx buf size is aligned
>>>>>> with
>>>>>> + * cache line alignment provided by the firmware, so tx buf's
>>>>>> start
>>>>>> + * address is guranteed to be aligned with the alignment
>>>>>> provided by
>>>>>> + * the firmware.
>>>>>> + */
>>>>>> + vrp->tx_bufs = bufs_va + (vrp->num_rx_buf * vrp->rx_buf_size);
>>>>>> /* set up the receive buffers */
>>>>>> for (i = 0; i < vrp->num_rx_buf; i++) {
>>>>>> struct scatterlist sg;
>>>>>> - void *cpu_addr = vrp->rx_bufs + i * vrp->buf_size;
>>>>>> + void *cpu_addr = vrp->rx_bufs + i * vrp->rx_buf_size;
>>>>>> - rpmsg_sg_init(&sg, cpu_addr, vrp->buf_size);
>>>>>> + rpmsg_sg_init(&sg, cpu_addr, vrp->rx_buf_size);
>>>>>> err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, cpu_addr,
>>>>>> GFP_KERNEL);
>>>>>> @@ -965,8 +1055,8 @@ static int rpmsg_remove_device(struct device
>>>>>> *dev, void *data)
>>>>>> static void rpmsg_remove(struct virtio_device *vdev)
>>>>>> {
>>>>>> struct virtproc_info *vrp = vdev->priv;
>>>>>> - unsigned int num_bufs = vrp->num_rx_buf + vrp->num_tx_buf;
>>>>>> - size_t total_buf_space = num_bufs * vrp->buf_size;
>>>>>> + size_t total_buf_space = (vrp->num_rx_buf * vrp->rx_buf_size) +
>>>>>> + (vrp->num_tx_buf * vrp->tx_buf_size);
>>>>>> int ret;
>>>>>> virtio_reset_device(vdev);
>>>>>> @@ -992,6 +1082,7 @@ static struct virtio_device_id id_table[] = {
>>>>>> static unsigned int features[] = {
>>>>>> VIRTIO_RPMSG_F_NS,
>>>>>> + VIRTIO_RPMSG_F_BUFSZ,
>>>>>> };
>>>>>> static struct virtio_driver virtio_ipc_driver = {
>>>>>> diff --git a/include/linux/rpmsg/virtio_rpmsg.h b/include/linux/
>>>>>> rpmsg/
>>>>>> virtio_rpmsg.h
>>>>>> new file mode 100644
>>>>>> index 000000000000..7e14da68fd17
>>>>>> --- /dev/null
>>>>>> +++ b/include/linux/rpmsg/virtio_rpmsg.h
>>>>>> @@ -0,0 +1,50 @@
>>>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>>>> +/*
>>>>>> + * Copyright (C) Pinecone Inc. 2019
>>>>>> + * Copyright (C) Xiang Xiao <xiaoxiang@pinecone.net>
>>>>>> + * Copyright (C) Advanced Micro Devices, Inc. 2026
>>>>>> + */
>>>>>> +
>>>>>> +#ifndef _LINUX_VIRTIO_RPMSG_H
>>>>>> +#define _LINUX_VIRTIO_RPMSG_H
>>>>>> +
>>>>>> +#include <linux/types.h>
>>>>>> +#include <linux/virtio_types.h>
>>>>>> +
>>>>>> +/* The feature bitmap for virtio rpmsg */
>>>>>> +#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service
>>>>>> notifications */
>>>>>> +#define VIRTIO_RPMSG_F_BUFSZ 1 /* RP get buffer size from config
>>>>>> space */
>>>>>> +
>>>>>> +/* Version of struct virtio_rpmsg_config understood by this
>>>>>> driver */
>>>>>> +#define RPMSG_VDEV_CONFIG_V1 1
>>>>>> +
>>>>>> +/**
>>>>>> + * struct virtio_rpmsg_config - config space for rpmsg virtio device
>>>>>> + *
>>>>>> + * @version: version of this structure, currently
>>>>>> %RPMSG_VDEV_CONFIG_V1.
>>>>>> + * @reserved: reserved for padding, must be zero.
>>>>>> + * @size: size of this structure in bytes.
>>>>>> + * @rpmsg_buf_align: required alignment in bytes for each buffer.
>>>>>> Must be a
>>>>>> + * power of two so that both the buffer sizes and the TX
>>>>>> buffer
>>>>>> + * base address can be aligned (e.g. to a cache line).
>>>>>> + * @reserved1: reserved for padding, must be zero. Keeps the
>>>>>> following 32-bit
>>>>>> + * fields naturally aligned.
>>>>>> + * @txbuf_size: Tx buf size from remote's view. For Linux this is
>>>>>> rx buf size.
>>>>>> + * @rxbuf_size: Rx buf size from remote's view. For Linux this is
>>>>>> tx buf size.
>>>>>> + *
>>>>>> + * This is the configuration structure shared by the device and the
>>>>>> driver,
>>>>>> + * read when %VIRTIO_RPMSG_F_BUFSZ is negotiated. The fields are
>>>>>> laid
>>>>>> out so
>>>>>> + * the structure is naturally 32-bit aligned.
>>>>>> + */
>>>>>> +struct virtio_rpmsg_config {
>>>>>> + u8 version;
>>>>>> + u8 reserved;
>>>>>
>>>>> Why about defining the version type to u16 to avoid the reserved
>>>>> field?
>>>>>
>>>>>> + __virtio16 size;
>>>>>> + __virtio16 rpmsg_buf_align;
>>>>>> + __virtio16 reserved1;
>>>>>
>>>>> Seems useless if __packed prevents the compiler from inserting extra
>>>>> padding
>>>>> bytes between fields,
>>>>>
>>>>>> + /* The tx/rx individual buffer size (if VIRTIO_RPMSG_F_BUFSZ) */
>>>>>> + __virtio32 txbuf_size;
>>>>>> + __virtio32 rxbuf_size;
>>>>>> +} __packed;
>>>>>
>>>>> proposal
>>>>>
>>>>> +struct virtio_rpmsg_config {
>>>>> + __virtio16 version;
>>>>> + __virtio16 size;
>>>>> + /* The tx/rx individual buffer size (if VIRTIO_RPMSG_F_BUFSZ) */
>>>>> + __virtio32 txbuf_size;
>>>>> + __virtio32 rxbuf_size;
>>>>> + __virtio16 rpmsg_buf_align;
>>>>> +} __packed;
>>>>> +
>>>>>
>>>>
>>>> I am okay with the above proposal with minor difference:
>>>>
>>>> My proposal:
>>>>
>>>> +struct virtio_rpmsg_config {
>>>> + u8 version;
>>>> + __virtio16 size;
>>>> + __virtio16 rpmsg_buf_align;
>>>> + /* The tx/rx individual buffer size (if VIRTIO_RPMSG_F_BUFSZ) */
>>>> + __virtio32 txbuf_size;
>>>> + __virtio32 rxbuf_size;
>>>> +} __packed;
>>>>
>>>> I just want to keep version field 8-bit, as we will probably never use
>>>> upper byte of that field if we use 16-bit. Rest is okay. If the
>>>> strucutre is packed then reserved bytes are not needed.
>>>>
>>>> Please let me know your view.
>>>
>>> No strong opinion on that. In the end, this structure is read only one
>>> time.
>>> If it is acceptable to Mathieu, it is acceptable to me.
>>>
>>> Thanks,
>>> Arnaud
>>>
>>>>
>>>> Thanks,
>>>> Tanmay
>>>>
>>>>
>>>>> Regards,
>>>>> Arnaud
>>>>>
>>>>>> +
>>>>>> +#endif /* _LINUX_VIRTIO_RPMSG_H */
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH] docs: arm64: Document that text_offset is always 0
From: Mark Rutland @ 2026-06-19 15:21 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linux-arm-kernel, Ard Biesheuvel, Will Deacon, Jonathan Corbet,
linux-doc, linux-kernel
In-Reply-To: <20260604140839.1930847-1-linux@rasmusvillemoes.dk>
On Thu, Jun 04, 2026 at 04:08:39PM +0200, Rasmus Villemoes wrote:
> When trying to figure out where to place and call an arm64 Image in
> memory, reading booting.rst should provide the answer. However, it
> requires quite some digging to figure out that text_offset is set via
> ".quad 0" in head.S and is thus actually always 0 since v5.10.
What is the actual problem?
The documentation in booting.rst is accurate; I don't see why it's
necessary to read the source code to look at text_offset. Immediately
above the text in your diff, the documentation has:
| 4. Call the kernel image
| ------------------------
|
| Requirement: MANDATORY
|
| The decompressed kernel image contains a 64-byte header as follows::
|
| u32 code0; /* Executable code */
| u32 code1; /* Executable code */
| u64 text_offset; /* Image load offset, little endian */
| u64 image_size; /* Effective Image size, little endian */
| u64 flags; /* kernel flags, little endian */
| u64 res2 = 0; /* reserved */
| u64 res3 = 0; /* reserved */
| u64 res4 = 0; /* reserved */
| u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
| u32 res5; /* reserved (used for PE COFF offset) */
Can you explain the problem you're facing? e.g.
* Is the documentation unclear, in a way that could be better?
* Is there some aspect of the boot protocol that is hard for a
bootloader to follow?
* Is there some problem with *testing* that bootloaders respect the
text_offset requirements?
* Something else?
> Update the documentation and make that explicit. Reword the 2MB
> requirement accordingly, and remove the paragraphs that only apply to
> the ancient versions where text_offset could be non-zero, as they only
> confuse a current reader.
>
> Fixes: 120dc60d0bdb ("arm64: get rid of TEXT_OFFSET")
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> I've included a Fixes tag since I spent way too much time tracking
> down where that text_offset might be defined. The mentioned commit did
> get rid of all references to TEXT_OFFSET-the-macro, but not
> text_offset-the-concept.
Keeping text_offset as a concept was deliberate. That allows us to keep
the documentation accruate for older kernel versions, and allows for the
possiblity that a non-zero offset is introduced in future (though I
admit that might be a tough sell).
> Documentation/arch/arm64/booting.rst | 20 +++++---------------
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst
> index 13ef311dace8..f4cc25b1fd56 100644
> --- a/Documentation/arch/arm64/booting.rst
> +++ b/Documentation/arch/arm64/booting.rst
> @@ -55,9 +55,6 @@ not exceed 2 megabytes in size. Since the dtb will be mapped cacheable
> using blocks of up to 2 megabytes in size, it must not be placed within
> any 2M region which must be mapped with any specific attributes.
>
> -NOTE: versions prior to v4.2 also require that the DTB be placed within
> -the 512 MB region starting at text_offset bytes below the kernel Image.
> -
> 3. Decompress the kernel image
> ------------------------------
>
> @@ -93,6 +90,8 @@ Header notes:
>
> - As of v3.17, all fields are little endian unless stated otherwise.
>
> +- As of v5.10, text_offset is always 0.
> +
> - code0/code1 are responsible for branching to stext.
>
> - when booting through EFI, code0/code1 are initially skipped.
> @@ -100,12 +99,6 @@ Header notes:
> entry point (efi_stub_entry). When the stub has done its work, it
> jumps to code0 to resume the normal boot process.
>
> -- Prior to v3.17, the endianness of text_offset was not specified. In
> - these cases image_size is zero and text_offset is 0x80000 in the
> - endianness of the kernel. Where image_size is non-zero image_size is
> - little-endian and must be respected. Where image_size is zero,
> - text_offset can be assumed to be 0x80000.
> -
So far we've tried to ensure that the documentation covers current *and*
older kernel versions. If we're going to drop text covering older
versions we'd need an explciit statemnt as to which kernel versions the
document is accurate for.
I would prefer that we retained documentation regarding the text_offset
field in the header, even if it happens to be zero today.
Mark.
> - The flags field (introduced in v3.17) is a little-endian 64-bit field
> composed as follows:
>
> @@ -135,12 +128,9 @@ Header notes:
> end of the kernel image. The amount of space required will vary
> depending on selected features, and is effectively unbound.
>
> -The Image must be placed text_offset bytes from a 2MB aligned base
> -address anywhere in usable system RAM and called there. The region
> -between the 2 MB aligned base address and the start of the image has no
> -special significance to the kernel, and may be used for other purposes.
> -At least image_size bytes from the start of the image must be free for
> -use by the kernel.
> +The Image must be placed at a 2MB aligned base address anywhere in
> +usable system RAM and called there. At least image_size bytes from
> +the start of the image must be free for use by the kernel.
> NOTE: versions prior to v4.6 cannot make use of memory below the
> physical offset of the Image so it is recommended that the Image be
> placed as close as possible to the start of system RAM.
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v3] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
From: Will Deacon @ 2026-06-19 14:58 UTC (permalink / raw)
To: Shanker Donthineni
Cc: Jason Gunthorpe, Catalin Marinas, Vladimir Murzin,
linux-arm-kernel@lists.infradead.org, Mark Rutland,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Vikram Sethi, Jason Sequeira
In-Reply-To: <25495831-f32d-4332-a7c2-fb1463b96174@nvidia.com>
On Tue, Jun 16, 2026 at 08:22:39AM -0500, Shanker Donthineni wrote:
> On 6/12/2026 7:48 AM, Jason Gunthorpe wrote:
> > On Thu, Jun 11, 2026 at 08:13:48PM -0500, Shanker Donthineni wrote:
> >
> > > For the scalar MMIO helpers, the workaround promotes the raw writes to
> > > store-release on affected CPUs as v1/v2 shown below. For the memcpy-toIO
> > > helpers, could you please clarify the specific reason for adding a dmb despite
> > > the documented no-ordering contract? Is the concern that some drivers may
> > > be relying on ordering across memcpy_toio_*() today even though the API
> > > does not guarantee it, and that we should cover those cases defensively?
> > I think given how arm implements them today the iocopy's are actually
> > the _relaxed variations.. I wonder if this matters to any user?
>
> Following Jason's observation that on arm64 the memcpy_toio()
> /__iowrite{32,64}_copy() helpers are effectively the relaxed
> (write-combining) variants, I'd like to settle one open point before posting
> v4: should the workaround also promote dgh() > dmb on affected CPUs (now
> Olympus core), or leave dgh() as a plain hint?
>
> If you'd still prefer the dmb defensively, to cover drivers that may
> rely on ordering across memcpy_toio() today despite the relaxed contract,
> I'm happy to fold it into v4.
The point is, you're going to have different behaviour to every other
arm64 system out there. You may be able to find vague comments in the
code that imply that you don't need to provide ordering, but at the end
of the day it's a pretty cavalier attitude imo and if a driver ever shows
up that relies on it then you're in trouble.
> Please let me know how you'd like me to proceed.
It's up to you. It's your broken CPU, not mine. You also haven't actually
provided any performance data for others to assess the trade-off.
If it was up to _me_, I'd upgrade dgh() on these CPUs to that I don't
need to worry about this again.
Will
^ permalink raw reply
* Re: [PATCH v2 02/11] mm: factor out adjust_range_hwpoison() from hugetlbfs
From: David Hildenbrand (Arm) @ 2026-06-19 14:52 UTC (permalink / raw)
To: Jane Chu, akpm
Cc: willy, jack, viro, brauner, muchun.song, osalvador, hughd,
baolin.wang, linmiaohe, nao.horiguchi, lorenzo, rppt, peterx,
corbet, linux-doc, linux-mm, linux-kernel, linux-fsdevel
In-Reply-To: <20260617172534.1740152-3-jane.chu@oracle.com>
On 6/17/26 19:25, Jane Chu wrote:
> The functionality and implementation of adjust_range_hwpoison() is
> generic, so factor it out and make it ready for generic use.
>
> [1] https://lore.kernel.org/linux-mm/aeZwAz6PcdlqSnJ2@casper.infradead.org/
>
> Suggested-by: Matthew Wilcox <willy@infradead.org>
> Signed-off-by: Jane Chu <jane.chu@oracle.com>
> ---
[...]
> -/*
> - * Check if a given raw @page is HWPOISON in a folio of any kind
> - */
> -bool is_raw_hwpoison_page_in_folio(struct page *page);
> -
> static inline unsigned long huge_page_mask_align(struct file *file)
> {
> return PAGE_MASK & ~huge_page_mask(hstate_file(file));
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 4e636647100c..a27ce4ad6247 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2753,6 +2753,37 @@ static void filemap_end_dropbehind_read(struct folio *folio)
> }
> }
>
> +/**
> + * adjust_range_hwpoison - adjust clean readable range to avoid hwpoison.
> + * @folio: folio that contains hwpoison(s).
> + * @offset: bytes into the folio where subsequent read starts.
> + * @bytes: number of bytes wish to read.
> + *
> + * Return: adjusted total number of bytes starting off @offset that can be
s/off/at/ ?
Apart from that, lgtm
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 01/11] mm/memory-failure: make is_raw_hwpoison_page_in_hugepage() general purpose
From: David Hildenbrand (Arm) @ 2026-06-19 14:49 UTC (permalink / raw)
To: Jane Chu, akpm
Cc: willy, jack, viro, brauner, muchun.song, osalvador, hughd,
baolin.wang, linmiaohe, nao.horiguchi, lorenzo, rppt, peterx,
corbet, linux-doc, linux-mm, linux-kernel, linux-fsdevel
In-Reply-To: <20260617172534.1740152-2-jane.chu@oracle.com>
On 6/17/26 19:25, Jane Chu wrote:
> Make is_raw_hwpoison_page_in_hugepage() general for checking whether
> a given raw page within any kind of folio is HW poisoned. Thus,
> replace folio_test_hwpoison() with folio_contain_hwpoisoned_page().
> Also rename to is_raw_hwpoison_page_in_folio().
>
> Signed-off-by: Jane Chu <jane.chu@oracle.com>
> ---
> fs/hugetlbfs/inode.c | 4 ++--
> include/linux/hugetlb.h | 4 ++--
> mm/memory-failure.c | 12 ++++++++++--
> 3 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 78d61bf2bd9b..66520f7c53c6 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -198,7 +198,7 @@ static size_t adjust_range_hwpoison(struct folio *folio, size_t offset,
> struct page *page = folio_page(folio, offset / PAGE_SIZE);
> size_t safe_bytes;
>
> - if (is_raw_hwpoison_page_in_hugepage(page))
> + if (is_raw_hwpoison_page_in_folio(page))
> return 0;
> /* Safe to read the remaining bytes in this page. */
> safe_bytes = PAGE_SIZE - (offset % PAGE_SIZE);
> @@ -206,7 +206,7 @@ static size_t adjust_range_hwpoison(struct folio *folio, size_t offset,
>
> /* Check each remaining page as long as we are not done yet. */
> for (; safe_bytes < bytes; safe_bytes += PAGE_SIZE, page++)
> - if (is_raw_hwpoison_page_in_hugepage(page))
> + if (is_raw_hwpoison_page_in_folio(page))
> break;
>
> return min(safe_bytes, bytes);
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 5957bc25efa8..a9846f043712 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -1079,9 +1079,9 @@ void hugetlb_unregister_node(struct node *node);
> #endif
>
> /*
> - * Check if a given raw @page in a hugepage is HWPOISON.
> + * Check if a given raw @page is HWPOISON in a folio of any kind
> */
> -bool is_raw_hwpoison_page_in_hugepage(struct page *page);
> +bool is_raw_hwpoison_page_in_folio(struct page *page);
>
> static inline unsigned long huge_page_mask_align(struct file *file)
> {
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index ee42d4361309..40129e0b8213 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1834,14 +1834,21 @@ static inline struct llist_head *raw_hwp_list_head(struct folio *folio)
> return (struct llist_head *)&folio->_hugetlb_hwpoison;
> }
>
> -bool is_raw_hwpoison_page_in_hugepage(struct page *page)
> +/**
> + * is_raw_hwpoison_page_in_folio - answers the question whether a given
> + * page is indeed hwpoisoned.
> + * @page: given page, maybe base page, part of a large folio or hugetlb.
> + *
> + * Return: true if @page is the raw hwpoisoned page; else, false.
> + */
Why do we need the "in_folio" part at all?
> +bool is_raw_hwpoison_page_in_folio(struct page *page)
> {
> struct llist_head *raw_hwp_head;
> struct raw_hwp_page *p;
> struct folio *folio = page_folio(page);
> bool ret = false;
>
> - if (!folio_test_hwpoison(folio))
> + if (!folio_contain_hwpoisoned_page(folio))
I wonder if we should just not call that function for hugetlb, it doesn't make
sense as hugetlb doesn't set _has_hwpoisoned.
But then, I wonder if we really need folio_contain_hwpoisoned_page() at all?
Why not a simple:
if (!folio_test_hugetlb(folio))
return PageHWPoison(page);
And now I am confused which scenario you are worried about (it's warm here ...)
can you explain which scenario you want to change?
> return false;
>
> if (!folio_test_hugetlb(folio))
> @@ -1868,6 +1875,7 @@ bool is_raw_hwpoison_page_in_hugepage(struct page *page)
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(is_raw_hwpoison_page_in_folio);
You should spell out why you export that function in the patch description.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] docs: arm64: Document that text_offset is always 0
From: Will Deacon @ 2026-06-19 14:33 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linux-arm-kernel, Ard Biesheuvel, Jonathan Corbet, linux-doc,
linux-kernel
In-Reply-To: <20260604140839.1930847-1-linux@rasmusvillemoes.dk>
On Thu, Jun 04, 2026 at 04:08:39PM +0200, Rasmus Villemoes wrote:
> When trying to figure out where to place and call an arm64 Image in
> memory, reading booting.rst should provide the answer. However, it
> requires quite some digging to figure out that text_offset is set via
> ".quad 0" in head.S and is thus actually always 0 since v5.10.
>
> Update the documentation and make that explicit. Reword the 2MB
> requirement accordingly, and remove the paragraphs that only apply to
> the ancient versions where text_offset could be non-zero, as they only
> confuse a current reader.
Doesn't this needlessly prevent us from having a non-zero offset in future,
if we wanted that for some reason?
Will
^ permalink raw reply
* Re: [PATCH 0/3] docs/zh_CN: update translation of doc-guide/sphinx.rst
From: Jonathan Corbet @ 2026-06-19 14:26 UTC (permalink / raw)
To: Jiandong Qiu, alexs, si.yanteng
Cc: dzm91, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260619140245.1982921-1-qiujiandong1998@gmail.com>
Jiandong Qiu <qiujiandong1998@gmail.com> writes:
> Hi all,
>
> This is my first time sending patches to the Linux community. I have
> been reading the kernel documentation to learn more about Linux, and in
> the process I found a few places where I could help improve the zh_CN
> translations. Comments and suggestions are welcome.
Thank you for working to improve our documentation!
I've added a couple of comments, though I need to defer to others to
judge the translation work itself. I do have one question, though: did
you do the translation yourself, or did you use some sort of tool? In
the latter case, you need to document that usage with Assisted-by tags.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 2/3] docs/zh_CN: add process/changes.rst translation
From: Jonathan Corbet @ 2026-06-19 14:23 UTC (permalink / raw)
To: Jiandong Qiu, alexs, si.yanteng
Cc: dzm91, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260619140245.1982921-3-qiujiandong1998@gmail.com>
Jiandong Qiu <qiujiandong1998@gmail.com> writes:
> Add the zh_CN translation of process/changes.rst.
>
> Update the translation through commit ece7e57afd51
> ("docs: changes.rst and ver_linux: sort the lists")
>
> Signed-off-by: Jiandong Qiu <qiujiandong1998@gmail.com>
> ---
> .../translations/zh_CN/process/changes.rst | 530 ++++++++++++++++++
> 1 file changed, 530 insertions(+)
> create mode 100644 Documentation/translations/zh_CN/process/changes.rst
>
> diff --git a/Documentation/translations/zh_CN/process/changes.rst b/Documentation/translations/zh_CN/process/changes.rst
> new file mode 100644
> index 000000000000..cc22f65e4888
> --- /dev/null
> +++ b/Documentation/translations/zh_CN/process/changes.rst
> @@ -0,0 +1,530 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include:: ../disclaimer-zh_CN.rst
> +
> +:Original: Documentation/process/changes.rst
> +
> +:翻译: 裘剑东 Jiandong Qiu <qiujiandong1998@gmail.com>
> +
> +.. _changes_zh:
Here too, we don't need this label.
(Yes, I'm quibbling on details because I am in no position to judge the
translation itself :)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 1/3] docs/zh_CN: add llvm.rst translation anchor
From: Jonathan Corbet @ 2026-06-19 14:23 UTC (permalink / raw)
To: Jiandong Qiu, alexs, si.yanteng
Cc: dzm91, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260619140245.1982921-2-qiujiandong1998@gmail.com>
Jiandong Qiu <qiujiandong1998@gmail.com> writes:
> Add the kbuild_llvm_zh label for local cross-references.
>
> Signed-off-by: Jiandong Qiu <qiujiandong1998@gmail.com>
> ---
> process/changes.rst refers to this anchor.
>
> Documentation/translations/zh_CN/kbuild/llvm.rst | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/translations/zh_CN/kbuild/llvm.rst b/Documentation/translations/zh_CN/kbuild/llvm.rst
> index f87e0181d8e7..5fdf281a614a 100644
> --- a/Documentation/translations/zh_CN/kbuild/llvm.rst
> +++ b/Documentation/translations/zh_CN/kbuild/llvm.rst
> @@ -5,6 +5,8 @@
> :Original: Documentation/kbuild/llvm.rst
> :Translator: 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn>
>
> +.. _kbuild_llvm_zh:
> +
Please, let's not add more of these top-of-file labels; I've been trying
to stomp those out for years. If this file needs to be referenced, just
reference it by name and the automarkup code will do the right thing.
Thanks,
jon
^ permalink raw reply
* [PATCH] NFS: pnfs: fix stale references in pnfs.rst
From: Minxi Hou @ 2026-06-19 14:20 UTC (permalink / raw)
To: linux-nfs; +Cc: trondmy, anna, cel, jlayton, linux-doc, Minxi Hou
The layout header list was moved from struct nfs_client (cl_layouts) to
struct nfs_server (layouts) in commit 6382a44138e7 ("NFS: move pnfs
layouts to nfs_server structure"), but the documentation was not updated.
Also update the layout driver description to reflect that the objects
layout driver was removed in commit 6d22323b2e9f ("nfs: remove the
objlayout driver"), leaving 3 layout types implemented in the kernel
client: files, blocks, and flexfiles.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
---
Documentation/filesystems/nfs/pnfs.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/nfs/pnfs.rst b/Documentation/filesystems/nfs/pnfs.rst
index 7c470ecdc3a9..ea3d15cc4549 100644
--- a/Documentation/filesystems/nfs/pnfs.rst
+++ b/Documentation/filesystems/nfs/pnfs.rst
@@ -22,7 +22,7 @@ outstanding RPC call that references it (LAYOUTGET, LAYOUTRETURN,
LAYOUTCOMMIT), and for each lseg held within.
Each header is also (when non-empty) put on a list associated with
-struct nfs_client (cl_layouts). Being put on this list does not bump
+struct nfs_server (layouts). Being put on this list does not bump
the reference count, as the layout is kept around by the lseg that
keeps it in the list.
@@ -62,8 +62,8 @@ bit is set, preventing any new lsegs from being added.
layout drivers
==============
-PNFS utilizes what is called layout drivers. The STD defines 4 basic
-layout types: "files", "objects", "blocks", and "flexfiles". For each
+PNFS utilizes what is called layout drivers. The Linux NFS client
+implements 3 layout types: "files", "blocks", and "flexfiles". For each
of these types there is a layout-driver with a common function-vectors
table which are called by the nfs-client pnfs-core to implement the
different layout types.
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-19 14:12 UTC (permalink / raw)
To: Nuno Sá
Cc: Janani Sunil, Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <ajU73_TkKrSbqD4f@nsa>
[-- Attachment #1: Type: text/plain, Size: 12325 bytes --]
On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > >
> > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > >
> > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > integrated precision reference.
> > > > > > > ...
> > > > > > > Probably others may comment on that, but...
> > > > > > >
> > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > >
> > > > > > > That way I suppose that an example would look like...
> > > > > > > > +
> > > > > > > > +patternProperties:
> > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > + type: object
> > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > +
> > > > > > > > + properties:
> > > > > > > > + reg:
> > > > > > > > + description: Channel number.
> > > > > > > > + minimum: 0
> > > > > > > > + maximum: 15
> > > > > > > > +
> > > > > > > > + adi,output-range-microvolt:
> > > > > > > > + description: |
> > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > + oneOf:
> > > > > > > > + - items:
> > > > > > > > + - const: 0
> > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > + - items:
> > > > > > > > + - const: -5000000
> > > > > > > > + - const: 5000000
> > > > > > > > + - items:
> > > > > > > > + - const: -10000000
> > > > > > > > + - const: 10000000
> > > > > > > > + - items:
> > > > > > > > + - const: -15000000
> > > > > > > > + - const: 15000000
> > > > > > > > + - items:
> > > > > > > > + - const: -20000000
> > > > > > > > + - const: 20000000
> > > > > > > > +
> > > > > > > > + required:
> > > > > > > > + - reg
> > > > > > > > +
> > > > > > > > + additionalProperties: false
> > > > > > > > +
> > > > > > > > +required:
> > > > > > > > + - compatible
> > > > > > > > + - reg
> > > > > > > > + - vdd-supply
> > > > > > > > + - avdd-supply
> > > > > > > > + - hvdd-supply
> > > > > > > > +
> > > > > > > > +dependencies:
> > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > +
> > > > > > > > +allOf:
> > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > +
> > > > > > > > +unevaluatedProperties: false
> > > > > > > > +
> > > > > > > > +examples:
> > > > > > > > + - |
> > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > +
> > > > > > > > + spi {
> > > > > > > > + #address-cells = <1>;
> > > > > > > > + #size-cells = <0>;
> > > > > > > > +
> > > > > > > > + dac@0 {
> > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > + reg = <0>;
> > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > +
> > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > +
> > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > +
> > > > > > > > + #address-cells = <1>;
> > > > > > > > + #size-cells = <0>;
> > > > > > > > +
> > > > > > > > + channel@0 {
> > > > > > > > + reg = <0>;
> > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + channel@1 {
> > > > > > > > + reg = <1>;
> > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + channel@2 {
> > > > > > > > + reg = <2>;
> > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > + };
> > > > > > > > + };
> > > > > > > > + };
> > > > > > > ...
> > > > > > >
> > > > > > > spi {
> > > > > > > #address-cells = <1>;
> > > > > > > #size-cells = <0>;
> > > > > > >
> > > > > > > multi-dac@0 {
> > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > reg = <0>;
> > > > > > > spi-max-frequency = <25000000>;
> > > > > > >
> > > > > > > #address-cells = <1>;
> > > > > > > #size-cells = <0>;
> > > > > > >
> > > > > > > dac@0 {
> > > > > > > reg = <0>;
> > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > >
> > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > >
> > > > > > > #address-cells = <1>;
> > > > > > > #size-cells = <0>;
> > > > > > >
> > > > > > > channel@0 {
> > > > > > > reg = <0>;
> > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > };
> > > > > > >
> > > > > > > channel@1 {
> > > > > > > reg = <1>;
> > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > };
> > > > > > >
> > > > > > > channel@2 {
> > > > > > > reg = <2>;
> > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > };
> > > > > > > }
> > > > > > >
> > > > > > > dac@1 {
> > > > > > > reg = <1>;
> > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > >
> > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > >
> > > > > > > #address-cells = <1>;
> > > > > > > #size-cells = <0>;
> > > > > > >
> > > > > > > channel@0 {
> > > > > > > reg = <0>;
> > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > };
> > > > > > >
> > > > > > > channel@1 {
> > > > > > > reg = <1>;
> > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > };
> > > > > > > }
> > > > > > > };
> > > > > > > };
> > > > > > >
> > > > > > > then you might need something like:
> > > > > > >
> > > > > > > patternProperties:
> > > > > > > "^dac@[0-3]$":
> > > > > > >
> > > > > > > and put most of the things under this node pattern.
> > > > > > >
> > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > >
> > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > Hi Rodrigo,
> > > > > >
> > > > > > Thank you for looking at this.
> > > > > >
> > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > speculatively without a validating use case.
> > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > looking at it another way a kind of distributed SPI mux.
> > > > >
> > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > in all devices in the chain as one big SPI message.
> > > > >
> > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > longer term how to support it cleanly in SPI.
> > >
> > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > see if I can find what I am thinking of...
> >
> >
> > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > slightly different properties.
> >
> > microchip,device-addr:
> > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > $ref: /schemas/types.yaml#/definitions/uint32
> > enum: [0, 1, 2, 3]
> > default: 0
> >
> > and
> >
> >
> > microchip,hw-device-address:
> > $ref: /schemas/types.yaml#/definitions/uint32
> > minimum: 0
> > maximum: 3
> > description:
> > The address is set on a per-device basis by fuses in the factory,
> > configured on request. If not requested, the fuses are set for 0x1.
> > The device address is part of the device markings to avoid
> > potential confusion. This address is coded on two bits, so four possible
> > addresses are available when multiple devices are present on the same
> > SPI bus with only one Chip Select line for all devices.
> > Each device communication starts by a CS falling edge, followed by the
> > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > which is first one on the wire).
> >
> > This sounds exactly like the sort of feature that you're dealing with
> > here?
> >
>
> The core idea yes but for this chip, things are a bit more annoying (but
> Janani can correct me if I'm wrong). Here, each device can, in theory,
> have it's own supplies, pins and at the very least, channels with maybe
> different scales. That is why Janani is proposing dac nodes. Given I
> honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> about solving this at the spi level.
>
> Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> together in the same bus.
I'm definitely missing something, because that property for the
microchip devices is not impacted what else is on the bus. AFAICT, you
could have an mcp3911 and an mcp3564 on the same bus even though both
are completely different devices with different drivers. They have
individual device nodes and their own supplies etc etc. These aren't
per-channel properties on an adc or dac, they're per child device on a
spi bus.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 3/3] docs/zh_CN: update sphinx.rst translation
From: Jiandong Qiu @ 2026-06-19 14:02 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260619140245.1982921-1-qiujiandong1998@gmail.com>
Update zh_CN tranlation of doc-guide/sphinx.rst.
Update the translation through commit f1c2db1f145b
("docs: move test_doc_build.py to tools/docs")
- sync the Chinese translation with current Sphinx build requirements
- add sections on HTML math rendering and minimum-version testing
- refresh guidance for tables, cross-references, and commit references
Signed-off-by: Jiandong Qiu <qiujiandong1998@gmail.com>
---
.../translations/zh_CN/doc-guide/sphinx.rst | 165 ++++++++++++++----
1 file changed, 133 insertions(+), 32 deletions(-)
diff --git a/Documentation/translations/zh_CN/doc-guide/sphinx.rst b/Documentation/translations/zh_CN/doc-guide/sphinx.rst
index 3375c6f3a811..5375f1f7cfcc 100644
--- a/Documentation/translations/zh_CN/doc-guide/sphinx.rst
+++ b/Documentation/translations/zh_CN/doc-guide/sphinx.rst
@@ -1,8 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
.. include:: ../disclaimer-zh_CN.rst
:Original: Documentation/doc-guide/sphinx.rst
-:译者: 吴想成 Wu XiangCheng <bobwxc@email.cn>
+:译者:
+ - 吴想成 Wu XiangCheng <bobwxc@email.cn>
+ - 裘剑东 Jiandong Qiu <qiujiandong1998@gmail.com>
.. _sphinxdoc_zh:
@@ -14,7 +17,7 @@ Linux内核使用 `Sphinx <http://www.sphinx-doc.org/>`_ 来把 ``Documentation`
换成漂亮的文档。使用 ``make htmldocs`` 或 ``make pdfdocs`` 命令即可构建HTML
或PDF格式的文档。生成的文档放在 ``Documentation/output`` 文件夹中。
-reStructuredText文件可能包含包含来自源文件的结构化文档注释或kernel-doc注释。
+reStructuredText文件可能包含来自源文件的结构化文档注释或kernel-doc注释。
通常它们用于描述代码的功能、类型和设计。kernel-doc注释有一些特殊的结构和
格式，但除此之外，它们还被作为reStructuredText处理。
@@ -26,7 +29,7 @@ reStructuredText文件可能包含包含来自源文件的结构化文档注释
安装Sphinx
==========
-Documentation/ 下的ReST文件现在使用sphinx1.7或更高版本构建。
+Documentation/ 下的ReST文件现在使用 ``sphinx`` 3.4.3 或更高版本构建。
这有一个脚本可以检查Sphinx的依赖项。更多详细信息见
:ref:`sphinx-pre-install_zh` 。
@@ -38,21 +41,13 @@ Documentation/ 下的ReST文件现在使用sphinx1.7或更高版本构建。
``virtualenv-3`` 或 ``virtualenv`` 在虚拟环境中安装Sphinx，具体取决于发行版
如何打包Python3。
-.. note::
-
- #) html输出建议使用RTD主题。根据Sphinx版本的不同，它应该用
- ``pip install sphinx_rtd_theme`` 单独安装。
-
- #) 一些ReST页面包含数学表达式。由于Sphinx的工作方式，这些表达式是使用 LaTeX
- 编写的。它需要安装amsfonts和amsmath宏包，以便显示。
+总之，如您要安装最新版的Sphinx，应执行::
-总之，如您要安装Sphinx 2.4.4版本，应执行::
+ $ virtualenv sphinx_latest
+ $ . sphinx_latest/bin/activate
+ (sphinx_latest) $ pip install -r Documentation/sphinx/requirements.txt
- $ virtualenv sphinx_2.4.4
- $ . sphinx_2.4.4/bin/activate
- (sphinx_2.4.4) $ pip install -r Documentation/sphinx/requirements.txt
-
-在运行 ``. sphinx_2.4.4/bin/activate`` 之后，提示符将变化，以指示您正在使用新
+在运行 ``. sphinx_latest/bin/activate`` 之后，提示符将变化，以指示您正在使用新
环境。如果您打开了一个新的shell，那么在构建文档之前，您需要重新运行此命令以再
次进入虚拟环境中。
@@ -76,6 +71,23 @@ PDF和LaTeX构建
根据发行版的不同，您可能还需要安装一系列 ``texlive`` 软件包，这些软件包提供了
``XeLaTeX`` 工作所需的最小功能集。
+HTML中的数学表达式
+------------------
+
+有些ReST页面中包含数学表达式。由于Sphinx的工作方式，这些表达式使用LaTeX
+符号书写。Sphinx在HTML输出中渲染数学表达式有两种方式：一种是名为 `imgmath`_
+的扩展，它将数学表达式转换成图像并嵌入到HTML页面中。
+另一种是名为 `mathjax`_ 的扩展，它将数学表达式的渲染交由支持 JavaScript
+的浏览器处理。
+在6.1版内核文档之前，前者是唯一可用的方式，并且需要安装大量texlive软件包，
+其中包括amsfonts和amsmath等。
+
+自内核6.1版本起，无需安装任何texlive软件包即可构建包含数学表达式的HTML
+页面。更多信息请参阅 :ref:`choice_of_math_renderer_zh`。
+
+.. _imgmath: https://www.sphinx-doc.org/en/master/usage/extensions/math.html#module-sphinx.ext.imgmath
+.. _mathjax: https://www.sphinx-doc.org/en/master/usage/extensions/math.html#module-sphinx.ext.mathjax
+
.. _sphinx-pre-install_zh:
检查Sphinx依赖项
@@ -108,7 +120,29 @@ PDF和LaTeX构建
``--no-virtualenv``
- 使用Sphinx的系统打包，而不是Python虚拟环境。
+ 使用系统发行版提供的Sphinx软件包，而不是Python虚拟环境。
+
+安装最小版本的Sphinx
+--------------------
+
+在修改Sphinx构建系统时，确保其最小支持版本仍然可用非常重要。
+然而，在现代发行版上，这样做正变得越来越困难，因为在Python 3.13及以上版本
+环境下，已经无法安装该最小版本。
+
+要按照 Documentation/translations/zh_CN/process/changes.rst
+中定义的最低支持Python版本进行测试，可以使用该版本创建一个虚拟环境，
+并安装最小依赖::
+
+ /usr/bin/python3.9 -m venv sphinx_min
+ . sphinx_min/bin/activate
+ pip install -r Documentation/sphinx/min_requirements.txt
+
+更全面的测试可以使用以下脚本完成:
+
+ tools/docs/test_doc_build.py
+
+该脚本会为每个受支持的Python版本创建一个虚拟环境，并可选择针对一定范围内的
+Sphinx版本构建文档。
Sphinx构建
==========
@@ -117,17 +151,66 @@ Sphinx构建
的格式：请参阅 ``make help`` 的文档部分。生成的文档放在 ``Documentation/output``
下相应格式的子目录中。
-要生成文档，显然必须安装Sphinx（ ``sphinx-build`` ）。要让HTML输出更漂亮，可以
-使用Read the Docs Sphinx主题（ ``sphinx_rtd_theme`` ）。对于PDF输出，您还需要
-``XeLaTeX`` 和来自ImageMagick（https://www.imagemagick.org）的 ``convert(1)`` 。
-所有这些软件在大多发行版中都可用或已打包。
+要生成文档，显然必须安装Sphinx（ ``sphinx-build`` ）。对于PDF输出，您还需
+要 ``XeLaTeX`` 和来自 ImageMagick（https://www.imagemagick.org）的
+``convert(1)`` 。\ [#ink]_ 所有这些软件在各大发行版中都很常见，
+也都有对应的软件包。
要传递额外的选项给Sphinx，可以使用make变量 ``SPHINXOPTS`` 。例如，使用
``make SPHINXOPTS=-v htmldocs`` 获得更详细的输出。
+也可以通过make变量 ``DOCS_CSS`` 传入一个额外的DOCS_CSS覆盖文件，以自定义
+html布局。
+
+默认情况下，构建HTML文档时使用的是"Alabaster"主题；该主题随Sphinx一同提供，
+无需单独安装。也可以通过make变量 ``DOCS_THEME`` 覆盖Sphinx主题。
+
+.. note::
+
+ 有些人可能更喜欢在html输出中使用RTD主题。根据Sphinx版本的不同，它可能需要
+ 单独安装，可使用 ``pip install sphinx_rtd_theme`` 进行安装。
+
+还有一个make变量 ``SPHINXDIRS`` ，在测试构建某个文档子集时很有用。例如，您可
+以通过运行 ``make SPHINXDIRS=doc-guide htmldocs`` 构建
+``Documentation/doc-guide`` 下的文档。 ``make help`` 的文档部分会显示可指定的
+子目录列表。
要删除生成的文档，请运行 ``make cleandocs`` 。
+.. [#ink] 如果还安装了来自 Inkscape（https://inkscape.org）的 ``inkscape(1)`` ，
+ 则能够提升嵌入到PDF文档中的图像质量，尤其是在5.18及之后的内核版本中。
+
+.. _choice_of_math_renderer_zh:
+
+数学渲染器的选择
+----------------
+
+自内核 6.1 版本起， ``mathjax`` 可作为html输出中数学渲染器的后备方案。\ [#sph1_8_zh]_
+
+数学渲染器会根据可用命令按如下方式选择：
+
+.. table:: HTML 中数学渲染器的选择
+
+ ============ ================= ============
+ 数学渲染器 所需命令 图像格式
+ ============ ================= ============
+ imgmath latex, dvipng PNG（栅格）
+ mathjax
+ ============ ================= ============
+
+也可以通过设置环境变量 ``SPHINX_IMGMATH`` 来覆盖该选择，如下所示：
+
+.. table:: 设置 ``SPHINX_IMGMATH`` 的效果
+
+ ====================== ==========
+ 设置 渲染器
+ ====================== ==========
+ ``SPHINX_IMGMATH=yes`` imgmath
+ ``SPHINX_IMGMATH=no`` mathjax
+ ====================== ==========
+
+.. [#sph1_8_zh] 数学渲染器的后备机制要求Sphinx >= 1.8。
+
编写文档
========
@@ -187,7 +270,8 @@ Sphinx构建
~~~~~~~~
尽管RST没有规定具体的顺序（“没有强加一个固定数量和顺序的节标题装饰风格，最终
- 按照的顺序将是实际遇到的顺序。”），但是拥有一个通用级别的文档更容易遵循。
+ 按照的顺序将是实际遇到的顺序。”），但整体上让较高层级的标题样式保持一致，
+ 会更便于阅读和理解文档结构。
* 对于插入固定宽度的文本块（用于代码样例、用例等）： ``::`` 用于语法高亮意义不
大的内容，尤其是短代码段； ``.. code-block:: <language>`` 用于需要语法高亮的
@@ -218,15 +302,24 @@ C域
神奇力量，如果给定函数名的索引项存在，文档构建系统会自动将对 ``function()``
的引用转换为交叉引用。如果在内核文档中看到 ``c:func:`` 的用法，请删除它。
-
-列表
+表格
----
-我们建议使用 *列式表* 格式。 *列式表* 格式是二级列表。与ASCII艺术相比，它们对
-文本文件的读者来说可能没有那么舒适。但其优点是易于创建或修改，而且修改的差异
-（diff）更有意义，因为差异仅限于修改的内容。
+reStructuredText 为表格语法提供了多种选项。内核文档中的表格通常优先使用
+*simple table* 或 *grid table* 语法。更多细节请参阅
+`reStructuredText 用户参考中的表格语法`_ 。
+
+.. _reStructuredText 用户参考中的表格语法:
+ https://docutils.sourceforge.io/docs/user/rst/quickref.html#tables
-*平铺表* 也是一个二级列表，类似于 *列式表* ，但具有一些额外特性：
+列式表
+~~~~~~
+
+列式表（``list-table``）格式对于无法用常规Sphinx ASCII艺术格式轻松排版的表格来说
+可能很有用。然而，这种格式对于纯文本文档的读者来说几乎无法理解，因此，
+除非有充分的理由，否则应避免使用。
+
+``flat-table`` 也是一个二级列表，类似于 ``list-table`` ，但具有一些额外特性：
* 列范围：使用 ``cspan`` 修饰，可以通过其他列扩展单元格
@@ -302,15 +395,15 @@ C域
从一页文档到另一页文档的交叉引用可以通过简单地写出文件路径来完成，无特殊格式
要求。路径可以是绝对路径或相对路径。绝对路径从“Documentation/”开始。例如，要
-交叉引用此页，以下写法皆可，取决于具体的文档目录（注意 ``.rst`` 扩展名是可选
+交叉引用此页，以下写法皆可，取决于具体的文档目录（注意 ``.rst`` 扩展名是必需
的）::
参见 Documentation/doc-guide/sphinx.rst 。此法始终可用。
请查看 sphinx.rst ，仅在同级目录中有效。
请阅读 ../sphinx.rst ，上级目录中的文件。
-如果要使用相对路径，则需要使用Sphinx的 ``doc`` 修饰。例如，从同一目录引用此页
-的操作如下::
+如果希望链接显示的文本不同于文档标题，则需要使用 Sphinx 的 ``doc`` 修饰。例
+如::
参见 :doc:`sphinx文档的自定义链接文本 <sphinx>`.
@@ -318,7 +411,15 @@ C域
个没有任何特殊作用的 ``:doc:`` 用法，请将其转换为文档路径。
有关交叉引用kernel-doc函数或类型的信息，请参阅
-Documentation/doc-guide/kernel-doc.rst 。
+Documentation/translations/zh_CN/doc-guide/kernel-doc.rst 。
+
+引用提交
+~~~~~~~~
+
+对 git 提交的引用如果采用以下格式书写，会自动转换为超链接::
+
+ commit 72bf4f1767f0
+ commit 72bf4f1767f0 ("net: do not leave an empty skb in write queue")
.. _sphinx_kfigure_zh:
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply related
* [PATCH 2/3] docs/zh_CN: add process/changes.rst translation
From: Jiandong Qiu @ 2026-06-19 14:02 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260619140245.1982921-1-qiujiandong1998@gmail.com>
Add the zh_CN translation of process/changes.rst.
Update the translation through commit ece7e57afd51
("docs: changes.rst and ver_linux: sort the lists")
Signed-off-by: Jiandong Qiu <qiujiandong1998@gmail.com>
---
.../translations/zh_CN/process/changes.rst | 530 ++++++++++++++++++
1 file changed, 530 insertions(+)
create mode 100644 Documentation/translations/zh_CN/process/changes.rst
diff --git a/Documentation/translations/zh_CN/process/changes.rst b/Documentation/translations/zh_CN/process/changes.rst
new file mode 100644
index 000000000000..cc22f65e4888
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/changes.rst
@@ -0,0 +1,530 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/process/changes.rst
+
+:翻译: 裘剑东 Jiandong Qiu <qiujiandong1998@gmail.com>
+
+.. _changes_zh:
+
+==================
+编译内核的最小需求
+==================
+
+引言
+====
+
+本文旨在给出运行当前内核版本所需的最低软件版本列表。
+
+本文最初基于 Linus 为 2.0.x 内核编写的 “Changes” 文件，因此也应将功劳归于
+与该文件相关的同一批人（Jared Mauch、Axel Boldt、Alessandro Sigala，
+以及互联网上无数其他用户）。
+
+当前最低需求
+------------
+
+在认为自己碰到了一个bug之前，请先至少升级到以下软件版本。
+如果你不确定当前运行的版本，建议使用右侧命令进行检查。
+若要列出系统中的程序及其版本，请执行 ``./scripts/ver_linux``
+
+再次提醒，本列表假定你已经能够正常运行一个Linux内核。另外，
+并非所有工具在所有系统上都是必需的；例如，如果你的机器没有任何
+PC Card硬件，那么大概无需关心 pcmciautils。
+
+====================== =============== ========================================
+ 程序 最低版本 版本检查命令
+====================== =============== ========================================
+bash 4.2 bash --version
+bc 1.06.95 bc --version
+bindgen（可选） 0.65.1 bindgen --version
+binutils 2.30 ld -v
+bison 2.0 bison --version
+btrfs-progs 0.18 btrfs --version
+Clang/LLVM（可选） 15.0.0 clang --version
+e2fsprogs 1.41.4 e2fsck -V
+flex 2.5.35 flex --version
+gdb 7.2 gdb --version
+GNU awk（可选） 5.1.0 gawk --version
+GNU C 8.1 gcc --version
+GNU make 4.0 make --version
+GNU tar 1.28 tar --version
+GRUB 0.93 grub --version || grub-install --version
+gtags（可选） 6.6.5 gtags --version
+iptables 1.4.2 iptables -V
+jfsutils 1.1.3 fsck.jfs -V
+kmod 13 kmod -V
+mcelog 0.6 mcelog --version
+mkimage（可选） 2017.01 mkimage --version
+nfs-utils 1.0.5 showmount --version
+openssl & libcrypto 1.0.0 openssl version
+pahole 1.22 pahole --version
+pcmciautils 004 pccardctl -V
+PPP 2.4.0 pppd --version
+procps 3.2.0 ps --version
+Python 3.9.x python3 --version
+quota-tools 3.09 quota -V
+Rust（可选） 1.78.0 rustc --version
+Sphinx\ [#f1]_ 3.4.3 sphinx-build --version
+squashfs-tools 4.0 mksquashfs -version
+udev 081 udevadm --version
+util-linux 2.10o mount --version
+xfsprogs 2.6.0 xfs_db -V
+====================== =============== ========================================
+
+.. [#f1] Sphinx 仅在构建内核文档时需要
+
+内核编译
+--------
+
+GCC
+~~~
+
+gcc 的版本要求可能会因你计算机中CPU的类型不同而有所变化。
+
+Clang/LLVM（可选）
+~~~~~~~~~~~~~~~~~~
+
+clang和LLVM工具的最新正式发行版（依据
+`releases.llvm.org <https://releases.llvm.org>`_）支持用于构建内核。
+较旧版本并不保证可用，我们也可能移除内核中为支持旧版而加入的兼容性处理。
+更多信息请参阅 :ref:`使用 Clang/LLVM 构建 Linux <kbuild_llvm_zh>`。
+
+Rust（可选）
+~~~~~~~~~~~~
+
+需要较新的 Rust 编译器版本。
+
+关于如何满足 Rust 支持的构建需求，请参阅
+Documentation/translations/zh_CN/rust/quick-start.rst。其中，``Makefile`` 目标
+``rustavailable`` 可用于检查 Rust 工具链为何未被检测到。
+
+bindgen（可选）
+~~~~~~~~~~~~~~~
+
+``bindgen`` 用于为内核的 C 侧生成Rust绑定。它依赖 ``libclang``。
+
+Make
+~~~~
+
+要构建内核，你需要 GNU make 4.0 或更高版本。
+
+Bash
+~~~~
+
+内核构建会使用一些 bash 脚本。需要 Bash 4.2 或更新版本。
+
+Binutils
+~~~~~~~~
+
+构建内核需要 Binutils 2.30 或更新版本。
+
+pkg-config
+~~~~~~~~~~
+
+从 Linux 4.18 起，构建系统需要 pkg-config 来检查已安装的 kconfig 工具，并确定用于
+'make {g,x}config' 的标志设置。此前虽然已经在使用 pkg-config，
+但并未进行检查或文档说明。
+
+Flex
+~~~~
+
+自 Linux 4.16 起，构建系统会在构建过程中生成词法分析器。这需要
+flex 2.5.35 或更高版本。
+
+
+Bison
+~~~~~
+
+自 Linux 4.16 起，构建系统会在构建过程中生成语法解析器。这需要 bison 2.0
+或更高版本。
+
+pahole
+~~~~~~
+
+自 Linux 5.2 起，如果选择了 CONFIG_DEBUG_INFO_BTF，构建系统会从 vmlinux 中的
+DWARF 生成 BTF（BPF Type Format），稍后也会为内核模块生成。这需要 pahole
+v1.22 或更高版本。
+
+它可从发行版中的 'dwarves' 或 'pahole' 软件包获得，或从
+https://fedorapeople.org/~acme/dwarves/ 获取。
+
+Perl
+~~~~
+
+要构建内核，你需要 perl 5 以及以下模块：``Getopt::Long``、
+``Getopt::Std``、``File::Basename`` 和 ``File::Find``。
+
+Python
+~~~~~~
+
+若干配置选项需要它：例如 arm/arm64 默认配置、CONFIG_LTO_CLANG、某些
+DRM 可选配置、kernel-doc 工具以及文档构建（Sphinx）等。
+
+BC
+~~
+
+构建 3.10 及以上版本内核时需要 bc。
+
+
+OpenSSL
+~~~~~~~
+
+模块签名和外部证书处理使用OpenSSL程序及其加密库来创建密钥并生成签名。
+
+如果启用了模块签名，那么构建 3.7 及以上版本内核时需要 openssl。构建
+4.3 及以上版本内核时，还需要 openssl 的开发包。
+
+Tar
+~~~
+
+如果你想通过 sysfs 启用对内核头文件的访问（CONFIG_IKHEADERS），则需要 GNU tar。
+
+gtags / GNU GLOBAL（可选）
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+内核构建要求 GNU GLOBAL 版本 6.6.5 或更高，以便通过 ``make gtags``
+生成标签文件。这是因为它使用了 gtags 的 ``-C (--directory)`` 选项。
+
+mkimage
+~~~~~~~
+
+该工具用于构建 Flat Image Tree（FIT），常见于 ARM 平台。该工具可通过
+``u-boot-tools`` 软件包获得，也可以从 U-Boot 源码构建。详见
+https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
+
+GNU AWK
+~~~~~~~
+
+如果你希望内核构建为内建模块生成地址范围数据（CONFIG_BUILTIN_MODULE_RANGES），
+则需要GNU AWK。
+
+系统工具
+--------
+
+架构方面的变化
+~~~~~~~~~~~~~~
+
+DevFS 已被废弃，转而使用 udev
+（https://www.kernel.org/pub/linux/utils/kernel/hotplug/）
+
+现在已经支持 32 位 UID。尽情享用！
+
+Linux 中函数的文档正在转向以内联文档形式存在，即在源码定义附近使用特殊格式的
+注释。这些注释可以与 Documentation/ 目录中的 ReST 文件结合，生成更丰富的文档，
+随后可以再转换为 PostScript、HTML、LaTex、ePUB 和 PDF 文件。若要将 ReST
+格式转换为你所需的格式，需要Sphinx。
+
+Util-linux
+~~~~~~~~~~
+
+较新的 util-linux 版本为更大容量磁盘提供 ``fdisk`` 支持，支持更多的 mount 选项，
+识别更多分区类型，以及其他类似改进。你大概会想升级它。
+
+Ksymoops
+~~~~~~~~
+
+如果发生了最糟糕的情况，内核出现 oops，你可能需要 ksymoops 工具来解码它，
+但在大多数情况下并不需要。通常更推荐在构建内核时启用 ``CONFIG_KALLSYMS``，
+这样可以产生可直接使用的可读转储（而且输出比 ksymoops 更好）。
+如果由于某种原因你的内核不是以 ``CONFIG_KALLSYMS`` 构建的，
+并且你也没有办法重新构建并在启用该选项的情况下重新复现Oops，
+那么你仍然可以使用 ksymoops 对该 Oops 进行解码。
+
+Mkinitrd
+~~~~~~~~
+
+``/lib/modules`` 文件树布局的这些变化同样要求升级 mkinitrd。
+
+E2fsprogs
+~~~~~~~~~
+
+最新版 ``e2fsprogs`` 修复了 fsck 和 debugfs 中的若干bug。显然，升级它是个好主意。
+
+JFSutils
+~~~~~~~~
+
+``jfsutils`` 软件包包含该文件系统的工具。可用工具如下：
+
+ - ``fsck.jfs`` - 启动事务日志重放，并检查和修复 JFS 格式分区。
+ - ``mkfs.jfs`` - 创建 JFS 格式分区。
+ - 该软件包中还提供了其他文件系统工具。
+
+Xfsprogs
+~~~~~~~~
+
+最新版 ``xfsprogs`` 包含 ``mkfs.xfs``、``xfs_db`` 和 ``xfs_repair`` 等
+XFS文件系统工具。它与架构无关，2.0.0 及以上的任何版本都应能与当前版本的
+XFS内核代码正常配合使用（推荐 2.6.0 或更高版本，因为其包含一些重要改进）。
+
+PCMCIAutils
+~~~~~~~~~~~
+
+PCMCIAutils取代了 ``pcmcia-cs``。它会在系统启动时正确设置 PCMCIA插槽；
+如果内核采用模块化并使用了 hotplug 子系统，它还会为16位PCMCIA设备加载相应模块。
+
+Quota-tools
+~~~~~~~~~~~
+
+如果你想使用较新的 version 2 配额格式，就需要支持 32 位 uid 和 gid。
+Quota-tools 3.07 及更新版本提供了该支持。请使用上表中推荐版本或更新版本。
+
+Intel IA32 微码
+~~~~~~~~~~~~~~~
+
+新增了一个驱动，可用于更新 Intel IA32 微码，并以普通（misc）
+字符设备的形式提供访问。如果你没有使用udev，则在使用前可能需要以root身份执行::
+
+ mkdir /dev/cpu
+ mknod /dev/cpu/microcode c 10 184
+ chmod 0644 /dev/cpu/microcode
+
+你可能还会希望获取用户空间的 microcode_ctl 工具来配合使用。
+
+udev
+~~~~
+
+``udev`` 是一个用户空间程序，用于动态填充 ``/dev``，
+仅为实际存在的设备创建设备节点。``udev`` 替代了 devfs 的基本功能，
+同时允许为设备提供持久化命名。
+
+FUSE
+~~~~
+
+需要 libfuse 2.4.0 或更高版本。绝对最低要求是 2.3.0，但 mount 选项
+``direct_io`` 和 ``kernel_cache`` 将无法工作。
+
+网络
+----
+
+通用变化
+~~~~~~~~
+
+如果你有较复杂的网络配置需求，应该考虑使用 ip-route2 中的网络工具。
+
+包过滤 / NAT
+~~~~~~~~~~~~
+
+数据包过滤和 NAT 代码使用的工具与此前的 2.4.x 内核系列相同（iptables）。
+它仍然包含与 2.2.x 风格 ipchains 以及 2.0.x 风格ipfwadm 的向后兼容模块。
+
+PPP
+~~~
+
+PPP 驱动已经过重构，以支持 multilink 并使其能够运行在多种介质层之上。如
+果你使用 PPP，请将 pppd 至少升级到2.4.0。
+
+如果你没有使用 udev，则必须拥有设备文件 /dev/ppp，可以通过以下命令创建::
+
+ mknod /dev/ppp c 108 0
+
+需要以 root 身份执行。
+
+NFS-utils
+~~~~~~~~~
+
+在很早期的内核（2.4 及更早版本）中，nfs 服务器需要知道哪些客户端希望通
+过 NFS 访问文件。这些信息会在客户端挂载文件系统时由 ``mountd`` 提供
+给内核，或者在系统启动时由 ``exportfs`` 提供。exportfs 会从
+``/var/lib/nfs/rmtab`` 中获取活跃客户端信息。
+
+这种方法相当脆弱，因为它依赖于 rmtab 的正确性，而这并不总是容易保证，
+尤其是在尝试实现故障切换时。即便系统运行正常，``rmtab``
+也会积累大量从未被移除的旧条目。
+
+在现代内核中，我们可以选择让内核在收到未知主机请求时通知 mountd，
+再由 mountd 将合适的导出信息提供给内核。这样就不再依赖 ``rmtab``，
+并且内核只需要知道当前活跃的客户端。
+
+要启用这一新功能，你需要在运行 exportfs 或 mountd 之前执行::
+
+ mount -t nfsd nfsd /proc/fs/nfsd
+
+建议尽可能使用防火墙将所有NFS服务与公共互联网隔离。
+
+mcelog
+~~~~~~
+
+在x86内核上，如果启用了 ``CONFIG_X86_MCE``，则需要 mcelog 工具来处理和
+记录机器检查事件。机器检查事件是CPU报告的错误，强烈建议对其进行处理。
+
+内核文档
+--------
+
+Sphinx
+~~~~~~
+
+关于Sphinx需求的详细信息，请参阅
+Documentation/translations/zh_CN/doc-guide/sphinx.rst 中的 :ref:`sphinx_install_zh`。
+
+rustdoc
+~~~~~~~
+
+``rustdoc`` 用于为 Rust 代码生成文档。更多信息请参阅
+Documentation/translations/zh_CN/rust/general-information.rst。
+
+获取更新的软件
+==============
+
+内核编译
+--------
+
+gcc
+~~~
+
+- <ftp://ftp.gnu.org/gnu/gcc/>
+
+Clang/LLVM
+~~~~~~~~~~
+
+- :ref:`获取 LLVM <zh_cn_getting_llvm>`。
+
+Rust
+~~~~
+
+- Documentation/rust/quick-start.rst。
+
+bindgen
+~~~~~~~
+
+- Documentation/rust/quick-start.rst。
+
+Make
+~~~~
+
+- <ftp://ftp.gnu.org/gnu/make/>
+
+Bash
+~~~~
+
+- <ftp://ftp.gnu.org/gnu/bash/>
+
+Binutils
+~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/devel/binutils/>
+
+Flex
+~~~~
+
+- <https://github.com/westes/flex/releases>
+
+Bison
+~~~~~
+
+- <ftp://ftp.gnu.org/gnu/bison/>
+
+OpenSSL
+~~~~~~~
+
+- <https://www.openssl.org/>
+
+系统工具
+--------
+
+Util-linux
+~~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/util-linux/>
+
+Kmod
+~~~~
+
+- <https://www.kernel.org/pub/linux/utils/kernel/kmod/>
+- <https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git>
+
+Ksymoops
+~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/>
+
+Mkinitrd
+~~~~~~~~
+
+- <https://code.launchpad.net/initrd-tools/main>
+
+E2fsprogs
+~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/>
+- <https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/>
+
+JFSutils
+~~~~~~~~
+
+- <https://jfs.sourceforge.net/>
+
+Xfsprogs
+~~~~~~~~
+
+- <https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git>
+- <https://www.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/>
+
+Pcmciautils
+~~~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/kernel/pcmcia/>
+
+Quota-tools
+~~~~~~~~~~~
+
+- <https://sourceforge.net/projects/linuxquota/>
+
+
+Intel P6 微码
+~~~~~~~~~~~~~
+
+- <https://downloadcenter.intel.com/>
+
+udev
+~~~~
+
+- <https://www.freedesktop.org/software/systemd/man/udev.html>
+
+FUSE
+~~~~
+
+- <https://github.com/libfuse/libfuse/releases>
+
+mcelog
+~~~~~~
+
+- <https://www.mcelog.org/>
+
+网络
+----
+
+PPP
+~~~
+
+- <https://download.samba.org/pub/ppp/>
+- <https://git.ozlabs.org/?p=ppp.git>
+- <https://github.com/paulusmack/ppp/>
+
+NFS-utils
+~~~~~~~~~
+
+- <https://sourceforge.net/project/showfiles.php?group_id=14>
+- <https://nfs.sourceforge.net/>
+
+Iptables
+~~~~~~~~
+
+- <https://netfilter.org/projects/iptables/index.html>
+
+Ip-route2
+~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/net/iproute2/>
+
+OProfile
+~~~~~~~~
+
+- <https://oprofile.sf.net/download/>
+
+内核文档
+--------
+
+Sphinx
+~~~~~~
+
+- <https://www.sphinx-doc.org/>
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply related
* [PATCH 1/3] docs/zh_CN: add llvm.rst translation anchor
From: Jiandong Qiu @ 2026-06-19 14:02 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260619140245.1982921-1-qiujiandong1998@gmail.com>
Add the kbuild_llvm_zh label for local cross-references.
Signed-off-by: Jiandong Qiu <qiujiandong1998@gmail.com>
---
process/changes.rst refers to this anchor.
Documentation/translations/zh_CN/kbuild/llvm.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/translations/zh_CN/kbuild/llvm.rst b/Documentation/translations/zh_CN/kbuild/llvm.rst
index f87e0181d8e7..5fdf281a614a 100644
--- a/Documentation/translations/zh_CN/kbuild/llvm.rst
+++ b/Documentation/translations/zh_CN/kbuild/llvm.rst
@@ -5,6 +5,8 @@
:Original: Documentation/kbuild/llvm.rst
:Translator: 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn>
+.. _kbuild_llvm_zh:
+
==========================
使用 Clang/LLVM 构建 Linux
==========================
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply related
* [PATCH 0/3] docs/zh_CN: update translation of doc-guide/sphinx.rst
From: Jiandong Qiu @ 2026-06-19 14:02 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
Hi all,
This is my first time sending patches to the Linux community. I have
been reading the kernel documentation to learn more about Linux, and in
the process I found a few places where I could help improve the zh_CN
translations. Comments and suggestions are welcome.
This series contains three patches, all intended to update the zh_CN
translation of doc-guide/sphinx.rst. That translation appears to have
been out of date for several years. While updating it, I noticed that
sphinx.rst refers to process/changes.rst, which did not yet have a zh_CN
translation, so I added one. During that work, I also noticed that
changes.rst refers to llvm.rst, so I added the missing anchor in the
zh_CN translation of llvm.rst.
Jiandong Qiu (3):
docs/zh_CN: add llvm.rst translation anchor
docs/zh_CN: add process/changes.rst translation
docs/zh_CN: update sphinx.rst translation
.../translations/zh_CN/doc-guide/sphinx.rst | 165 ++++--
.../translations/zh_CN/kbuild/llvm.rst | 2 +
.../translations/zh_CN/process/changes.rst | 530 ++++++++++++++++++
3 files changed, 665 insertions(+), 32 deletions(-)
create mode 100644 Documentation/translations/zh_CN/process/changes.rst
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 12/15] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: Uwe Kleine-König @ 2026-06-19 13:59 UTC (permalink / raw)
To: Selvamani.Rajagopal
Cc: Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, Parthiban Veerasooran, Richard Cochran, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Simon Horman, Jonathan Corbet,
Shuah Khan, netdev, linux-kernel, devicetree, linux-doc,
Jerry Ray
In-Reply-To: <20260614-s2500-mac-phy-support-v5-12-89874b72f725@onsemi.com>
[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]
On Sun, Jun 14, 2026 at 10:00:28AM -0700, Selvamani Rajagopal via B4 Relay wrote:
> +static const struct of_device_id s2500_of_match[] = {
> + { .compatible = "onnn,s2500" },
> + {}
s/{}/{ }/
> +};
> +
> +static const struct spi_device_id s2500_ids[] = {
> + { "s2500" },
> + {}
> +};
Please make this:
static const struct spi_device_id s2500_ids[] = {
{ .name = "s2500" },
{ }
};
> +MODULE_DEVICE_TABLE(spi, s2500_ids);
> +
> +static struct spi_driver s2500_driver = {
> + .driver = {
> + .name = DRV_NAME,
> + .of_match_table = s2500_of_match,
> + },
> + .probe = s2500_probe,
> + .remove = s2500_remove,
> + .id_table = s2500_ids,
Tastes are different, but the idea to align = is usually screwed by
follow up patches. Here it's broken from the start. If you ask me: Use a
single space before each =.
> +};
> +
> +module_spi_driver(s2500_driver);
Usually there is no empty line between the driver struct and the macro
registering it.
> +
> +MODULE_AUTHOR("Piergiorgio Beruto <pier.beruto@onsemi.com>");
> +MODULE_AUTHOR("Selva Rajagopal <selvamani.rajagopal@onsemi.com>");
> +MODULE_DESCRIPTION("onsemi MACPHY ethernet driver");
> +MODULE_LICENSE("GPL");
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Catalin Marinas @ 2026-06-19 13:19 UTC (permalink / raw)
To: Harry Yoo
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <b1502a60-09a1-4699-886b-93d041de7023@kernel.org>
On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
> On 6/12/26 1:44 PM, Dev Jain wrote:
> > Introduce a boot option to tag only at allocation time of the objects. This
> > reduces KASAN MTE overhead, the tradeoff being reduced ability of
> > catching bugs.
>
> I think most of overhead when enabling MTE comes from loading and
> validing tags for every memory access (either in SYNC or ASYNC mode),
> rather than from storing tags.
I guess it depends on the workload. Lots of allocations for short-lived
buffers (e.g. network traffic) may notice the additional tagging more
than the actual tag checking.
Of course, it would be nice to get some numbers from those who have
access to MTE capable hardware.
> > Now, when a memory object will be freed, it will retain the random tag it
> > had at allocation time. This compromises on catching UAF bugs, till the
> > time the object is not reallocated, at which point it will have a new
> > random tag.
> >
> > Hence, not catching "use-after-free-before-reallocation" and not catching
> > "double-free" will be the compromise for reduced KASAN overhead.
>
> I doubt users who care about security enough to enable HW_TAGS KASAN
> are willing to compromise on security just to save a few instructions
> to store tags in the free path.
>
> To me, it looks like too much of a compromise on security for little
> performance gain.
I don't think there's much compromise on security for use-after-free.
The buffer will be re-tagged later so use-after-realloc should be
caught, especially if we ensure that a different tag will be used (I
don't think Dev's patches do this).
Of course, if you want MTE as a debug/bug-finding feature, tagging on
both allocation and freeing is highly recommended. This patchset is
aimed for those wanting to run MTE in production and squeeze a bit more
performance out of it (with the compromise of not detecting
use-after-free, only prevent access after re-allocation).
--
Catalin
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Catalin Marinas @ 2026-06-19 13:04 UTC (permalink / raw)
To: Harry Yoo
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <2a7d21fa-28c1-446c-97f5-2513f29157d3@kernel.org>
On Thu, Jun 18, 2026 at 11:05:43PM +0900, Harry Yoo wrote:
> On 6/18/26 10:35 PM, Harry Yoo wrote:
> > On 6/12/26 1:44 PM, Dev Jain wrote:
> >> Introduce a boot option to tag only at allocation time of the objects. This
> >> reduces KASAN MTE overhead, the tradeoff being reduced ability of
> >> catching bugs.
> >
> > I think most of overhead when enabling MTE comes from loading and
> > validing tags for every memory access (either in SYNC or ASYNC mode),
> > rather than from storing tags.
>
> Is there any reason not to use STGM instead of STG + DC GVA when
> setting/clearing tags for large sizes when we know they are properly
> aligned?
STGM is intended for copying tags when paired with LDGM. Have you seen
hardware where STGM is faster than STG or DC GVA? For properly aligned
buffers, I'd expect DC GVA to behave at least on par with STGM.
--
Catalin
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-19 13:01 UTC (permalink / raw)
To: Conor Dooley
Cc: Janani Sunil, Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260619-bunch-diocese-dd7805cc17ff@spud>
On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > >
> > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > >
> > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > integrated precision reference.
> > > > > > ...
> > > > > > Probably others may comment on that, but...
> > > > > >
> > > > > > This parent node may support device addressing for multi-device support through
> > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > other resources like the toggle pins or reset and enable.
> > > > > >
> > > > > > That way I suppose that an example would look like...
> > > > > > > +
> > > > > > > +patternProperties:
> > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > + type: object
> > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > +
> > > > > > > + properties:
> > > > > > > + reg:
> > > > > > > + description: Channel number.
> > > > > > > + minimum: 0
> > > > > > > + maximum: 15
> > > > > > > +
> > > > > > > + adi,output-range-microvolt:
> > > > > > > + description: |
> > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > + oneOf:
> > > > > > > + - items:
> > > > > > > + - const: 0
> > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > + - items:
> > > > > > > + - const: -5000000
> > > > > > > + - const: 5000000
> > > > > > > + - items:
> > > > > > > + - const: -10000000
> > > > > > > + - const: 10000000
> > > > > > > + - items:
> > > > > > > + - const: -15000000
> > > > > > > + - const: 15000000
> > > > > > > + - items:
> > > > > > > + - const: -20000000
> > > > > > > + - const: 20000000
> > > > > > > +
> > > > > > > + required:
> > > > > > > + - reg
> > > > > > > +
> > > > > > > + additionalProperties: false
> > > > > > > +
> > > > > > > +required:
> > > > > > > + - compatible
> > > > > > > + - reg
> > > > > > > + - vdd-supply
> > > > > > > + - avdd-supply
> > > > > > > + - hvdd-supply
> > > > > > > +
> > > > > > > +dependencies:
> > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > +
> > > > > > > +allOf:
> > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > +
> > > > > > > +unevaluatedProperties: false
> > > > > > > +
> > > > > > > +examples:
> > > > > > > + - |
> > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > +
> > > > > > > + spi {
> > > > > > > + #address-cells = <1>;
> > > > > > > + #size-cells = <0>;
> > > > > > > +
> > > > > > > + dac@0 {
> > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > + reg = <0>;
> > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > +
> > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > +
> > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > +
> > > > > > > + #address-cells = <1>;
> > > > > > > + #size-cells = <0>;
> > > > > > > +
> > > > > > > + channel@0 {
> > > > > > > + reg = <0>;
> > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + channel@1 {
> > > > > > > + reg = <1>;
> > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + channel@2 {
> > > > > > > + reg = <2>;
> > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > + };
> > > > > > > + };
> > > > > > > + };
> > > > > > ...
> > > > > >
> > > > > > spi {
> > > > > > #address-cells = <1>;
> > > > > > #size-cells = <0>;
> > > > > >
> > > > > > multi-dac@0 {
> > > > > > compatible = "adi,ad5529r-16";
> > > > > > reg = <0>;
> > > > > > spi-max-frequency = <25000000>;
> > > > > >
> > > > > > #address-cells = <1>;
> > > > > > #size-cells = <0>;
> > > > > >
> > > > > > dac@0 {
> > > > > > reg = <0>;
> > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > hvss-supply = <&hvss_regulator>;
> > > > > >
> > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > >
> > > > > > #address-cells = <1>;
> > > > > > #size-cells = <0>;
> > > > > >
> > > > > > channel@0 {
> > > > > > reg = <0>;
> > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > };
> > > > > >
> > > > > > channel@1 {
> > > > > > reg = <1>;
> > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > };
> > > > > >
> > > > > > channel@2 {
> > > > > > reg = <2>;
> > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > };
> > > > > > }
> > > > > >
> > > > > > dac@1 {
> > > > > > reg = <1>;
> > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > hvss-supply = <&hvss_regulator>;
> > > > > >
> > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > >
> > > > > > #address-cells = <1>;
> > > > > > #size-cells = <0>;
> > > > > >
> > > > > > channel@0 {
> > > > > > reg = <0>;
> > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > };
> > > > > >
> > > > > > channel@1 {
> > > > > > reg = <1>;
> > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > };
> > > > > > }
> > > > > > };
> > > > > > };
> > > > > >
> > > > > > then you might need something like:
> > > > > >
> > > > > > patternProperties:
> > > > > > "^dac@[0-3]$":
> > > > > >
> > > > > > and put most of the things under this node pattern.
> > > > > >
> > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > >
> > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > Hi Rodrigo,
> > > > >
> > > > > Thank you for looking at this.
> > > > >
> > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > speculatively without a validating use case.
> > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > looking at it another way a kind of distributed SPI mux.
> > > >
> > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > That would leave the path open to supporting the addressing at a later date.
> > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > in all devices in the chain as one big SPI message.
> > > >
> > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > longer term how to support it cleanly in SPI.
> >
> > I'd swear I have seen this before, from some Microchip devices. Let me
> > see if I can find what I am thinking of...
>
>
> microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> slightly different properties.
>
> microchip,device-addr:
> description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> $ref: /schemas/types.yaml#/definitions/uint32
> enum: [0, 1, 2, 3]
> default: 0
>
> and
>
>
> microchip,hw-device-address:
> $ref: /schemas/types.yaml#/definitions/uint32
> minimum: 0
> maximum: 3
> description:
> The address is set on a per-device basis by fuses in the factory,
> configured on request. If not requested, the fuses are set for 0x1.
> The device address is part of the device markings to avoid
> potential confusion. This address is coded on two bits, so four possible
> addresses are available when multiple devices are present on the same
> SPI bus with only one Chip Select line for all devices.
> Each device communication starts by a CS falling edge, followed by the
> clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> which is first one on the wire).
>
> This sounds exactly like the sort of feature that you're dealing with
> here?
>
The core idea yes but for this chip, things are a bit more annoying (but
Janani can correct me if I'm wrong). Here, each device can, in theory,
have it's own supplies, pins and at the very least, channels with maybe
different scales. That is why Janani is proposing dac nodes. Given I
honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
about solving this at the spi level.
Ah and to make it more annoying, we can also mix 12 and 16 bits variants
together in the same bus.
- Nuno Sá
^ permalink raw reply
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: Cristian Marussi @ 2026-06-19 12:51 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Cristian Marussi, Christian Brauner, linux-kernel,
linux-arm-kernel, arm-scmi, linux-fsdevel, linux-doc,
sudeep.holla, james.quinlan, f.fainelli, vincent.guittot,
etienne.carriere, peng.fan, michal.simek, d-gole, jic23,
elif.topuz, lukasz.luba, philip.radford, souvik.chakravarty,
leitao, kas, puranjay, usama.arif, kernel-team
In-Reply-To: <0025b907-27b9-4a51-b78f-f8ad413644d0@kernel.org>
On Fri, Jun 19, 2026 at 12:16:58PM +0200, David Hildenbrand (Arm) wrote:
>
> >> Is the configuration aspect limited to enabling selected events, or is there
> >> more that can be configured?
Hi,
> >>
> >
> > The needed configuration is:
> >
> > - global Telemetry enable (tlm_enable)
> > - global common update_interval (current_update_interval)
>
> Okay, so simple global properties.
>
> > - per-DE enable/disable (des/0x<NNNN>/enable)
> > - per-DE timestamping enable/disable (des/0x<NNNN>/tstamp_enable)
> >
> > ... then there are a couple of handy catch-all entries:
> > all_des_enable, all_des_tstamp_enable
>
> Okay, so fairly trivial configs.
Yes mostly on/off switches or single values config.
> >
> > Note that all the existent DEs are discovered at runtime dynamically via
> > SCMI in the background at init/probe and then never change: i.e.
> > the tree is statically created upon discovery, user cannot
> > create/destroy or symlink files at will, nor the backend platform FW
> > running the SCMI server can pop-up new DataEvents after the initial
> > enumeration.
>
> That makes sense.
>
> >
> > All the above configs can also be pre-defined in the FW (at built time)
> > as being default boot-on with predefined values, like a specific
> > boot-on update interval, so that you could have a system in which really
> > you dont need to configure anything...everything is on and you just
> > read data. (unless you want to change config of course...)
>
> Okay, so the initial value of some parameters might not be "disabled" etc.
Yes at the protocol layer I take care to lookup all of this states at
init so that the initial states are consistent with what exposed...
>
> I guess, from a user space perspective, reading should be allowed by everyone
> but writing should be limited to root?
>
Yes it is currently world readable and only root has write access by default,
BUT in this latest V4 I added (as asked by some internal team) handling of the
usual uid/gid/umask mount options so that a privileged user can change the ownership
policy at mount time. (not supporting anyway FS_USERNS_MOUNT since it does not
make sense to support containers for SCMI Telemetry)
> >
> > There is more stuff that indeed is configurable per the SCMI spec
> > but these additional params are hidden into the SCMI Telemetry protocol
> > layer (the initial patches in this series) and NOT made available to
> > the driver/users of the protocol (like the SCMI FS driver that sits on
> > top)
>
> Do you assume that there will get significantly more config options added in the
> future for user space to configure?
No, I dont think so...the only planned extensions were to support more
performant read access mechanisms, i.e. direct mmap'ability of FW/Kernel
SCMI Telemetry shared memory areas...BUT that will immediately dump all
the bulk of the lower layer protocol work into the tools domain...and
we're not ready to do so...beside having one more thing, the tool, to keep
in sync with possible future spec changes (unless exposing even more stuff
like tlm mem-areas accessors to the UAPI...that would be painful kernel
side and not desired AFAIU...)
>
> >
> > IOW, this humonguos series (~8k lines) is only partially composed by
> > the Filesystem driver (~3k): the bulk of the Telemetry logic and SCMI
> > message exchanges are contained in the SCMI Protocol stack which has
> > been extended to support the Telemerty protocol at first
> > (the 'firmware: arm_scmi:' initial patches).
> >
> > This latter common support is exposed by the SCMI stack for the SCMI
> > drivers to use via custom per-protocol operations (not an orginal name :P)
> > exposed in include/linux/scmi_protocol.h
> >
> > So when you write into FS to configure smth, you end up calling an internal
> > tlm_proto_ops that in turn will cause an SCMI message to be sent
> > (in some cases say to enable a DE or set the update interval)
>
> Makes sense.
>
> >
> > When you read something, you end up calling another Telemetry operation
> > that in turn returns you the DataEvent value you were looking for...how
> > this is retrieved via SCMI in the background is transparent to the
> > FS driver because, again, these details are buried into the protocol
> > layer. Talking about reads, you can:
> >
> > - read a single value from des/0x<NNNN>/value
> > - read ALL the currently enabled DE in a bulk read via des_bulk_read
> >
> > ...most of the other entries in the tree are simply RO properties of the DEs
> > that have been discovered at enumeration time.
>
> Is this bulk-reading relevant for performance or just a "nice to have" ?
>
I suppose depends on your usage pattern: it is definitely relevant
because the main collection mechanism are shared memory areas (SHMTIs)
between the platform firmware and the Kernel: such areas being accessed
from 2 differnt worlds concurrently come with a SCMI-specified
synchro/consistency mechanism based simply on a pair of sequence numbers
placed at the start and at the end of the SHMTI, so that the FW increases
such magic numbers in a well-known way before and after updating the SHMTI
values, so that the kernel can detect (without any interlocking mechanism)
if a platform write happened in the middle of its reads...
...so if you read one single DE 64bit value, under the hood the kernel
would have had to really perform at leats 3 reads from the SHMTI to check
the consistecy of that single read...
... while if you do a bulk_read the overhead due to the consistecy
checks gets 'spread' across a number of DEs because the kernel will snapshot
the whole SHMTIs (potentially KBytes) between the 2 consistency reads
...the good side effect of all of this is that I can leverage such
sequence number to optimize reads..i.e. do NOT even try to read anything
if the new sequnce number is unchanged from the last one I cached on the
last successfull read of this value...
So at the end I would say it is NOT simply a nice to have BUT it is
certainly only the first step towards a more performant alternative access
(like with mmaps)...it depends on the usage pattern...I am not sure what
mechanism is used by our tools more...
>
> >
> > Given that walking a FS tree and issuing configuration as writes is NOT
> > performant really (nor handy if you are not a human), currently, even
> > in this FS-based series you can really perform all of the discovery AND
> > the configuration tasks WITHOUT walking the filesystem tree, but instead
> > issuing a bunch of IOCTLs issued on a special 'control' file that I
> > embedded in the FS. Such UAPI IOCTLs described at:
>
> Makes sense.
>
> >
> > https://lore.kernel.org/arm-scmi/20260612223802.1337232-6-cristian.marussi@arm.com/T/#u
> >
> > So my plan of action in order to get rid of the FS in-kenel implementation
> > would be to drop this Filesystem in favour of simple character devices
> > and move the existent IOCTLs interface (revisited where needed) on top of
> > these devices: that way you will be able to use IOCTLs to enumerate the
> > Telemetry sources and then configure them.
> >
> > Read will then happen (probably) leveraging a number of chardev fops like:
> > IOCTLs, .read and .mmap...up to the tool decide what to use.
> >
> > After this porting to chardev is done, I would start optionally exposing
> > again all of this in a human-readable alternative way by adding a layer
> > of FUSE on top of this chardev interface.
>
> Yes. How high-priority is the fs side? Or would a tool using a library to access
> this information also work in the first step?
>
I have to sync with tools on this...because they are stiil probably
using currently the FS, but it was already planned for the future to move to
a more low level access (ioctl/mmap)...
...my aim would be, at this point, to favour this transition without sudden
breaking their current world (and have to expatriate :P)
..from my personal point of view, I would certainly like to still have the
FUSE layer for ease of testing and verification on my side...but it is just
a nice to have...
> >
> > Basically my aim is to drop the FS implementation from the kernel, as
> > advised, while trying to optionally make it still available via a userspace
> > FUSE implementation...IOW the intention would be for the next V5 to expose
> > the same interfaces as V4 but with the help of a tool instead that builds,
> > if wanted, a FUSE mount built on top of the chardev interface.
[snip]
> >>
> >> It's a good question how that could be done, if you need more information about
> >> these events from user space.
> >
> > I have NOT really delved into that, so as of know we do NOT fed any data
> > to existing Kernel subsystems, not there is any available in-kernel
> > interface to consume DE data (nobody asked), but, I can imagine 2 solution:
> >
> > - our beloved architects decide to 'architect' more DataEvents in the
> > next version of the spec.. i.e. they reserve some specific DE IDs to
> > represent some well defined entity (like it is done already in the spec
> > for a dozen IDs)...this avoids the needs of any new interface all
> > together
>
> That would be the cleanest solution :)
>
Definitely agree.
> >
> > OR
> >
> > - we open some sort of user-->kernel ABI channel 'somewhere' where the
> > userspace tool, interpreting the JSON description, can communicate something
> > like " on this platform ID 1,2,3,4 should be fed to the IIO sensors frmwk
> > too, while ID 39,8,76 can be fed to HWMON..." etc
> >
> >>
> >> [...]
> >>
> >>
> >> That sounds reasonable.
> >>
> >> [...]
> >>
[snip]
> > Regarding the user concurrency, I have already explicitly pushed back on
> > this, our own tools team: any concurrent read or configuration write is
> > allowed and properly handled in a consistent way, BUT on the configuration
> > side the last write/ioctl wins: there is NO in-kernel OR userspace
> > co-ordination provided out of the box: IOW if you use multiple tools
> > concurrently to apply conflicting configurations, it is none of our problem
>
> Would concurrent reading work? I assume so, right?
>
Yes concurrent reading is not a problem, and concurrent writes are
properly handled at the write/message level (i.e. no corruption) BUT
no co-ordination is provided from the kernel on those config writes,
last write wins.
> >
> > ...similarly as if you have an actively running network configuration daemon
> > and you try to set your IP manually...nobody will prevent you from doing this,
> > the same netlink will be used freely by you on the shell and the daemon (if you
> > have enough privilege), but you will gonna have unexpected result...
> >
> > I dont either see the case to enforce exclusive access for Telemetry resources:
> > co-ordination is up to the user in my view...I mean if you have 2 tools
> > configuring concurrently SCMI telemetry in a conflicting way something has been
> > misconfigured somewhere
> >
> > .....having said that, I understand that the concurrency co-ordination
> > issue can be particularly tricky to spot and solve in userspace, so I DO
> > expose a generation counter entry that is updated on any configuration
> > change, so that a userspace app using Telemetry can monitor (poll) this
> > counter to spot if someone else on the system is quietly suddenly applying
> > configuration changes...
>
> Okay, so a single writer (admin) changing stuff could get picked up my possibly
> many concurrent readers?
Mmm...not sure what you mean here...
If you configure your Telemetry as you desire and start collecting data via
readers, BUT then some other process changes configs under your belt, that is
allowed as said, and so your analisys could be impacted...(something turned off
as an example, or update interval changed)...
...so while this is NOT regulated/co-ordinated by the Kernel, in order to
ease the detection of such events by your reading process, I provide a pollable
entry that returns an integer and then blocks until such counter is next updated
by an intervening under-the-hood configuration change...so you can configure,
monitor the generatin counter and then starts reading you data, sure that you
will detect any conflicting re-config issued by a rougue process...
(and I have to still extend this event polling mechanism to use a user
provided eventfd...since it was NOT strictly needed...but now with
IOCTLs interface I will add that too...)
>
> >
> >>>
> >>> Should/could such a tool live in the kernel tree (tools/) at least for
> >>> ease of development/deployment ?
> >>
> >> I think OOT.
> >>
> >
> > Ok.
> >
> > Sorry for the long email..I hope I have clarified the situation, anyway
> > I am already moving to get rid of the in-kernel interface as advised in
> > favour of a chardev kernel interface and an optional FUSE based FS...
>
> Yes, thank you a lot, I hope it also helps Christian to help push this into the
> right direction!
>
Thanks a lot, David !
Cristian
^ permalink raw reply
* Re: [PATCH v8 05/46] KVM: Make CONFIG_KVM_VM_MEMORY_ATTRIBUTES selectable
From: Julian Braha @ 2026-06-19 12:51 UTC (permalink / raw)
To: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, jmattson, jthoughton, michael.roth, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
tabba, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Baoquan He, Jason Gunthorpe, Vlastimil Babka
Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260618-gmem-inplace-conversion-v8-5-9d2959357853@google.com>
Hi Ackerley,
On 6/19/26 01:31, Ackerley Tng via B4 Relay wrote:
> config KVM_VM_MEMORY_ATTRIBUTES
> - bool
> + depends on KVM_SW_PROTECTED_VM || KVM_INTEL_TDX || KVM_AMD_SEV
> + bool "Enable per-VM PRIVATE vs. SHARED attributes (for CoCo VMs)"
Sorry for the style nitpick, but could you keep the type and prompt as
the first attribute in the Kconfig option definition (like the other
options do)?
- Julian Braha
^ permalink raw reply
* Re: [PATCH v8 00/46] guest_memfd: In-place conversion support
From: Garg, Shivank @ 2026-06-19 12:28 UTC (permalink / raw)
To: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, jmattson, jthoughton, michael.roth, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, steven.price, tabba, willy,
wyihan, yan.y.zhao, forkloop, pratyush, suzuki.poulose,
aneesh.kumar, liam, Paolo Bonzini, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
Baoquan He, Jason Gunthorpe, Vlastimil Babka
Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260618-gmem-inplace-conversion-v8-0-9d2959357853@google.com>
On 6/19/2026 6:01 AM, Ackerley Tng via B4 Relay wrote:
> This is v8 of guest_memfd in-place conversion support.
>
> Up till now, guest_memfd supports the entire inode worth of memory being
> used as all-shared, or all-private. CoCo VMs may request guest memory to be
> converted between private and shared states, and the only way to support
> that currently would be to have the userspace VMM provide two sources of
> backing memory from completely different areas of physical memory.
>
> pKVM has a use case for in-place sharing: the guest and host may be
> cooperating on given data, and pKVM doesn't protect data through
> encryption, so copying that given data between different areas of physical
> memory as part of conversions would be unnecessary work.
>
> This series also serves as a foundation for guest_memfd huge page
> support. Now, guest_memfd only supports PAGE_SIZE pages, so if two sources
> of backing memory are used, the userspace VMM could maintain a steady total
> memory utilized by punching out the pages that are not used. When huge
> pages are available in guest_memfd, even if the backing memory source
> supports hole punching within a huge page, punching out pages to maintain
> the total memory utilized by a VM would be introducing lots of
> fragmentation.
>
> In-place conversion avoids fragmentation by allowing the same physical
> memory to be used for both shared and private memory, with guest_memfd
> tracks the shared/private status of all the pages at a per-page
> granularity.
>
> The central principle, which guest_memfd continues to uphold, is that any
> guest-private page will not be mappable to host userspace. All pages will
> be mmap()-able in host userspace, but accesses to guest-private pages (as
> tracked by guest_memfd) will result in a SIGBUS.
>
> This series introduces a guest_memfd ioctl (not kvm, vm or vcpu, but
> guest_memfd ioctl) that allows userspace to set memory
> attributes (shared/private) directly through the guest_memfd. This is the
> appropriate interface because shared/private-ness is a property of memory
> and hence the request should be sent directly to the memory provider -
> guest_memfd.
>
> Tested with both CONFIG_KVM_VM_MEMORY_ATTRIBUTES enabled and disabled:
>
> + tools/testing/selftests/kvm/guest_memfd_test.c
> + tools/testing/selftests/kvm/pre_fault_memory_test.c
> + tools/testing/selftests/kvm/x86/guest_memfd_conversions_test.c
> + tools/testing/selftests/kvm/x86/private_mem_conversions_test.c
> + tools/testing/selftests/kvm/x86/private_mem_kvm_exits_test.c
>
> Updates for this revision:
>
> + Updated the series to _not_ deprecate all of VM memory attributes, but
> only deprecate tracking of the PRIVATE attributes in VM memory
> attributes. This takes into account upcoming RWX attributes support,
> which will be tracked at the VM level.
> + Reshuffled the earlier commits that deal with preparing KVM to stop
> seeing VM memory attributes as the only source of attributes.
> + Addressed comments from v7
>
> TODOs
>
> + Retest with TDX selftests. v7 was tested with TDX [12], but the setup there was
> wrong. Conversions were successful (no errors), but the shared memory being
> tested is actually in a completely different host physical page.
> + Retest with SNP selftests. v6 was tested with SNP, I ported that to v7
> and those ran fine too. Just need to double-check for v8.
>
> This series is based on kvm-x86/next, and here's the tree for your convenience:
>
> https://github.com/googleprodkernel/linux-cc/commits/guest_memfd-inplace-conversion-v8
>
> Older series:
>
> + RFCv7 is at [11]
> + RFCv6 is at [10]
> + RFCv5 is at [8]
> + RFCv4 is at [7]
> + RFCv3 is at [6]
> + RFCv2 is at [5]
> + RFCv1 is at [4]
> + Previous versions of this feature, part of other series, are available at
> [1][2][3].
>
> [1] https://lore.kernel.org/all/bd163de3118b626d1005aa88e71ef2fb72f0be0f.1726009989.git.ackerleytng@google.com/
> [2] https://lore.kernel.org/all/20250117163001.2326672-6-tabba@google.com/
> [3] https://lore.kernel.org/all/b784326e9ccae6a08388f1bf39db70a2204bdc51.1747264138.git.ackerleytng@google.com/
> [4] https://lore.kernel.org/all/cover.1760731772.git.ackerleytng@google.com/T/
> [5] https://lore.kernel.org/all/cover.1770071243.git.ackerleytng@google.com/T/
> [6] https://lore.kernel.org/r/20260313-gmem-inplace-conversion-v3-0-5fc12a70ec89@google.com/T/
> [7] https://lore.kernel.org/all/20260326-gmem-inplace-conversion-v4-0-e202fe950ffd@google.com/T/
> [8] https://lore.kernel.org/r/20260428-gmem-inplace-conversion-v5-0-d8608ccfca22@google.com
> [9] https://lore.kernel.org/all/20260414-selftest-global-metadata-v1-0-fd223922bc57@google.com/T/
> [10] https://lore.kernel.org/r/20260507-gmem-inplace-conversion-v6-0-91ab5a8b19a4@google.com
> [11] https://lore.kernel.org/r/20260522-gmem-inplace-conversion-v7-0-2f0fae496530@google.com
> [12] https://lore.kernel.org/all/20260605134153.204152-1-ackerleytng@google.com/
>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
> Ackerley Tng (27):
> KVM: Make CONFIG_KVM_VM_MEMORY_ATTRIBUTES selectable
> KVM: Enumerate support for PRIVATE memory iff kvm_arch_has_private_mem is defined
> KVM: guest_memfd: Introduce function to check GFN private/shared status
> KVM: guest_memfd: Only prepare folios for private pages
> KVM: guest_memfd: Add base support for KVM_SET_MEMORY_ATTRIBUTES2
> KVM: guest_memfd: Ensure pages are not in use before conversion
> KVM: guest_memfd: Call arch invalidate hooks on conversion
> KVM: guest_memfd: Return early if range already has requested attributes
> KVM: guest_memfd: Advertise KVM_SET_MEMORY_ATTRIBUTES2 ioctl
> KVM: guest_memfd: Handle lru_add fbatch refcounts during conversion safety check
> KVM: guest_memfd: Use actual size for invalidation in kvm_gmem_release()
> KVM: guest_memfd: Determine invalidation filter from memory attributes
> KVM: guest_memfd: Zero page while getting pfn
> KVM: TDX: Make source page optional for KVM_TDX_INIT_MEM_REGION
> KVM: guest_memfd: Make in-place conversion the default
> KVM: selftests: Test basic single-page conversion flow
> KVM: selftests: Test conversion flow when INIT_SHARED
> KVM: selftests: Test conversion precision in guest_memfd
> KVM: selftests: Test conversion before allocation
> KVM: selftests: Convert with allocated folios in different layouts
> KVM: selftests: Test that truncation does not change shared/private status
> KVM: selftests: Add helpers to pin pages with CONFIG_GUP_TEST
> KVM: selftests: Test conversion with elevated page refcount
> KVM: selftests: Reset shared memory after hole-punching
> KVM: selftests: Provide function to look up guest_memfd details from gpa
> KVM: selftests: Make TEST_EXPECT_SIGBUS thread-safe
> KVM: selftests: Update private_mem_conversions_test to mmap() guest_memfd
>
> Michael Roth (1):
> KVM: SEV: Make 'uaddr' parameter optional for KVM_SEV_SNP_LAUNCH_UPDATE
>
> Sean Christopherson (18):
> KVM: guest_memfd: Introduce per-gmem attributes, use to guard user mappings
> KVM: Rename KVM_GENERIC_MEMORY_ATTRIBUTES to KVM_VM_MEMORY_ATTRIBUTES
> KVM: Move KVM_VM_MEMORY_ATTRIBUTES config definition to x86
> KVM: Decouple kvm_has_arch_private_mem from CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> KVM: Rename memory attribute APIs to prepare for in-place gmem conversion
> KVM: Provide generic interface for checking memory private/shared status
> KVM: guest_memfd: Wire up core private/shared attribute interfaces
> KVM: Consolidate private memory and guest_memfd ifdeffery in kvm_host.h
> KVM: guest_memfd: Enable INIT_SHARED on guest_memfd for x86 Coco VMs
> KVM: selftests: Create gmem fd before "regular" fd when adding memslot
> KVM: selftests: Rename guest_memfd{,_offset} to gmem_{fd,offset}
> KVM: selftests: Add support for mmap() on guest_memfd in core library
> KVM: selftests: Add selftests global for guest memory attributes capability
> KVM: selftests: Add helpers for calling ioctls on guest_memfd
> KVM: selftests: Test that shared/private status is consistent across processes
> KVM: selftests: Provide common function to set memory attributes
> KVM: selftests: Check fd/flags provided to mmap() when setting up memslot
> KVM: selftests: Update private memory exits test to work with per-gmem attributes
>
Hi,
Thanks for this series.
This works well for me on AMD EPYC 7713 (SEV-SNP enabled). I tested:
1. KVM selftests: all tests pass.
2. Using in-place conversion QEMU branch [1]:
qemu-system-x86_64 \
-machine q35,confidential-guest-support=sev0 \
-enable-kvm -cpu EPYC-v4 -smp 8,maxcpus=8 -m 120G -no-reboot \
-object memory-backend-guest-memfd,id=ram0,size=60G,share=on,host-nodes=0-1,policy=interleave \
-object memory-backend-guest-memfd,id=ram1,size=60G,share=on,host-nodes=0,policy=bind \
-numa node,nodeid=0,memdev=ram0,cpus=0-3 \
-numa node,nodeid=1,memdev=ram1,cpus=4-7 \
-object sev-snp-guest,id=sev0,policy=0x30000,cbitpos=51,reduced-phys-bits=1,convert-in-place=on \
-bios "$OVMF" \
-drive file="$DISK",if=none,id=disk0,format=qcow2 \
-device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 \
-netdev user,id=net0,hostfwd=tcp::8000-:22 -device virtio-net-pci,netdev=net0 \
-kernel "$KERNEL" -initrd "$INITRD" \
-append "$ROOT ro console=ttyS0,115200" \
-trace enable=kvm_convert_memory,file=/tmp/convert.log \
-nographic -serial mon:stdio
The guest boots successfully and run memory hogger. With this, I verified the
shared <-> private conversion logs (trace_kvm_convert_memory).
3. Additionally, verified the NUMA placement for SEV-SNP. With this series,
NUMA mempolicy support for guest_memfd [2] now works for SEV-SNP as well.
[1] https://github.com/amdese/qemu/commits/snp-inplace-rfc1
[2] https://lore.kernel.org/kvm/20251016172853.52451-1-seanjc@google.com
Tested-by: Shivank Garg <shivankg@amd.com>
Best regards,
Shivank
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-19 11:40 UTC (permalink / raw)
To: Janani Sunil
Cc: Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260619-obstinate-polo-a230bef97fda@spud>
[-- Attachment #1: Type: text/plain, Size: 10234 bytes --]
On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> >
> > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > >
> > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > integrated precision reference.
> > > > > ...
> > > > > Probably others may comment on that, but...
> > > > >
> > > > > This parent node may support device addressing for multi-device support through
> > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > other resources like the toggle pins or reset and enable.
> > > > >
> > > > > That way I suppose that an example would look like...
> > > > > > +
> > > > > > +patternProperties:
> > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > + type: object
> > > > > > + description: Child nodes for individual channel configuration
> > > > > > +
> > > > > > + properties:
> > > > > > + reg:
> > > > > > + description: Channel number.
> > > > > > + minimum: 0
> > > > > > + maximum: 15
> > > > > > +
> > > > > > + adi,output-range-microvolt:
> > > > > > + description: |
> > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > + oneOf:
> > > > > > + - items:
> > > > > > + - const: 0
> > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > + - items:
> > > > > > + - const: -5000000
> > > > > > + - const: 5000000
> > > > > > + - items:
> > > > > > + - const: -10000000
> > > > > > + - const: 10000000
> > > > > > + - items:
> > > > > > + - const: -15000000
> > > > > > + - const: 15000000
> > > > > > + - items:
> > > > > > + - const: -20000000
> > > > > > + - const: 20000000
> > > > > > +
> > > > > > + required:
> > > > > > + - reg
> > > > > > +
> > > > > > + additionalProperties: false
> > > > > > +
> > > > > > +required:
> > > > > > + - compatible
> > > > > > + - reg
> > > > > > + - vdd-supply
> > > > > > + - avdd-supply
> > > > > > + - hvdd-supply
> > > > > > +
> > > > > > +dependencies:
> > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > +
> > > > > > +allOf:
> > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > +
> > > > > > +unevaluatedProperties: false
> > > > > > +
> > > > > > +examples:
> > > > > > + - |
> > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > +
> > > > > > + spi {
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + dac@0 {
> > > > > > + compatible = "adi,ad5529r-16";
> > > > > > + reg = <0>;
> > > > > > + spi-max-frequency = <25000000>;
> > > > > > +
> > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > +
> > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > +
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + channel@0 {
> > > > > > + reg = <0>;
> > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > + };
> > > > > > +
> > > > > > + channel@1 {
> > > > > > + reg = <1>;
> > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > + };
> > > > > > +
> > > > > > + channel@2 {
> > > > > > + reg = <2>;
> > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > + };
> > > > > > + };
> > > > > > + };
> > > > > ...
> > > > >
> > > > > spi {
> > > > > #address-cells = <1>;
> > > > > #size-cells = <0>;
> > > > >
> > > > > multi-dac@0 {
> > > > > compatible = "adi,ad5529r-16";
> > > > > reg = <0>;
> > > > > spi-max-frequency = <25000000>;
> > > > >
> > > > > #address-cells = <1>;
> > > > > #size-cells = <0>;
> > > > >
> > > > > dac@0 {
> > > > > reg = <0>;
> > > > > vdd-supply = <&vdd_regulator>;
> > > > > avdd-supply = <&avdd_regulator>;
> > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > hvss-supply = <&hvss_regulator>;
> > > > >
> > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > >
> > > > > #address-cells = <1>;
> > > > > #size-cells = <0>;
> > > > >
> > > > > channel@0 {
> > > > > reg = <0>;
> > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > };
> > > > >
> > > > > channel@1 {
> > > > > reg = <1>;
> > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > };
> > > > >
> > > > > channel@2 {
> > > > > reg = <2>;
> > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > };
> > > > > }
> > > > >
> > > > > dac@1 {
> > > > > reg = <1>;
> > > > > vdd-supply = <&vdd_regulator>;
> > > > > avdd-supply = <&avdd_regulator>;
> > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > hvss-supply = <&hvss_regulator>;
> > > > >
> > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > >
> > > > > #address-cells = <1>;
> > > > > #size-cells = <0>;
> > > > >
> > > > > channel@0 {
> > > > > reg = <0>;
> > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > };
> > > > >
> > > > > channel@1 {
> > > > > reg = <1>;
> > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > };
> > > > > }
> > > > > };
> > > > > };
> > > > >
> > > > > then you might need something like:
> > > > >
> > > > > patternProperties:
> > > > > "^dac@[0-3]$":
> > > > >
> > > > > and put most of the things under this node pattern.
> > > > >
> > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > >
> > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > Hi Rodrigo,
> > > >
> > > > Thank you for looking at this.
> > > >
> > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > speculatively without a validating use case.
> > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > looking at it another way a kind of distributed SPI mux.
> > >
> > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > That would leave the path open to supporting the addressing at a later date.
> > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > in all devices in the chain as one big SPI message.
> > >
> > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > longer term how to support it cleanly in SPI.
>
> I'd swear I have seen this before, from some Microchip devices. Let me
> see if I can find what I am thinking of...
microchip,mcp3911 and microchip,mcp3564 both seem to do this with
slightly different properties.
microchip,device-addr:
description: Device address when multiple MCP3911 chips are present on the same SPI bus.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
and
microchip,hw-device-address:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
description:
The address is set on a per-device basis by fuses in the factory,
configured on request. If not requested, the fuses are set for 0x1.
The device address is part of the device markings to avoid
potential confusion. This address is coded on two bits, so four possible
addresses are available when multiple devices are present on the same
SPI bus with only one Chip Select line for all devices.
Each device communication starts by a CS falling edge, followed by the
clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
which is first one on the wire).
This sounds exactly like the sort of feature that you're dealing with
here?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox