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

[Jeff Hugo <jeff.hugo@oss.qualcomm.com>]

On 9/29/2026 11:56 PM, Sumit Kumar wrote:
> 
> 
> On 9/26/2026 4:36 PM, Manivannan Sadhasivam wrote:
>> On Tue, Sep 08, 2026 at 02:57:22PM +0530, 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.
>>>
>>> The new sysfs ABI is documented under Documentation/ABI/testing/, not
>>> stable/, since this is a new interface without established API
>>> guarantees yet. It is unrelated to the existing stable MHI sysfs ABI
>>> documented in Documentation/ABI/stable/sysfs-bus-mhi, despite both
>>> being covered by the same MAINTAINERS entry.
>>>
>>> Co-developed-by: Krishna Chaitanya Chundru 
>>> <krishna.chundru@oss.qualcomm.com>
>>> Signed-off-by: Krishna Chaitanya Chundru 
>>> <krishna.chundru@oss.qualcomm.com>
>>> Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
>>> ---
>>>   .../ABI/testing/sysfs-bus-mhi-devices-loopback     |  40 +++
>>>   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            | 287 ++++++++++ 
>>> +++++++++++
>>>   7 files changed, 349 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..9e47e8443f309199691a50d70adadf84f3237037
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-mhi-devices-loopback
>>> @@ -0,0 +1,40 @@
>>> +What:        /sys/bus/mhi/devices/mhi<N>_LOOPBACK/tre_size
>>> +Date:        August 2026
>>> +KernelVersion:    7.4
>>> +Contact:    mhi@lists.linux.dev
>>> +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.4
>>> +Contact:    mhi@lists.linux.dev
>>> +Description:
>>> +        (RO) Maximum allowed Transfer Ring Element (TRE) size in bytes.
>>> +        Reading this file returns the upper bound for the tre_size
>>> +        attribute.
>>> +
>>> +What:        /sys/bus/mhi/devices/mhi<N>_LOOPBACK/num_tre
>>> +Date:        August 2026
>>> +KernelVersion:    7.4
>>> +Contact:    mhi@lists.linux.dev
>>> +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 does the user know 'channel ring capacity'?
> If the user enters a number greater than the ring capacity the error 
> will log the max num_tre value.
> Would you prefer having a new sysfs entry similar to 'max_tre_size'? 
> something like 'max_num_tre'.

Yes, a new sysfs entry sounds like a reasonable idea.  Having the user 
guess, and then try to read an error log which they may or may not have 
sounds like a way to cause frustration in users, particularly for any 
kind of scripted use.