Re: [PATCH v5 1/3] bus: mhi: host: clients: Add loopback driver with sysfs interface
From: Sumit Kumar
Date: Wed Aug 19 2026 - 05:47:39 EST
On 8/18/2026 1:44 AM, Jeff Hugo wrote:
On 8/17/2026 4:14 AM, Sumit Kumar wrote:Acknowledged, thanks — targeting 7.4 next.
The MHI specification defines a LOOPBACK channel. The endpoint firmware
echoes back whatever the host sends on this channel. Without a host-side
driver, there is no way to exercise this channel to validate MHI data path
integrity between host and endpoint.
Add a host-side loopback driver that binds to the LOOPBACK channel and
expose a sysfs interface for data path testing. The sysfs interface allows
users to configure TRE buffer size and count, trigger a loopback test, and
read the result.
Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@xxxxxxxxxxxxxxxx>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@xxxxxxxxxxxxxxxx>
Signed-off-by: Sumit Kumar <sumit.kumar@xxxxxxxxxxxxxxxx>
---
.../ABI/testing/sysfs-bus-mhi-devices-loopback | 39 +++
MAINTAINERS | 1 +
drivers/bus/mhi/host/Kconfig | 1 +
drivers/bus/mhi/host/Makefile | 1 +
drivers/bus/mhi/host/clients/Kconfig | 17 ++
drivers/bus/mhi/host/clients/Makefile | 2 +
drivers/bus/mhi/host/clients/loopback.c | 289 +++++++++++++++++++++
7 files changed, 350 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-mhi-devices-loopback b/Documentation/ABI/testing/sysfs-bus-mhi-devices-loopback
new file mode 100644
index 0000000000000000000000000000000000000000..1622a146110c2069c8b51e5bdf665c882b853303
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-mhi-devices-loopback
@@ -0,0 +1,39 @@
+What: /sys/bus/mhi/devices/mhi<N>_LOOPBACK/tre_size
+Date: August 2026
+KernelVersion: 7.2
This series missed 7.2, and will miss 7.3 since the merge window is already open. Next oppertunity is 7.4.
Will update the description.
+Contact: mhi@xxxxxxxxxxxxxxx
+Description:
+ (RW) Size of each Transfer Ring Element (TRE) buffer in bytes
+ used for the loopback test. Valid range is 1 to the value
+ reported by max_tre_size. Default value is 32 bytes.
+
+What: /sys/bus/mhi/devices/mhi<N>_LOOPBACK/max_tre_size
+Date: August 2026
+KernelVersion: 7.2
+Contact: mhi@xxxxxxxxxxxxxxx
+Description:
+ (RO) Maximum allowed TRE size in bytes. Reading this file
Entry before this and after this explains the TRE acronym, but this does not. It probably should, as someone may jump directly to this section and not read the entire document start to finish.
if you try to write any value bigger than ring capacity the error will report it with the max ring capacity.
+ returns the upper bound for the tre_size attribute.
+
+What: /sys/bus/mhi/devices/mhi<N>_LOOPBACK/num_tre
+Date: August 2026
+KernelVersion: 7.2
+Contact: mhi@xxxxxxxxxxxxxxx
+Description:
+ (RW) Number of Transfer Ring Elements (TREs) to use per
+ loopback test. Must be greater than zero and must not exceed
+ the channel ring capacity. Default value is 1.
How would I know the channel ring capacity? Should I just try values until I get an error?
Would you prefer having another read only sysfs to find out the ring capacity ?
Since currently we are checking the data path, random bytes should suffice for now.
+
+What: /sys/bus/mhi/devices/mhi<N>_LOOPBACK/start
+Date: August 2026
+KernelVersion: 7.2
+Contact: mhi@xxxxxxxxxxxxxxx
+Description:
+ (WO) Write any value to trigger a loopback test. The driver
+ sends random data to the endpoint using the configured tre_size
It feels like these kind of interfaces usually give an option to specify a byte pattern as well, but I don't see that option here. Is random data considered to cover all usecases?
Happy to add a pattern option later if a concrete use case needs deterministic content, but I'd prefer random as the default.
Commit text needs to be fixed for this, Thanks will update it in the next revision.
+ and num_tre parameters, waits for the endpoint to echo it back,
+ and verifies the received data matches what was sent.
+
+ This is a blocking write that returns when the test completes
+ or times out after 5 seconds. The write returns an error code
+ if the test fails or times out.
diff --git a/MAINTAINERS b/MAINTAINERS
index a4b89bd497ad5051c190025838e0e93d257ed061..098b12692140514da52565a3200801f5e24a43b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17469,6 +17469,7 @@ L: linux-arm-msm@xxxxxxxxxxxxxxx
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git
F: Documentation/ABI/stable/sysfs-bus-mhi
+F: Documentation/ABI/testing/sysfs-bus-mhi-devices-loopback
Commit text says this ABI is stable. Seems odd its being added to testing.
those are just examples, will reword it.
F: Documentation/mhi/
F: drivers/bus/mhi/
F: drivers/pci/endpoint/functions/pci-epf-mhi.c
diff --git a/drivers/bus/mhi/host/Kconfig b/drivers/bus/mhi/host/Kconfig
index da5cd0c9fc620ab595e742c422f1a22a2a84c7b9..627c57948235aa52348179ae8b2d0826ebaed01e 100644
--- a/drivers/bus/mhi/host/Kconfig
+++ b/drivers/bus/mhi/host/Kconfig
@@ -29,3 +29,4 @@ config MHI_BUS_PCI_GENERIC
This driver provides MHI PCI controller driver for devices such as
Qualcomm SDX55 based PCIe modems.
+source "drivers/bus/mhi/host/clients/Kconfig"
diff --git a/drivers/bus/mhi/host/Makefile b/drivers/bus/mhi/host/Makefile
index 859c2f38451c669b3d3014c374b2b957c99a1cfe..2a16008aeb38127494782bbff4e1656428d2b776 100644
--- a/drivers/bus/mhi/host/Makefile
+++ b/drivers/bus/mhi/host/Makefile
@@ -4,3 +4,4 @@ mhi-$(CONFIG_MHI_BUS_DEBUG) += debugfs.o
obj-$(CONFIG_MHI_BUS_PCI_GENERIC) += mhi_pci_generic.o
mhi_pci_generic-y += pci_generic.o
+obj-y += clients/
diff --git a/drivers/bus/mhi/host/clients/Kconfig b/drivers/bus/mhi/host/clients/Kconfig
new file mode 100644
index 0000000000000000000000000000000000000000..312a0b5a8e83b6ad7246453908bd552841a89188
--- /dev/null
+++ b/drivers/bus/mhi/host/clients/Kconfig
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config MHI_BUS_LOOPBACK
+ tristate "MHI LOOPBACK client driver"
+ depends on MHI_BUS
+ help
+ MHI LOOPBACK client driver that binds to the MHI LOOPBACK channel
+ as defined in the MHI specification. The LOOPBACK channel is
+ implemented by MHI-based devices (modems, WLAN) in the field, where
Are modems, WLAN the only devices that implement this, or are those intended to be examples? Current reads as a limitation.
I missed the recent rebase on mhi-next therefore missed these merges. will rebase and fix.
+ the endpoint firmware echoes back whatever the host sends.
+
+ This driver exposes a sysfs interface for testing MHI data path
+ integrity between host and endpoint. Users can configure the TRE
+ size and count, and trigger a loopback test.
+
+ To compile this driver as a module, choose M here. The module
+ will be called mhi_loopback.
diff --git a/drivers/bus/mhi/host/clients/Makefile b/drivers/bus/mhi/host/clients/Makefile
new file mode 100644
index 0000000000000000000000000000000000000000..3811b6928f42b38f94b1167941cf3b0fe512d32b
--- /dev/null
+++ b/drivers/bus/mhi/host/clients/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_MHI_BUS_LOOPBACK) += mhi_loopback.o
+mhi_loopback-y += loopback.o
diff --git a/drivers/bus/mhi/host/clients/loopback.c b/drivers/bus/mhi/host/clients/loopback.c
new file mode 100644
index 0000000000000000000000000000000000000000..02a952e8e01222cd8cb842c9f9490479df8ea2bd
--- /dev/null
+++ b/drivers/bus/mhi/host/clients/loopback.c
@@ -0,0 +1,289 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/atomic.h>
+#include <linux/cleanup.h>
+#include <linux/completion.h>
+#include <linux/errno.h>
+#include <linux/mhi.h>
+#include <linux/mod_devicetable.h>
I'm pretty sure this is now incorrect based on cleanups that just occured in tree.
tre_pending tracks how many of the tre_count queued DL+UL completions
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/random.h>
+#include <linux/sizes.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/types.h>
+
+#define MHI_LOOPBACK_DEFAULT_TRE_SIZE 32
+#define MHI_LOOPBACK_DEFAULT_NUM_TRE 1
+#define MHI_LOOPBACK_TIMEOUT_MS 5000
+#define MHI_LOOPBACK_MAX_TRE_SIZE (SZ_64K - 1)
+
+struct mhi_loopback {
+ struct mhi_device *mdev;
+ /* Serializes the sysfs attributes against a running test */
+ struct mutex lb_mutex;
+ struct completion comp;
+ atomic_t tre_pending;
I'm not really sure I understand what purpose this is serving.
are still outstanding; comp is signaled once it hits zero, which is what
start_store() waits on. Will add a comment for it.
num_tre and tre_size are sysfs attribute values parsed with kstrtou32() from a text write,+ u32 num_tre;
+ u32 tre_size;
I'm pretty sure these are the wrong types since they cross kernel boundaries.
they don't cross into any MHI wire-protocol struct or UAPI boundary, and u32 comfortably covers
the valid range (num_tre is ring-capacity-bounded, tre_size caps at MHI_LOOPBACK_MAX_TRE_SIZE = 64K-1)
Could you explain a little bit more about the boundary concern.