[PATCH v4 0/2] remoteproc: add AMD BRAM-based remote processor driver

[PATCH v4 0/2] remoteproc: add AMD BRAM-based remote processor driver

[Ben Levinsky]

Add a BRAM-based remoteproc driver and corresponding binding for AMD
soft processors located in programmable logic.

The series models a soft-core processor subsystem that executes firmware
from dual-port BRAM. The BRAM window is described in the processor-local
address space and translated to the Linux-visible system physical address
through the parent bus ranges property.

This series depends on the remoteproc cleanup series available here:

  https://lore.kernel.org/linux-remoteproc/ah2aVdlsLqy9aeHP@p14s/

That series adds the common WC ioremap carveout callbacks and optional
ELF resource-table helper used by patch 2.

v4:
  Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc

  - Sorted the SoC-specific compatible enum by name.

  Patch 2, remoteproc: add AMD BRAM-based remote processor driver

  - Dropped the driver-specific MAINTAINERS entry.
  - Trimmed the Kconfig help text.
  - Reused the common WC ioremap/iounmap carveout callbacks.
  - Reused the common optional ELF resource-table helper.
  - Used resource_size(&res) for the translated memory window size.
  - Kept the coredump segment address as the processor-local device
    address. The coredump path resolves segment addresses through
    rproc_da_to_va() against the registered carveout device address, while
    res.start is the Linux-visible system physical address after DT
    translation and may differ from the processor-local BRAM address.

v3:
  This version updates the binding to use SoC-specific compatibles with
  the fallback form discussed on the thread.

  Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc

  - Reworked the compatible schema to use SoC-specific compatibles.
  - Added amd,versal2-bram-rproc to the supported compatible list.
  - Used xlnx,zynqmp-bram-rproc as the fallback compatible.
  - Updated the example to match the new compatible scheme.

  Patch 2, remoteproc: add AMD BRAM-based remote processor driver

  - Updated the driver OF match table to bind via the
    xlnx,zynqmp-bram-rproc fallback compatible.

v2:
  This version pivots the series away from a MicroBlaze-specific binding
  and driver shape and instead models a BRAM-based soft-core processor
  subsystem more generally.

  This follows the upstream feedback that amd,microblaze was too tied to
  the processor architecture while also being too generic as a DT
  compatible for the hardware interface being described.

  Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc

  - Renamed the binding away from amd,microblaze and reframed it around a
    BRAM-based soft-core processor subsystem.
  - Dropped the redundant trailing "binding" wording from the patch
    subject.
  - Rewrote the binding text to describe the hardware rather than the Linux
    remoteproc framework.
  - Reworked the example to address the original dt_binding_check
    complaints about the root node and simple-pm-bus example shape.
  - Added a clocks property for the soft-core subsystem.

  Patch 2, remoteproc: add AMD BRAM-based remote processor driver

  - Renamed the driver away from the MicroBlaze-specific name to match the
    BRAM-based binding.
  - Added clock handling for the soft-core subsystem and the matching
    COMMON_CLK dependency in Kconfig.
  - Cleaned up the reset comments and removed the success dev_dbg() message
    called out in review.

Ben Levinsky (2):
  dt-bindings: remoteproc: document AMD BRAM-based rproc
  remoteproc: add AMD BRAM-based remote processor driver

 .../bindings/remoteproc/amd,bram-rproc.yaml   | 105 +++++++++
 drivers/remoteproc/Kconfig                    |  11 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/amd_bram_rproc.c           | 213 ++++++++++++++++++
 4 files changed, 330 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
 create mode 100644 drivers/remoteproc/amd_bram_rproc.c

-- 
2.34.1

[PATCH v4 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Ben Levinsky]

Describe an AMD BRAM-based remote processor controlled through the
remoteproc framework.

The binding models a soft-core processor subsystem instantiated in AMD
programmable logic and using dual-port BRAM for firmware storage and
execution. The remoteproc device is represented as a child node whose
reg property describes the firmware memory window in the processor-local
address space. The parent bus node provides standard devicetree address
translation through ranges so Linux can access the same BRAM through the
system physical address space.

