* [PATCH net V2 2/2] net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
From: Suraj Gupta @ 2026-03-27 7:32 UTC (permalink / raw)
To: Radhey Shyam Pandey, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Michal Simek, Sean Anderson, Daniel Borkmann, Ariane Keller,
netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260327073238.134948-1-suraj.gupta2@amd.com>
When a TX packet spans multiple buffer descriptors (scatter-gather),
axienet_free_tx_chain sums the per-BD actual length from descriptor
status into a caller-provided accumulator. That sum is reset on each
NAPI poll. If the BDs for a single packet complete across different
polls, the earlier bytes are lost and never credited to BQL. This
causes BQL to think bytes are permanently in-flight, eventually
stalling the TX queue.
The SKB pointer is stored only on the last BD of a packet. When that
BD completes, use skb->len for the byte count instead of summing
per-BD status lengths. This matches netdev_sent_queue(), which debits
skb->len, and naturally survives across polls because no partial
packet contributes to the accumulator.
Fixes: c900e49d58eb ("net: xilinx: axienet: Implement BQL")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index b06e4c37ff61..263c4b67fd5a 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -770,8 +770,8 @@ static int axienet_device_reset(struct net_device *ndev)
* @first_bd: Index of first descriptor to clean up
* @nr_bds: Max number of descriptors to clean up
* @force: Whether to clean descriptors even if not complete
- * @sizep: Pointer to a u32 filled with the total sum of all bytes
- * in all cleaned-up descriptors. Ignored if NULL.
+ * @sizep: Pointer to a u32 accumulating the total byte count of
+ * completed packets (using skb->len). Ignored if NULL.
* @budget: NAPI budget (use 0 when not called from NAPI poll)
*
* Would either be called after a successful transmit operation, or after
@@ -805,6 +805,8 @@ static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
DMA_TO_DEVICE);
if (cur_p->skb && (status & XAXIDMA_BD_STS_COMPLETE_MASK)) {
+ if (sizep)
+ *sizep += cur_p->skb->len;
napi_consume_skb(cur_p->skb, budget);
packets++;
}
@@ -818,9 +820,6 @@ static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
wmb();
cur_p->cntrl = 0;
cur_p->status = 0;
-
- if (sizep)
- *sizep += status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
}
if (!force) {
--
2.49.1
^ permalink raw reply related
* [PATCH net V2 1/2] net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
From: Suraj Gupta @ 2026-03-27 7:32 UTC (permalink / raw)
To: Radhey Shyam Pandey, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Michal Simek, Sean Anderson, Daniel Borkmann, Ariane Keller,
netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260327073238.134948-1-suraj.gupta2@amd.com>
The XAXIDMA_BD_CTRL_LENGTH_MASK and XAXIDMA_BD_STS_ACTUAL_LEN_MASK
macros were defined as 0x007FFFFF (23 bits), but the AXI DMA IP
product guide (PG021) specifies the buffer length field as bits 25:0
(26 bits). Update both masks to match the IP documentation.
In practice this had no functional impact, since Ethernet frames are
far smaller than 2^23 bytes and the extra bits were always zero, but
the masks should still reflect the hardware specification.
Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index 5ff742103beb..fcd3aaef27fc 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -105,7 +105,7 @@
#define XAXIDMA_BD_HAS_DRE_MASK 0xF00 /* Whether has DRE mask */
#define XAXIDMA_BD_WORDLEN_MASK 0xFF /* Whether has DRE mask */
-#define XAXIDMA_BD_CTRL_LENGTH_MASK 0x007FFFFF /* Requested len */
+#define XAXIDMA_BD_CTRL_LENGTH_MASK GENMASK(25, 0) /* Requested len */
#define XAXIDMA_BD_CTRL_TXSOF_MASK 0x08000000 /* First tx packet */
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
@@ -130,7 +130,7 @@
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
-#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007FFFFF /* Actual len */
+#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK GENMASK(25, 0) /* Actual len */
#define XAXIDMA_BD_STS_COMPLETE_MASK 0x80000000 /* Completed */
#define XAXIDMA_BD_STS_DEC_ERR_MASK 0x40000000 /* Decode error */
#define XAXIDMA_BD_STS_SLV_ERR_MASK 0x20000000 /* Slave error */
--
2.49.1
^ permalink raw reply related
* [PATCH net V2 0/2] Correct BD length masks and BQL accounting for multi-BD TX packets
From: Suraj Gupta @ 2026-03-27 7:32 UTC (permalink / raw)
To: Radhey Shyam Pandey, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Michal Simek, Sean Anderson, Daniel Borkmann, Ariane Keller,
netdev, linux-arm-kernel, linux-kernel
This patch series fixes two issues in the Xilinx AXI Ethernet driver:
1. Corrects the BD length masks to match the AXIDMA IP spec.
2. Fixes BQL accounting for multi-BD TX packets.
---
Changes in V2:
- Define BD length masks with GENMASK(25, 0) per PG021.
- Credit BQL using skb->len on packet completion instead of summing
per-BD actual lengths from descriptor status.
---
Suraj Gupta (2):
net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 ++++-----
2 files changed, 6 insertions(+), 7 deletions(-)
--
2.49.1
^ permalink raw reply
* Re: [PATCH v3 3/3] drm/gem-dma: Support DRM_MODE_DUMB_KERNEL_MAP flag
From: Thomas Zimmermann @ 2026-03-27 7:29 UTC (permalink / raw)
To: Chen-Yu Tsai, Maarten Lankhorst, Maxime Ripard, David Airlie,
Simona Vetter
Cc: Rob Herring, dri-devel, linux-kernel, linux-arm-kernel,
Sasha Finkelstein, Janne Grunau, Liviu Dudau, Paul Kocialkowski,
Neil Armstrong, Laurent Pinchart, Tomi Valkeinen, Kieran Bingham,
Biju Das, Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Jernej Skrabec, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance, Icenowy Zheng, Laurent Pinchart,
Tomi Valkeinen
In-Reply-To: <20260326100248.1171828-4-wenst@chromium.org>
Hi
Am 26.03.26 um 11:01 schrieb Chen-Yu Tsai:
> From: Rob Herring <robh@kernel.org>
>
> Add support in DMA helpers to handle callers specifying
> DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
> change. drm_gem_dma_dumb_create() always creates a kernel mapping as
> before. drm_gem_dma_dumb_create_internal() lets the caller set the flags
> as desired.
>
> drm_gem_dma_dumb_create_internal() users have DRM_MODE_DUMB_KERNEL_MAP
> added to preserve existing behavior.
>
> A dumb buffer allocated from these devices can be shared (exported) to
> another device. The consuming device may require the kernel mapping to
> scan out the buffer to its own display. Such devices include DisplayLink
> and various MIPI DBI based displays. Therefore altering the behavior
> should be given much consideration.
NAK on this whole thing. Please do not clutter the sources with these
flags and tests. If drivers cannot use the gem-cma helpers, they should
not do so. Maybe these drivers _are_ different. Then give them different
interfaces or even a different memory manager, if necessary.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> [wenst@chromium.org: Rebase onto renamed GEM DMA helpers]
> [wenst@chromium.org: show "vaddr=(no mapping)" in drm_gem_dma_print_info()]
> [wenst@chromium.org: Add DRM_MODE_DUMB_KERNEL_MAP to new drivers]
> [wenst@chromium.org: Add flags field to drm_gem_dma_create_with_handle()
> kerneldoc]
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v2:
> - Added back DRM_MODE_DUMB_KERNEL_MAP flag to all drivers calling
> drm_gem_dma_dumb_create_internal()
> - Expanded commit message to cover display drivers needing the kernel
> mapping to do scan out
>
> Changes since v1:
> - Rebased onto renamed GEM DMA helpers
> - Added check in drm_fb_dma_get_scanout_buffer() and drm_gem_dma_vmap().
> - Made drm_gem_dma_print_info() show "vaddr=(no mapping)" for objects
> allocated without kernel mapping
> - Dropped existing DRM_MODE_DUMB_KERNEL_MAP flag addition in various
> drivers
> - Added DRM_MODE_DUMB_KERNEL_MAP flag to adp_drm_gem_dumb_create()
> - Added flags field kerneldoc for drm_gem_dma_create_with_handle()
>
> Cc: Sasha Finkelstein <fnkl.kernel@gmail.com>
> Cc: Janne Grunau <j@jannau.net>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Paul Kocialkowski <paulk@sys-base.io>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> Cc: Biju Das <biju.das.jz@bp.renesas.com>
> Cc: Yannick Fertre <yannick.fertre@foss.st.com>
> Cc: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
> Cc: Philippe Cornu <philippe.cornu@foss.st.com>
> Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>
> Cc: "Maíra Canal" <mcanal@igalia.com>
> Cc: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
> Cc: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
> drivers/gpu/drm/adp/adp_drv.c | 1 +
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 1 +
> drivers/gpu/drm/arm/malidp_drv.c | 1 +
> drivers/gpu/drm/drm_fb_dma_helper.c | 4 ++
> drivers/gpu/drm/drm_gem_dma_helper.c | 67 ++++++++++++-------
> drivers/gpu/drm/logicvc/logicvc_drm.c | 1 +
> drivers/gpu/drm/meson/meson_drv.c | 1 +
> drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 2 +
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 1 +
> drivers/gpu/drm/stm/drv.c | 3 +-
> drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
> drivers/gpu/drm/vc4/vc4_drv.c | 2 +
> drivers/gpu/drm/verisilicon/vs_drm.c | 2 +
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +
> 14 files changed, 63 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/adp/adp_drv.c b/drivers/gpu/drm/adp/adp_drv.c
> index 4554cf75565e..c549b44b3814 100644
> --- a/drivers/gpu/drm/adp/adp_drv.c
> +++ b/drivers/gpu/drm/adp/adp_drv.c
> @@ -95,6 +95,7 @@ static int adp_drm_gem_dumb_create(struct drm_file *file_priv,
> {
> args->height = ALIGN(args->height, 64);
> args->size = args->pitch * args->height;
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
>
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> }
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index 6ed504099188..2c096ebaea33 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -29,6 +29,7 @@ static int komeda_gem_dma_dumb_create(struct drm_file *file,
> struct komeda_dev *mdev = dev->dev_private;
> u32 pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> args->pitch = ALIGN(pitch, mdev->chip.bus_width);
>
> return drm_gem_dma_dumb_create_internal(file, dev, args);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index b765f6c9eea4..5519f48a27c0 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -464,6 +464,7 @@ static int malidp_dumb_create(struct drm_file *file_priv,
> /* allocate for the worst case scenario, i.e. rotated buffers */
> u8 alignment = malidp_hw_get_pitch_align(malidp->dev, 1);
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8), alignment);
>
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c b/drivers/gpu/drm/drm_fb_dma_helper.c
> index fd71969d2fb1..12a44accc48c 100644
> --- a/drivers/gpu/drm/drm_fb_dma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_dma_helper.c
> @@ -187,6 +187,10 @@ int drm_fb_dma_get_scanout_buffer(struct drm_plane *plane,
> if (!dma_obj->vaddr)
> return -ENODEV;
>
> + /* Buffer was allocated with NO_KERNEL_MAPPING */
> + if (dma_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> + return -ENODEV;
This is a good example of what I'm talking about. A driver that cannot
provide a scanout buffer should not set the callback in the first place.
Best regards
Thomas
> +
> iosys_map_set_vaddr(&sb->map[0], dma_obj->vaddr);
> sb->format = fb->format;
> sb->height = fb->height;
> diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
> index 9722c9fc86f3..281fb563f061 100644
> --- a/drivers/gpu/drm/drm_gem_dma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_dma_helper.c
> @@ -116,26 +116,8 @@ __drm_gem_dma_create(struct drm_device *drm, size_t size, bool private)
> return ERR_PTR(ret);
> }
>
> -/**
> - * drm_gem_dma_create - allocate an object with the given size
> - * @drm: DRM device
> - * @size: size of the object to allocate
> - *
> - * This function creates a DMA GEM object and allocates memory as backing store.
> - * The allocated memory will occupy a contiguous chunk of bus address space.
> - *
> - * For devices that are directly connected to the memory bus then the allocated
> - * memory will be physically contiguous. For devices that access through an
> - * IOMMU, then the allocated memory is not expected to be physically contiguous
> - * because having contiguous IOVAs is sufficient to meet a devices DMA
> - * requirements.
> - *
> - * Returns:
> - * A struct drm_gem_dma_object * on success or an ERR_PTR()-encoded negative
> - * error code on failure.
> - */
> -struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> - size_t size)
> +static struct drm_gem_dma_object *
> +drm_gem_dma_create_flags(struct drm_device *drm, size_t size, u32 flags)
> {
> struct drm_gem_dma_object *dma_obj;
> int ret;
> @@ -146,6 +128,9 @@ struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> if (IS_ERR(dma_obj))
> return dma_obj;
>
> + if (!(flags & DRM_MODE_DUMB_KERNEL_MAP))
> + dma_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
> +
> if (dma_obj->map_noncoherent) {
> dma_obj->vaddr = dma_alloc_noncoherent(drm_dev_dma_dev(drm),
> size,
> @@ -171,6 +156,30 @@ struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> drm_gem_object_put(&dma_obj->base);
> return ERR_PTR(ret);
> }
> +
> +/**
> + * drm_gem_dma_create - allocate an object with the given size
> + * @drm: DRM device
> + * @size: size of the object to allocate
> + *
> + * This function creates a DMA GEM object and allocates memory as backing store.
> + * The allocated memory will occupy a contiguous chunk of bus address space.
> + *
> + * For devices that are directly connected to the memory bus then the allocated
> + * memory will be physically contiguous. For devices that access through an
> + * IOMMU, then the allocated memory is not expected to be physically contiguous
> + * because having contiguous IOVAs is sufficient to meet a devices DMA
> + * requirements.
> + *
> + * Returns:
> + * A struct drm_gem_dma_object * on success or an ERR_PTR()-encoded negative
> + * error code on failure.
> + */
> +struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> + size_t size)
> +{
> + return drm_gem_dma_create_flags(drm, size, DRM_MODE_DUMB_KERNEL_MAP);
> +}
> EXPORT_SYMBOL_GPL(drm_gem_dma_create);
>
> /**
> @@ -179,6 +188,7 @@ EXPORT_SYMBOL_GPL(drm_gem_dma_create);
> * @file_priv: DRM file-private structure to register the handle for
> * @drm: DRM device
> * @size: size of the object to allocate
> + * @flags: DRM_MODE_DUMB_* flags if any
> * @handle: return location for the GEM handle
> *
> * This function creates a DMA GEM object, allocating a chunk of memory as
> @@ -194,14 +204,14 @@ EXPORT_SYMBOL_GPL(drm_gem_dma_create);
> */
> static struct drm_gem_dma_object *
> drm_gem_dma_create_with_handle(struct drm_file *file_priv,
> - struct drm_device *drm, size_t size,
> + struct drm_device *drm, size_t size, u32 flags,
> uint32_t *handle)
> {
> struct drm_gem_dma_object *dma_obj;
> struct drm_gem_object *gem_obj;
> int ret;
>
> - dma_obj = drm_gem_dma_create(drm, size);
> + dma_obj = drm_gem_dma_create_flags(drm, size, DRM_MODE_DUMB_KERNEL_MAP);
> if (IS_ERR(dma_obj))
> return dma_obj;
>
> @@ -283,7 +293,7 @@ int drm_gem_dma_dumb_create_internal(struct drm_file *file_priv,
> args->size = args->pitch * args->height;
>
> dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
> - &args->handle);
> + args->flags, &args->handle);
> return PTR_ERR_OR_ZERO(dma_obj);
> }
> EXPORT_SYMBOL_GPL(drm_gem_dma_dumb_create_internal);
> @@ -313,12 +323,13 @@ int drm_gem_dma_dumb_create(struct drm_file *file_priv,
> struct drm_gem_dma_object *dma_obj;
> int ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> ret = drm_mode_size_dumb(drm, args, 0, 0);
> if (ret)
> return ret;
>
> dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
> - &args->handle);
> + args->flags, &args->handle);
> return PTR_ERR_OR_ZERO(dma_obj);
> }
> EXPORT_SYMBOL_GPL(drm_gem_dma_dumb_create);
> @@ -412,7 +423,10 @@ void drm_gem_dma_print_info(const struct drm_gem_dma_object *dma_obj,
> struct drm_printer *p, unsigned int indent)
> {
> drm_printf_indent(p, indent, "dma_addr=%pad\n", &dma_obj->dma_addr);
> - drm_printf_indent(p, indent, "vaddr=%p\n", dma_obj->vaddr);
> + if (dma_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> + drm_printf_indent(p, indent, "vaddr=(no mapping)\n");
> + else
> + drm_printf_indent(p, indent, "vaddr=%p\n", dma_obj->vaddr);
> }
> EXPORT_SYMBOL(drm_gem_dma_print_info);
>
> @@ -511,6 +525,9 @@ EXPORT_SYMBOL_GPL(drm_gem_dma_prime_import_sg_table);
> int drm_gem_dma_vmap(struct drm_gem_dma_object *dma_obj,
> struct iosys_map *map)
> {
> + if (dma_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> + return -ENOMEM;
> +
> iosys_map_set_vaddr(map, dma_obj->vaddr);
>
> return 0;
> diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.c b/drivers/gpu/drm/logicvc/logicvc_drm.c
> index bbebf4fc7f51..595a71163cb5 100644
> --- a/drivers/gpu/drm/logicvc/logicvc_drm.c
> +++ b/drivers/gpu/drm/logicvc/logicvc_drm.c
> @@ -39,6 +39,7 @@ static int logicvc_drm_gem_dma_dumb_create(struct drm_file *file_priv,
> {
> struct logicvc_drm *logicvc = logicvc_drm(drm_dev);
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> /* Stride is always fixed to its configuration value. */
> args->pitch = logicvc->config.row_stride * DIV_ROUND_UP(args->bpp, 8);
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
> index 49ff9f1f16d3..9fa339d6e273 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -83,6 +83,7 @@ static irqreturn_t meson_irq(int irq, void *arg)
> static int meson_dumb_create(struct drm_file *file, struct drm_device *dev,
> struct drm_mode_create_dumb *args)
> {
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> /*
> * We need 64bytes aligned stride, and PAGE aligned size
> */
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> index 60e6f43b8ab2..611fe3d4a4d8 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> @@ -424,6 +424,8 @@ int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
> if (ret)
> return ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> +
> return drm_gem_dma_dumb_create_internal(file, dev, args);
> }
>
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> index 87f171145a23..359f85bd84eb 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> @@ -184,6 +184,7 @@ int rzg2l_du_dumb_create(struct drm_file *file, struct drm_device *dev,
> unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> unsigned int align = 16 * args->bpp / 8;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> args->pitch = roundup(min_pitch, align);
>
> return drm_gem_dma_dumb_create_internal(file, dev, args);
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 56d53ac3082d..a0bc2e215adb 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -51,8 +51,9 @@ static int stm_gem_dma_dumb_create(struct drm_file *file,
> * in order to optimize data transfer, pitch is aligned on
> * 128 bytes, height is aligned on 4 bytes
> */
> - args->pitch = roundup(min_pitch, 128);
> args->height = roundup(args->height, 4);
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> + args->pitch = roundup(min_pitch, 128);
>
> return drm_gem_dma_dumb_create_internal(file, dev, args);
> }
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 8a409eee1dca..d3ff53ce2450 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -36,6 +36,7 @@ static int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
> struct drm_device *drm,
> struct drm_mode_create_dumb *args)
> {
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> /* The hardware only allows even pitches for YUV buffers. */
> args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8), 2);
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index a14ecb769461..7a04cf52f511 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -87,6 +87,8 @@ static int vc5_dumb_create(struct drm_file *file_priv,
> if (ret)
> return ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> +
> return drm_gem_dma_dumb_create_internal(file_priv, dev, args);
> }
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_drm.c b/drivers/gpu/drm/verisilicon/vs_drm.c
> index fd259d53f49f..fe3591244d02 100644
> --- a/drivers/gpu/drm/verisilicon/vs_drm.c
> +++ b/drivers/gpu/drm/verisilicon/vs_drm.c
> @@ -44,6 +44,8 @@ static int vs_gem_dumb_create(struct drm_file *file_priv,
> if (ret)
> return ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> +
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> }
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index 02f3a7d78cf8..aa3822b3cb08 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -371,6 +371,8 @@ static int zynqmp_dpsub_dumb_create(struct drm_file *file_priv,
> if (ret)
> return ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> +
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> }
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* [GIT,PULL] arm64: dts: hisilicon: fixes for v7.0
From: Wei Xu @ 2026-03-27 7:23 UTC (permalink / raw)
To: soc, arm
Cc: linux-arm-kernel, Arnd Bergmann, xuwei5, zhangyi.ac,
Wuliebao (Joab, Turing Solution), Shenqingchun(DanielShen),
huangdaode, liguozhu, Zengtao (B), Jonathan Cameron, shiju.jose,
salil.mehta, Shawn Guo
Hi ARM SoC maintainers,
Please consider to pull the following changes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://github.com/hisilicon/linux-hisi.git tags/hisi-dts-fixes-for-7.0
for you to fetch changes up to 1af997cad473d505248df6d9577183bb91f69670:
arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges (2026-03-21 03:38:11 +0000)
----------------------------------------------------------------
HiSilicon dts fixes for v7.0
- Correct the PCIe reset GPIO polarity for hi3798cv200-poplar
- Add the missing dma-ranges for hi3798cv200
----------------------------------------------------------------
Shawn Guo (2):
arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity
arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges
arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts | 2 +-
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Krzysztof Kozlowski @ 2026-03-27 7:23 UTC (permalink / raw)
To: Jian Hu
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-2-jian.hu@amlogic.com>
On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>
> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/3] drm: Introduce DRM_MODE_DUMB_KERNEL_MAP flag
From: Thomas Zimmermann @ 2026-03-27 7:21 UTC (permalink / raw)
To: Chen-Yu Tsai, Maarten Lankhorst, Maxime Ripard, David Airlie,
Simona Vetter
Cc: Rob Herring, dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20260326100248.1171828-2-wenst@chromium.org>
Hi
Am 26.03.26 um 11:01 schrieb Chen-Yu Tsai:
> From: Rob Herring <robh@kernel.org>
>
> Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> drm_mode_create_dumb. This flag is for internal kernel use to indicate
> if dumb buffer allocation needs a kernel mapping. This is needed only for
> GEM DMA where creating a kernel mapping or not has to be decided at
> allocation time because creating a mapping on demand (with vmap()) is not
> guaranteed to work.
I still don't understand what you're trying to achieve. As I pointed
out, ever driver's memory manager potentially requires a vmap. Passing
around flags will not solve that problem. If vmap is not possible, the
driver should not provide the vmap callbacks in the first place.
Best regards
Thomas
>
> Several drivers are using reimplementing the GEM DMA helpers because
> they distinguish between kernel and userspace allocations to create a
> kernel mapping or not. Adding a flag allows migrating these drivers
> to the helpers while preserving their existing behavior. These include
> exynos, rockchip, and previously mediatek.
>
> Update the callers of drm_mode_dumb_create() to set
> drm_mode_dumb_create.flags to appropriate defaults. Currently, flags can
> be set to anything by userspace, but is unused within the kernel. Let's
> force flags to zero (no kernel mapping) for userspace callers by default.
> For in kernel clients, set DRM_MODE_DUMB_KERNEL_MAP by default. Drivers
> can override this as needed.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> [wenst@chromium.org: Emit warning (once) if args->flags is not zero]
> [wenst@chromium.org: Moved flag def. to include/drm/drm_dumb_buffers.h]
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v2:
> - Switched to drm_warn_once()
> - Moved flag definition from include/uapi/ to include/drm/drm_dumb_buffers.h
> - Reworded commit message
>
> Changes since v1:
> - Emit warning if args->flags is not zero
> ---
> drivers/gpu/drm/drm_client.c | 2 ++
> drivers/gpu/drm/drm_dumb_buffers.c | 4 ++++
> include/drm/drm_dumb_buffers.h | 3 +++
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 46c465bce98c..3d3e61823cc1 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -14,6 +14,7 @@
> #include <drm/drm_client_event.h>
> #include <drm/drm_device.h>
> #include <drm/drm_drv.h>
> +#include <drm/drm_dumb_buffers.h>
> #include <drm/drm_file.h>
> #include <drm/drm_fourcc.h>
> #include <drm/drm_framebuffer.h>
> @@ -404,6 +405,7 @@ drm_client_buffer_create_dumb(struct drm_client_dev *client, u32 width, u32 heig
> dumb_args.width = width;
> dumb_args.height = height;
> dumb_args.bpp = drm_format_info_bpp(info, 0);
> + dumb_args.flags = DRM_MODE_DUMB_KERNEL_MAP;
> ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
> if (ret)
> return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
> index e2b62e5fb891..60f4c2d08641 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -233,6 +233,10 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> struct drm_mode_create_dumb *args = data;
> int err;
>
> + if (args->flags)
> + drm_warn_once(dev, "drm_mode_create_dumb.flags is not zero.\n");
> + args->flags = 0;
> +
> err = drm_mode_create_dumb(dev, args, file_priv);
> if (err) {
> args->handle = 0;
> diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
> index 1f3a8236fb3d..4657e44533f4 100644
> --- a/include/drm/drm_dumb_buffers.h
> +++ b/include/drm/drm_dumb_buffers.h
> @@ -6,6 +6,9 @@
> struct drm_device;
> struct drm_mode_create_dumb;
>
> +/* drm_mode_create_dumb flags for internal use */
> +#define DRM_MODE_DUMB_KERNEL_MAP (1<<0)
> +
> int drm_mode_size_dumb(struct drm_device *dev,
> struct drm_mode_create_dumb *args,
> unsigned long hw_pitch_align,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* [GIT,PULL] hisilicon: driver updates for v7.1
From: Wei Xu @ 2026-03-27 7:16 UTC (permalink / raw)
To: soc, arm
Cc: linux-arm-kernel, Arnd Bergmann, xuwei5, zhangyi.ac,
Wuliebao (Joab, Turing Solution), Shenqingchun(DanielShen),
huangdaode, liguozhu, Zengtao (B), lihuisong (C),
Jonathan Cameron, shiju.jose, salil.mehta
Hi ARM SoC maintainers,
Please consider to pull the following changes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://github.com/hisilicon/linux-hisi.git tags/hisi-drivers-for-7.1
for you to fetch changes up to a8f5c98517c7c89947024f79e5854e6b09766b79:
soc: hisilicon: kunpeng_hccs: Remove unused input parameter (2026-03-21 03:55:35 +0000)
----------------------------------------------------------------
HiSilicon driver updates for v7.1
- Fix two compiler warnings on kunpeng_hccs driver
----------------------------------------------------------------
Huisong Li (2):
soc: hisilicon: kunpeng_hccs: Fix discard ‘const’ qualifier compiling warning
soc: hisilicon: kunpeng_hccs: Remove unused input parameter
drivers/soc/hisilicon/kunpeng_hccs.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH v11] arm64: dts: imx8ulp: Add CSI and ISI Nodes
From: guoniu.zhou @ 2026-03-27 7:11 UTC (permalink / raw)
To: Rui Miguel Silva, Laurent Pinchart, Martin Kepplinger,
Purism Kernel Team, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel, Frank Li
Cc: linux-media, devicetree, imx, linux-arm-kernel, linux-kernel,
G . N . Zhou
From: Guoniu Zhou <guoniu.zhou@nxp.com>
The CSI-2 in the i.MX8ULP is almost identical to the version present
in the i.MX8QXP/QM and is routed to the ISI. Add both the ISI and CSI
nodes and mark them as disabled by default since capture is dependent
on an attached camera.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
---
This was previously sent as patch 5/5 in the v10 series based on media
tree [1]. Patches 1-4 have already been applied to linux-next tree, but
not yet to media tree . This v11 addresses the conflict with the removal
of include/dt-bindings/reset/imx8ulp-pcc-reset.h.
Changes in v11:
- Rebased on latest media/next
- Removed #include <dt-bindings/reset/imx8ulp-pcc-reset.h> which was
deleted by Rob's dt-bindings cleanup series [2]
- Replaced reset macros with numeric values and added comments to
document the reset indices
- Link to v10: https://lore.kernel.org/r/20251205-csi2_imx8ulp-v10-5-190cdadb20a3@nxp.com
Changes in v6:
- Update compatible string in dts for csi node.
- Link to v5: https://lore.kernel.org/r/20250901-csi2_imx8ulp-v5-4-67964d1471f3@nxp.com
Changes in v4:
- Change csr clock name to pclk which is more readability.
- Link to v3: https://lore.kernel.org/all/20250825-csi2_imx8ulp-v3-4-35885aba62bc@nxp.com
Changes in v3:
- Change pclk clock name to csr to match IP port name.
- Link to v2: https://lore.kernel.org/all/20250822-csi2_imx8ulp-v2-4-26a444394965@nxp.com
Changes in v2:
- Move dts patch as the last one.
- Add "fsl,imx8qxp-mipi-csi2" to compatible string list of csi node.
- Link to v1: https://lore.kernel.org/all/20250812081923.1019345-3-guoniu.zhou@oss.nxp.com
[1] https://lore.kernel.org/all/20251205-csi2_imx8ulp-v10-0-190cdadb20a3@nxp.com/
[2] https://lore.kernel.org/all/20251212231203.727227-1-robh@kernel.org/
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 66 ++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 9b5d98766512..84f05c83c702 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -859,6 +859,72 @@ spdif: spdif@2dab0000 {
dma-names = "rx", "tx";
status = "disabled";
};
+
+ isi: isi@2dac0000 {
+ compatible = "fsl,imx8ulp-isi";
+ reg = <0x2dac0000 0x10000>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc5 IMX8ULP_CLK_ISI>,
+ <&cgc2 IMX8ULP_CLK_LPAV_AXI_DIV>;
+ clock-names = "axi", "apb";
+ power-domains = <&scmi_devpd IMX8ULP_PD_ISI>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ isi_in: endpoint {
+ remote-endpoint = <&mipi_csi_out>;
+ };
+ };
+ };
+ };
+
+ mipi_csi: csi@2daf0000 {
+ compatible = "fsl,imx8ulp-mipi-csi2";
+ reg = <0x2daf0000 0x10000>,
+ <0x2dad0000 0x10000>;
+ clocks = <&pcc5 IMX8ULP_CLK_CSI>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_ESC>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_UI>,
+ <&pcc5 IMX8ULP_CLK_CSI_REGS>;
+ clock-names = "core", "esc", "ui", "pclk";
+ assigned-clocks = <&pcc5 IMX8ULP_CLK_CSI>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_ESC>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_UI>,
+ <&pcc5 IMX8ULP_CLK_CSI_REGS>;
+ assigned-clock-parents = <&cgc2 IMX8ULP_CLK_PLL4_PFD1_DIV1>,
+ <&cgc2 IMX8ULP_CLK_PLL4_PFD1_DIV2>,
+ <&cgc2 IMX8ULP_CLK_PLL4_PFD0_DIV1>;
+ assigned-clock-rates = <200000000>,
+ <80000000>,
+ <100000000>,
+ <79200000>;
+ power-domains = <&scmi_devpd IMX8ULP_PD_MIPI_CSI>;
+ resets = <&pcc5 5>, /* PCC5_CSI_REGS_SWRST */
+ <&pcc5 6>; /* PCC5_CSI_SWRST> */
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_csi_out: endpoint {
+ remote-endpoint = <&isi_in>;
+ };
+ };
+ };
+ };
};
gpiod: gpio@2e200000 {
--
2.34.1
^ permalink raw reply related
* [PATCH] ARM: dts: aspeed: anacapa: Enable MCTP and FRU for NIC
From: Andy Chung via B4 Relay @ 2026-03-27 6:59 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Andy Chung, Andy Chung
From: Andy Chung <Andy.Chung@amd.com>
Add the mctp-controller property to enable frontend NIC management
via PLDM over MCTP.
Also add EEPROM device for NIC FRU.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
Add the mctp-controller property to enable frontend NIC management
via PLDM over MCTP.
Also add EEPROM device for NIC FRU.
---
.../dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 67 +++++++++++++++++++++-
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
index 221af858cb6b..138b081be049 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -584,38 +584,67 @@ eeprom@56 {
// R Bridge Board
&i2c10 {
status = "okay";
+ multi-master;
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
i2c-mux@71 {
compatible = "nxp,pca9548";
reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
- i2c-mux-idle-disconnect;
i2c10mux0ch0: i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
};
i2c10mux0ch1: i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch2: i2c@2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch3: i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch4: i2c@4 {
reg = <4>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch5: i2c@5 {
reg = <5>;
@@ -661,38 +690,72 @@ i2c10mux0ch7: i2c@7 {
// L Bridge Board
&i2c11 {
status = "okay";
+ multi-master;
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
i2c-mux@71 {
compatible = "nxp,pca9548";
reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
- i2c-mux-idle-disconnect;
i2c11mux0ch0: i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // FE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch1: i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch2: i2c@2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch3: i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch4: i2c@4 {
reg = <4>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch5: i2c@5 {
reg = <5>;
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260327-dts_enable_nic_mctp-e35a5765b176
Best regards,
--
Andy Chung <Andy.Chung@amd.com>
^ permalink raw reply related
* Re: [PATCH v5] MAINTAINERS: Add Axiado reviewer and Maintainers
From: Krzysztof Kozlowski @ 2026-03-27 6:54 UTC (permalink / raw)
To: Karthikeyan Mitran, Arnd Bergmann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Prasad Bolisetty, Tzu-Hao Wei,
Axiado Reviewers
Cc: devicetree, linux-arm-kernel, linux-kernel, Alexandre Belloni,
Drew Fustini, Linus Walleij, Harshit Shah
In-Reply-To: <20260326-maintainers-addition-and-axiado-ax3000_dtsi-update-v5-1-648dfe9bff29@axiado.com>
On 26/03/2026 21:50, Karthikeyan Mitran wrote:
> From: Prasad Bolisetty <pbolisetty@axiado.com>
>
> Adding 3 new maintainers Prasad,Tzu-Hao, and Karthikeyan
> and adding a group reviewer entry for review coverage,
> Removed previous maintainer as the previous maintainer moved from project
...
> ---
> MAINTAINERS | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 55af015174a5..49f47e8c2ec3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2605,7 +2605,10 @@ F: arch/arm/mach-aspeed/
> N: aspeed
>
> ARM/AXIADO ARCHITECTURE
> -M: Harshit Shah <hshah@axiado.com>
> +M: Prasad Bolisetty <pbolisetty@axiado.com>
> +M: Tzu-Hao Wei <twei@axiado.com>
> +M: Karthikeyan Mitran <kmitran@axiado.com>
> +R: Axiado Reviewers <linux-maintainer@axiado.com>
How many entries do you need? You already have three, so who is in
Axiado reviewers? And what is "review coverage" you mentioned in the
commit msg.
I skimmed through https://lore.kernel.org/all/?q=f%3Aaxiado.com and I do
not see reviews from any of these addresses, so it all looks like you
add some corporate structure, because some managers want to see what is
posted.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Manivannan Sadhasivam @ 2026-03-27 6:52 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <20260326080444.gbesciaa5zwvcgoy@skbuf>
On Thu, Mar 26, 2026 at 10:04:44AM +0200, Vladimir Oltean wrote:
> On Wed, Mar 25, 2026 at 01:57:31PM +0200, Vladimir Oltean wrote:
> > On Wed, Mar 25, 2026 at 05:21:14PM +0530, Manivannan Sadhasivam wrote:
> > > I believe I added the power_count check for phy_exit(). But since that got
> > > moved, the check becomes no longer necessary.
> >
> > FYI, the power_count keeps track of the balance of phy_power_on() and
> > phy_power_off() calls, whereas it is the init_count keeps track of
> > phy_init() and phy_exit() calls. They are only related to the extent
> > that you must respect the phy_init() -> phy_power_on() -> phy_power_off()
> > -> phy_exit() sequence. But in any case, both should be considered
> > PHY-internal fields. The "Order of API calls" section from
> > Documentation/driver-api/phy/phy.rst mentions the order that I just
> > described above, and consumers should just ensure they follow that.
>
> Ok, so we can close this topic of "checking the power_count not needed"
> by linking to the conversation which spun off here:
> https://lore.kernel.org/lkml/20260325120122.265973-1-manivannan.sadhasivam@oss.qualcomm.com/
>
Sure.
> Mani, I spent some more time to figure out what's really going on with
> this unexpected phy_power_off() call. Do you think you could
> regression-test the patch attached?
>
I tested the patch. But it fails ufs_qcom_power_up_sequence() if PHY was already
powered on:
[ 31.513321] qcom-qmp-ufs-phy 1d87000.phy: phy initialization timed-out
[ 31.513335] ufshcd-qcom 1d84000.ufshc: Failed to calibrate PHY: -110
[ 31.565273] ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
Funny thing is, it didn't affect the functionality since the UFS core retries
ufshcd_hba_enable() and in the error path of ufs_qcom_power_up_sequence(),
phy_power_off() gets called and that causes the next try to succeed. So it is
evident that, if PHY was already powered ON, it should be powered off before
ufs_qcom_phy_power_on(). And due to the UFS driver design,
ufs_qcom_power_up_sequence() can get called multiple times. So we cannot just
remove phy_power_off().
Below diff on top of your patch fixes the issue:
```
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index ed067247d72a..2c9fe03f349e 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -567,6 +567,8 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
if (ret)
return ret;
+ ufs_qcom_phy_power_off(host);
+
ret = ufs_qcom_phy_set_gear(host, mode);
if (ret) {
dev_err(hba->dev, "%s: phy_set_mode_ext() failed, ret = %d\n",
```
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply related
* Re: [PATCH v5] nvme: Skip trace complete_rq on host path error
From: 전민식 @ 2026-03-27 6:37 UTC (permalink / raw)
To: Keith Busch, hch@lst.de
Cc: Justin Tee, axboe@kernel.dk, sven@kernel.org, j@jannau.net,
neal@gompa.dev, sagi@grimberg.me, justin.tee@broadcom.com,
nareshgottumukkala83@gmail.com, paul.ely@broadcom.com,
James Smart, kch@nvidia.com, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org, 이은수,
칸찬, 전민식
In-Reply-To: <acVGECskf5pg3_MY@kbusch-mbp>
On Thu, Mar 26, 2026 at 08:43 -0600, Keith Busch wrote:
> Yeah, the spec is not very clear on their use. It just defines the codes
> and a one sentence description, and then never mentioned again. I think
> it allows the possibility for the controller to internally complete a
> command with such status from some undefined OOB mechanism. I'm not sure
> why the host needs to have their own self-generated status codes anyway
> since it can already attach whatever arbitrary flags it wants to its
> private data, like how we use NVME_REQ_CANCELLED.
>
> Anyway if a controller did return it for whatever reason, even if it is
> a bug, we'd want to see it in the trace.
Sorry, The date is wrong, so I send it again.
On Thu, Mar 26, 2026 at 08:43 -0600, hch@lst.de wrote:
-> On Thu, Mar 26, 2026 at 14:43PM UTC, Keith Busch wrote:
I've confirmed what you discussed, and it seems like the approach you
proposed is a better one.
Can I send patch v7 as above?
Regards,
Minsik Jeon
^ permalink raw reply
* [PATCH] coresight: cti: fix the check condition in inout_sel_store
From: Jie Gan @ 2026-03-27 6:24 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Mathieu Poirier, Greg Kroah-Hartman,
Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, Jie Gan
Correct the upper bound from CTIINOUTEN_MAX to config->nr_trig_max,
since nr_trig_max varies across CTI devices. An out-of-bounds issue
occurs when a value greater than config->nr_trig_max is provided,
leading to unexpected errors.
Fixes: b5213376c240 ("coresight: cti: Add sysfs access to program function registers")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-cti-sysfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-cti-sysfs.c b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
index 4c0a60840efb..bf3c73607c1c 100644
--- a/drivers/hwtracing/coresight/coresight-cti-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
@@ -337,10 +337,11 @@ static ssize_t inout_sel_store(struct device *dev,
{
unsigned long val;
struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
+ struct cti_config *config = &drvdata->config;
if (kstrtoul(buf, 0, &val))
return -EINVAL;
- if (val > (CTIINOUTEN_MAX - 1))
+ if (val >= config->nr_trig_max)
return -EINVAL;
guard(raw_spinlock_irqsave)(&drvdata->spinlock);
---
base-commit: e77a5a5cfe43b4c25bd44a3818e487033287517f
change-id: 20260327-fix-cti-issue-3dda5e4636f7
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v5] nvme: Skip trace complete_rq on host path error
From: 전민식 @ 2026-03-27 6:19 UTC (permalink / raw)
To: Keith Busch, hch@lst.de
Cc: Justin Tee, axboe@kernel.dk, sven@kernel.org, j@jannau.net,
neal@gompa.dev, sagi@grimberg.me, justin.tee@broadcom.com,
nareshgottumukkala83@gmail.com, paul.ely@broadcom.com,
James Smart, kch@nvidia.com, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org, 이은수,
칸찬, 전민식
In-Reply-To: <acVGECskf5pg3_MY@kbusch-mbp>
On Thu, Mar 26, 2026 at 03:43PM +0100, hch@lst.de wrote:
> Yeah, the spec is not very clear on their use. It just defines the codes
> and a one sentence description, and then never mentioned again. I think
> it allows the possibility for the controller to internally complete a
> command with such status from some undefined OOB mechanism. I'm not sure
> why the host needs to have their own self-generated status codes anyway
> since it can already attach whatever arbitrary flags it wants to its
> private data, like how we use NVME_REQ_CANCELLED.
>
> Anyway if a controller did return it for whatever reason, even if it is
> a bug, we'd want to see it in the trace.
I've confirmed what you discussed, and it seems like the approach you
proposed is a better one.
Can I send patch v7 as above?
Regrad,
Minsik Jeon
^ permalink raw reply
* Re: [PATCH v3] ASoC: dt-bindings: imx-card: Add dsp_a DAI format
From: Shengjiu Wang @ 2026-03-27 6:06 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li, s.hauer,
kernel, festevam, linux-sound, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260327031504.497650-1-chancel.liu@nxp.com>
On Fri, Mar 27, 2026 at 11:15 AM Chancel Liu <chancel.liu@nxp.com> wrote:
>
> Existing i.MX audio sound card described by this binding use codecs
> that operate in i2s or dsp_b formats. The newly added CS42448 codec
> requires dsp_a for its TDM interface. To properly describe such
> hardware in DT, the binding needs to allow dsp_a DAI format.
>
> Only i2s, dsp_b and dsp_a are included because these are the formats
> actually used by the hardware supported by this binding. Other formats
> such as left_j, right_j, ac97 are not used or required by the hardware
"pdm", "left_j", "right_j" are supported by SAI, so I think they should be added
from the hardware point of view.
Best regards
Shengjiu Wang
Shengjiu Wang
> currently covered by this binding, so they are intentionally not added.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
> Changes in v3:
> - Rewrote commit message completely to describe hardware requirements.
> Explicitly documented why only dsp_a is added and why other formats
> are not included.
> - Rebased on latest code base. No functional changes.
>
> Changes in v2:
> - Updated commit message to explain current support for i2s and dsp_b
> formats and new support for dsp_a. No code changes.
>
> Documentation/devicetree/bindings/sound/imx-audio-card.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> index 5424d4f16f52..75757fbccd89 100644
> --- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> @@ -37,6 +37,7 @@ patternProperties:
> items:
> enum:
> - i2s
> + - dsp_a
> - dsp_b
>
> dai-tdm-slot-num: true
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH v2 0/2] selftests/arm64: Fix sve2p1_sigill() and add cmpbr_sigill() for hwcap test
From: wuyifan @ 2026-03-27 5:59 UTC (permalink / raw)
To: Will Deacon, catalin.marinas, shuah, broonie, yeoreum.yun,
jonathan.cameron, linux-kernel, linux-arm-kernel, linux-kselftest,
linuxarm
Cc: kernel-team, xiaqinxin, prime.zeng, wangyushan12, xuwei5,
fanghao11, wangzhou1
In-Reply-To: <177279809096.1376203.6124931515335372340.b4-ty@kernel.org>
HiWill,
Gentle ping on patch 2/2. I have received a Reviewed-by from Mark Brown
and there have been no further review comments so far.
Could you please consider applying it if everything looks good?
On 3/6/2026 8:26 PM, Will Deacon wrote:
> On Thu, 05 Mar 2026 09:36:36 +0800, Yifan Wu wrote:
>> This patch series fixes and adds two selftests in the arm64 hwcap
>> test suite.
>>
>> Patch 1/2 fixes the sve2p1_sigill() test to correctly detect the
>> FEAT_SVE2p1 feature. Previously, the test incorrectly assumed that
>> the presence of FEAT_SVE2.1 implied support for the BFADD
>> instruction, which actually depends on the FEAT_SVE_B16B16 feature.
>> The test is updated to use the LD1Q instruction, which is
>> unambiguously implied by FEAT_SVE2p1.
>>
>> [...]
> Applied first patch to arm64 (for-next/fixes), thanks!
>
> [1/2] selftest/arm64: Fix sve2p1_sigill() to hwcap test
> https://git.kernel.org/arm64/c/d87c828daa7e
>
> Cheers,
Thanks,
Yifan
^ permalink raw reply
* Re: [PATCH v3 2/3] drm/gem-dma: Use the dma_*_attr API variant
From: Chen-Yu Tsai @ 2026-03-27 5:48 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter
Cc: Rob Herring, dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20260326100248.1171828-3-wenst@chromium.org>
On Thu, Mar 26, 2026 at 6:03 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> From: Rob Herring <robh@kernel.org>
>
> In preparation to allow DRM DMA users to adjust the DMA_ATTR_* flags,
> convert the DMA helper code to use the dma_*_attr APIs instead of the
> dma_*_wc variants.
>
> Only the DMA_ATTR_WRITE_COMBINE and DMA_ATTR_NO_WARN attributes are set
> in this commit, so there's no functional change.
>
> Update rcar_du_vsp_map_fb() to use dma_get_sgtable_attrs() instead of
> dma_get_sgtable().
>
> Also change the dma_free_wc() call in vc4_bo_purge() in the vc4 driver
> to use dma_free_attrs() to match. vc4_bo is a sub-class of
> drm_gem_dma_object.
>
> Sub-classes of |struct drm_gem_dma_object| can also set additional
> DMA_ATTR_* flags if they choose so. For example a sub-class could
> set DMA_ATTR_FORCE_CONTIGUOUS in certain cases.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> [wenst@chromium.org: Rebase onto renamed DMA helpers]
> [wenst@chromium.org: Make vc4_bo_purge() use matching dma_free_attrs()]
> [wenst@chromium.org: Make rcar_du_vsp_map_fb() use dma_get_sgtable_attrs()]
> [wenst@chromium.org: Expand commit message to mention that sub-classes
> can set extra DMA_ATTR_* flags]
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
>
> ---
> Changes since v2:
> - rcar-du: Change dma_get_sgtable() to dma_get_sgtable_attrs()
>
> Changes since v1:
> - Rebased onto renamed DMA helpers
> - Made vc4_bo_purge() use matching dma_free_attrs()
> - Expanded commit message to mention that sub-classes can set extra
> DMA_ATTR_* flags
> ---
> drivers/gpu/drm/drm_gem_dma_helper.c | 26 +++++++++++--------
> drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c | 5 ++--
> drivers/gpu/drm/vc4/vc4_bo.c | 2 +-
> include/drm/drm_gem_dma_helper.h | 3 +++
> 4 files changed, 22 insertions(+), 14 deletions(-)
[...]
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c
> index 94c22d2db197..a4896096e3bc 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c
> @@ -291,8 +291,9 @@ int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
> dst = sg_next(dst);
> }
> } else {
> - ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr,
> - gem->dma_addr, gem->base.size);
> + ret = dma_get_sgtable_attrs(rcdu->dev, sgt, gem->vaddr,
> + gem->dma_addr, gem->base.size
> + gem->dma_attrs);
This doesn't compile. Sorry for the noise.
^ permalink raw reply
* Re: [PATCH v3 3/3] drm/gem-dma: Support DRM_MODE_DUMB_KERNEL_MAP flag
From: Chen-Yu Tsai @ 2026-03-27 5:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter
Cc: Rob Herring, dri-devel, linux-kernel, linux-arm-kernel,
Sasha Finkelstein, Janne Grunau, Liviu Dudau, Paul Kocialkowski,
Neil Armstrong, Laurent Pinchart, Tomi Valkeinen, Kieran Bingham,
Biju Das, Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Jernej Skrabec, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance, Icenowy Zheng, Laurent Pinchart,
Tomi Valkeinen
In-Reply-To: <20260326100248.1171828-4-wenst@chromium.org>
On Thu, Mar 26, 2026 at 6:03 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> From: Rob Herring <robh@kernel.org>
>
> Add support in DMA helpers to handle callers specifying
> DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
> change. drm_gem_dma_dumb_create() always creates a kernel mapping as
> before. drm_gem_dma_dumb_create_internal() lets the caller set the flags
> as desired.
>
> drm_gem_dma_dumb_create_internal() users have DRM_MODE_DUMB_KERNEL_MAP
> added to preserve existing behavior.
>
> A dumb buffer allocated from these devices can be shared (exported) to
> another device. The consuming device may require the kernel mapping to
> scan out the buffer to its own display. Such devices include DisplayLink
> and various MIPI DBI based displays. Therefore altering the behavior
> should be given much consideration.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> [wenst@chromium.org: Rebase onto renamed GEM DMA helpers]
> [wenst@chromium.org: show "vaddr=(no mapping)" in drm_gem_dma_print_info()]
> [wenst@chromium.org: Add DRM_MODE_DUMB_KERNEL_MAP to new drivers]
> [wenst@chromium.org: Add flags field to drm_gem_dma_create_with_handle()
> kerneldoc]
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v2:
> - Added back DRM_MODE_DUMB_KERNEL_MAP flag to all drivers calling
> drm_gem_dma_dumb_create_internal()
> - Expanded commit message to cover display drivers needing the kernel
> mapping to do scan out
>
> Changes since v1:
> - Rebased onto renamed GEM DMA helpers
> - Added check in drm_fb_dma_get_scanout_buffer() and drm_gem_dma_vmap().
> - Made drm_gem_dma_print_info() show "vaddr=(no mapping)" for objects
> allocated without kernel mapping
> - Dropped existing DRM_MODE_DUMB_KERNEL_MAP flag addition in various
> drivers
> - Added DRM_MODE_DUMB_KERNEL_MAP flag to adp_drm_gem_dumb_create()
> - Added flags field kerneldoc for drm_gem_dma_create_with_handle()
>
> Cc: Sasha Finkelstein <fnkl.kernel@gmail.com>
> Cc: Janne Grunau <j@jannau.net>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Paul Kocialkowski <paulk@sys-base.io>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> Cc: Biju Das <biju.das.jz@bp.renesas.com>
> Cc: Yannick Fertre <yannick.fertre@foss.st.com>
> Cc: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
> Cc: Philippe Cornu <philippe.cornu@foss.st.com>
> Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>
> Cc: "Maíra Canal" <mcanal@igalia.com>
> Cc: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
> Cc: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
> drivers/gpu/drm/adp/adp_drv.c | 1 +
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 1 +
> drivers/gpu/drm/arm/malidp_drv.c | 1 +
> drivers/gpu/drm/drm_fb_dma_helper.c | 4 ++
> drivers/gpu/drm/drm_gem_dma_helper.c | 67 ++++++++++++-------
> drivers/gpu/drm/logicvc/logicvc_drm.c | 1 +
> drivers/gpu/drm/meson/meson_drv.c | 1 +
> drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 2 +
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 1 +
> drivers/gpu/drm/stm/drv.c | 3 +-
> drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
> drivers/gpu/drm/vc4/vc4_drv.c | 2 +
> drivers/gpu/drm/verisilicon/vs_drm.c | 2 +
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +
> 14 files changed, 63 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/adp/adp_drv.c b/drivers/gpu/drm/adp/adp_drv.c
> index 4554cf75565e..c549b44b3814 100644
> --- a/drivers/gpu/drm/adp/adp_drv.c
> +++ b/drivers/gpu/drm/adp/adp_drv.c
> @@ -95,6 +95,7 @@ static int adp_drm_gem_dumb_create(struct drm_file *file_priv,
> {
> args->height = ALIGN(args->height, 64);
> args->size = args->pitch * args->height;
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
>
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> }
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index 6ed504099188..2c096ebaea33 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -29,6 +29,7 @@ static int komeda_gem_dma_dumb_create(struct drm_file *file,
> struct komeda_dev *mdev = dev->dev_private;
> u32 pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> args->pitch = ALIGN(pitch, mdev->chip.bus_width);
>
> return drm_gem_dma_dumb_create_internal(file, dev, args);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index b765f6c9eea4..5519f48a27c0 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -464,6 +464,7 @@ static int malidp_dumb_create(struct drm_file *file_priv,
> /* allocate for the worst case scenario, i.e. rotated buffers */
> u8 alignment = malidp_hw_get_pitch_align(malidp->dev, 1);
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8), alignment);
>
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c b/drivers/gpu/drm/drm_fb_dma_helper.c
> index fd71969d2fb1..12a44accc48c 100644
> --- a/drivers/gpu/drm/drm_fb_dma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_dma_helper.c
> @@ -187,6 +187,10 @@ int drm_fb_dma_get_scanout_buffer(struct drm_plane *plane,
> if (!dma_obj->vaddr)
> return -ENODEV;
>
> + /* Buffer was allocated with NO_KERNEL_MAPPING */
> + if (dma_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> + return -ENODEV;
> +
> iosys_map_set_vaddr(&sb->map[0], dma_obj->vaddr);
> sb->format = fb->format;
> sb->height = fb->height;
> diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
> index 9722c9fc86f3..281fb563f061 100644
> --- a/drivers/gpu/drm/drm_gem_dma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_dma_helper.c
> @@ -116,26 +116,8 @@ __drm_gem_dma_create(struct drm_device *drm, size_t size, bool private)
> return ERR_PTR(ret);
> }
>
> -/**
> - * drm_gem_dma_create - allocate an object with the given size
> - * @drm: DRM device
> - * @size: size of the object to allocate
> - *
> - * This function creates a DMA GEM object and allocates memory as backing store.
> - * The allocated memory will occupy a contiguous chunk of bus address space.
> - *
> - * For devices that are directly connected to the memory bus then the allocated
> - * memory will be physically contiguous. For devices that access through an
> - * IOMMU, then the allocated memory is not expected to be physically contiguous
> - * because having contiguous IOVAs is sufficient to meet a devices DMA
> - * requirements.
> - *
> - * Returns:
> - * A struct drm_gem_dma_object * on success or an ERR_PTR()-encoded negative
> - * error code on failure.
> - */
> -struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> - size_t size)
> +static struct drm_gem_dma_object *
> +drm_gem_dma_create_flags(struct drm_device *drm, size_t size, u32 flags)
> {
> struct drm_gem_dma_object *dma_obj;
> int ret;
> @@ -146,6 +128,9 @@ struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> if (IS_ERR(dma_obj))
> return dma_obj;
>
> + if (!(flags & DRM_MODE_DUMB_KERNEL_MAP))
> + dma_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
> +
> if (dma_obj->map_noncoherent) {
> dma_obj->vaddr = dma_alloc_noncoherent(drm_dev_dma_dev(drm),
> size,
> @@ -171,6 +156,30 @@ struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> drm_gem_object_put(&dma_obj->base);
> return ERR_PTR(ret);
> }
> +
> +/**
> + * drm_gem_dma_create - allocate an object with the given size
> + * @drm: DRM device
> + * @size: size of the object to allocate
> + *
> + * This function creates a DMA GEM object and allocates memory as backing store.
> + * The allocated memory will occupy a contiguous chunk of bus address space.
> + *
> + * For devices that are directly connected to the memory bus then the allocated
> + * memory will be physically contiguous. For devices that access through an
> + * IOMMU, then the allocated memory is not expected to be physically contiguous
> + * because having contiguous IOVAs is sufficient to meet a devices DMA
> + * requirements.
> + *
> + * Returns:
> + * A struct drm_gem_dma_object * on success or an ERR_PTR()-encoded negative
> + * error code on failure.
> + */
> +struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> + size_t size)
> +{
> + return drm_gem_dma_create_flags(drm, size, DRM_MODE_DUMB_KERNEL_MAP);
> +}
> EXPORT_SYMBOL_GPL(drm_gem_dma_create);
>
> /**
> @@ -179,6 +188,7 @@ EXPORT_SYMBOL_GPL(drm_gem_dma_create);
> * @file_priv: DRM file-private structure to register the handle for
> * @drm: DRM device
> * @size: size of the object to allocate
> + * @flags: DRM_MODE_DUMB_* flags if any
> * @handle: return location for the GEM handle
> *
> * This function creates a DMA GEM object, allocating a chunk of memory as
> @@ -194,14 +204,14 @@ EXPORT_SYMBOL_GPL(drm_gem_dma_create);
> */
> static struct drm_gem_dma_object *
> drm_gem_dma_create_with_handle(struct drm_file *file_priv,
> - struct drm_device *drm, size_t size,
> + struct drm_device *drm, size_t size, u32 flags,
> uint32_t *handle)
> {
> struct drm_gem_dma_object *dma_obj;
> struct drm_gem_object *gem_obj;
> int ret;
>
> - dma_obj = drm_gem_dma_create(drm, size);
> + dma_obj = drm_gem_dma_create_flags(drm, size, DRM_MODE_DUMB_KERNEL_MAP);
Sashiko pointed out an obvious (to me now) error here: this should pass
`flags`, not the flag directly.
ChenYu
^ permalink raw reply
* Re: [PATCH 0/4] drm/exynos: Random cleanups
From: Chen-Yu Tsai @ 2026-03-27 5:44 UTC (permalink / raw)
To: Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Alim Akhtar
Cc: David Airlie, Simona Vetter, dri-devel, linux-samsung-soc,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260326094308.1161335-1-wenst@chromium.org>
On Thu, Mar 26, 2026 at 5:43 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> Hi,
>
> Here are some cleanups for the exynos drm driver. This was done as part
> of the conversion of the driver to GEM DMA helpers. These patches have
> no dependency, unlike the actual conversion, so I am sending them
> separately for inclusion now.
>
> Please take a look.
I should add that these patches were only compile tested.
> Thanks
> ChenYu
>
> Chen-Yu Tsai (4):
> drm/exynos: Internalize exynos_drm_gem_free_object()
> drm/exynos: Use DRM core dedicated DMA device tracking facility
> drm/exynos: Drop exynos_drm_gem.size field
> drm/exynos: Drop MAX_FB_BUFFER in favor of DRM_FORMAT_MAX_PLANES
>
> drivers/gpu/drm/exynos/exynos_drm_dma.c | 11 +++---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 9 -----
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +--
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 13 ++++---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 50 +++++++++++--------------
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 8 ----
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 +-
> 9 files changed, 41 insertions(+), 63 deletions(-)
>
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-j721e: Fix QSGMII overlay by adding SERDES PHY
From: Vignesh Raghavendra @ 2026-03-27 5:15 UTC (permalink / raw)
To: Chintan Vankar
Cc: Andrew Davis, Siddharth Vadapalli, Conor Dooley,
Krzysztof Kozlowski, Rob Herring, Tero Kristo,
Vignesh Raghavendra, Nishanth Menon, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <20260326072237.1324027-1-c-vankar@ti.com>
On Thu, 26 Mar 2026 12:52:37 +0530, Chintan Vankar <c-vankar@ti.com> wrote:
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso b/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso
> index 8376fa4b6ee1..d403a3db0265 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-evm-quad-port-eth-exp.dtso
> @@ -42,7 +42,8 @@ &cpsw0_port2 {
> phy-handle = <&cpsw9g_phy1>;
> phy-mode = "qsgmii";
> mac-address = [00 00 00 00 00 00];
> - phys = <&cpsw0_phy_gmii_sel 2>;
> + phys = <&cpsw0_phy_gmii_sel 2>, <&serdes0_qsgmii_link>;
> + phy-names = "mac", "serdes";
Dont you need this for all the other ports as well, just like in J784s4
overlay?
--
Vignesh
^ permalink raw reply
* Re: [PATCH v2 0/3] Fix MMC pin pull configurations
From: Vignesh Raghavendra @ 2026-03-27 4:56 UTC (permalink / raw)
To: Nishanth Menon, Judith Mendez
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel, Moteen Shah, Andrew Davis
In-Reply-To: <20260223233731.2690472-1-jm@ti.com>
Hi Judith Mendez,
On Mon, 23 Feb 2026 17:37:28 -0600, Judith Mendez wrote:
> This series corrects MMC pin pull-up/pull-down configurations across
> TI AM62L EVM, AM62P SK, & AM62 LP SK boards to properly match their
> hardware design.
>
> Most boards have external pull-ups on MMC pins, but DT configuration
> was also enabling internal pulls. Having both internal and external
> pulls active causes several issues:
> - Unnecessary power consumption due to stronger pull resistance
> - Floating pins violating SPEC recommendations
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/3] arm64: dts: ti: k3-am62p5-sk: Disable MMC1 internal pulls on data pins
commit: 6d4441be969bea89bb9702781f5dfb3a8f2a02a4
[2/3] arm64: dts: ti: k3-am62l-evm: Disable MMC1 internal pulls on data pins
commit: 02532ba56362907b6aca3e8289c4a9247ef83325
[3/3] arm64: dts: ti: k3-am62-lp-sk: Enable internal pulls for MMC0 data pins
commit: ee2a9d9c9e6c9643fb7e45febcaedfbc038e483a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: [PATCH v4 0/5] k3-am68-phyboard-izar dsi support
From: Vignesh Raghavendra @ 2026-03-27 4:53 UTC (permalink / raw)
To: Dominik Haller
Cc: Vignesh Raghavendra, linux-kernel, devicetree, linux-arm-kernel,
upstream
In-Reply-To: <20260320212349.420951-1-d.haller@phytec.de>
Hi Dominik Haller,
On Fri, 20 Mar 2026 14:23:41 -0700, Dominik Haller wrote:
> This series adds support for the two dsi based display interfaces of the
> phyboard-izar with the phycore-am68x/tda4x som.
>
> dsi0 gets converted to lvds on the som using a SN65DSI83 bridge in the
> default configuration. The phyboard-izar kit comes with a 10.1" lvds
> display with usb touch as addon.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/5] arm64: dts: ti: k3-am68-phyboard-izar: Assign dss clocks
commit: ae41091c65453b900a9a96294ee7ff007dc671e4
[2/5] arm64: dts: ti: k3-am68-phycore-som: Add DSI->LVDS bridge
commit: 2295927906ce448a25ec7fc6f5da731b364d6b90
[3/5] arm64: dts: ti: k3-am68-phyboard-izar: Add LVDS-Display
commit: 1bdfd6abc1ec5d60474a2f0b96955480b33e0644
[4/5] arm64: dts: ti: k3-j721s2-main: Add DSI1
commit: db0da07c37a2a79b19a07eef2f218dc830275e7d
[5/5] arm64: dts: ti: k3-am68-phyboard-izar: Add PEB-AV-15 overlay
commit: 6e5df7cc5455dfcfac4764f00d121ee6a6796e2c
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: [PATCH v5 0/5] arm64: dts: ti: k3-am62: Support Main UART wakeup
From: Vignesh Raghavendra @ 2026-03-27 4:51 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kendall Willis
Cc: vishalm, sebin.francis, khilman, d-gole, msp, a-kaur,
s-kochidanadu, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260212-b4-uart-daisy-chain-dts-v5-0-26c7f534e567@ti.com>
Hi Kendall Willis,
On Thu, 12 Feb 2026 11:27:19 -0600, Kendall Willis wrote:
> arm64: dts: ti: k3-am62: Support Main UART wakeup
>
> This series adds wakeup support for the Main UART in the device tree of
> the TI AM62 family of devices. It defines the specific pins and pinctrl
> states needed to wakeup the system from the Main UART via I/O
> daisy-chaining. The wakeup-source property is configured to describe the
> low power modes the system can wakeup from using the Main UART.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/5] arm64: dts: ti: k3-am62x-sk-common: Enable Main UART wakeup
commit: ab16e17f6f4d216831a0736cf0f8d59b12b1d102
[2/5] arm64: dts: ti: k3-am62a7-sk: Enable Main UART wakeup
commit: 809c32b708c5e085c2c63fb05d2c6260c233a3ba
[3/5] arm64: dts: ti: k3-am62p5-sk: Enable Main UART wakeup
commit: 32ddcdde224a19a8c3cf9e0c9b7d6d9eced8db22
[4/5] arm64: dts: ti: k3-am62l3-evm: Enable Main UART wakeup
commit: abdec802da403a7ba0af5f87e8ab9671b71a00e4
[5/5] arm64: dts: ti: k3-am62d2-evm: Enable Main UART wakeup
commit: dbe21aa940f482fe3bba9d4731b6863ab85e8f55
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
* Re: (subset) [PATCH v4 0/5] k3-am68-phyboard-izar dsi support
From: Vignesh Raghavendra @ 2026-03-27 4:48 UTC (permalink / raw)
To: Dominik Haller; +Cc: linux-kernel, devicetree, linux-arm-kernel, upstream
In-Reply-To: <20260320212349.420951-1-d.haller@phytec.de>
Hi Dominik Haller,
On Fri, 20 Mar 2026 14:23:41 -0700, Dominik Haller wrote:
> k3-am68-phyboard-izar dsi support
>
> This series adds support for the two dsi based display interfaces of the
> phyboard-izar with the phycore-am68x/tda4x som.
>
> dsi0 gets converted to lvds on the som using a SN65DSI83 bridge in the
> default configuration. The phyboard-izar kit comes with a 10.1" lvds
> display with usb touch as addon.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/5] arm64: dts: ti: k3-am68-phyboard-izar: Assign dss clocks
commit: cda1fef2ec679bfb74580273cb7dd7a1cecd77f7
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox