[RFC PATCH 0/2] Add NPAC driver to accel subsystem

[RFC PATCH 0/2] Add NPAC driver to accel subsystem

[Jaspinder Budhal]

This series adds support for the Network Packet ACcelerator (NPAC)
client driver. NPAC is a hardware accelerator for offloading
packet processing tasks from the various hosts on TI's TDA5 family
of SoCs.

This is a minimal reference implementation to establish the framework
for NPAC acceleration support in the Linux kernel. Further details
are in patch 1 which adds documentation for the driver and describes
the system architecture, driver interface, and execution flows.

This RFC is submitted for getting feedback on the initial implementation.

Jaspinder Budhal (2):
  Documentation: accel: Add NPAC client driver documentation
  accel/npac: Add NPAC client driver

 Documentation/accel/npac.rst  | 142 ++++++++++++++++++++++
 drivers/accel/Kconfig         |   1 +
 drivers/accel/Makefile        |   1 +
 drivers/accel/npac/Kconfig    |  13 ++
 drivers/accel/npac/Makefile   |   3 +
 drivers/accel/npac/npac_drv.c | 218 ++++++++++++++++++++++++++++++++++
 6 files changed, 378 insertions(+)
 create mode 100644 Documentation/accel/npac.rst
 create mode 100644 drivers/accel/npac/Kconfig
 create mode 100644 drivers/accel/npac/Makefile
 create mode 100644 drivers/accel/npac/npac_drv.c

-- 
2.34.1

[RFC PATCH 1/2] Documentation: accel: Add NPAC client driver documentation

[Jaspinder Budhal]

NPAC (Network Packet ACcelerator) is a hardware accelerator present on
TI's TDA5 family of SoCs, designed to offload network packet processing
tasks from various hosts. It can be used to implement various packet
processing use cases such as ACL (Access Control List) rule enforcement,
reducing host CPU load.

This is an RFC patch for getting feedback on the initial implementation.

See the TDA54 SoC datasheet for hardware details:
https://www.ti.com/lit/ds/symlink/tda54-q1.pdf

Signed-off-by: Jaspinder Budhal <j-budhal@ti.com>
---
 Documentation/accel/npac.rst | 142 +++++++++++++++++++++++++++++++++++
 1 file changed, 142 insertions(+)
 create mode 100644 Documentation/accel/npac.rst