A clock input feeds the soft-core processor subsystem, and an active-low
reset GPIO holds the processor in reset until firmware loading
completes. The firmware-name property is optional.

Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
 .../bindings/remoteproc/amd,bram-rproc.yaml   | 105 ++++++++++++++++++
 1 file changed, 105 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
new file mode 100644
index 000000000000..c4fadf25c230
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <ben.levinsky@amd.com>
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
+
+  Hardware Architecture:
+
+    Host (PS)                        Programmable Logic (PL)
+    =========                        ======================
+
+    AXI Interface -----------------> AXI BRAM Controller (Host Port)
+                                             |
+                                             | Port A
+                                             v
+                                     +-----------------+
+                                     |  Dual-Port BRAM |
+                                     | (shared memory) |
+                                     +-----------------+
+                                             ^
+                                             | Port B
+                                             |
+                                     AXI BRAM Controller (Soft-core Port)
+                                             ^
+                                             | LMB
+                                             |
+                                     Soft-core CPU (MicroBlaze/V)
+
+    GPIO --------------------------> Proc Sys Reset ----> CPU Reset Signal
+
+    Clock -------------------------> Clock Distribution -> CPU Clock
+
+  Memory Architecture:
+
+    The dual-port BRAM allows simultaneous access from both processors:
+      - Port A: Connected to the host AXI BRAM controller for firmware loading
+      - Port B: Connected to the soft-core local memory bus for execution
+
+  The reg property describes the executable BRAM window in the processor-local
+  address space. The parent bus node translates that window to the system
+  physical address space by using standard devicetree address translation
+  through ranges. A clock input and a reset GPIO control the subsystem.
+
+properties:
+  compatible:
+    oneOf:
+      - const: xlnx,zynqmp-bram-rproc
+      - items:
+          - enum:
+              - amd,versal2-bram-rproc
+              - xlnx,versal-bram-rproc
+              - xlnx,versal-net-bram-rproc
+          - const: xlnx,zynqmp-bram-rproc
+
+  reg:
+    maxItems: 1
+    description:
+      Processor-local address and size of the BRAM firmware memory window,
+      as seen by the soft-core processor (typically 0x0 for reset vector).
+      The parent bus ranges property must translate this window to the
+      corresponding system physical address.
+
+  clocks:
+    maxItems: 1
+    description:
+      Clock input for the soft-core processor subsystem.
+
+  firmware-name:
+    maxItems: 1
+    description:
+      Name of the firmware ELF file to load.
+
+  reset-gpios:
+    maxItems: 1
+    description:
+      GPIO specifier controlling the soft-core reset input.
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - reset-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    remoteproc@0 {
+      compatible = "xlnx,zynqmp-bram-rproc";
+      reg = <0x0 0x40000>;
+      clocks = <&pl_clk>;
+      firmware-name = "firmware.elf";
+      reset-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+    };
+...
-- 
2.34.1

[PATCH v4 2/2] remoteproc: add AMD BRAM-based remote processor driver

[Ben Levinsky]

Add a remoteproc driver for AMD soft-core processor subsystems
instantiated in programmable logic and using dual-port BRAM for
firmware storage and execution.

The driver parses the firmware memory window from the remoteproc device
node's reg property, interprets that address and size in the
processor-local address space, and then uses standard devicetree
address translation through the parent bus ranges property to obtain
the corresponding Linux-visible system physical address.

The resulting translated region is registered as the executable
remoteproc carveout and coredump segment.

The processor is controlled through an active-low reset GPIO and a
subsystem clock. The clock is enabled before reset is released, and the
processor is kept in reset until firmware loading completes.

The firmware-name property is optional, allowing firmware to be
assigned later through the remoteproc framework. Firmware images
without a resource table are also accepted.

Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
 drivers/remoteproc/Kconfig          |  11 ++
 drivers/remoteproc/Makefile         |   1 +
 drivers/remoteproc/amd_bram_rproc.c | 213 ++++++++++++++++++++++++++++
 3 files changed, 225 insertions(+)
 create mode 100644 drivers/remoteproc/amd_bram_rproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c521c744e7db..58fa566b609f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -23,6 +23,17 @@ config REMOTEPROC_CDEV
 
 	  It's safe to say N if you don't want to use this interface.
 
