Re: [PATCH v5 1/3] bus: mhi: host: clients: Add loopback driver with sysfs interface

On 8/18/2026 1:44 AM, Jeff Hugo wrote:
> On 8/17/2026 4:14 AM, Sumit Kumar wrote:
>> 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 
>> <[email protected]>
>> Signed-off-by: Krishna Chaitanya Chundru 
>> <[email protected]>
>> Signed-off-by: Sumit Kumar <[email protected]>
>> ---
>>   .../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.
Acknowledged, thanks — targeting 7.4 next.
>
>> +Contact:    [email protected]
>> +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:    [email protected]
>> +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.
Will update the description.
>
>> +        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:    [email protected]
>> +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?
if you try to write any value bigger than ring capacity the error will 
report it with the max ring capacity.
Would you prefer having another read only sysfs to find out the ring 
capacity ?
>
>> +
>> +What:        /sys/bus/mhi/devices/mhi<N>_LOOPBACK/start
>> +Date:        August 2026
>> +KernelVersion:    7.2
>> +Contact:    [email protected]
>> +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?
Since currently we are checking the data path, random bytes should 
suffice for now.
Happy to add a pattern option later if a concrete use case needs 
deterministic content, but I'd prefer random as the default.
>
>> +        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:    [email protected]
>>   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.
Commit text needs to be fixed for this, Thanks will update it in the 
next revision.
>
>>   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.
those are just examples, will reword it.
>
>> +      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.
I missed the recent rebase on mhi-next therefore missed these merges. 
will rebase and fix.
>
>> +#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.
>
tre_pending tracks how many of the tre_count queued DL+UL completions
are still outstanding; comp is signaled once it hits zero, which is what
start_store() waits on. Will add a comment for it.
>> +    u32 num_tre;
>> +    u32 tre_size;
>
> I'm pretty sure these are the wrong types since they cross kernel 
> boundaries.
>
num_tre and tre_size are sysfs attribute values parsed with kstrtou32() 
from a text write,
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.