diff --git a/Documentation/accel/npac.rst b/Documentation/accel/npac.rst
new file mode 100644
index 000000000000..fba6ddd0cfd2
--- /dev/null
+++ b/Documentation/accel/npac.rst
@@ -0,0 +1,142 @@
+.. SPDX-License-Identifier: GPL-2.0-only OR MIT
+
+====================================================
+Texas Instruments NPAC (Network Packet ACcelerator)
+====================================================
+
+Overview
+========
+
+NPAC (Network Packet ACcelerator) is a hardware accelerator available
+on Texas Instruments SoCs in the TDA5 family that provides network packet
+processing acceleration [0]_.
+
+The NPAC Host Driver runs on a dedicated remote processor and manages
+NPAC hardware.
+
+The NPAC client driver provides offloading support for ethernet-related tasks
+and communicates with the NPAC Host Driver over RPMsg (Remote Processor
+Messaging).
+
+The driver exposes /dev/accel/accel* as the userspace interface for accelerator
+configuration and management operations.
+
+The NPAC Host Driver supports ACL (Access Control
+List) [1]_ rule offload. ACL configuration requests are sent by the client
+driver to the NPAC Host Driver.
+
+Communication Model
+-------------------
+
+The NPAC client driver registers with the RPMsg subsystem during driver
+initialization.
+
+When the NPAC host driver announces the NPAC RPMsg service endpoint, the
+RPMsg core matches the announced service against the registered NPAC client
+driver and invokes the driver probe callback.
+
+Offload command received from userspace are formatted into RPMsgs and sent
+to the NPAC Host Driver.
+
+NPAC Host Driver responses are received through RPMsg callbacks.
+
+ACL Rule Offload
+----------------
+
+ACL (Access Control List) rules are packet filtering policies that define how
+network traffic should be handled — for example, dropping packets from a
+blacklisted source IP or allowing traffic only from trusted MAC addresses.
+
+In the standard Linux networking stack, ACL enforcement is handled in software
+by the netfilter subsystem. Each packet is inspected against the configured
+ruleset on the host CPU. On embedded SoCs in the TDA5 family such as TDA54,
+the per-packet overhead of software-based ACL enforcement accumulates under
+high traffic rates, increasing CPU utilization and reducing the processing
+capacity available for other system functions.
+
+The NPAC client driver offloads rules from Linux to NPAC hardware.
+Once a rule is programmed, matching packets are handled entirely by NPAC,
+reducing CPU load.
+
+For example, a rule to drop all packets from a specific source IP or to
+allow packets from a trusted source is offloaded to NPAC. Instead of the
+host parsing each packet and applying the ACL rules, NPAC enforces the
+rule directly in hardware.
+
+Userspace Interface
+-------------------
+
+The driver exposes /dev/accel/accel* as the userspace control interface for ACL
+rule management operations.
+
+The interface uses IOCTL-based request handling for accelerator configuration
+and rule management operations.
+
+IOCTL Commands
+~~~~~~~~~~~~~~
+
+DRM_IOCTL_NPAC_ACL_ADD_RULE
+
+  This IOCTL allows userspace to add an ACL rule to the accelerator. The
+  call will forward the rule to the NPAC host driver for hardware programming.
+  The NPAC Host Driver is responsible for validating the rule and applying it to
+  the NPAC hardware.
+
+DRM_IOCTL_NPAC_ACL_DELETE_RULE
+
+  This IOCTL allows userspace to remove an ACL rule from the accelerator.
+  The call will forward the deletion request to the NPAC host driver, which
+  will remove the rule from the NPAC hardware.
+
+Driver Lifecycle
+----------------
+
+The driver lifecycle is coordinated through the RPMsg framework.
+
+Probe Flow
+~~~~~~~~~~
+
+1. The NPAC client driver registers with the RPMsg subsystem
+
+2. NPAC host driver initializes on the remote processor
+
+3. NPAC Host Driver announces its RPMsg service endpoint
+
+4. The RPMsg subsystem in Linux matches the announced service against
+   the registered NPAC client driver
+
+5. The RPMsg subsystem invokes the driver probe callback
+
+6. Driver communication resources are initialized
+
+7. /dev/accel/accel* becomes available to userspace
+
+Request Flow
+~~~~~~~~~~~~
+
+1. Userspace submits an ACL configuration request through /dev/accel/accel*
+
+2. The request is forwarded to the NPAC host driver using RPMsg
+
+3. The NPAC Host Driver validates the request and performs the required hardware
+   programming operations
+
+4. NPAC Host Driver responses are received by the Linux driver through the RPMsg
+   callback.
+
+RPMsg Integration
+-----------------
+
+The driver integrates with the Linux RPMsg subsystem for communication with
+the NPAC host driver processor.
+
+RPMsg is used as the transport mechanism for:
+
+- Accelerator configuration requests
+- NPAC Host Driver responses
+
+References
+----------
+
+.. [0] https://www.ti.com/lit/ds/symlink/tda54-q1.pdf
+.. [1] https://en.wikipedia.org/wiki/Access-control_list#Networking_ACLs
-- 
2.34.1

[RFC PATCH 2/2] accel/npac: Add NPAC client driver

[Jaspinder Budhal]

Add the Linux client driver for the Network Packet ACcelerator (NPAC).
The driver communicates with the NPAC host driver via RPMsg,
allowing offloading of ethernet-related packet processing tasks.

The driver provides the basic framework for receiving offload commands
via IOCTL and communicating with the NPAC hardware accelerator.

