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

[Manivannan Sadhasivam <mani@kernel.org>]

On Fri, Oct 02, 2026 at 09:57:21AM -0600, Jeff Hugo wrote:
> 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.

Yes!

- Mani

-- 
மணிவண்ணன் சதாசிவம்