+config AMD_BRAM_REMOTEPROC
+	tristate "AMD BRAM-based remoteproc support"
+	depends on OF && COMMON_CLK && (GPIOLIB || COMPILE_TEST)
+	help
+	  Say y or m here to support a BRAM-based remote processor managed
+	  through the remoteproc framework.
+
+	  The processor is controlled through a reset GPIO and clock.
+
+	  If unsure, say N.
+
 config IMX_REMOTEPROC
 	tristate "i.MX remoteproc support"
 	depends on ARCH_MXC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 1c7598b8475d..5c39664b50c3 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,6 +11,7 @@ remoteproc-y				+= remoteproc_sysfs.o
 remoteproc-y				+= remoteproc_virtio.o
 remoteproc-y				+= remoteproc_elf_loader.o
 obj-$(CONFIG_REMOTEPROC_CDEV)		+= remoteproc_cdev.o
+obj-$(CONFIG_AMD_BRAM_REMOTEPROC)	+= amd_bram_rproc.o
 obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
 obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
diff --git a/drivers/remoteproc/amd_bram_rproc.c b/drivers/remoteproc/amd_bram_rproc.c
new file mode 100644
index 000000000000..a595875f9ce8
--- /dev/null
+++ b/drivers/remoteproc/amd_bram_rproc.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD BRAM-based Remote Processor driver
+ *
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ *
+ * This driver supports soft-core processors (MicroBlaze, MicroBlaze-V, or
+ * similar) instantiated in AMD programmable logic, using dual-port BRAM
+ * for firmware storage and execution.
+ *
+ * The firmware memory (BRAM) is described in the processor-local address
+ * space and translated to the Linux-visible system physical address with
+ * standard devicetree address translation.
+ *
+ * Reset is controlled via GPIO connected to Processor System Reset IP.
+ */
+
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+
+#include "remoteproc_internal.h"
+
+/**
+ * struct amd_bram_rproc - AMD BRAM-based remoteproc private data
+ * @dev: device pointer
+ * @reset: GPIO descriptor for reset control (active-low)
+ * @clk: processor clock
+ */
+struct amd_bram_rproc {
+	struct device *dev;
+	struct gpio_desc *reset;
+	struct clk *clk;
+};
+
+static int amd_bram_rproc_prepare(struct rproc *rproc)
+{
+	struct amd_bram_rproc *priv = rproc->priv;
+	struct rproc_mem_entry *mem;
+	struct resource res;
+	u64 da, size;
+	int ret;
+
+	ret = of_property_read_reg(priv->dev->of_node, 0, &da, &size);
+	if (ret) {
+		dev_err(priv->dev, "failed to parse executable memory reg\n");
+		return ret;
+	}
+
+	if (!size || size > U32_MAX) {
+		dev_err(priv->dev, "invalid executable memory size\n");
+		return -EINVAL;
+	}
+
+	if (da > U32_MAX) {
+		dev_err(priv->dev, "invalid executable memory address\n");
+		return -EINVAL;
+	}
+
+	ret = of_address_to_resource(priv->dev->of_node, 0, &res);
+	if (ret) {
+		dev_err(priv->dev, "failed to translate executable memory reg\n");
+		return ret;
+	}
+
+	mem = rproc_mem_entry_init(priv->dev, NULL, (dma_addr_t)res.start,
+				   resource_size(&res), da,
+				   rproc_mem_entry_ioremap_wc,
+				   rproc_mem_entry_iounmap,
+				   dev_name(priv->dev));
+	if (!mem)
+		return -ENOMEM;
+
+	rproc_add_carveout(rproc, mem);
+	rproc_coredump_add_segment(rproc, da, resource_size(&res));
+
+	return 0;
+}
+
+static int amd_bram_rproc_start(struct rproc *rproc)
+{
+	struct amd_bram_rproc *priv = rproc->priv;
+	int ret;
+
+	/* Enable clock before releasing reset */
+	ret = clk_prepare_enable(priv->clk);
+	if (ret) {
+		dev_err(priv->dev, "failed to enable clock: %d\n", ret);
+		return ret;
+	}
+
+	/* Deassert reset and let the processor run. */
+	ret = gpiod_set_value_cansleep(priv->reset, 0);
+	if (ret) {
+		dev_err(priv->dev, "failed to deassert reset: %d\n", ret);
+		clk_disable_unprepare(priv->clk);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int amd_bram_rproc_stop(struct rproc *rproc)
+{
+	struct amd_bram_rproc *priv = rproc->priv;
+	int ret;
+
+	/* Assert reset before disabling the processor clock. */
+	ret = gpiod_set_value_cansleep(priv->reset, 1);
+	if (ret) {
+		dev_err(priv->dev, "failed to assert reset: %d\n", ret);
+		return ret;
+	}
+
+	/* Disable clock after asserting reset */
+	clk_disable_unprepare(priv->clk);
+
+	return 0;
+}
+
+static int amd_bram_rproc_parse_fw(struct rproc *rproc,
+				   const struct firmware *fw)
+{
+	rproc_elf_load_rsc_table_optional(rproc, fw, dev_dbg,
+					  "no resource table found\n");
+	return 0;
+}
+
+static const struct rproc_ops amd_bram_rproc_ops = {
+	.prepare	= amd_bram_rproc_prepare,
+	.start		= amd_bram_rproc_start,
+	.stop		= amd_bram_rproc_stop,
+	.load		= rproc_elf_load_segments,
+	.sanity_check	= rproc_elf_sanity_check,
+	.get_boot_addr	= rproc_elf_get_boot_addr,
+	.parse_fw	= amd_bram_rproc_parse_fw,
+};
+
+static int amd_bram_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct amd_bram_rproc *priv;
+	const char *fw_name = NULL;
+	struct rproc *rproc;
+	int ret;
+
+	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
+	if (ret < 0 && ret != -EINVAL)
+		return dev_err_probe(dev, ret,
+				     "failed to parse firmware-name property\n");
+
+	rproc = devm_rproc_alloc(dev, dev_name(dev), &amd_bram_rproc_ops,
+				 fw_name, sizeof(*priv));
+	if (!rproc)
+		return -ENOMEM;
+
+	priv = rproc->priv;
+	priv->dev = dev;
+
+	/* Get the processor clock */
+	priv->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(priv->clk))
+		return dev_err_probe(dev, PTR_ERR(priv->clk),
+				     "failed to get clock\n");
+
+	/*
+	 * Keep the processor in reset until remoteproc has finished loading
+	 * firmware into the executable memory window described by reg and
+	 * translated through the parent bus ranges property.
+	 */
+	priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(priv->reset))
+		return dev_err_probe(dev, PTR_ERR(priv->reset),
+				     "failed to get reset gpio\n");
+
+	rproc->auto_boot = false;
+
+	ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to set DMA mask\n");
+
+	platform_set_drvdata(pdev, rproc);
+
+	ret = devm_rproc_add(dev, rproc);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to register rproc\n");
+
+	return 0;
+}
+
+static const struct of_device_id amd_bram_rproc_of_match[] = {
+	{ .compatible = "xlnx,zynqmp-bram-rproc" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, amd_bram_rproc_of_match);
+
+static struct platform_driver amd_bram_rproc_driver = {
+	.probe = amd_bram_rproc_probe,
+	.driver = {
+		.name = "amd-bram-rproc",
+		.of_match_table = amd_bram_rproc_of_match,
+	},
+};
+module_platform_driver(amd_bram_rproc_driver);
+
+MODULE_DESCRIPTION("AMD BRAM-based Remote Processor driver");
+MODULE_AUTHOR("Ben Levinsky <ben.levinsky@amd.com>");
+MODULE_LICENSE("GPL");
-- 
2.34.1

Re: [PATCH v4 2/2] remoteproc: add AMD BRAM-based remote processor driver

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Missing `.find_loaded_rsc_table` callback in `rproc_ops` breaks firmware IPC initialization.
- [Low] Undefined functions used in driver cause immediate build failure.

Pre-existing issues:
- [Critical] Integer overflow in `rproc_coredump()` leads to a massive heap buffer overflow.
--

commit 114ec0b0402b4fa78538fad8bece1af5eac1df59
Author: Ben Levinsky <ben.levinsky@amd.com>

remoteproc: add AMD BRAM-based remote processor driver

Add a remoteproc driver for AMD soft-core processor subsystems using BRAM
for firmware storage. The driver parses the memory window from devicetree,
registers the carveout, and controls the processor via reset GPIO and clock.

> diff --git a/drivers/remoteproc/amd_bram_rproc.c b/drivers/remoteproc/amd_bram_rproc.c
> new file mode 100644
> index 0000000000000..a595875f9ce8c
> --- /dev/null
> +++ b/drivers/remoteproc/amd_bram_rproc.c
[ ... ]
> +static int amd_bram_rproc_prepare(struct rproc *rproc)
> +{
[ ... ]
> +	mem = rproc_mem_entry_init(priv->dev, NULL, (dma_addr_t)res.start,
> +				   resource_size(&res), da,
> +				   rproc_mem_entry_ioremap_wc,
> +				   rproc_mem_entry_iounmap,
> +				   dev_name(priv->dev));

[Severity: Low]
Are rproc_mem_entry_ioremap_wc and rproc_mem_entry_iounmap defined anywhere
in the kernel tree? It appears these functions are missing, which would cause
the driver to fail to compile and link.

> +	if (!mem)
> +		return -ENOMEM;
> +
> +	rproc_add_carveout(rproc, mem);
> +	rproc_coredump_add_segment(rproc, da, resource_size(&res));

[Severity: Critical]
This is a pre-existing issue, but does adding an unbounded coredump segment
size here risk an integer overflow in the remoteproc core?

In drivers/remoteproc/remoteproc_coredump.c:rproc_coredump(), segment sizes
are accumulated into data_size without overflow checks:

        if (dump_conf == RPROC_COREDUMP_ENABLED)
                data_size += segment->size;

If a massive size (approaching U32_MAX on 32-bit systems) is provided from
the devicetree reg property, this could wrap around, leading to a much
smaller vmalloc allocation. Later, rproc_copy_segment() is called with the
original massive size, writing blindly into the undersized heap buffer.

> +
> +	return 0;
> +}
[ ... ]
> +static int amd_bram_rproc_parse_fw(struct rproc *rproc,
> +				   const struct firmware *fw)
> +{
> +	rproc_elf_load_rsc_table_optional(rproc, fw, dev_dbg,
> +					  "no resource table found\n");

[Severity: Low]
Is rproc_elf_load_rsc_table_optional defined anywhere? Similar to the
allocator callbacks above, this function appears to be missing from the tree.

> +	return 0;
> +}
> +
> +static const struct rproc_ops amd_bram_rproc_ops = {
> +	.prepare	= amd_bram_rproc_prepare,
> +	.start		= amd_bram_rproc_start,
> +	.stop		= amd_bram_rproc_stop,
> +	.load		= rproc_elf_load_segments,
> +	.sanity_check	= rproc_elf_sanity_check,
> +	.get_boot_addr	= rproc_elf_get_boot_addr,
> +	.parse_fw	= amd_bram_rproc_parse_fw,
> +};

[Severity: High]
Will firmware IPC initialize correctly without a .find_loaded_rsc_table
callback?

When the core loads a firmware with a resource table, rproc_fw_boot() calls
rproc_find_loaded_rsc_table(). Since .find_loaded_rsc_table is omitted here,
it returns NULL. This causes the core to silently skip copying the updated
rproc->cached_table to the device's loaded table in memory, leaving the
firmware to use uninitialized or FW_RSC_ADDR_ANY addresses for
communication.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629164003.3940208-1-ben.levinsky@amd.com?part=2

Re: [PATCH v4 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Krzysztof Kozlowski]

On Mon, Jun 29, 2026 at 09:40:02AM -0700, Ben Levinsky wrote:
> Describe an AMD BRAM-based remote processor controlled through the
> remoteproc framework.
> 
> The binding models a soft-core processor subsystem instantiated in AMD
> programmable logic and using dual-port BRAM for firmware storage and
> execution. The remoteproc device is represented as a child node whose
> reg property describes the firmware memory window in the processor-local
> address space. The parent bus node provides standard devicetree address
> translation through ranges so Linux can access the same BRAM through the
> system physical address space.
> 
> A clock input feeds the soft-core processor subsystem, and an active-low
> reset GPIO holds the processor in reset until firmware loading
> completes. The firmware-name property is optional.
> 
> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>

So you are going to ignore my emails? You know, it can work both ways.

I drop this from Patchwork.

Best regards,
Krzysztof

Re: [PATCH v4 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Ben Levinsky]

Hi Krzysztof,

I apologize if this came off as my ignoring your emails.

In the v3 you had said: 

> +          - enum:
> +              - xlnx,versal-bram-rproc
> +              - xlnx,versal-net-bram-rproc
> +              - amd,versal2-bram-rproc

If there is going to be a new version, this should be sorted by name.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>


I was uncomfortable in adding the Reviewed-by if that is what you meant.

In this v4 I believe your review comment to sort by name was addressed.

Apologies for my misunderstanding.

Respectfully,
Ben Levinsky

On 6/29/26 11:53 PM, Krzysztof Kozlowski wrote:
> On Mon, Jun 29, 2026 at 09:40:02AM -0700, Ben Levinsky wrote:
>> Describe an AMD BRAM-based remote processor controlled through the
>> remoteproc framework.
>>
>> The binding models a soft-core processor subsystem instantiated in AMD
>> programmable logic and using dual-port BRAM for firmware storage and
>> execution. The remoteproc device is represented as a child node whose
>> reg property describes the firmware memory window in the processor-local
>> address space. The parent bus node provides standard devicetree address
>> translation through ranges so Linux can access the same BRAM through the
>> system physical address space.
>>
>> A clock input feeds the soft-core processor subsystem, and an active-low
>> reset GPIO holds the processor in reset until firmware loading
>> completes. The firmware-name property is optional.
>>
>> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
> 
> So you are going to ignore my emails? You know, it can work both ways.
> 
> I drop this from Patchwork.
> 
> Best regards,
> 
> 

Re: [PATCH v4 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Krzysztof Kozlowski]

On 30/06/2026 15:47, Ben Levinsky wrote:
> Hi Krzysztof,
> 
> I apologize if this came off as my ignoring your emails.
> 
> In the v3 you had said: 
> 
>> +          - enum:
>> +              - xlnx,versal-bram-rproc
>> +              - xlnx,versal-net-bram-rproc
>> +              - amd,versal2-bram-rproc
> 
> If there is going to be a new version, this should be sorted by name.
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> 
> 
> I was uncomfortable in adding the Reviewed-by if that is what you meant.
> 
> In this v4 I believe your review comment to sort by name was addressed.
> 
> Apologies for my misunderstanding.

Did you implement my comment? It seems yes. Did you change something
else? It seems not, at least changelog is silent. So why would me Review
tag be not appropriate if you actually implemented reviewer's feedback?

Best regards,
Krzysztof

Re: [PATCH v4 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Ben Levinsky]

On 6/30/26 7:27 AM, Krzysztof Kozlowski wrote:
> On 30/06/2026 15:47, Ben Levinsky wrote:
>> Hi Krzysztof,
>>
>> I apologize if this came off as my ignoring your emails.
>>
>> In the v3 you had said: 
>>
>>> +          - enum:
>>> +              - xlnx,versal-bram-rproc
>>> +              - xlnx,versal-net-bram-rproc
>>> +              - amd,versal2-bram-rproc
>>
>> If there is going to be a new version, this should be sorted by name.
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>>
>> I was uncomfortable in adding the Reviewed-by if that is what you meant.
>>
>> In this v4 I believe your review comment to sort by name was addressed.
>>
>> Apologies for my misunderstanding.
> 
> Did you implement my comment? It seems yes. Did you change something
> else? It seems not, at least changelog is silent. So why would me Review
> tag be not appropriate if you actually implemented reviewer's feedback?
> 
> Best regards,
> Krzysztof

Hi Krzysztof,

Thank you for the clarification.

I misunderstood the intent of your earlier email and erred on the side of caution by not carrying over the Reviewed-by tag. Since the only change in patch v4 1/2 was implementing your review feedback (as noted in the cover letter changelog), I understand now that it would have been appropriate to retain your Reviewed-by.

I'll make sure to carry over Reviewed-by tags in similar situations going forward when only the reviewed feedback has been incorporated.

Given that the current series has already been posted, what would you recommend as the next step? Should I simply wait for the series to progress as-is, or would you prefer that I send a follow-up revision restoring your Reviewed-by tag?

Thanks again for the explanation, and apologies for the confusion.

Best regards,
Ben