* Re: [PATCH 12/15] accel/qda: Add FastRPC invocation support
From: Ekansh Gupta @ 2026-06-04 5:09 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <43a7laqb7mnrvleunnmbxwhvzr6w3au4ofjri4r4ap7clsx6mc@jxqlr4a2lw56>
On 20-05-2026 19:26, Dmitry Baryshkov wrote:
> On Tue, May 19, 2026 at 11:46:02AM +0530, Ekansh Gupta via B4 Relay wrote:
>> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>>
>> Implement the FastRPC remote procedure call path, allowing user-space
>> to invoke methods on the DSP via DRM_IOCTL_QDA_REMOTE_INVOKE.
>>
>> qda_fastrpc.c / qda_fastrpc.h
>> Implements the FastRPC protocol layer: argument marshalling
>> (qda_fastrpc_invoke_pack), response unmarshalling
>> (qda_fastrpc_invoke_unpack), and invocation context lifecycle
>> management. Each invocation allocates a fastrpc_invoke_context
>> which tracks buffer descriptors, GEM objects, and the completion
>> used to synchronise with the DSP response.
>>
>> Buffer arguments are handled in three ways:
>> - DMA-BUF fd: imported via PRIME, IOMMU-mapped dma_addr used
>> - Direct (inline): copied into the GEM-backed message buffer
>> - DMA handle: fd forwarded to DSP, physical page descriptor computed
>
> No. This needs to go away. The QDA should support only one way to pass
> data - via the GEM buffers. Everything else should be handled by the
> shim layer, etc.
each FD passed here is a GEM buffer. The reason to pass fd is that there
are some APIs on DSP side which takes fd as an argument and the user
might use the same on their skel implementation. So in this case the
remote call will take fd to DSP and the skel implementation will use the
FD.>
>>
>> qda_rpmsg.c
>> Implements qda_rpmsg_send_msg() which sends the wire-format
>> fastrpc_msg (embedded as the first member of qda_msg) directly
>> via rpmsg_send(), and qda_rpmsg_wait_for_rsp() which blocks on
>> the context completion. The RPMsg callback dispatches responses
>> to waiting contexts via the ctx_xa XArray.
>>
>> qda_ioctl.c
>> qda_ioctl_invoke() drives the full invocation lifecycle:
>> allocate context → assign XArray ID → prepare args → allocate
>> GEM message buffer → pack → send → wait → unpack → free.
>>
>> qda_drv.h / qda_drv.c
>> qda_dev gains ctx_xa (XArray for in-flight context lookup) and
>> remote_session_id_counter (atomic counter for session IDs).
>> qda_file_priv gains remote_session_id for per-session tracking.
>>
>> include/uapi/drm/qda_accel.h
>> Adds DRM_IOCTL_QDA_REMOTE_INVOKE (command 0x07; command numbers
>> 0x03–0x06 are reserved) and the associated drm_qda_invoke_args
>> and drm_qda_fastrpc_invoke_args structures.
>>
>> Assisted-by: Claude:claude-4-6-sonnet
>> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>> ---
>> drivers/accel/qda/Makefile | 1 +
>> drivers/accel/qda/qda_drv.c | 17 ++
>> drivers/accel/qda/qda_drv.h | 8 +
>> drivers/accel/qda/qda_fastrpc.c | 597 ++++++++++++++++++++++++++++++++++++++++
>> drivers/accel/qda/qda_fastrpc.h | 271 ++++++++++++++++++
>> drivers/accel/qda/qda_ioctl.c | 104 +++++++
>> drivers/accel/qda/qda_ioctl.h | 1 +
>> drivers/accel/qda/qda_rpmsg.c | 136 ++++++++-
>> drivers/accel/qda/qda_rpmsg.h | 17 ++
>> include/uapi/drm/qda_accel.h | 39 +++
>> 10 files changed, 1189 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/accel/qda/Makefile b/drivers/accel/qda/Makefile
>> index fb092e56d7f3..2d10420cd1ec 100644
>> --- a/drivers/accel/qda/Makefile
>> +++ b/drivers/accel/qda/Makefile
>> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_ACCEL_QDA) := qda.o
>> qda-y := \
>> qda_cb.o \
>> qda_drv.o \
>> + qda_fastrpc.o \
>> qda_gem.o \
>> qda_ioctl.o \
>> qda_memory_dma.o \
>> diff --git a/drivers/accel/qda/qda_drv.c b/drivers/accel/qda/qda_drv.c
>> index ef8bd573b836..704c7d3127d2 100644
>> --- a/drivers/accel/qda/qda_drv.c
>> +++ b/drivers/accel/qda/qda_drv.c
>> @@ -26,6 +26,8 @@ static int qda_open(struct drm_device *dev, struct drm_file *file)
>>
>> qda_file_priv->pid = current->pid;
>> qda_file_priv->qda_dev = qda_dev_from_drm(dev);
>> + qda_file_priv->remote_session_id =
>> + atomic_inc_return(&qda_file_priv->qda_dev->remote_session_id_counter);
>> file->driver_priv = qda_file_priv;
>>
>> return 0;
>> @@ -57,6 +59,7 @@ static const struct drm_ioctl_desc qda_ioctls[] = {
>> DRM_IOCTL_DEF_DRV(QDA_QUERY, qda_ioctl_query, 0),
>> DRM_IOCTL_DEF_DRV(QDA_GEM_CREATE, qda_ioctl_gem_create, 0),
>> DRM_IOCTL_DEF_DRV(QDA_GEM_MMAP_OFFSET, qda_ioctl_gem_mmap_offset, 0),
>> + DRM_IOCTL_DEF_DRV(QDA_REMOTE_INVOKE, qda_ioctl_invoke, 0),
>> };
>>
>> static const struct drm_driver qda_drm_driver = {
>> @@ -93,6 +96,17 @@ static void cleanup_memory_manager(struct qda_dev *qdev)
>> }
>> }
>>
>> +static void cleanup_device_resources(struct qda_dev *qdev)
>> +{
>> + xa_destroy(&qdev->ctx_xa);
>> +}
>> +
>> +static void init_device_resources(struct qda_dev *qdev)
>> +{
>> + atomic_set(&qdev->remote_session_id_counter, 0);
>> + xa_init_flags(&qdev->ctx_xa, XA_FLAGS_ALLOC1);
>> +}
>> +
>> static int init_memory_manager(struct qda_dev *qdev)
>> {
>> qdev->iommu_mgr = kzalloc_obj(*qdev->iommu_mgr);
>> @@ -106,6 +120,7 @@ void qda_deinit_device(struct qda_dev *qdev)
>> {
>> mutex_destroy(&qdev->import_lock);
>> cleanup_memory_manager(qdev);
>> + cleanup_device_resources(qdev);
>> }
>>
>> int qda_init_device(struct qda_dev *qdev)
>> @@ -114,10 +129,12 @@ int qda_init_device(struct qda_dev *qdev)
>>
>> mutex_init(&qdev->import_lock);
>> qdev->current_import_file_priv = NULL;
>> + init_device_resources(qdev);
>>
>> ret = init_memory_manager(qdev);
>> if (ret) {
>> drm_err(&qdev->drm_dev, "Failed to initialize memory manager: %d\n", ret);
>> + cleanup_device_resources(qdev);
>> mutex_destroy(&qdev->import_lock);
>> }
>>
>> diff --git a/drivers/accel/qda/qda_drv.h b/drivers/accel/qda/qda_drv.h
>> index 96ce4135e2d9..420cccff42bf 100644
>> --- a/drivers/accel/qda/qda_drv.h
>> +++ b/drivers/accel/qda/qda_drv.h
>> @@ -6,10 +6,12 @@
>> #ifndef __QDA_DRV_H__
>> #define __QDA_DRV_H__
>>
>> +#include <linux/atomic.h>
>> #include <linux/device.h>
>> #include <linux/list.h>
>> #include <linux/rpmsg.h>
>> #include <linux/types.h>
>> +#include <linux/xarray.h>
>> #include <drm/drm_device.h>
>> #include <drm/drm_drv.h>
>> #include <drm/drm_file.h>
>> @@ -28,6 +30,8 @@ struct qda_file_priv {
>> struct qda_iommu_device *assigned_iommu_dev;
>> /** @pid: Process ID for tracking */
>> pid_t pid;
>> + /** @remote_session_id: Unique session identifier */
>> + u32 remote_session_id;
>> };
>>
>> /**
>> @@ -51,8 +55,12 @@ struct qda_dev {
>> struct mutex import_lock;
>> /** @current_import_file_priv: Current file_priv during prime import */
>> struct drm_file *current_import_file_priv;
>> + /** @ctx_xa: XArray for FastRPC context management */
>> + struct xarray ctx_xa;
>> /** @dsp_name: Name of the DSP domain (e.g. "cdsp", "adsp") */
>> const char *dsp_name;
>> + /** @remote_session_id_counter: Atomic counter for unique session IDs */
>> + atomic_t remote_session_id_counter;
>> };
>>
>> /**
>> diff --git a/drivers/accel/qda/qda_fastrpc.c b/drivers/accel/qda/qda_fastrpc.c
>> new file mode 100644
>> index 000000000000..0ec37175a098
>> --- /dev/null
>> +++ b/drivers/accel/qda/qda_fastrpc.c
>> @@ -0,0 +1,597 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> +#include <linux/slab.h>
>> +#include <linux/uaccess.h>
>> +#include <linux/sort.h>
>> +#include <linux/completion.h>
>> +#include <linux/dma-buf.h>
>> +#include <drm/drm_gem.h>
>> +#include "qda_fastrpc.h"
>> +#include "qda_drv.h"
>> +#include "qda_gem.h"
>> +#include "qda_memory_manager.h"
>> +#include "qda_prime.h"
>> +
>> +/**
>> + * get_gem_obj_from_dmabuf_fd() - Import a DMA-BUF fd and return the GEM object
>> + * @ctx: FastRPC invocation context
>> + * @dmabuf_fd: DMA-BUF file descriptor supplied by user space
>> + * @gem_obj: Output GEM object (caller must call drm_gem_object_put() when done)
>> + *
>> + * Imports the DMA-BUF fd into the QDA device via qda_prime_fd_to_handle()
>> + * (which performs IOMMU device assignment for newly imported buffers) and
>> + * then looks up the resulting GEM object. The caller is responsible for
>> + * calling drm_gem_object_put() on the returned object.
>> + *
>> + * Return: 0 on success, negative error code on failure
>> + */
>> +static int get_gem_obj_from_dmabuf_fd(struct fastrpc_invoke_context *ctx,
>> + int dmabuf_fd,
>> + struct drm_gem_object **gem_obj)
>> +{
>> + struct drm_device *dev = ctx->file_priv->minor->dev;
>> + u32 handle;
>> + int ret;
>> +
>> + ret = qda_prime_fd_to_handle(dev, ctx->file_priv, dmabuf_fd, &handle);
>> + if (ret)
>> + return ret;
>> +
>> + *gem_obj = drm_gem_object_lookup(ctx->file_priv, handle);
>> + if (!*gem_obj)
>> + return -ENOENT;
>> +
>> + return 0;
>> +}
>> +
>> +static void setup_pages_from_gem_obj(struct qda_gem_obj *qda_gem_obj,
>> + struct fastrpc_phy_page *pages)
>> +{
>> + pages->addr = qda_gem_obj->dma_addr;
>> + pages->size = qda_gem_obj->size;
>> +}
>> +
>> +static u64 calculate_vma_offset(u64 user_ptr)
>> +{
>> + struct vm_area_struct *vma;
>> + u64 user_ptr_page_mask = user_ptr & PAGE_MASK;
>> + u64 vma_offset = 0;
>> +
>> + mmap_read_lock(current->mm);
>> + vma = find_vma(current->mm, user_ptr);
>> + if (vma)
>> + vma_offset = user_ptr_page_mask - vma->vm_start;
>> + mmap_read_unlock(current->mm);
>> +
>> + return vma_offset;
>> +}
>> +
>> +static u64 calculate_page_aligned_size(u64 ptr, u64 len)
>> +{
>> + u64 pg_start = (ptr & PAGE_MASK) >> PAGE_SHIFT;
>> + u64 pg_end = ((ptr + len - 1) & PAGE_MASK) >> PAGE_SHIFT;
>> + u64 aligned_size = (pg_end - pg_start + 1) * PAGE_SIZE;
>> +
>> + return aligned_size;
>> +}
>> +
>> +static struct fastrpc_invoke_buf *fastrpc_invoke_buf_start(union fastrpc_remote_arg *pra, int len)
>> +{
>> + return (struct fastrpc_invoke_buf *)(&pra[len]);
>> +}
>> +
>> +static struct fastrpc_phy_page *fastrpc_phy_page_start(struct fastrpc_invoke_buf *buf, int len)
>> +{
>> + return (struct fastrpc_phy_page *)(&buf[len]);
>> +}
>> +
>> +static int fastrpc_get_meta_size(struct fastrpc_invoke_context *ctx)
>> +{
>> + int size = 0;
>> +
>> + size = (sizeof(struct fastrpc_remote_buf) +
>> + sizeof(struct fastrpc_invoke_buf) +
>> + sizeof(struct fastrpc_phy_page)) * ctx->nscalars +
>> + sizeof(u64) * FASTRPC_MAX_FDLIST +
>> + sizeof(u32) * FASTRPC_MAX_CRCLIST;
>> +
>> + return size;
>> +}
>> +
>> +static u64 fastrpc_get_payload_size(struct fastrpc_invoke_context *ctx, int metalen)
>> +{
>> + u64 size = 0;
>> + int oix;
>> +
>> + size = ALIGN(metalen, FASTRPC_ALIGN);
>> +
>> + for (oix = 0; oix < ctx->nbufs; oix++) {
>> + int i = ctx->olaps[oix].raix;
>> +
>> + if (ctx->args[i].fd == 0 || ctx->args[i].fd == -1) {
>> + if (ctx->olaps[oix].offset == 0)
>> + size = ALIGN(size, FASTRPC_ALIGN);
>> +
>> + size += (ctx->olaps[oix].mend - ctx->olaps[oix].mstart);
>> + }
>> + }
>> +
>> + return size;
>> +}
>> +
>> +/**
>> + * qda_fastrpc_context_free() - Free an invocation context
>> + * @ref: Reference counter embedded in the context
>> + *
>> + * Called when the reference count reaches zero; releases all resources
>> + * associated with the invocation context.
>> + */
>> +void qda_fastrpc_context_free(struct kref *ref)
>> +{
>> + struct fastrpc_invoke_context *ctx;
>> + int i;
>> +
>> + ctx = container_of(ref, struct fastrpc_invoke_context, refcount);
>> + if (ctx->gem_objs) {
>> + for (i = 0; i < ctx->nscalars; ++i) {
>> + if (ctx->gem_objs[i])
>> + drm_gem_object_put(ctx->gem_objs[i]);
>> + }
>> + kfree(ctx->gem_objs);
>> + }
>> +
>> + if (ctx->msg_gem_obj)
>> + drm_gem_object_put(&ctx->msg_gem_obj->base);
>> +
>> + kfree(ctx->olaps);
>> +
>> + kfree(ctx->args);
>> + kfree(ctx->req);
>> + kfree(ctx->rsp);
>> + kfree(ctx->input_pages);
>> + kfree(ctx->inbuf);
>> +
>> + kfree(ctx);
>> +}
>> +
>> +#define CMP(aa, bb) ((aa) == (bb) ? 0 : (aa) < (bb) ? -1 : 1)
>> +
>> +static int olaps_cmp(const void *a, const void *b)
>> +{
>> + struct fastrpc_buf_overlap *pa = (struct fastrpc_buf_overlap *)a;
>> + struct fastrpc_buf_overlap *pb = (struct fastrpc_buf_overlap *)b;
>> + /* sort with lowest starting buffer first */
>> + int st = CMP(pa->start, pb->start);
>> + /* sort with highest ending buffer first */
>> + int ed = CMP(pb->end, pa->end);
>> +
>> + return st == 0 ? ed : st;
>> +}
>> +
>> +static void fastrpc_get_buff_overlaps(struct fastrpc_invoke_context *ctx)
>> +{
>> + u64 max_end = 0;
>> + int i;
>> +
>> + for (i = 0; i < ctx->nbufs; ++i) {
>> + ctx->olaps[i].start = ctx->args[i].ptr;
>> + ctx->olaps[i].end = ctx->olaps[i].start + ctx->args[i].length;
>> + ctx->olaps[i].raix = i;
>> + }
>> +
>> + sort(ctx->olaps, ctx->nbufs, sizeof(*ctx->olaps), olaps_cmp, NULL);
>> +
>> + for (i = 0; i < ctx->nbufs; ++i) {
>> + if (ctx->olaps[i].start < max_end) {
>> + ctx->olaps[i].mstart = max_end;
>> + ctx->olaps[i].mend = ctx->olaps[i].end;
>> + ctx->olaps[i].offset = max_end - ctx->olaps[i].start;
>> +
>> + if (ctx->olaps[i].end > max_end) {
>> + max_end = ctx->olaps[i].end;
>> + } else {
>> + ctx->olaps[i].mend = 0;
>> + ctx->olaps[i].mstart = 0;
>> + }
>> + } else {
>> + ctx->olaps[i].mend = ctx->olaps[i].end;
>> + ctx->olaps[i].mstart = ctx->olaps[i].start;
>> + ctx->olaps[i].offset = 0;
>> + max_end = ctx->olaps[i].end;
>> + }
>> + }
>> +}
>> +
>> +/**
>> + * qda_fastrpc_context_alloc() - Allocate a new FastRPC invocation context
>> + *
>> + * Return: Pointer to allocated context, or ERR_PTR on failure
>> + */
>> +struct fastrpc_invoke_context *qda_fastrpc_context_alloc(void)
>> +{
>> + struct fastrpc_invoke_context *ctx = NULL;
>> +
>> + ctx = kzalloc_obj(*ctx);
>> + if (!ctx)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + INIT_LIST_HEAD(&ctx->node);
>> +
>> + ctx->retval = -1;
>> + ctx->pid = current->pid;
>> + init_completion(&ctx->work);
>> + ctx->msg_gem_obj = NULL;
>> + kref_init(&ctx->refcount);
>> +
>> + return ctx;
>> +}
>> +
>> +/*
>> + * process_fd_buffer() - Handle an in/out buffer argument backed by a DMA-BUF fd
>> + *
>> + * args[i].fd is a DMA-BUF fd. We import it to obtain the GEM object and its
>> + * IOMMU-mapped dma_addr for the physical page descriptor. The DSP uses the
>> + * physical address directly for this buffer type; the fd is not forwarded.
>> + */
>> +static int process_fd_buffer(struct fastrpc_invoke_context *ctx, int i,
>> + union fastrpc_remote_arg *rpra, struct fastrpc_phy_page *pages)
>> +{
>> + struct drm_gem_object *gem_obj;
>> + struct qda_gem_obj *qda_gem_obj;
>> + int err;
>> + u64 len = ctx->args[i].length;
>> + u64 vma_offset;
>> +
>> + err = get_gem_obj_from_dmabuf_fd(ctx, ctx->args[i].fd, &gem_obj);
>> + if (err)
>> + return err;
>> +
>> + ctx->gem_objs[i] = gem_obj;
>> + qda_gem_obj = to_qda_gem_obj(gem_obj);
>> +
>> + rpra[i].buf.pv = (u64)ctx->args[i].ptr;
>> +
>> + pages[i].addr = qda_gem_obj->dma_addr;
>> +
>> + vma_offset = calculate_vma_offset(ctx->args[i].ptr);
>> + pages[i].addr += vma_offset;
>> + pages[i].size = calculate_page_aligned_size(ctx->args[i].ptr, len);
>> +
>> + return 0;
>> +}
>> +
>> +static int process_direct_buffer(struct fastrpc_invoke_context *ctx, int i, int oix,
>> + union fastrpc_remote_arg *rpra, struct fastrpc_phy_page *pages,
>> + uintptr_t *args, u64 *rlen, u64 pkt_size)
>> +{
>> + int mlen;
>> + u64 len = ctx->args[i].length;
>> + int inbufs = ctx->inbufs;
>> +
>> + if (ctx->olaps[oix].offset == 0) {
>> + *rlen -= ALIGN(*args, FASTRPC_ALIGN) - *args;
>> + *args = ALIGN(*args, FASTRPC_ALIGN);
>> + }
>> +
>> + mlen = ctx->olaps[oix].mend - ctx->olaps[oix].mstart;
>> +
>> + if (*rlen < mlen)
>> + return -ENOSPC;
>> +
>> + rpra[i].buf.pv = *args - ctx->olaps[oix].offset;
>> +
>> + pages[i].addr = ctx->msg->phys - ctx->olaps[oix].offset + (pkt_size - *rlen);
>> + pages[i].addr = pages[i].addr & PAGE_MASK;
>> + pages[i].size = calculate_page_aligned_size(rpra[i].buf.pv, len);
>> +
>> + *args = *args + mlen;
>> + *rlen -= mlen;
>> +
>> + if (i < inbufs) {
>> + void *dst = (void *)(uintptr_t)rpra[i].buf.pv;
>> + void *src = (void *)(uintptr_t)ctx->args[i].ptr;
>> +
>> + /*
>> + * For user-space invocations (INVOKE_DYNAMIC), ptr is a user
>> + * virtual address and must be copied safely. For all other
>> + * (kernel-internal) invocations, ptr is a kernel address set
>> + * by the driver itself and can be copied directly.
>> + */
>> + if (ctx->type == FASTRPC_RMID_INVOKE_DYNAMIC) {
>> + if (copy_from_user(dst, (void __user *)src, len))
>> + return -EFAULT;
>> + } else {
>> + memcpy(dst, src, len);
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * process_dma_handle() - Handle a DMA-handle scalar argument
>> + *
>> + * args[i].fd is a DMA-BUF fd. We import it to get the physical page
>> + * descriptor for the kernel, but forward the original DMA-BUF fd to the
>> + * DSP in rpra[i].dma.fd so the DSP can identify the buffer by its fd.
>> + */
>> +static int process_dma_handle(struct fastrpc_invoke_context *ctx, int i,
>> + union fastrpc_remote_arg *rpra, struct fastrpc_phy_page *pages)
>> +{
>> + if (ctx->args[i].fd > 0) {
>> + struct drm_gem_object *gem_obj;
>> + struct qda_gem_obj *qda_gem_obj;
>> + int err;
>> +
>> + err = get_gem_obj_from_dmabuf_fd(ctx, ctx->args[i].fd, &gem_obj);
>> + if (err)
>> + return err;
>> +
>> + ctx->gem_objs[i] = gem_obj;
>> + qda_gem_obj = to_qda_gem_obj(gem_obj);
>> +
>> + setup_pages_from_gem_obj(qda_gem_obj, &pages[i]);
>> +
>> + /* Forward the original DMA-BUF fd to the DSP */
>> + rpra[i].dma.fd = ctx->args[i].fd;
>> + rpra[i].dma.len = ctx->args[i].length;
>> + rpra[i].dma.offset = (u64)ctx->args[i].ptr;
>> + } else {
>> + rpra[i].buf.pv = ctx->args[i].ptr;
>> + rpra[i].buf.len = ctx->args[i].length;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * qda_fastrpc_get_header_size() - Compute the FastRPC message header size
>> + * @ctx: FastRPC invocation context
>> + * @out_size: Pointer to store the aligned packet size in bytes
>> + *
>> + * Return: 0 on success, negative error code on failure
>> + */
>> +int qda_fastrpc_get_header_size(struct fastrpc_invoke_context *ctx, size_t *out_size)
>> +{
>> + ctx->inbufs = REMOTE_SCALARS_INBUFS(ctx->sc);
>> + ctx->metalen = fastrpc_get_meta_size(ctx);
>> + ctx->pkt_size = fastrpc_get_payload_size(ctx, ctx->metalen);
>> +
>> + ctx->aligned_pkt_size = PAGE_ALIGN(ctx->pkt_size);
>> + if (ctx->aligned_pkt_size == 0)
>> + return -EINVAL;
>> +
>> + *out_size = ctx->aligned_pkt_size;
>> + return 0;
>> +}
>> +
>> +static int fastrpc_get_args(struct fastrpc_invoke_context *ctx)
>> +{
>> + union fastrpc_remote_arg *rpra;
>> + struct fastrpc_invoke_buf *list;
>> + struct fastrpc_phy_page *pages;
>> + int i, oix, err = 0;
>> + u64 rlen;
>> + uintptr_t args;
>> + size_t hdr_size;
>> +
>> + ctx->inbufs = REMOTE_SCALARS_INBUFS(ctx->sc);
>> + err = qda_fastrpc_get_header_size(ctx, &hdr_size);
>> + if (err)
>> + return err;
>> +
>> + ctx->msg->buf = ctx->msg_gem_obj->virt;
>> + ctx->msg->phys = ctx->msg_gem_obj->dma_addr;
>> +
>> + memset(ctx->msg->buf, 0, ctx->aligned_pkt_size);
>> +
>> + rpra = (union fastrpc_remote_arg *)ctx->msg->buf;
>> + ctx->list = fastrpc_invoke_buf_start(rpra, ctx->nscalars);
>> + ctx->pages = fastrpc_phy_page_start(ctx->list, ctx->nscalars);
>> + list = ctx->list;
>> + pages = ctx->pages;
>> + args = (uintptr_t)ctx->msg->buf + ctx->metalen;
>> + rlen = ctx->pkt_size - ctx->metalen;
>> + ctx->rpra = rpra;
>> +
>> + for (oix = 0; oix < ctx->nbufs; ++oix) {
>> + i = ctx->olaps[oix].raix;
>> +
>> + rpra[i].buf.pv = 0;
>> + rpra[i].buf.len = ctx->args[i].length;
>> + list[i].num = ctx->args[i].length ? 1 : 0;
>> + list[i].pgidx = i;
>> +
>> + if (!ctx->args[i].length)
>> + continue;
>> +
>> + if (ctx->args[i].fd > 0)
>> + err = process_fd_buffer(ctx, i, rpra, pages);
>> + else
>> + err = process_direct_buffer(ctx, i, oix, rpra, pages, &args, &rlen,
>> + ctx->pkt_size);
>> +
>> + if (err)
>> + goto bail_gem;
>> + }
>> +
>> + for (i = ctx->nbufs; i < ctx->nscalars; ++i) {
>> + list[i].num = ctx->args[i].length ? 1 : 0;
>> + list[i].pgidx = i;
>> +
>> + err = process_dma_handle(ctx, i, rpra, pages);
>> + if (err)
>> + goto bail_gem;
>> + }
>> +
>> + return 0;
>> +
>> +bail_gem:
>> + if (ctx->msg_gem_obj) {
>> + drm_gem_object_put(&ctx->msg_gem_obj->base);
>> + ctx->msg_gem_obj = NULL;
>> + }
>> +
>> + return err;
>> +}
>> +
>> +static int fastrpc_put_args(struct fastrpc_invoke_context *ctx, struct qda_msg *msg)
>> +{
>> + union fastrpc_remote_arg *rpra;
>> + int i, err = 0;
>> +
>> + if (!ctx)
>> + return -EINVAL;
>> +
>> + rpra = ctx->rpra;
>> + if (!rpra)
>> + return -EINVAL;
>> +
>> + for (i = ctx->inbufs; i < ctx->nbufs; ++i) {
>> + if (ctx->args[i].fd <= 0) {
>> + void *src = (void *)(uintptr_t)rpra[i].buf.pv;
>> + void *dst = (void *)(uintptr_t)ctx->args[i].ptr;
>> + u64 len = rpra[i].buf.len;
>> +
>> + if (ctx->type == FASTRPC_RMID_INVOKE_DYNAMIC)
>> + err = copy_to_user((void __user *)dst, src, len) ? -EFAULT : 0;
>> + else
>> + memcpy(dst, src, len);
>> + if (err)
>> + break;
>> + }
>> + }
>> +
>> + return err;
>> +}
>> +
>> +/**
>> + * qda_fastrpc_invoke_pack() - Pack an invocation context into a QDA message
>> + * @ctx: FastRPC invocation context
>> + * @msg: QDA message structure to pack into
>> + *
>> + * Return: 0 on success, negative error code on failure
>> + */
>> +int qda_fastrpc_invoke_pack(struct fastrpc_invoke_context *ctx,
>> + struct qda_msg *msg)
>> +{
>> + int err = 0;
>> +
>> + if (ctx->handle == FASTRPC_INIT_HANDLE)
>> + msg->fastrpc.remote_session_id = 0;
>> + else
>> + msg->fastrpc.remote_session_id = ctx->remote_session_id;
>> +
>> + ctx->msg = msg;
>> +
>> + err = fastrpc_get_args(ctx);
>> + if (err)
>> + return err;
>> +
>> + dma_wmb();
>> +
>> + msg->fastrpc.tid = ctx->pid;
>> + msg->fastrpc.ctx = ctx->ctxid | ctx->pd;
>> + msg->fastrpc.handle = ctx->handle;
>> + msg->fastrpc.sc = ctx->sc;
>> + msg->fastrpc.addr = ctx->msg->phys;
>> + msg->fastrpc.size = roundup(ctx->pkt_size, PAGE_SIZE);
>> + msg->fastrpc_ctx = ctx;
>> + msg->file_priv = ctx->file_priv;
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * qda_fastrpc_invoke_unpack() - Unpack a response message into an invocation context
>> + * @ctx: FastRPC invocation context
>> + * @msg: QDA message structure to unpack from
>> + *
>> + * Return: 0 on success, negative error code on failure
>> + */
>> +int qda_fastrpc_invoke_unpack(struct fastrpc_invoke_context *ctx,
>> + struct qda_msg *msg)
>> +{
>> + int err;
>> +
>> + dma_rmb();
>> +
>> + err = fastrpc_put_args(ctx, msg);
>> + if (err)
>> + return err;
>> +
>> + err = ctx->retval;
>> + return err;
>> +}
>> +
>> +static int fastrpc_prepare_args_invoke(struct fastrpc_invoke_context *ctx, char __user *argp)
>> +{
>> + struct drm_qda_invoke_args invoke_args;
>> + struct drm_qda_fastrpc_invoke_args *args = NULL;
>> + u32 nscalars;
>> +
>> + /* argp is DRM ioctl data (kernel pointer); args pointer within it is user-space */
>> + memcpy(&invoke_args, argp, sizeof(invoke_args));
>> +
>> + ctx->handle = invoke_args.handle;
>> + ctx->sc = invoke_args.sc;
>> +
>> + nscalars = REMOTE_SCALARS_LENGTH(ctx->sc);
>> + if (!nscalars) {
>> + ctx->args = NULL;
>> + return 0;
>> + }
>> +
>> + args = kcalloc(nscalars, sizeof(*args), GFP_KERNEL);
>> + if (!args)
>> + return -ENOMEM;
>> +
>> + if (copy_from_user(args, u64_to_user_ptr(invoke_args.args),
>> + nscalars * sizeof(*args))) {
>> + kfree(args);
>> + return -EFAULT;
>> + }
>> +
>> + ctx->args = args;
>> + return 0;
>> +}
>> +
>> +/**
>> + * qda_fastrpc_prepare_args() - Prepare arguments for a FastRPC invocation
>> + * @ctx: FastRPC invocation context
>> + * @argp: User-space pointer to invocation arguments
>> + *
>> + * Return: 0 on success, negative error code on failure
>> + */
>> +int qda_fastrpc_prepare_args(struct fastrpc_invoke_context *ctx, char __user *argp)
>> +{
>> + int err;
>> +
>> + switch (ctx->type) {
>> + case FASTRPC_RMID_INVOKE_DYNAMIC:
>> + err = fastrpc_prepare_args_invoke(ctx, argp);
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> + if (err)
>> + return err;
>> +
>> + ctx->nscalars = REMOTE_SCALARS_LENGTH(ctx->sc);
>> + ctx->nbufs = REMOTE_SCALARS_INBUFS(ctx->sc) + REMOTE_SCALARS_OUTBUFS(ctx->sc);
>> +
>> + if (ctx->nscalars) {
>> + ctx->gem_objs = kcalloc(ctx->nscalars, sizeof(*ctx->gem_objs), GFP_KERNEL);
>> + if (!ctx->gem_objs)
>> + return -ENOMEM;
>> + ctx->olaps = kcalloc(ctx->nscalars, sizeof(*ctx->olaps), GFP_KERNEL);
>> + if (!ctx->olaps) {
>> + kfree(ctx->gem_objs);
>> + ctx->gem_objs = NULL;
>> + return -ENOMEM;
>> + }
>> + fastrpc_get_buff_overlaps(ctx);
>> + }
>> +
>> + return err;
>> +}
>> diff --git a/drivers/accel/qda/qda_fastrpc.h b/drivers/accel/qda/qda_fastrpc.h
>> new file mode 100644
>> index 000000000000..ce77baeccfba
>> --- /dev/null
>> +++ b/drivers/accel/qda/qda_fastrpc.h
>> @@ -0,0 +1,271 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +#ifndef __QDA_FASTRPC_H__
>> +#define __QDA_FASTRPC_H__
>> +
>> +#include <linux/completion.h>
>> +#include <linux/kref.h>
>> +#include <linux/list.h>
>> +#include <linux/types.h>
>> +#include <drm/drm_drv.h>
>> +#include <drm/drm_file.h>
>> +#include <drm/qda_accel.h>
>> +
>> +/* Forward declarations */
>> +struct qda_gem_obj;
>> +
>> +/*
>> + * FastRPC scalar extraction macros
>> + *
>> + * These macros extract different fields from the scalar value that describes
>> + * the arguments passed in a FastRPC invocation.
>> + */
>> +#define REMOTE_SCALARS_INBUFS(sc) (((sc) >> 16) & 0x0ff)
>> +#define REMOTE_SCALARS_OUTBUFS(sc) (((sc) >> 8) & 0x0ff)
>> +#define REMOTE_SCALARS_INHANDLES(sc) (((sc) >> 4) & 0x0f)
>> +#define REMOTE_SCALARS_OUTHANDLES(sc) ((sc) & 0x0f)
>> +#define REMOTE_SCALARS_LENGTH(sc) (REMOTE_SCALARS_INBUFS(sc) + \
>> + REMOTE_SCALARS_OUTBUFS(sc) + \
>> + REMOTE_SCALARS_INHANDLES(sc) + \
>> + REMOTE_SCALARS_OUTHANDLES(sc))
>> +
>> +/* FastRPC configuration constants */
>> +#define FASTRPC_ALIGN 128 /* Alignment requirement */
>> +#define FASTRPC_MAX_FDLIST 16 /* Maximum file descriptors */
>> +#define FASTRPC_MAX_CRCLIST 64 /* Maximum CRC list entries */
>> +
>> +/*
>> + * FastRPC scalar construction macros
>> + *
>> + * These macros build the scalar value that describes the arguments
>> + * for a FastRPC invocation.
>> + */
>> +#define FASTRPC_BUILD_SCALARS(attr, method, in, out, oin, oout) \
>> + (((attr & 0x07) << 29) | \
>> + ((method & 0x1f) << 24) | \
>> + ((in & 0xff) << 16) | \
>> + ((out & 0xff) << 8) | \
>> + ((oin & 0x0f) << 4) | \
>> + (oout & 0x0f))
>> +
>> +#define FASTRPC_SCALARS(method, in, out) \
>> + FASTRPC_BUILD_SCALARS(0, method, in, out, 0, 0)
>> +
>> +/**
>> + * struct fastrpc_buf_overlap - Buffer overlap tracking structure
>> + *
>> + * Tracks overlapping buffer regions to optimise memory mapping and avoid
>> + * redundant mappings of the same physical memory.
>
> WHat for? Even if this is a valid optimization, implement it as a
> subsequent patch. The first goal should be very simple - get GEM buffers
> from the app, pass them to the DSP, read the results.
yes, this implementation is mimicking the existing fastrpc design where
non-FD buffers are also supported. I am currently evaluating the
maintainance of such buffers from userspace side and trying to
understand the impacts of the same. I am planning to bring it as a
future enhancement if there is no regression.>
>> + */
>> +struct fastrpc_buf_overlap {
>
> Stop clashing the names with the existing fastrpc driver.
ack.>
>> + /** @start: Start address of the buffer in user virtual address space */
>> + u64 start;
>> + /** @end: End address of the buffer in user virtual address space */
>> + u64 end;
>> + /** @raix: Remote argument index associated with this overlap */
>> + int raix;
>> + /** @mstart: Start address of the mapped region */
>> + u64 mstart;
>> + /** @mend: End address of the mapped region */
>> + u64 mend;
>> + /** @offset: Offset within the mapped region */
>> + u64 offset;
>> +};
>> +
>> +/**
>> + * struct fastrpc_remote_dmahandle - Remote DMA handle descriptor
>> + */
>> +struct fastrpc_remote_dmahandle {
>> + /** @fd: DMA-BUF file descriptor */
>> + s32 fd;
>> + /** @offset: Byte offset within the DMA-BUF */
>> + u32 offset;
>> + /** @len: Length of the region in bytes */
>> + u32 len;
>> +};
>> +
>> +/**
>> + * struct fastrpc_remote_buf - Remote buffer descriptor
>> + */
>> +struct fastrpc_remote_buf {
>> + /** @pv: Buffer pointer (user virtual address) */
>> + u64 pv;
>> + /** @len: Length of the buffer in bytes */
>> + u64 len;
>> +};
>> +
>> +/**
>> + * union fastrpc_remote_arg - Remote argument (buffer or DMA handle)
>> + */
>> +union fastrpc_remote_arg {
>> + /** @buf: Inline buffer descriptor */
>> + struct fastrpc_remote_buf buf;
>> + /** @dma: DMA-BUF handle descriptor */
>> + struct fastrpc_remote_dmahandle dma;
>> +};
>> +
>> +/**
>> + * struct fastrpc_phy_page - Physical page descriptor
>> + */
>> +struct fastrpc_phy_page {
>> + /** @addr: Physical (IOMMU) address of the page */
>> + u64 addr;
>> + /** @size: Size of the contiguous region in bytes */
>> + u64 size;
>> +};
>> +
>> +/**
>> + * struct fastrpc_invoke_buf - Invoke buffer descriptor
>> + */
>> +struct fastrpc_invoke_buf {
>> + /** @num: Number of contiguous physical regions */
>> + u32 num;
>> + /** @pgidx: Index into the physical page array */
>> + u32 pgidx;
>> +};
>> +
>> +/**
>> + * struct fastrpc_msg - FastRPC wire message for remote invocations
>> + *
>> + * Sent to the remote processor via RPMsg. This is the exact layout
>> + * the DSP expects; do not reorder or add fields without DSP firmware
>> + * coordination.
>> + */
>> +struct fastrpc_msg {
>> + /** @remote_session_id: Session identifier on the remote processor */
>> + int remote_session_id;
>> + /** @tid: Thread ID of the invoking thread */
>> + int tid;
>> + /** @ctx: Context identifier for matching request/response */
>> + u64 ctx;
>> + /** @handle: Handle of the remote method to invoke */
>> + u32 handle;
>> + /** @sc: Scalars value encoding in/out buffer counts */
>> + u32 sc;
>> + /** @addr: Physical address of the message payload buffer */
>> + u64 addr;
>> + /** @size: Size of the message payload in bytes */
>> + u64 size;
>> +};
>> +
>> +/**
>> + * struct qda_msg - FastRPC message with kernel-internal bookkeeping
>> + *
>> + * The wire-format portion is kept in the embedded @fastrpc member (must
>> + * be first) so that &qda_msg->fastrpc can be passed directly to
>> + * rpmsg_send() without a copy.
>> + */
>> +struct qda_msg {
>> + /**
>> + * @fastrpc: Wire-format message sent to the DSP via RPMsg.
>> + * Must be the first member.
>> + */
>> + struct fastrpc_msg fastrpc;
>> + /** @buf: Kernel virtual address of the payload buffer */
>> + void *buf;
>> + /** @phys: Physical/DMA address of the payload buffer */
>> + u64 phys;
>> + /** @ret: Return value from the remote processor */
>> + int ret;
>> + /** @fastrpc_ctx: Back-pointer to the owning invocation context */
>> + struct fastrpc_invoke_context *fastrpc_ctx;
>> + /** @file_priv: DRM file private data for GEM object lookup */
>> + struct drm_file *file_priv;
>> +};
>> +
>> +/**
>> + * struct fastrpc_invoke_context - Remote procedure call invocation context
>> + *
>> + * Maintains all state for a single remote procedure call, including buffer
>> + * management, synchronisation, and result handling.
>> + */
>> +struct fastrpc_invoke_context {
>> + /** @node: List node for linking contexts in a queue */
>> + struct list_head node;
>> + /** @ctxid: Unique context identifier (XArray key shifted left by 4) */
>> + u64 ctxid;
>> + /** @inbufs: Number of input buffers */
>> + int inbufs;
>> + /** @outbufs: Number of output buffers */
>> + int outbufs;
>> + /** @handles: Number of DMA-BUF handle arguments */
>> + int handles;
>> + /** @nscalars: Total number of scalar arguments */
>> + int nscalars;
>> + /** @nbufs: Total number of buffer arguments (inbufs + outbufs) */
>> + int nbufs;
>
> If it is inbufs + outbufs, why do you need it here?
>
>> + /** @pid: Process ID of the calling process */
>> + int pid;
>> + /** @retval: Return value from the remote invocation */
>> + int retval;
>> + /** @metalen: Length of the FastRPC metadata header in bytes */
>> + int metalen;
>
> size_t, also why do you need it?
>
>> + /** @remote_session_id: Session identifier on the remote processor */
>> + int remote_session_id;
>> + /** @pd: Protection domain identifier encoded into the context ID */
>> + int pd;
>> + /** @type: Invocation type (e.g. FASTRPC_RMID_INVOKE_DYNAMIC) */
>> + int type;
>> + /** @sc: Scalars value encoding in/out buffer counts */
>> + u32 sc;
>
> How is this different from the counts above?
sc carries the method id and handle counts. The reason to maintain count
separately is to avoid calculating it again and again.>
>> + /** @handle: Handle of the remote method being invoked */
>> + u32 handle;
>> + /** @crc: Pointer to CRC values for data integrity checking */
>> + u32 *crc;
>
> Add it later. It's unused. Drop all unused fields.
ack.>
>> + /** @fdlist: Pointer to array of DMA-BUF file descriptors */
>> + u64 *fdlist;
>
> Why do you need DMA-BUFs in the invocation context? They all should be
> GEM buffers.
the reason is that the users are dependent on FDs as they can import
buffers allocated from anywhere and there are DSP APIs which takes fd as
an argument, so they might end up using the same in there skel
implementation.>
>> + /** @pkt_size: Total payload size in bytes */
>> + u64 pkt_size;
>> + /** @aligned_pkt_size: Page-aligned payload size for GEM allocation */
>> + u64 aligned_pkt_size;
>> + /** @list: Array of invoke buffer descriptors */
>> + struct fastrpc_invoke_buf *list;
>> + /** @pages: Array of physical page descriptors for all arguments */
>> + struct fastrpc_phy_page *pages;
>> + /** @input_pages: Array of physical page descriptors for input buffers */
>> + struct fastrpc_phy_page *input_pages;
>
> I think you are trying to bring all the complexity from the old driver
> with no added benefit. Please don't. Use the existing memory manager.
> Let it handle all the gory details. If someting is not there, we should
> consider extending GEM instead.
I'm not changing the metadata format as the DSP might not understand the
messages if we modify it. Also, the fd is still being used because of
the client dependency on it. I'll check if there is any other logic that
needs alteration here.>
>> + /** @work: Completion used to synchronise with the DSP response */
>> + struct completion work;
>> + /** @msg: Pointer to the QDA message structure for this invocation */
>> + struct qda_msg *msg;
>> + /** @rpra: Array of remote procedure arguments */
>> + union fastrpc_remote_arg *rpra;
>> + /** @gem_objs: Array of GEM objects imported for argument buffers */
>> + struct drm_gem_object **gem_objs;
>> + /** @args: User-space invoke argument descriptors */
>> + struct drm_qda_fastrpc_invoke_args *args;
>> + /** @olaps: Array of buffer overlap descriptors for deduplication */
>> + struct fastrpc_buf_overlap *olaps;
>> + /** @refcount: Reference counter for context lifetime management */
>> + struct kref refcount;
>> + /** @msg_gem_obj: GEM object backing the message payload buffer */
>> + struct qda_gem_obj *msg_gem_obj;
>> + /** @file_priv: DRM file private data */
>> + struct drm_file *file_priv;
>> + /** @init_mem_gem_obj: GEM object for protection domain init memory */
>> + struct qda_gem_obj *init_mem_gem_obj;
>> + /** @req: Pointer to kernel-internal request buffer */
>> + void *req;
>> + /** @rsp: Pointer to kernel-internal response buffer */
>> + void *rsp;
>> + /** @inbuf: Pointer to kernel-internal input buffer */
>> + void *inbuf;
>> +};
>> +
>> +/* Remote Method ID table - identifies initialization and control operations */
>> +#define FASTRPC_RMID_INVOKE_DYNAMIC 0xFFFFFFFF /* Dynamic method invocation */
>> +
>> +/* Common handle for initialization operations */
>> +#define FASTRPC_INIT_HANDLE 0x1
>> +
>> +void qda_fastrpc_context_free(struct kref *ref);
>> +struct fastrpc_invoke_context *qda_fastrpc_context_alloc(void);
>> +int qda_fastrpc_prepare_args(struct fastrpc_invoke_context *ctx, char __user *argp);
>> +int qda_fastrpc_get_header_size(struct fastrpc_invoke_context *ctx, size_t *out_size);
>> +int qda_fastrpc_invoke_pack(struct fastrpc_invoke_context *ctx, struct qda_msg *msg);
>> +int qda_fastrpc_invoke_unpack(struct fastrpc_invoke_context *ctx, struct qda_msg *msg);
>> +
>> +#endif /* __QDA_FASTRPC_H__ */
>> diff --git a/drivers/accel/qda/qda_ioctl.c b/drivers/accel/qda/qda_ioctl.c
>> index 1769c85a3e98..c81268c20b04 100644
>> --- a/drivers/accel/qda/qda_ioctl.c
>> +++ b/drivers/accel/qda/qda_ioctl.c
>> @@ -3,8 +3,10 @@
>> #include <drm/drm_ioctl.h>
>> #include <drm/qda_accel.h>
>> #include "qda_drv.h"
>> +#include "qda_fastrpc.h"
>> #include "qda_gem.h"
>> #include "qda_ioctl.h"
>> +#include "qda_rpmsg.h"
>>
>> /**
>> * qda_ioctl_query() - Query DSP device information
>> @@ -74,3 +76,105 @@ int qda_ioctl_gem_mmap_offset(struct drm_device *dev, void *data, struct drm_fil
>>
>> return drm_gem_dumb_map_offset(file_priv, dev, args->handle, &args->offset);
>> }
>> +
>> +static int fastrpc_context_get_id(struct fastrpc_invoke_context *ctx, struct qda_dev *qdev)
>> +{
>> + int ret;
>> + u32 id;
>> +
>> + if (!qdev)
>> + return -EINVAL;
>> +
>> + ret = xa_alloc(&qdev->ctx_xa, &id, ctx, xa_limit_32b, GFP_KERNEL);
>> + if (ret)
>> + return ret;
>> +
>> + ctx->ctxid = id << 4;
>
> Why is it being shifted?
this is to accomodate PD type>
>> + return 0;
>> +}
>> +
>
^ permalink raw reply
* Re: [PATCH net-next V2 7/7] devlink: Add eswitch mode boot defaults
From: Randy Dunlap @ 2026-06-04 3:53 UTC (permalink / raw)
To: Mark Bloch, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, David S. Miller
Cc: Jonathan Corbet, Shuah Khan, Jiri Pirko, Simon Horman,
Sunil Goutham, Linu Cherian, Geetha sowjanya, hariprasad,
Subbaraya Sundeep, Bharat Bhushan, Saeed Mahameed,
Leon Romanovsky, Tariq Toukan, Borislav Petkov (AMD),
Andrew Morton, Peter Zijlstra (Intel), Thomas Gleixner,
Petr Mladek, Tejun Heo, Vlastimil Babka, Feng Tang, Dave Hansen,
Christian Brauner, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, Li RongQing, Paul E. McKenney, Ethan Nelson-Moore,
linux-doc, linux-kernel, netdev, linux-rdma
In-Reply-To: <e4aada53-fb80-41a8-9a8e-d19414f6466b@nvidia.com>
On 6/3/26 6:16 PM, Mark Bloch wrote:
>
>
> On 03/06/2026 23:06, Randy Dunlap wrote:
>> Hi.
>>
>> On 6/3/26 12:32 PM, Mark Bloch wrote:
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>>> index 063c11ca33e5..7af9f2898d92 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -1264,6 +1264,31 @@ Kernel parameters
>>> dell_smm_hwmon.fan_max=
>>> [HW] Maximum configurable fan speed.
>>>
>>> + devlink_eswitch_mode=
>>> + [NET]
>>> + Format:
>>> + [<selector>]:<mode>
>>
>> It appears (please correct me if I am mistaken) that the '[' and ']'
>> above don't mean "optional" but instead they are required characters...
>>
>>> +
>>> + <selector>:
>>> + * | <handle>[,<handle>...]
>>
>> while here they mean "optional".
>>
>> That is confusing (inconsistent). Also, if the square brackets are
>> always required around the <selector>, what purpose do they serve?
>
> Yes, you are right, this is confusing. The outer square brackets are part of
> the syntax and are required, while the brackets in "[,<handle>...]" mean that
> additional handles are optional.
>
> I couldn't find a better way to describe this. What I want to say is that the
> selector is always wrapped in square brackets. Inside the brackets it can either
> be "*" to match all devices, or a comma separated list of handles. If "*" is
> not used, then at least one handle has to be provided.
>
> Maybe it would be clearer to spell it out explicitly, something like:
>
> Format:
> [<selector>]:<mode>
>
> The '[' and ']' characters are literal and required.
>
> <selector>:
> * | <handle>[,<handle>...]
>
> If '*' is not used, <selector> must contain at least one <handle>.
>
> Does that sound like a reasonable way to document it?
Yes, that helps a little bit. Better than nothing.
But why are they required at all?
>>> +
>>> + <handle>:
>>> + <bus-name>/<dev-name>
>>> +
>>> + Configure default devlink eswitch mode for matching
>>> + devlink instances during device initialization.
>>> +
>>> + <mode>:
>>> + legacy | switchdev | switchdev_inactive
>>> +
>>> + Examples:
>>> + devlink_eswitch_mode=[*]:switchdev
>>> + devlink_eswitch_mode=[pci/0000:08:00.0]:switchdev
>>> + devlink_eswitch_mode=[pci/0000:08:00.0,pci/0000:09:00.1]:legacy
>>> +
>>> + See Documentation/networking/devlink/devlink-defaults.rst
>>> + for the full syntax.
>>> +
>>> dfltcc= [HW,S390]
>>> Format: { on | off | def_only | inf_only | always }
>>> on: s390 zlib hardware support for compression on
>>
>>
>
--
~Randy
^ permalink raw reply
* [PATCH v3] docs: pt_BR: update "Purpose of Defconfigs" section in maintainer-soc.rst
From: Amanda Corrêa @ 2026-06-04 3:18 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Amanda Corrêa
This update includes the "Purpose of Defconfigs" section translated
to Brazilian Portuguese.
Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
---
v2:
- Adjust translation of section title to "Propósito dos Defconfigs"
for better clarity in Portuguese.
v3:
- Fix plural agreement in section title
- Clarify that the referenced device must be supported by upstream
.../translations/pt_BR/process/maintainer-soc.rst | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-soc.rst b/Documentation/translations/pt_BR/process/maintainer-soc.rst
index 5a3ae213e..eb8040a62 100644
--- a/Documentation/translations/pt_BR/process/maintainer-soc.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-soc.rst
@@ -8,7 +8,7 @@ Visão Geral
-----------
O subsistema SoC é um local de agregação para códigos específicos de SoC
-System on Chip). Os principais componentes do subsistema são:
+(System on Chip). Os principais componentes do subsistema são:
* Devicetrees (DTS) para ARM de 32 e 64 bits e RISC-V.
* Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*).
@@ -220,3 +220,13 @@ A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita
usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve
descrição resumindo as alterações no pull request. Para mais detalhes sobre o
envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``.
+
+Propósito dos Defconfigs
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
+distribuições têm suas próprias configurações. Uma mudança que adiciona novas
+opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
+em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
+suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
+para máquinas não upstream não deve ser aceito.
--
2.43.0
^ permalink raw reply related
* [PATCH v2] docs: pt_BR: update "Purpose of Defconfigs" section in maintainer-soc.rst
From: Amanda Corrêa @ 2026-06-04 3:02 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Amanda Corrêa
This update includes the "Purpose of Defconfigs" section translated
to Brazilian Portuguese.
Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
---
v2:
- Adjust translation of section title to "Propósito dos Defconfigs"
for better clarity in Portuguese.
.../translations/pt_BR/process/maintainer-soc.rst | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-soc.rst b/Documentation/translations/pt_BR/process/maintainer-soc.rst
index 5a3ae213e..eb8040a62 100644
--- a/Documentation/translations/pt_BR/process/maintainer-soc.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-soc.rst
@@ -8,7 +8,7 @@ Visão Geral
-----------
O subsistema SoC é um local de agregação para códigos específicos de SoC
-System on Chip). Os principais componentes do subsistema são:
+(System on Chip). Os principais componentes do subsistema são:
* Devicetrees (DTS) para ARM de 32 e 64 bits e RISC-V.
* Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*).
@@ -220,3 +220,13 @@ A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita
usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve
descrição resumindo as alterações no pull request. Para mais detalhes sobre o
envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``.
+
+Propósito dos Defconfigs
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
+distribuições têm suas próprias configurações. Uma mudança que adiciona novas
+opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
+em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
+suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
+para máquinas não upstream não deve ser aceito.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] docs: pt_BR: update "Purpose of Defconfigs" section in maintainer-soc.rst
From: Daniel Pereira @ 2026-06-04 2:51 UTC (permalink / raw)
To: Amanda Corrêa; +Cc: linux-doc
In-Reply-To: <20260604002212.42092-1-amandacorreasilvax@gmail.com>
Em qua., 3 de jun. de 2026 às 21:22, Amanda Corrêa
<amandacorreasilvax@gmail.com> escreveu:
> +Propósito do Defconfigs
> +~~~~~~~~~~~~~~~~~~~~~~~
I notice that the phrase "Propósito do Defconfigs" is grammatically
incorrect because "defconfigs" is plural.
In my view, the correct form should be "Propósito dos Defconfigs" to
maintain proper plural agreement.
> +Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
> +distribuições têm suas próprias configurações. Uma mudança que adiciona novas
> +opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
> +em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
> +suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
> +para máquinas não upstream não deve ser aceito.
The original text explicitly states "upstream-supported
machine/board". It is fundamental to include the term
"no upstream" in the Portuguese translation to make it clear that the
machine or device must already be accepted in the main development
tree.
Additionally, I suggest using "dispositivo" instead of "placa", as
translating "board" literally to "placa"
in Portuguese can sound ambiguous (often confused with an expansion
card like a GPU). In our technical jargon, "dispositivo"
is much more precise for embedded hardware.
^ permalink raw reply
* Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback
From: Hao Jia @ 2026-06-04 2:11 UTC (permalink / raw)
To: Nhat Pham, Yosry Ahmed
Cc: Johannes Weiner, akpm, tj, shakeel.butt, mhocko, mkoutny,
chengming.zhou, muchun.song, roman.gushchin, cgroups, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <CAKEwX=OhxUxRCEfvZMnWzXy=Fa4jgzL3DuP-RmaVzdK65m4bew@mail.gmail.com>
On 2026/6/4 02:14, Nhat Pham wrote:
> On Wed, Jun 3, 2026 at 10:58 AM Yosry Ahmed <yosry@kernel.org> wrote:
>>
>> On Wed, Jun 03, 2026 at 07:22:36PM +0800, Hao Jia wrote:
>>>
>>>
>>> On 2026/5/30 09:40, Yosry Ahmed wrote:
>>>> On Fri, May 29, 2026 at 12:58:09PM -0700, Nhat Pham wrote:
>>>>> On Tue, May 26, 2026 at 4:46 AM Hao Jia <jiahao.kernel@gmail.com> wrote:
>>>>>>
>>>>>> From: Hao Jia <jiahao1@lixiang.com>
>>>>>>
>>>>>> Zswap currently writes back pages to backing swap reactively, triggered
>>>>>> either by the shrinker or when the pool reaches its size limit. There is
>>>>>> no mechanism to control the amount of writeback for a specific memory
>>>>>> cgroup. However, users may want to proactively write back zswap pages,
>>>>>> e.g., to free up memory for other applications or to prepare for
>>>>>> memory-intensive workloads.
>>>>>>
>>>>>> Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup
>>>>>> interface. When specified, this key bypasses standard memory reclaim
>>>>>> and exclusively performs proactive zswap writeback up to the requested
>>>>>> budget. If omitted, the default reclaim behavior remains unchanged.
>>>>>>
>>>>>> Example usage:
>>>>>> # Write back 100MB of pages from zswap to the backing swap
>>>>>> echo "100M zswap_writeback_only" > memory.reclaim
>>>>>
>>>>> Hmmm, so this 100MB is the pre-compression size? i.e if this 100 MB
>>>>> compresses to 25 MB, then you're only freeing 25 MB?
>>>>>
>>>>> I'm ok-ish with this, but can you document it?
>>>>
>>>> That's a good point. I think pre-compressed size doesn't make sense to
>>>> be honest. We should care about how much memory we are actually trying
>>>> to save by doing writeback here.
>>>>
>>>> The pre-compressed size is only useful in determining the blast radius,
>>>> how many actual pages are going to have slower page faults now. But
>>>> then, I don't think there's a reasonable way for userspace to decide
>>>> that.
>>>>
>>>> I understand passing in the compressed size is tricky because we need to
>>>> keep track of the size of the compressed pages we end up writing back,
>>>> but it should be doable.
>>>
>>> Agreed. Using pre-compressed size is probably easier to implement. IIRC,
>>> interfaces like ZRAM writeback_limit are also calculated using the
>>> pre-compressed size.
>>>
>>> I'll clarify this in the documentation in the next version.
>>>
>>>>
>>>> If we really want pre-compressed size here, then yes we need to make it
>>>> very clear, and I vote that we use a separate interface in this case
>>>> because memory.reclaim having different meanings for the amount of
>>>> memory written to it is extremely counter-intuitive.
>>>>
>>> Agree. This would indeed break the semantics of memory.reclaim. I will use a
>>> separate interface for proactive writeback in the next version.
>>
>> But doesn't it make more sense to specify the compressed size, which is
>> ultimately the amount of memory you actually want to reclaim.
>>
>
> I personally prefer compressed size to pre-compressed size. That's
> kinda what user cares about, no?
>
> One thing we can do is let users prescribe a compressed size, but
> internally, we can multiply that by the average compression ratio.
> That gives us a guesstimate of how many pages we need to reclaim, and
> you can follow the rest of your implementation as is (perhaps with
> short-circuit when we reach the goal with fewer pages reclaimed).
Got it. I will change it to use the compressed size in the next version.
Yosry, Nhat, should we continue using the zswap_writeback_only key to
trigger proactive writeback?
Thanks,
Hao
^ permalink raw reply
* Re: [PATCH v3 1/4] mm/zswap: Make shrink_worker writeback cursor per-memcg
From: Hao Jia @ 2026-06-04 1:58 UTC (permalink / raw)
To: Yosry Ahmed
Cc: akpm, tj, hannes, shakeel.butt, mhocko, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin, cgroups, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <aiBpibRNi0BcM1Zu@google.com>
On 2026/6/4 01:53, Yosry Ahmed wrote:
> On Wed, Jun 03, 2026 at 11:02:54AM +0800, Hao Jia wrote:
>>
>>
>> On 2026/6/3 07:19, Yosry Ahmed wrote:
>>>>>>>> Proactive writeback also wants a similar per-memcg cursor that is
>>>>>>>> scoped to the specified memcg, so that repeated invocations against
>>>>>>>> the same memcg make forward progress across its descendant memcgs
>>>>>>>> instead of restarting from the first child memcg each time.
>>>>>>>
>>>>>>> Is this a problem in practice?
>>>>>>>
>>>>>>> Is the concern the overhead of scanning memcgs repeatedly, or lack of
>>>>>>> fairness? I wonder if we should just do writeback in batches from all
>>>>>>> memcgs, similar to how reclaim does it, then evaluate at the end if we
>>>>>>> need to start over?
>>>>>>>
>>>>>>
>>>>>> Not using a per-cgroup cursor will cause issues for "repeated small-budget
>>>>>> calls" cases. For example, repeatedly triggering a 2MB writeback might
>>>>>> result in only writing back pages from the first few child memcgs every
>>>>>> time. In the worst-case scenario (where the writeback amount is less than
>>>>>> WB_BATCH), it might only ever write back from the first child memcg.
>>>>>
>>>>> Right, so a fairness concern?
>>>>>
>>>>> I wonder if we should just reclaim a batch from each memcg, then check
>>>>> if we reached the goal, otherwise start over. If the batch size is small
>>>>> enough that should work?
>>>>
>>>> Even with a small batch size, for small writeback requests triggered by
>>>> user-space (e.g., 2MB, which is batch size * N), it might still repeatedly
>>>> write back from only the first N child memcgs.
>>>
>>> Yes, I understand, I am asking if this is a problem in practice. For
>>> this to be a problem we'd need to trigger small writeback requests and
>>> have many memcgs.
>>>
>>>> This could cause the user-space agent to prematurely give up on zswap
>>>> writeback.
>>>
>>> Why? The kernel should not return before trying to writeback from all
>>> memcgs. If we scan the first N child memcgs and did not writeback
>>> enough, we should keep going, right?
>>>
>>
>> Yes, this issue is not caused by the kernel, but rather by our user-space
>> agent itself.
>>
>> For instance, suppose a parent memcg has two children, memcg1 and memcg2,
>> each with 200MB of zswap (100MB inactive). Triggering proactive writeback on
>> the parent memcg will exhaust memcg1's inactive zswap pages. After that,
>> even though memcg2 still has plenty of inactive zswap pages, it will
>> continue to write back memcg1's active zswap pages. Writing back active
>> zswap pages causes the user-space agent to prematurely abort the writeback
>> because it detects that certain memcg metrics have exceeded predefined
>> thresholds.
>
> This will only happen if the reclaim size is smaller than the batch
> size, right? Otherwise the kernel should reclaim more or less equally
> from both memcgs?
>
I gave it some thought. Not using a cursor could lead to unfairness
issues with certain writeback sizes:
- If the writeback size is an odd multiple of WB_BATCH (e.g.,
triggering a writeback of 3 * WB_BATCH), with 2 child cgroups, the
writeback ratio might end up being 2:1.
- If a memcg has 5 child cgroups and a writeback of 2 * WB_BATCH is
triggered, it might repeatedly write back from only the first 2 child
cgroups.
Although setting a smaller WB_BATCH might mitigate this unfairness, it
could hurt writeback efficiency. Let's just use per-memcg cursors to
completely fix these corner cases.
Thanks,
Hao
>> Of course, real-world scenarios are much more complex, and this kind of case
>> is extremely rare in our environment.
>>
>> That being said, your suggestion of using the global lock for the per-memcg
>> cursors makes the writeback fairer and would resolve these corner cases.
>
> Right, but I'd rather not do per-memcg cursors at all if we can avoid
> it. Will using batches help make reclaim fair over all memcgs without a
> cursor?
>
> We can always add the cursor later if needed.
^ permalink raw reply
* Re: [PATCH net-next V2 7/7] devlink: Add eswitch mode boot defaults
From: Mark Bloch @ 2026-06-04 1:16 UTC (permalink / raw)
To: Randy Dunlap, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, David S. Miller
Cc: Jonathan Corbet, Shuah Khan, Jiri Pirko, Simon Horman,
Sunil Goutham, Linu Cherian, Geetha sowjanya, hariprasad,
Subbaraya Sundeep, Bharat Bhushan, Saeed Mahameed,
Leon Romanovsky, Tariq Toukan, Borislav Petkov (AMD),
Andrew Morton, Peter Zijlstra (Intel), Thomas Gleixner,
Petr Mladek, Tejun Heo, Vlastimil Babka, Feng Tang, Dave Hansen,
Christian Brauner, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, Li RongQing, Paul E. McKenney, Ethan Nelson-Moore,
linux-doc, linux-kernel, netdev, linux-rdma
In-Reply-To: <d276e842-dd8f-40b7-806b-71572503005e@infradead.org>
On 03/06/2026 23:06, Randy Dunlap wrote:
> Hi.
>
> On 6/3/26 12:32 PM, Mark Bloch wrote:
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 063c11ca33e5..7af9f2898d92 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1264,6 +1264,31 @@ Kernel parameters
>> dell_smm_hwmon.fan_max=
>> [HW] Maximum configurable fan speed.
>>
>> + devlink_eswitch_mode=
>> + [NET]
>> + Format:
>> + [<selector>]:<mode>
>
> It appears (please correct me if I am mistaken) that the '[' and ']'
> above don't mean "optional" but instead they are required characters...
>
>> +
>> + <selector>:
>> + * | <handle>[,<handle>...]
>
> while here they mean "optional".
>
> That is confusing (inconsistent). Also, if the square brackets are
> always required around the <selector>, what purpose do they serve?
Yes, you are right, this is confusing. The outer square brackets are part of
the syntax and are required, while the brackets in "[,<handle>...]" mean that
additional handles are optional.
I couldn't find a better way to describe this. What I want to say is that the
selector is always wrapped in square brackets. Inside the brackets it can either
be "*" to match all devices, or a comma separated list of handles. If "*" is
not used, then at least one handle has to be provided.
Maybe it would be clearer to spell it out explicitly, something like:
Format:
[<selector>]:<mode>
The '[' and ']' characters are literal and required.
<selector>:
* | <handle>[,<handle>...]
If '*' is not used, <selector> must contain at least one <handle>.
Does that sound like a reasonable way to document it?
Mark
>
>> +
>> + <handle>:
>> + <bus-name>/<dev-name>
>> +
>> + Configure default devlink eswitch mode for matching
>> + devlink instances during device initialization.
>> +
>> + <mode>:
>> + legacy | switchdev | switchdev_inactive
>> +
>> + Examples:
>> + devlink_eswitch_mode=[*]:switchdev
>> + devlink_eswitch_mode=[pci/0000:08:00.0]:switchdev
>> + devlink_eswitch_mode=[pci/0000:08:00.0,pci/0000:09:00.1]:legacy
>> +
>> + See Documentation/networking/devlink/devlink-defaults.rst
>> + for the full syntax.
>> +
>> dfltcc= [HW,S390]
>> Format: { on | off | def_only | inf_only | always }
>> on: s390 zlib hardware support for compression on
>
>
^ permalink raw reply
* Re: [PATCH v6 11/12] ima: Support staging and deleting N measurements records
From: steven chen @ 2026-06-04 0:25 UTC (permalink / raw)
To: Roberto Sassu, corbet, skhan, zohar, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu, steven chen
In-Reply-To: <20260602111401.1706052-12-roberto.sassu@huaweicloud.com>
On 6/2/2026 4:14 AM, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Add support for sending a value N between 1 and ULONG_MAX to the IMA
> original measurement interface. This value represents the number of
> measurements that should be deleted from the current measurements list. In
> this case, measurements are staged in an internal non-user visible list,
> and immediately deleted.
>
> This staging method allows the remote attestation agents to easily separate
> the measurements that were verified (staged and deleted) from those that
> weren't due to the race between taking a TPM quote and reading the
> measurements list.
>
> In order to minimize the locking time of ima_extend_list_mutex, deleting
> N records is realized by doing a lockless walk in the current measurements
> list to determine the N-th entry to cut, to cut the current measurements
> list under the lock, and by deleting the excess records after releasing the
> lock.
>
> Flushing the hash table is not supported for N records, since it would
> require removing the N records one by one from the hash table under the
> ima_extend_list_mutex lock, which would increase the locking time.
>
> Link: https://github.com/linux-integrity/linux/issues/1
> Co-developed-by: Steven Chen <chenste@linux.microsoft.com>
Signed-off-by: Steven Chen <chenste@linux.microsoft.com>
> Co-developed-by: Roberto Sassu <roberto.sassu@huawei.com>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> ---
> security/integrity/ima/Kconfig | 3 ++
> security/integrity/ima/ima.h | 1 +
> security/integrity/ima/ima_fs.c | 32 +++++++++++++--
> security/integrity/ima/ima_queue.c | 63 ++++++++++++++++++++++++++++++
> 4 files changed, 96 insertions(+), 3 deletions(-)
>
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 02436670f746..f4d25e045808 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -341,6 +341,9 @@ config IMA_STAGING
> It allows user space to stage the measurements list for deletion and
> to delete the staged measurements after confirmation.
>
> + Or, alternatively, it allows user space to specify N measurements
> + records to stage internally, so that they can be immediately deleted.
> +
> On kexec, staging is aborted and any staged measurement records are
> copied to the secondary kernel.
>
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index d2e740c8ff75..7a1b2d6a8b59 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -320,6 +320,7 @@ struct ima_template_desc *lookup_template_desc(const char *name);
> bool ima_template_has_modsig(const struct ima_template_desc *ima_template);
> int ima_queue_stage(void);
> int ima_queue_staged_delete_all(void);
> +int ima_queue_delete_partial(unsigned long req_value);
> int ima_restore_measurement_entry(struct ima_template_entry *entry);
> int ima_restore_measurement_list(loff_t bufsize, void *buf);
> int ima_measurements_show(struct seq_file *m, void *v);
> diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
> index 96d7503a605b..174a94740da1 100644
> --- a/security/integrity/ima/ima_fs.c
> +++ b/security/integrity/ima/ima_fs.c
> @@ -28,6 +28,7 @@
> * Requests:
> * 'A\n': stage the entire measurements list
> * 'D\n': delete all staged measurements
> + * '[1, ULONG_MAX]\n' delete N measurements records
> */
> #define STAGED_REQ_LENGTH 21
>
> @@ -343,6 +344,7 @@ static ssize_t _ima_measurements_write(struct file *file,
> loff_t *ppos, bool staged_interface)
> {
> char req[STAGED_REQ_LENGTH];
> + unsigned long req_value;
> int ret;
>
> if (datalen < 2 || datalen > STAGED_REQ_LENGTH)
> @@ -370,7 +372,24 @@ static ssize_t _ima_measurements_write(struct file *file,
> ret = ima_queue_staged_delete_all();
> break;
> default:
> - ret = -EINVAL;
> + if (staged_interface)
> + return -EINVAL;
> +
> + if (ima_flush_htable) {
> + pr_debug("Deleting staged N measurements not supported when flushing the hash table is requested\n");
> + return -EINVAL;
> + }
> +
> + ret = kstrtoul(req, 10, &req_value);
> + if (ret < 0)
> + return ret;
> +
> + if (req_value == 0) {
> + pr_debug("Must delete at least one entry\n");
> + return -EINVAL;
> + }
> +
> + ret = ima_queue_delete_partial(req_value);
> }
>
> if (ret < 0)
> @@ -379,6 +398,12 @@ static ssize_t _ima_measurements_write(struct file *file,
> return datalen;
> }
>
> +static ssize_t ima_measurements_write(struct file *file, const char __user *buf,
> + size_t datalen, loff_t *ppos)
> +{
> + return _ima_measurements_write(file, buf, datalen, ppos, false);
> +}
> +
> static ssize_t ima_measurements_staged_write(struct file *file,
> const char __user *buf,
> size_t datalen, loff_t *ppos)
> @@ -389,6 +414,7 @@ static ssize_t ima_measurements_staged_write(struct file *file,
> static const struct file_operations ima_measurements_ops = {
> .open = ima_measurements_open,
> .read = seq_read,
> + .write = ima_measurements_write,
> .llseek = seq_lseek,
> .release = ima_measurements_release,
> };
> @@ -470,6 +496,7 @@ static int ima_ascii_measurements_open(struct inode *inode, struct file *file)
> static const struct file_operations ima_ascii_measurements_ops = {
> .open = ima_ascii_measurements_open,
> .read = seq_read,
> + .write = ima_measurements_write,
> .llseek = seq_lseek,
> .release = ima_measurements_release,
> };
> @@ -603,14 +630,13 @@ static int __init create_securityfs_measurement_lists(bool staging)
> {
> const struct file_operations *ascii_ops = &ima_ascii_measurements_ops;
> const struct file_operations *binary_ops = &ima_measurements_ops;
> - umode_t permissions = (S_IRUSR | S_IRGRP);
> + umode_t permissions = (S_IRUSR | S_IRGRP | S_IWUSR | S_IWGRP);
> const char *file_suffix = "";
> int count = NR_BANKS(ima_tpm_chip);
>
> if (staging) {
> ascii_ops = &ima_ascii_measurements_staged_ops;
> binary_ops = &ima_measurements_staged_ops;
> - permissions |= (S_IWUSR | S_IWGRP);
> file_suffix = "_staged";
> }
>
> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
> index af0502f27d57..718991ba8bcd 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -405,6 +405,69 @@ int ima_queue_staged_delete_all(void)
> return 0;
> }
>
> +/**
> + * ima_queue_delete_partial - Delete current measurements
> + * @req_value: Number of measurements to delete
> + *
> + * Delete the requested number of measurements from the current measurements
> + * list, and update the number of records and the binary run-time size
> + * accordingly.
> + *
> + * Refuse to delete current measurements if measurement is suspended, so that
> + * dump can be done in a lockless way and user space is notified about current
> + * measurements being carried over to the secondary kernel, so that it does not
> + * save them twice.
> + *
> + * Return: Zero on success, a negative value otherwise.
> + */
> +int ima_queue_delete_partial(unsigned long req_value)
> +{
> + unsigned long req_value_copy = req_value;
> + unsigned long size_to_remove = 0, num_to_remove = 0;
> + LIST_HEAD(ima_measurements_trim);
> + struct ima_queue_entry *qe;
> + int ret = 0;
> +
> + /*
> + * list_for_each_entry_rcu() without rcu_read_lock() is fine because
> + * only list append can happen concurrently. No list replace due to the
> + * staging/delete writers mutual exclusion.
> + */
> + list_for_each_entry_rcu(qe, &ima_measurements, later, true) {
> + size_to_remove += get_binary_runtime_size(qe->entry);
> + num_to_remove++;
> +
> + if (--req_value_copy == 0)
> + break;
> + }
> +
> + /* Not enough records to delete. */
> + if (req_value_copy > 0)
> + return -ENOENT;
> +
> + mutex_lock(&ima_extend_list_mutex);
> + if (ima_measurements_suspended) {
> + mutex_unlock(&ima_extend_list_mutex);
> + return -ESTALE;
> + }
> +
> + /*
> + * qe remains valid because ima_fs.c enforces single-writer exclusion.
> + */
> + __list_cut_position(&ima_measurements_trim, &ima_measurements,
> + &qe->later);
> +
> + atomic_long_sub(num_to_remove, &ima_num_records[BINARY]);
> +
> + if (IS_ENABLED(CONFIG_IMA_KEXEC))
> + binary_runtime_size[BINARY] -= size_to_remove;
> +
> + mutex_unlock(&ima_extend_list_mutex);
> +
> + ima_queue_delete(&ima_measurements_trim, false);
> + return ret;
> +}
> +
> /**
> * ima_queue_delete - Delete measurements
> * @head: List head measurements are deleted from
^ permalink raw reply
* [PATCH] docs: pt_BR: update "Purpose of Defconfigs" section in maintainer-soc.rst
From: Amanda Corrêa @ 2026-06-04 0:22 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Amanda Corrêa
This update includes the "Purpose of Defconfigs" section translated
to Brazilian Portuguese.
Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
---
.../translations/pt_BR/process/maintainer-soc.rst | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-soc.rst b/Documentation/translations/pt_BR/process/maintainer-soc.rst
index 5a3ae213e..96dc9a130 100644
--- a/Documentation/translations/pt_BR/process/maintainer-soc.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-soc.rst
@@ -8,7 +8,7 @@ Visão Geral
-----------
O subsistema SoC é um local de agregação para códigos específicos de SoC
-System on Chip). Os principais componentes do subsistema são:
+(System on Chip). Os principais componentes do subsistema são:
* Devicetrees (DTS) para ARM de 32 e 64 bits e RISC-V.
* Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*).
@@ -220,3 +220,13 @@ A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita
usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve
descrição resumindo as alterações no pull request. Para mais detalhes sobre o
envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``.
+
+Propósito do Defconfigs
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
+distribuições têm suas próprias configurações. Uma mudança que adiciona novas
+opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
+em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
+suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
+para máquinas não upstream não deve ser aceito.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 1/3] mm/swap: colocate page-cluster sysctl with swap readahead
From: Barry Song @ 2026-06-04 0:14 UTC (permalink / raw)
To: Jianyue Wu
Cc: Andrew Morton, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Youngjun Park, Qi Zheng, Shakeel Butt, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Johannes Weiner, David Hildenbrand,
Michal Hocko, Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Hugh Dickins,
Baolin Wang, Jonathan Corbet, Shuah Khan, linux-mm, linux-kernel,
linux-doc
In-Reply-To: <20260603-ch-swap-series-plus-folio-lru-cleanup-v4-1-ce0219e100d9@gmail.com>
On Wed, Jun 3, 2026 at 9:05 PM Jianyue Wu <wujianyue000@gmail.com> wrote:
>
> page_cluster and the vm.page-cluster sysctl are only used by swap-in
> readahead in swap_state.c. Move them out of swap.c together with
> swap_readahead_setup(), and make page_cluster static to that file.
>
> Rename swap_setup() while moving it as well. The helper is internal to
> MM and now only sets up swap readahead defaults and its sysctl hook, so
> the more specific name matches its reduced scope.
>
> swap_setup() previously lived in mm/swap.c, which is built
> unconditionally, so the vm.page-cluster sysctl was registered also on
> CONFIG_SWAP=n kernels. swap_readahead_setup() is now a no-op stub when
> CONFIG_SWAP is disabled, so vm.page-cluster is no longer registered
> there. The knob only tunes swap-in readahead and had no effect without
> swap.
>
> Suggested-by: Baoquan He <bhe@redhat.com>
> Suggested-by: Barry Song <baohua@kernel.org>
> Signed-off-by: Jianyue Wu <wujianyue000@gmail.com>
> ---
Reviewed-by: Barry Song <baohua@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next] docs: exclude driver and netdevsim bugs
From: Jacob Keller @ 2026-06-03 22:54 UTC (permalink / raw)
To: Johannes Berg, Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
workflows, linux-doc
In-Reply-To: <c78c1ff315ec96795461f100064bc42c524a67e3.camel@sipsolutions.net>
On 6/3/2026 1:12 PM, Johannes Berg wrote:
> On Wed, 2026-06-03 at 09:29 -0700, Jakub Kicinski wrote:
>>
>> +Additionally, netdev does not consider bugs to be ``net``-worthy
>> +if they fulfill **all** of the following criteria:
>> + - bug is in a hardware device driver;
>> + - bug is either a missing error handling or is part of the error handling flow;
>
> Do you really want to be this specific?
>
I agree, this does feel a little overly specific. Perhaps there is
better wording to clarify the intent such that it could cover your
example as well? Hmm.
> Take this fix for example that I mentioned the other day:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260531145435.701703-1-runyu.xiao@seu.edu.cn/
>
> It doesn't formally fall under that definition, but I think it should,
> it's a silly thing to send to stable etc.
>
> This isn't even a USB device where you could reasonably argue that
> someone might plug in a random one and it could be programmed to look
> like the device in question and misbehave. Sure, you can build PCIe
> hardware too that can do that, technically, and there's technically
> external PCIe via Thunderbolt, but it's still far harder to actually do
> anything with.
>
>> + - bug was discovered by a static analysis / AI tool;
>
> I'm not (yet?) convinced that this bullet point is right.
>
> It risks getting into an argument about how much the LLM did to discover
> it, or if the actual discovery was a manual process after the LLM
> pointed out issues, or whatever ...
>
> Maybe more importantly, why should that even change the result?
>
> It's true that today the reason to start spelling this out more clearly
> is AI related, but that's really because of (a) the scale, and (b) many
> of the people running the LLMs not being aware of (and frankly often not
> really caring about) the community norms. I'm not convinced that the
> "silliness" of a change should be measured by how it originated.
>
Right. The point to me seems that "fixes" made purely to resolve tool
hits (static analysis, checkpatch, LLM, whatever) have lower value than
fixes which have a stronger motivation such as user reports.
I'm not sure I have a better wording, and perhaps you could remove this
bit entirely.
>> + - bug was triggered/observed only with kernel changes or fault injection.
>
> Given this fourth bullet point, we'd still accept fixes for such driver
> problems that people actually run into, while excluding "theoretical"
> things that are discovered by "reading the code".
>
Right. One could argue that some race conditions are difficult to
trigger because a window is very narrow, and fault injection could make
it much easier... But we could still accept such fixes as development
improvement rather than through the "net" tree, so I think this criteria
is good.
> johannes
>
^ permalink raw reply
* Re: [PATCH v2 4/4] dt-bindings: input: remove obsolete matrix-keymap.txt
From: Rob Herring (Arm) @ 2026-06-03 22:26 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Conor Dooley, David S. Miller, Andrew Lunn, linux-tegra,
linux-input, Mauro Carvalho Chehab, Heiner Kallweit,
Thierry Reding, linux-media, Krzysztof Kozlowski, Jakub Kicinski,
Vladimir Oltean, linux-doc, linux-kernel, Eric Dumazet,
Dmitry Torokhov, Jonathan Hunter, Simon Horman, devicetree,
Paolo Abeni, Lee Jones, netdev, Shuah Khan, Russell King,
Jonathan Corbet
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-4-c8c19876ab64@gmail.com>
On Wed, 03 Jun 2026 15:42:21 -0500, Akash Sukhavasi wrote:
> matrix-keymap.txt has been a single-line redirect to
> matrix-keymap.yaml since commit 639d6eda3b80 ("dt-bindings: input:
> Convert matrix-keymap to json-schema"), which introduced the .yaml
> schema and reduced the .txt to a stub in the same change. The .yaml
> has the same filename in the same directory, making this redirect
> unnecessary for discoverability.
>
> Eight instances across six files still reference matrix-keymap.txt,
> forcing readers through an extra hop to reach the .yaml. The stub has
> not been touched since June 2020. Update all references across input
> and mfd binding documentation to point directly to matrix-keymap.yaml
> and remove the stub.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> v2:
> - Patch 4/4: corrected commit message (eight references in six files,
> not eight files), Sashiko review.
> https://sashiko.dev/#/patchset/20260529052246.4934-1-akash.sukhavasi@gmail.com?part=4
>
> v1: https://lore.kernel.org/all/20260529052246.4934-5-akash.sukhavasi@gmail.com/
> ---
> Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt | 2 +-
> Documentation/devicetree/bindings/input/clps711x-keypad.txt | 2 +-
> Documentation/devicetree/bindings/input/matrix-keymap.txt | 1 -
> Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | 2 +-
> Documentation/devicetree/bindings/input/pxa27x-keypad.txt | 2 +-
> Documentation/devicetree/bindings/input/st-keyscan.txt | 2 +-
> Documentation/devicetree/bindings/mfd/tc3589x.txt | 6 +++---
> 7 files changed, 8 insertions(+), 9 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/4] dt-bindings: remove redundant .txt redirect stubs
From: Rob Herring @ 2026-06-03 22:21 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Vladimir Oltean,
Simon Horman, Jonathan Corbet, Shuah Khan, Dmitry Torokhov,
Thierry Reding, Jonathan Hunter, Lee Jones, netdev, devicetree,
linux-kernel, linux-media, linux-doc, linux-input, linux-tegra
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
On Wed, Jun 03, 2026 at 03:42:17PM -0500, Akash Sukhavasi wrote:
> Several .txt files under Documentation/devicetree/bindings/ contain
> only a redirect notice pointing to a .yaml schema with the same base
> filename in the same directory. These stubs were useful during the
> .txt to .yaml transition but are now redundant, since the .yaml is
> discoverable by name. Meanwhile, other documentation still references
> some of these stubs, forcing readers through an unnecessary extra hop
> to reach the actual schema.
>
> This series removes four such stubs and updates all remaining
> cross-references to point directly to the .yaml schemas.
>
> Other redirect stubs in the tree were evaluated and intentionally
> kept:
>
> - Stubs pointing to .yaml files with different names (e.g.,
> spi-bus.txt -> spi-controller.yaml) serve as breadcrumbs for
> the renamed schema.
>
> - Stubs pointing to multiple .yaml files (e.g., nvmem.txt ->
> nvmem.yaml and nvmem-consumer.yaml) convey that the content
> was split.
>
> - Stubs pointing to .yaml files in a different directory (e.g.,
> reset/st,stm32-rcc.txt -> clock/st,stm32-rcc.yaml) serve as
> cross-directory pointers.
>
> Two additional same-name, same-directory stubs (leds/common.txt,
> regulator/regulator.txt) have significantly more cross references
> and will be addressed in a follow-up series.
>
> v2:
> - Patch 4/4: corrected commit message (eight references in six files, not
> eight files), Sashiko review.
> https://sashiko.dev/#/patchset/20260529052246.4934-1-akash.sukhavasi@gmail.com?part=4
>
> v1: https://lore.kernel.org/all/20260529052246.4934-1-akash.sukhavasi@gmail.com/
>
> Patch 1 supersedes my earlier standalone submission:
> https://lore.kernel.org/all/20260523004223.3045-1-akash.sukhavasi@gmail.com/
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> Akash Sukhavasi (4):
> dt-bindings: net: remove obsolete mdio.txt
> dt-bindings: media: remove obsolete rc.txt
> dt-bindings: net: dsa: remove obsolete dsa.txt
> dt-bindings: input: remove obsolete matrix-keymap.txt
This goes to 3 different subsystems, so it should be 3 different series.
No need to resend just for that.
Rob
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: net: dsa: remove obsolete dsa.txt
From: Rob Herring (Arm) @ 2026-06-03 22:20 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Dmitry Torokhov, linux-media, Thierry Reding, linux-input,
Eric Dumazet, linux-tegra, Shuah Khan, David S. Miller,
Krzysztof Kozlowski, Conor Dooley, devicetree,
Mauro Carvalho Chehab, Heiner Kallweit, Andrew Lunn, Simon Horman,
Jakub Kicinski, netdev, linux-kernel, Jonathan Hunter, Lee Jones,
Russell King, Paolo Abeni, Vladimir Oltean, Jonathan Corbet,
linux-doc
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-3-c8c19876ab64@gmail.com>
On Wed, 03 Jun 2026 15:42:20 -0500, Akash Sukhavasi wrote:
> dsa.txt has been a redirect to dsa.yaml since commit bce58590d1bd
> ("dt-bindings: net: dsa: Add DSA yaml binding") introduced the .yaml
> schema. The .yaml has the same filename in the same directory, making
> this redirect unnecessary for discoverability.
>
> Two files still reference dsa.txt, forcing readers through an extra
> hop to reach the .yaml. The stub has not been touched since August
> 2020. Update references in lan9303.txt and
> Documentation/networking/dsa/dsa.rst to point directly to dsa.yaml
> and remove the stub.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> Documentation/devicetree/bindings/net/dsa/dsa.txt | 4 ----
> Documentation/devicetree/bindings/net/dsa/lan9303.txt | 2 +-
> Documentation/networking/dsa/dsa.rst | 2 +-
> 3 files changed, 2 insertions(+), 6 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: media: remove obsolete rc.txt
From: Rob Herring (Arm) @ 2026-06-03 22:20 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Jakub Kicinski, Jonathan Hunter, Paolo Abeni, linux-kernel,
linux-input, Heiner Kallweit, Eric Dumazet, devicetree,
Simon Horman, Mauro Carvalho Chehab, linux-media, linux-tegra,
David S. Miller, Jonathan Corbet, Shuah Khan, Conor Dooley,
Lee Jones, Andrew Lunn, Krzysztof Kozlowski, Russell King,
linux-doc, netdev, Vladimir Oltean, Dmitry Torokhov,
Thierry Reding
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-2-c8c19876ab64@gmail.com>
On Wed, 03 Jun 2026 15:42:19 -0500, Akash Sukhavasi wrote:
> rc.txt has been a single-line redirect to rc.yaml since
> commit 7c31b9d67342 ("media: dt-bindings: media: Add YAML schemas for
> the generic RC bindings"), which introduced the .yaml schema and
> reduced the .txt to a stub in the same change. The .yaml has the same
> filename in the same directory, making this redirect unnecessary
> for discoverability.
>
> One file still references rc.txt, forcing readers through an extra
> hop to reach the .yaml. The stub has not been touched since August
> 2019. Update the reference in hix5hd2-ir.txt to point directly to
> rc.yaml and remove the stub.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> Documentation/devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
> Documentation/devicetree/bindings/media/rc.txt | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: net: remove obsolete mdio.txt
From: Rob Herring (Arm) @ 2026-06-03 22:19 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Heiner Kallweit, David S. Miller, Vladimir Oltean, linux-media,
linux-tegra, Dmitry Torokhov, linux-doc, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-kernel, Mauro Carvalho Chehab,
devicetree, Simon Horman, Andrew Lunn, Paolo Abeni, Lee Jones,
Krzysztof Kozlowski, netdev, Eric Dumazet, linux-input,
Russell King, Thierry Reding, Jonathan Hunter, Jakub Kicinski
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-1-c8c19876ab64@gmail.com>
On Wed, 03 Jun 2026 15:42:18 -0500, Akash Sukhavasi wrote:
> mdio.txt has been a single-line redirect to mdio.yaml since
> commit 62d77ff7ecbf ("dt-bindings: net: Add a YAML schemas for the
> generic MDIO options"), which introduced the .yaml schema and reduced
> the .txt to a stub in the same change. The .yaml has the same filename
> in the same directory, making this redirect unnecessary for
> discoverability.
>
> No files in the tree reference mdio.txt and it has not been touched
> since June 2019. Remove the obsolete stub.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> Documentation/devicetree/bindings/net/mdio.txt | 1 -
> 1 file changed, 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 00/42] guest_memfd: In-place conversion support
From: Ackerley Tng @ 2026-06-03 21:27 UTC (permalink / raw)
To: Ackerley Tng via B4 Relay, aik, andrew.jones, binbin.wu, brauner,
chao.p.peng, david, ira.weiny, 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, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka
Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260522-gmem-inplace-conversion-v7-0-2f0fae496530@google.com>
Ackerley Tng via B4 Relay <devnull+ackerleytng.google.com@kernel.org>
writes:
> This is v7 of guest_memfd in-place conversion support.
>
Here's the outstanding items after going over everyone's comments
including Sashiko's:
+ KVM: TDX: Make source page optional for KVM_TDX_INIT_MEM_REGION
+ Need to move page clearing into __kvm_gmem_get_pfn to resolve
leak where populate can put initialized kernel memory into TDX
guest
+ See suggested fix at [1]
+ KVM: guest_memfd: Only prepare folios for private pages,
+ s/non-CoCo/CoCo in commit message "INIT_SHARED is about to be
supported for non-CoCo VMs in a later patch in this series
+ Use Suggested-by: Michael Roth <michael.roth@amd.com>
+ KVM: selftests: Test that shared/private status is consistent across
processes
+ Improve test reliability using pthread_mutex
+ I have a fixup patch offline.
I would like feedback on these:
+ KVM: selftests: Test conversion with elevated page refcount
+ Askar pointed out that soon vmsplice may not pin pages. Should I
pin pages through CONFIG_GUP_TEST like in [2]? I prefer not to
take a dependency on CONFIG_GUP_TEST.
+ KVM: selftests: Add script to exercise private_mem_conversions_test
+ Would like to know what people think of a wrapper script before
I address Sashiko's comments.
[1] https://lore.kernel.org/all/CAEvNRgEVC=fFuKVgZYvWyZD7t_zvUZihFG8hrACjvtkD5cwugw@mail.gmail.com/
[2] https://lore.kernel.org/all/baa8838f623102931e755cf34c86314b305af49c.1747264138.git.ackerleytng@google.com/
>
> [...snip...]
>
^ permalink raw reply
* [PATCH v2 1/1] dt-bindings: net: dsa: Convert lan9303.txt to yaml format
From: Frank.Li @ 2026-06-03 21:09 UTC (permalink / raw)
To: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan, Frank Li,
open list:NETWORKING DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:DOCUMENTATION
Cc: imx
From: Frank Li <Frank.Li@nxp.com>
Convert lan9303.txt to yaml format to fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx53-kp-hsc.dtb: /soc/bus@50000000/i2c@53fec000/switch@a: failed to match any schema with compatible: ['smsc,lan9303-i2c']
Additional changes:
- rename switch-phy to switch in example.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2:
- fix typo Additional in commit message
- add rob's reviewed-by tags
- fix doc ref problem
---
.../devicetree/bindings/net/dsa/lan9303.txt | 100 --------------
.../bindings/net/dsa/smsc,lan9303.yaml | 123 ++++++++++++++++++
Documentation/networking/dsa/lan9303.rst | 2 +-
3 files changed, 124 insertions(+), 101 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/dsa/lan9303.txt
create mode 100644 Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
deleted file mode 100644
index 46a732087f5ca..0000000000000
--- a/Documentation/devicetree/bindings/net/dsa/lan9303.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-SMSC/MicroChip LAN9303 three port ethernet switch
--------------------------------------------------
-
-Required properties:
-
-- compatible: should be
- - "smsc,lan9303-i2c" for I2C managed mode
- or
- - "smsc,lan9303-mdio" for mdio managed mode
-
-Optional properties:
-
-- reset-gpios: GPIO to be used to reset the whole device
-- reset-duration: reset duration in milliseconds, defaults to 200 ms
-
-Subnodes:
-
-The integrated switch subnode should be specified according to the binding
-described in dsa/dsa.txt. The CPU port of this switch is always port 0.
-
-Note: always use 'reg = <0/1/2>;' for the three DSA ports, even if the device is
-configured to use 1/2/3 instead. This hardware configuration will be
-auto-detected and mapped accordingly.
-
-Example:
-
-I2C managed mode:
-
- master: masterdevice@X {
-
- fixed-link { /* RMII fixed link to LAN9303 */
- speed = <100>;
- full-duplex;
- };
- };
-
- switch: switch@a {
- compatible = "smsc,lan9303-i2c";
- reg = <0xa>;
- reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
- reset-duration = <200>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 { /* RMII fixed link to master */
- reg = <0>;
- ethernet = <&master>;
- };
-
- port@1 { /* external port 1 */
- reg = <1>;
- label = "lan1";
- };
-
- port@2 { /* external port 2 */
- reg = <2>;
- label = "lan2";
- };
- };
- };
-
-MDIO managed mode:
-
- master: masterdevice@X {
- phy-handle = <&switch>;
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- switch: switch-phy@0 {
- compatible = "smsc,lan9303-mdio";
- reg = <0>;
- reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
- reset-duration = <100>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- ethernet = <&master>;
- };
-
- port@1 { /* external port 1 */
- reg = <1>;
- label = "lan1";
- };
-
- port@2 { /* external port 2 */
- reg = <2>;
- label = "lan2";
- };
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml b/Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
new file mode 100644
index 0000000000000..42f8473538a07
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/smsc,lan9303.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SMSC/MicroChip LAN9303 three port ethernet switch
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The LAN9303 is a three port ethernet switch with integrated PHYs for the
+ two external ports. The third port is an RMII/MII interface to a host
+ processor. The device can be managed via I2C or MDIO.
+
+ Note - always use 'reg = <0/1/2>;' for the three DSA ports, even if the
+ device is configured to use 1/2/3 instead. This hardware configuration
+ will be auto-detected and mapped accordingly.
+
+properties:
+ compatible:
+ enum:
+ - smsc,lan9303-i2c
+ - smsc,lan9303-mdio
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ GPIO to be used to reset the whole device
+ maxItems: 1
+
+ reset-duration:
+ description:
+ Reset duration in milliseconds
+ default: 200
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: dsa.yaml#
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ /* I2C managed mode */
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@a {
+ compatible = "smsc,lan9303-i2c";
+ reg = <0xa>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <200>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ /* MDIO managed mode */
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "smsc,lan9303-mdio";
+ reg = <0>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <100>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+ };
diff --git a/Documentation/networking/dsa/lan9303.rst b/Documentation/networking/dsa/lan9303.rst
index ab81b4e0139e3..776572be265e1 100644
--- a/Documentation/networking/dsa/lan9303.rst
+++ b/Documentation/networking/dsa/lan9303.rst
@@ -12,7 +12,7 @@ Driver details
The driver is implemented as a DSA driver, see ``Documentation/networking/dsa/dsa.rst``.
-See ``Documentation/devicetree/bindings/net/dsa/lan9303.txt`` for device tree
+See ``Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml`` for device tree
binding.
The LAN9303 can be managed both via MDIO and I2C, both supported by this driver.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 0/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: vladimir.murzin, xuwei5, broonie, ryan.roberts, corbet,
catalin.marinas, oupton, kevin.brodsky, maz, yeoreum.yun, skhan,
yangyicong, thuth, kuninori.morimoto.gx, lucaswei, lpieralisi,
miko.lenczewski, mark.rutland, james.clark, Zeng Heng
Cc: kernel-team, Will Deacon, wangkefeng.wang, linux-arm-kernel,
linux-kernel, linux-doc, zengheng4
In-Reply-To: <20260603062025.1504083-1-zengheng@huaweicloud.com>
On Wed, 03 Jun 2026 14:20:23 +0800, Zeng Heng wrote:
> v3: https://lore.kernel.org/all/20260601112000.1145391-1-zengheng@huaweicloud.com/
> v2: https://lore.kernel.org/all/20260529063132.766491-1-zengheng@huaweicloud.com/
> v1: https://lore.kernel.org/all/20260526015720.206854-1-zengheng@huaweicloud.com/
>
> Changes in v4:
> - Keep orthogonality for CONFIG_NVIDIA_CARMEL_CNP_ERRATUM and
> CONFIG_HISILICON_ERRATUM_162100125 within the cnp_erratum_cpus array.
>
> [...]
Applied to arm64 (for-next/errata), thanks!
[1/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
https://git.kernel.org/arm64/c/25996982ebcf
[2/2] arm64: kernel: Disable CNP on HiSilicon HIP09
https://git.kernel.org/arm64/c/f64328ecf4bf
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] arm64: Document SVE constraints on new hwcaps
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-doc,
linux-kernel
In-Reply-To: <20260522-arm64-elf-hwcaps-sve-cleanup-v1-1-07b0cedfc6fa@kernel.org>
On Fri, 22 May 2026 18:50:28 +0100, Mark Brown wrote:
> Two of the SVE hwcaps added for the SVE features in the 2025 dpISA did
> not explicitly call out their dependency on SVE in the ABI documentation.
> Do so.
>
> While we're here reorder the SVE and fature specific ID registers for
> HWCAP3_SVE_LUT6 which did have the SVE dependency but listed it second
> unlike the other SVE specific ID registers.
>
> [...]
Applied to arm64 (for-next/cpufeature), thanks!
[1/1] arm64: Document SVE constraints on new hwcaps
https://git.kernel.org/arm64/c/f20f8fe086b2
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* [PATCH v2 4/4] dt-bindings: input: remove obsolete matrix-keymap.txt
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
matrix-keymap.txt has been a single-line redirect to
matrix-keymap.yaml since commit 639d6eda3b80 ("dt-bindings: input:
Convert matrix-keymap to json-schema"), which introduced the .yaml
schema and reduced the .txt to a stub in the same change. The .yaml
has the same filename in the same directory, making this redirect
unnecessary for discoverability.
Eight instances across six files still reference matrix-keymap.txt,
forcing readers through an extra hop to reach the .yaml. The stub has
not been touched since June 2020. Update all references across input
and mfd binding documentation to point directly to matrix-keymap.yaml
and remove the stub.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
v2:
- Patch 4/4: corrected commit message (eight references in six files,
not eight files), Sashiko review.
https://sashiko.dev/#/patchset/20260529052246.4934-1-akash.sukhavasi@gmail.com?part=4
v1: https://lore.kernel.org/all/20260529052246.4934-5-akash.sukhavasi@gmail.com/
---
Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/clps711x-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/matrix-keymap.txt | 1 -
Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | 2 +-
Documentation/devicetree/bindings/input/pxa27x-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/st-keyscan.txt | 2 +-
Documentation/devicetree/bindings/mfd/tc3589x.txt | 6 +++---
7 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
index 262deab73588..33514eba0c9c 100644
--- a/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
+++ b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
@@ -59,7 +59,7 @@ Board Specific Properties:
subsystem (optional).
- linux,keymap: The keymap for keys as described in the binding document
- devicetree/bindings/input/matrix-keymap.txt.
+ devicetree/bindings/input/matrix-keymap.yaml.
Example:
#include "dt-bindings/input/input.h"
diff --git a/Documentation/devicetree/bindings/input/clps711x-keypad.txt b/Documentation/devicetree/bindings/input/clps711x-keypad.txt
index 3eed8819d05d..5f4514c0cd5f 100644
--- a/Documentation/devicetree/bindings/input/clps711x-keypad.txt
+++ b/Documentation/devicetree/bindings/input/clps711x-keypad.txt
@@ -5,7 +5,7 @@ Required Properties:
- row-gpios: List of GPIOs used as row lines.
- poll-interval: Poll interval time in milliseconds.
- linux,keymap: The definition can be found at
- bindings/input/matrix-keymap.txt.
+ bindings/input/matrix-keymap.yaml.
Optional Properties:
- autorepeat: Enable autorepeat feature.
diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt
deleted file mode 100644
index 79f6d01aecaa..000000000000
--- a/Documentation/devicetree/bindings/input/matrix-keymap.txt
+++ /dev/null
@@ -1 +0,0 @@
-This file has been moved to matrix-keymap.yaml
diff --git a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
index 1faa7292e21f..460b64d332cd 100644
--- a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
+++ b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
@@ -12,7 +12,7 @@ Required properties:
- nvidia,kbc-col-pins: The KBC pins which are configured as column. This is an
array of pin numbers which is used as column.
- linux,keymap: The keymap for keys as described in the binding document
- devicetree/bindings/input/matrix-keymap.txt.
+ devicetree/bindings/input/matrix-keymap.yaml.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each entry in reset-names.
diff --git a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
index f8674f7e5ea5..a727d66eece4 100644
--- a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
+++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
@@ -10,7 +10,7 @@ Required Properties
interval for matrix key. The value is in binary number of 2ms
Optional Properties For Matrix Keyes
-Please refer to matrix-keymap.txt
+Please refer to matrix-keymap.yaml
Optional Properties for Direct Keyes
- marvell,direct-key-count : How many direct keyes are used.
diff --git a/Documentation/devicetree/bindings/input/st-keyscan.txt b/Documentation/devicetree/bindings/input/st-keyscan.txt
index 51eb428e5c85..fd88f40faebf 100644
--- a/Documentation/devicetree/bindings/input/st-keyscan.txt
+++ b/Documentation/devicetree/bindings/input/st-keyscan.txt
@@ -17,7 +17,7 @@ Required properties:
See ../pinctrl/pinctrl-bindings.txt for details.
- linux,keymap: The keymap for keys as described in the binding document
- devicetree/bindings/input/matrix-keymap.txt.
+ devicetree/bindings/input/matrix-keymap.yaml.
- keypad,num-rows: Number of row lines connected to the keypad controller.
diff --git a/Documentation/devicetree/bindings/mfd/tc3589x.txt b/Documentation/devicetree/bindings/mfd/tc3589x.txt
index 4f22b2b07dc5..a6d356e90f42 100644
--- a/Documentation/devicetree/bindings/mfd/tc3589x.txt
+++ b/Documentation/devicetree/bindings/mfd/tc3589x.txt
@@ -48,11 +48,11 @@ Optional nodes:
- compatible : must be "toshiba,tc3589x-keypad"
- debounce-delay-ms : debounce interval in milliseconds
- keypad,num-rows : number of rows in the matrix, see
- bindings/input/matrix-keymap.txt
+ bindings/input/matrix-keymap.yaml
- keypad,num-columns : number of columns in the matrix, see
- bindings/input/matrix-keymap.txt
+ bindings/input/matrix-keymap.yaml
- linux,keymap: the definition can be found in
- bindings/input/matrix-keymap.txt
+ bindings/input/matrix-keymap.yaml
- linux,no-autorepeat: do no enable autorepeat feature.
- wakeup-source: use any event on keypad as wakeup event.
(Legacy property supported: "linux,wakeup")
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: net: dsa: remove obsolete dsa.txt
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
dsa.txt has been a redirect to dsa.yaml since commit bce58590d1bd
("dt-bindings: net: dsa: Add DSA yaml binding") introduced the .yaml
schema. The .yaml has the same filename in the same directory, making
this redirect unnecessary for discoverability.
Two files still reference dsa.txt, forcing readers through an extra
hop to reach the .yaml. The stub has not been touched since August
2020. Update references in lan9303.txt and
Documentation/networking/dsa/dsa.rst to point directly to dsa.yaml
and remove the stub.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Documentation/devicetree/bindings/net/dsa/dsa.txt | 4 ----
Documentation/devicetree/bindings/net/dsa/lan9303.txt | 2 +-
Documentation/networking/dsa/dsa.rst | 2 +-
3 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.txt b/Documentation/devicetree/bindings/net/dsa/dsa.txt
deleted file mode 100644
index dab208b5c7c7..000000000000
--- a/Documentation/devicetree/bindings/net/dsa/dsa.txt
+++ /dev/null
@@ -1,4 +0,0 @@
-Distributed Switch Architecture Device Tree Bindings
-----------------------------------------------------
-
-See Documentation/devicetree/bindings/net/dsa/dsa.yaml for the documentation.
diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
index 46a732087f5c..0337c2ccfa9a 100644
--- a/Documentation/devicetree/bindings/net/dsa/lan9303.txt
+++ b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
@@ -16,7 +16,7 @@ Optional properties:
Subnodes:
The integrated switch subnode should be specified according to the binding
-described in dsa/dsa.txt. The CPU port of this switch is always port 0.
+described in dsa/dsa.yaml. The CPU port of this switch is always port 0.
Note: always use 'reg = <0/1/2>;' for the three DSA ports, even if the device is
configured to use 1/2/3 instead. This hardware configuration will be
diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst
index fd3c254ced1d..42a99f5dfa2e 100644
--- a/Documentation/networking/dsa/dsa.rst
+++ b/Documentation/networking/dsa/dsa.rst
@@ -509,7 +509,7 @@ Device Tree
-----------
DSA features a standardized binding which is documented in
-``Documentation/devicetree/bindings/net/dsa/dsa.txt``. PHY/MDIO library helper
+``Documentation/devicetree/bindings/net/dsa/dsa.yaml``. PHY/MDIO library helper
functions such as ``of_get_phy_mode()``, ``of_phy_connect()`` are also used to query
per-port PHY specific details: interface connection, MDIO bus location, etc.
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: media: remove obsolete rc.txt
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
rc.txt has been a single-line redirect to rc.yaml since
commit 7c31b9d67342 ("media: dt-bindings: media: Add YAML schemas for
the generic RC bindings"), which introduced the .yaml schema and
reduced the .txt to a stub in the same change. The .yaml has the same
filename in the same directory, making this redirect unnecessary
for discoverability.
One file still references rc.txt, forcing readers through an extra
hop to reach the .yaml. The stub has not been touched since August
2019. Update the reference in hix5hd2-ir.txt to point directly to
rc.yaml and remove the stub.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Documentation/devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
Documentation/devicetree/bindings/media/rc.txt | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
index ca4cf774662e..f777c2707e65 100644
--- a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
+++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
@@ -11,7 +11,7 @@ Required properties:
- clocks: clock phandle and specifier pair.
Optional properties:
- - linux,rc-map-name: see rc.txt file in the same directory.
+ - linux,rc-map-name: see rc.yaml file in the same directory.
- hisilicon,power-syscon: DEPRECATED. Don't use this in new dts files.
Provide correct clocks instead.
diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt
deleted file mode 100644
index be629f7fa77e..000000000000
--- a/Documentation/devicetree/bindings/media/rc.txt
+++ /dev/null
@@ -1 +0,0 @@
-This file has been moved to rc.yaml.
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: net: remove obsolete mdio.txt
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
mdio.txt has been a single-line redirect to mdio.yaml since
commit 62d77ff7ecbf ("dt-bindings: net: Add a YAML schemas for the
generic MDIO options"), which introduced the .yaml schema and reduced
the .txt to a stub in the same change. The .yaml has the same filename
in the same directory, making this redirect unnecessary for
discoverability.
No files in the tree reference mdio.txt and it has not been touched
since June 2019. Remove the obsolete stub.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Documentation/devicetree/bindings/net/mdio.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/mdio.txt b/Documentation/devicetree/bindings/net/mdio.txt
deleted file mode 100644
index cf8a0105488e..000000000000
--- a/Documentation/devicetree/bindings/net/mdio.txt
+++ /dev/null
@@ -1 +0,0 @@
-This file has moved to mdio.yaml.
--
2.54.0
^ permalink raw reply related
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