Signed-off-by: Jaspinder Budhal <j-budhal@ti.com>
---
 drivers/accel/Kconfig         |   1 +
 drivers/accel/Makefile        |   1 +
 drivers/accel/npac/Kconfig    |  13 ++
 drivers/accel/npac/Makefile   |   3 +
 drivers/accel/npac/npac_drv.c | 218 ++++++++++++++++++++++++++++++++++
 5 files changed, 236 insertions(+)
 create mode 100644 drivers/accel/npac/Kconfig
 create mode 100644 drivers/accel/npac/Makefile
 create mode 100644 drivers/accel/npac/npac_drv.c

diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig
index bdf48ccafcf2..a6d8c1ebfcf1 100644
--- a/drivers/accel/Kconfig
+++ b/drivers/accel/Kconfig
@@ -28,6 +28,7 @@ source "drivers/accel/amdxdna/Kconfig"
 source "drivers/accel/ethosu/Kconfig"
 source "drivers/accel/habanalabs/Kconfig"
 source "drivers/accel/ivpu/Kconfig"
+source "drivers/accel/npac/Kconfig"
 source "drivers/accel/qaic/Kconfig"
 source "drivers/accel/rocket/Kconfig"
 
diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile
index 1d3a7251b950..0df7b9f2ae18 100644
--- a/drivers/accel/Makefile
+++ b/drivers/accel/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_DRM_ACCEL_AMDXDNA)		+= amdxdna/
 obj-$(CONFIG_DRM_ACCEL_ARM_ETHOSU)	+= ethosu/
 obj-$(CONFIG_DRM_ACCEL_HABANALABS)	+= habanalabs/
 obj-$(CONFIG_DRM_ACCEL_IVPU)		+= ivpu/
+obj-$(CONFIG_DRM_ACCEL_NPAC_CLIENT)	+= npac/
 obj-$(CONFIG_DRM_ACCEL_QAIC)		+= qaic/
 obj-$(CONFIG_DRM_ACCEL_ROCKET)		+= rocket/
\ No newline at end of file
diff --git a/drivers/accel/npac/Kconfig b/drivers/accel/npac/Kconfig
new file mode 100644
index 000000000000..a9543ac2c7aa
--- /dev/null
+++ b/drivers/accel/npac/Kconfig
@@ -0,0 +1,13 @@
+config DRM_ACCEL_NPAC_CLIENT
+	tristate "NPAC Client Driver"
+	depends on DRM_ACCEL
+	depends on RPMSG
+	help
+	  This driver is the NPAC (Network Packet ACcelerator) client,
+	  communicating with the NPAC host driver running on a remote
+	  processor over RPMsg. The driver registers with the DRM accelerator
+	  framework and exposes /dev/accel/accel* as the userspace interface
+	  for ACL rule offload operations.
+	  If you have a device with NPAC and wish to use it with this
+	  driver, say M to compile this driver as a module, or Y to
+	  compile it into the kernel.
diff --git a/drivers/accel/npac/Makefile b/drivers/accel/npac/Makefile
new file mode 100644
index 000000000000..89f4773d7041
--- /dev/null
+++ b/drivers/accel/npac/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_DRM_ACCEL_NPAC_CLIENT) += npac_drv.o
diff --git a/drivers/accel/npac/npac_drv.c b/drivers/accel/npac/npac_drv.c
new file mode 100644
index 000000000000..7516382ba74b
--- /dev/null
+++ b/drivers/accel/npac/npac_drv.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include <drm/drm_accel.h>
+#include <drm/drm_drv.h>
+#include <drm/drm_file.h>
+#include <drm/drm_gem.h>
+#include <drm/drm_ioctl.h>
+#include <linux/completion.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/rpmsg.h>
+
+#define NPAC_RPMSG_SERVICE_NAME	"ti.npac"
+#define NPAC_ACK_TIMEOUT_MS	1000
+
+/**
+ * enum npac_acl_cmd - IOCTL command numbers for NPAC ACL operations.
+ */
+enum npac_acl_cmd {
+	/** @NPAC_ACL_ADD_RULE: Add an ACL rule. */
+	NPAC_ACL_ADD_RULE,
+
+	/** @NPAC_ACL_DELETE_RULE: Delete an ACL rule. */
+	NPAC_ACL_DELETE_RULE,
+};
+
+/**
+ * enum npac_acl_match_type - Match field selector for an ACL rule.
+ */
+enum npac_acl_match_type {
+	/** @NPAC_ACL_MATCH_SRC_IPV4: Match on source IPv4 address. */
+	NPAC_ACL_MATCH_SRC_IPV4 = 1,
+
+	/** @NPAC_ACL_MATCH_DST_IPV4: Match on destination IPv4 address. */
+	NPAC_ACL_MATCH_DST_IPV4,
+
+	/** @NPAC_ACL_MATCH_SRC_MAC: Match on source MAC address. */
+	NPAC_ACL_MATCH_SRC_MAC,
+
+	/** @NPAC_ACL_MATCH_DST_MAC: Match on destination MAC address. */
+	NPAC_ACL_MATCH_DST_MAC,
+};
+
+/**
+ * enum npac_acl_verdict - Action to apply when an ACL rule matches.
+ */
+enum npac_acl_verdict {
+	/** @NPAC_ACL_VERDICT_ALLOW: Accept the matched packet. */
+	NPAC_ACL_VERDICT_ALLOW = 1,
+
+	/** @NPAC_ACL_VERDICT_DROP: Drop the matched packet. */
+	NPAC_ACL_VERDICT_DROP,
+};
+
+/* Sized for the largest match field: a 6-byte MAC address. */
+#define NPAC_ACL_MATCH_VALUE_MAX	6
+
+struct npac_acl_offload_rule {
+	__u32 match_type;
+	__u32 verdict;
+	__u8  match_value[NPAC_ACL_MATCH_VALUE_MAX];
+};
+
+#define DRM_IOCTL_NPAC_ACL_ADD_RULE \
+	DRM_IOWR(DRM_COMMAND_BASE + NPAC_ACL_ADD_RULE, struct npac_acl_offload_rule)
+
+#define DRM_IOCTL_NPAC_ACL_DELETE_RULE \
+	DRM_IOWR(DRM_COMMAND_BASE + NPAC_ACL_DELETE_RULE, struct npac_acl_offload_rule)
+
+struct npac_device {
+	struct drm_device drm;
+	struct rpmsg_device *rpdev;
+	struct mutex req_lock; /* lock for request */
+	struct completion ack;
+};
+
+static inline struct npac_device *drm_to_npac_device(struct drm_device *dev)
+{
+	return container_of(dev, struct npac_device, drm);
+}
+
+static int npac_add_rule_ioctl(struct drm_device *dev, void *data,
+			       struct drm_file *file)
+{
+	struct npac_device *npac = drm_to_npac_device(dev);
+	struct npac_acl_offload_rule *rule = data;
+	int ret;
+
+	dev_dbg(dev->dev, "add rule ioctl received\n");
+
+	mutex_lock(&npac->req_lock);
+	reinit_completion(&npac->ack);
+	ret = rpmsg_send(npac->rpdev->ept, rule, sizeof(*rule));
+	if (ret) {
+		dev_err(dev->dev, "rpmsg_send failed: %d\n", ret);
+		mutex_unlock(&npac->req_lock);
+		return ret;
+	}
+	if (!wait_for_completion_timeout(&npac->ack,
+					 msecs_to_jiffies(NPAC_ACK_TIMEOUT_MS))) {
+		dev_err(dev->dev, "ack timed out\n");
+		mutex_unlock(&npac->req_lock);
+		return -ETIMEDOUT;
+	}
+	mutex_unlock(&npac->req_lock);
+	return 0;
+}
+
+static int npac_delete_rule_ioctl(struct drm_device *dev, void *data,
+				  struct drm_file *file)
+{
+	struct npac_device *npac = drm_to_npac_device(dev);
+	struct npac_acl_offload_rule *rule = data;
+	int ret;
+
+	dev_dbg(dev->dev, "delete rule ioctl received\n");
+
+	mutex_lock(&npac->req_lock);
+	reinit_completion(&npac->ack);
+	ret = rpmsg_send(npac->rpdev->ept, rule, sizeof(*rule));
+	if (ret) {
+		dev_err(dev->dev, "rpmsg_send failed: %d\n", ret);
+		mutex_unlock(&npac->req_lock);
+		return ret;
+	}
+	if (!wait_for_completion_timeout(&npac->ack,
+					 msecs_to_jiffies(NPAC_ACK_TIMEOUT_MS))) {
+		dev_err(dev->dev, "ack timed out\n");
+		mutex_unlock(&npac->req_lock);
+		return -ETIMEDOUT;
+	}
+	mutex_unlock(&npac->req_lock);
+	return 0;
+}
+
+static const struct drm_ioctl_desc npac_drm_ioctls[] = {
+	DRM_IOCTL_DEF_DRV(NPAC_ACL_ADD_RULE,    npac_add_rule_ioctl,    DRM_ROOT_ONLY),
+	DRM_IOCTL_DEF_DRV(NPAC_ACL_DELETE_RULE, npac_delete_rule_ioctl, DRM_ROOT_ONLY),
+};
+
+DEFINE_DRM_ACCEL_FOPS(npac_fops);
+
+static const struct drm_driver npac_drm_driver = {
+	.driver_features	= DRIVER_COMPUTE_ACCEL,
+	.ioctls			= npac_drm_ioctls,
+	.num_ioctls		= ARRAY_SIZE(npac_drm_ioctls),
+	.fops			= &npac_fops,
+	.name			= "npac",
+	.desc			= "NPAC Client Driver",
+};
+
+static int npac_cb(struct rpmsg_device *rpdev, void *data, int len,
+		   void *priv, u32 src)
+{
+	struct npac_device *npac = dev_get_drvdata(&rpdev->dev);
+
+	dev_dbg(&rpdev->dev, "ack received\n");
+	complete(&npac->ack);
+	return 0;
+}
+
+static int npac_probe(struct rpmsg_device *rpdev)
+{
+	struct npac_device *npac;
+	int ret;
+
+	npac = devm_drm_dev_alloc(&rpdev->dev, &npac_drm_driver,
+				  struct npac_device, drm);
+	if (IS_ERR(npac))
+		return PTR_ERR(npac);
+
+	npac->rpdev = rpdev;
+	mutex_init(&npac->req_lock);
+	init_completion(&npac->ack);
+	dev_set_drvdata(&rpdev->dev, npac);
+
+	ret = drm_dev_register(&npac->drm, 0);
+	if (ret) {
+		dev_err(&rpdev->dev, "Failed to register DRM accel device: %d\n", ret);
+		return ret;
+	}
+
+	dev_info(&rpdev->dev, "NPAC Client driver probed\n");
+	return 0;
+}
+
+static void npac_remove(struct rpmsg_device *rpdev)
+{
+	struct npac_device *npac = dev_get_drvdata(&rpdev->dev);
+
+	drm_dev_unplug(&npac->drm);
+
+	dev_info(&rpdev->dev, "NPAC Client Driver removed\n");
+}
+
+static struct rpmsg_device_id npac_id_table[] = {
+	{ .name = NPAC_RPMSG_SERVICE_NAME },
+	{},
+};
+MODULE_DEVICE_TABLE(rpmsg, npac_id_table);
+
+static struct rpmsg_driver npac_driver = {
+	.drv.name	= KBUILD_MODNAME,
+	.id_table	= npac_id_table,
+	.probe		= npac_probe,
+	.callback	= npac_cb,
+	.remove		= npac_remove,
+};
+
+module_rpmsg_driver(npac_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("NPAC Client Driver");
+MODULE_AUTHOR("Jaspinder Budhal <j-budhal@ti.com>");
-- 
2.34.1

Re: [RFC PATCH 1/2] Documentation: accel: Add NPAC client driver documentation

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The proposed design violates kernel architecture by bypassing the standard networking stack and misusing the compute accelerator (accel/DRM) subsystem for network packet processing and ACL offloads.
- [Low] Usage of deprecated, non-inclusive terminology ('blacklisted').
- [Low] Grammatical error in the documentation regarding command pluralization.
--

commit 76a459f24739ffcc1e2f6fc248380fee0d5af75f
Author: Jaspinder Budhal <j-budhal@ti.com>

Documentation: accel: Add NPAC client driver documentation

This commit adds documentation for the Texas Instruments NPAC (Network Packet
ACcelerator) client driver. It details the accelerator's purpose of offloading
network packet processing tasks like ACL rule enforcement. The documentation
also outlines its userspace interface and RPMsg communication model.

> diff --git a/Documentation/accel/npac.rst b/Documentation/accel/npac.rst
> new file mode 100644
> index 0000000000000..fba6ddd0cfd2c
> --- /dev/null
> +++ b/Documentation/accel/npac.rst
[ ... ]
> +When the NPAC host driver announces the NPAC RPMsg service endpoint, the
> +RPMsg core matches the announced service against the registered NPAC client
> +driver and invokes the driver probe callback.
> +
> +Offload command received from userspace are formatted into RPMsgs and sent

[Severity: Low]
This isn't a bug, but there is a grammatical error here. Should "command" be
pluralized to "commands" to match the plural verb "are"?

> +to the NPAC Host Driver.
> +
> +NPAC Host Driver responses are received through RPMsg callbacks.
> +
> +ACL Rule Offload
> +----------------
> +
> +ACL (Access Control List) rules are packet filtering policies that define how
> +network traffic should be handled — for example, dropping packets from a
> +blacklisted source IP or allowing traffic only from trusted MAC addresses.

[Severity: Low]
This isn't a bug, but the Linux kernel coding style guidelines recommend using
inclusive terminology. Could "blacklisted" be replaced with "blocklisted" or
"denylisted"?

[ ... ]
> +IOCTL Commands
> +~~~~~~~~~~~~~~
> +
> +DRM_IOCTL_NPAC_ACL_ADD_RULE
> +
> +  This IOCTL allows userspace to add an ACL rule to the accelerator. The

[Severity: High]
Does this UAPI design bypass the established Linux networking subsystem APIs
for packet filtering?

The accel subsystem is generally intended for generic compute, ML, and AI
workloads. Introducing a custom UAPI for network packet filtering via
/dev/accel/accel* and DRM_IOCTL_NPAC_ACL_ADD_RULE bypasses standard
interfaces like tc-flower (via ndo_setup_tc) or netfilter hardware offload.

This custom interface would prevent standard networking utilities such as tc
or nftables from managing these ACLs, and it removes the standard software
fallback path. Should this driver integrate with the standard networking stack
instead of implementing custom DRM IOCTLs?

> +  call will forward the rule to the NPAC host driver for hardware programming.
> +  The NPAC Host Driver is responsible for validating the rule and applying it to
> +  the NPAC hardware.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701062505.1091840-1-j-budhal@ti.com?part=1

Re: [RFC PATCH 2/2] accel/npac: Add NPAC client driver

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider:
- [High] Missing DRM device removal protection (drm_dev_enter/exit) in IOCTL handlers leads to a Use-After-Free of the RPMsg endpoint.
- [High] A shared completion mechanism without transaction IDs causes delayed hardware ACKs to falsely complete subsequent IOCTL requests.
- [High] Spurious or early RPMsg messages cause a NULL pointer dereference in `npac_cb` before `probe` completes.
- [High] The ADD and DELETE rule IOCTLs send identical payloads over RPMsg without any command identifier.
- [Medium] Implicit padding in the `npac_acl_offload_rule` UAPI structure leaks uninitialized userspace memory to the remote processor and breaks ABI.
- [Medium] Driver ignores the remote processor's response content, incorrectly assuming all ACKs indicate success.
- [Low] UAPI structs and IOCTL definitions are placed in the driver C file instead of a dedicated UAPI header.
--

commit f09e8a02272732ea035f9ef6c3a3f177ff86129a
Author: Jaspinder Budhal <j-budhal@ti.com>

accel/npac: Add NPAC client driver

This commit adds the Linux client driver for the Network Packet ACcelerator
(NPAC). The driver communicates with the NPAC host driver via RPMsg to
offload ethernet-related packet processing tasks, providing an IOCTL
interface for userspace ACL rule management.

> diff --git a/drivers/accel/npac/npac_drv.c b/drivers/accel/npac/npac_drv.c
> new file mode 100644
> index 0000000000000..7516382ba74b6
> --- /dev/null
> +++ b/drivers/accel/npac/npac_drv.c
[ ... ]
> +struct npac_acl_offload_rule {
> +	__u32 match_type;
> +	__u32 verdict;
> +	__u8  match_value[NPAC_ACL_MATCH_VALUE_MAX];
> +};

[Severity: Medium]
Does this structure have an implicit 2-byte padding at the end due to the
__u32 alignment?

If so, the DRM IOCTL copy_from_user() path could copy uninitialized memory
from userspace, leaking it to the remote processor. Should explicit padding
(e.g., __u8 reserved[2]) be added to stabilize the ABI?

[Severity: High]
How does the hardware differentiate between ADD and DELETE commands?

Since both IOCTLs send this exact same payload, the remote processor receives
an identical byte sequence without an opcode or command identifier.

> +#define DRM_IOCTL_NPAC_ACL_ADD_RULE \
> +	DRM_IOWR(DRM_COMMAND_BASE + NPAC_ACL_ADD_RULE, struct npac_acl_offload_rule)
> +
> +#define DRM_IOCTL_NPAC_ACL_DELETE_RULE \
> +	DRM_IOWR(DRM_COMMAND_BASE + NPAC_ACL_DELETE_RULE, struct npac_acl_offload_rule)

[Severity: Low]
Should these UAPI structures and IOCTL definitions be placed in a dedicated
UAPI header (e.g., include/uapi/drm/npac_drm.h) instead of being hidden in
the driver source?

[ ... ]
> +static int npac_add_rule_ioctl(struct drm_device *dev, void *data,
> +			       struct drm_file *file)
> +{
> +	struct npac_device *npac = drm_to_npac_device(dev);
> +	struct npac_acl_offload_rule *rule = data;
> +	int ret;
> +
> +	dev_dbg(dev->dev, "add rule ioctl received\n");
> +
> +	mutex_lock(&npac->req_lock);
> +	reinit_completion(&npac->ack);
> +	ret = rpmsg_send(npac->rpdev->ept, rule, sizeof(*rule));

[Severity: High]
Can this result in a use-after-free if the RPMsg device is unbound while
the IOCTL is executing?

Since the execution isn't protected by drm_dev_enter() and drm_dev_exit(),
drm_dev_unplug() can return immediately and the RPMsg endpoint could be
destroyed while rpmsg_send() is still accessing it.

> +	if (ret) {
> +		dev_err(dev->dev, "rpmsg_send failed: %d\n", ret);
> +		mutex_unlock(&npac->req_lock);
> +		return ret;
> +	}
> +	if (!wait_for_completion_timeout(&npac->ack,
> +					 msecs_to_jiffies(NPAC_ACK_TIMEOUT_MS))) {

[Severity: High]
If this wait times out, the firmware might still be processing the command
and send an ACK later.

If a subsequent IOCTL acquires req_lock and calls reinit_completion(),
could a delayed ACK from the first request cause the second IOCTL to falsely
return success before its actual request is processed? Should there be a
transaction ID to match ACKs to specific requests?

[ ... ]
> +static int npac_cb(struct rpmsg_device *rpdev, void *data, int len,
> +		   void *priv, u32 src)
> +{
> +	struct npac_device *npac = dev_get_drvdata(&rpdev->dev);
> +
> +	dev_dbg(&rpdev->dev, "ack received\n");
> +	complete(&npac->ack);

[Severity: High]
Is it possible for dev_get_drvdata() to return NULL here?

If a message arrives on the RPMsg bus before dev_set_drvdata() is called
during npac_probe(), this will result in a NULL pointer dereference.

[Severity: Medium]
Does the remote processor ever send status or error codes in the payload if
a rule is rejected (e.g., if the hardware rule table is full)?

The data and len parameters are completely ignored here, which might cause
userspace to believe a rule was successfully offloaded when the hardware
actually rejected it.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701062505.1091840-1-j-budhal@ti.com?part=2