Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
MIME-Version: 1.0
References: <20231121-dev-iio-backend-v1-0-6a3d542eba35@analog.com>
 <CAMknhBH0pF_+z_JqWGscELBmAEDyxLAtgQ-j3=6P2MeFXnzhWQ@mail.gmail.com>
 <CAMknhBEcEJ01nO0p5_vy4jVBVTL_rhEk+pvBpXdMtaDurc-05A@mail.gmail.com> <369a72dd34c0bc457620b88594a975d96aa85a22.camel@gmail.com>
In-Reply-To: <369a72dd34c0bc457620b88594a975d96aa85a22.camel@gmail.com>
From:   David Lechner <dlechner@baylibre.com>
Date:   Sat, 2 Dec 2023 10:16:52 -0600
Message-ID: <CAMknhBEg+cFrm9kQh1G+8nxGPCFsBaca3rnLEnXZ1h=XDS1aeQ@mail.gmail.com>
Subject: Re: [PATCH 00/12] iio: add new backend framework
To:     =?UTF-8?B?TnVubyBTw6E=?= <noname.nuno@gmail.com>
Cc:     nuno.sa@analog.com, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org, linux-iio@vger.kernel.org,
        Olivier MOYSAN <olivier.moysan@foss.st.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Frank Rowand <frowand.list@gmail.com>,
        Jonathan Cameron <jic23@kernel.org>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Michael Hennerich <Michael.Hennerich@analog.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sat, Dec 2, 2023 at 3:37=E2=80=AFAM Nuno S=C3=A1 <noname.nuno@gmail.com>=
 wrote:
>
> On Fri, 2023-12-01 at 21:53 -0600, David Lechner wrote:
> > On Thu, Nov 30, 2023 at 5:54=E2=80=AFPM David Lechner <dlechner@baylibr=
e.com> wrote:
> > >
> > > On Tue, Nov 21, 2023 at 4:17=E2=80=AFAM Nuno Sa via B4 Relay
> > > <devnull+nuno.sa.analog.com@kernel.org> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > This is a Framework to handle complex IIO aggregate devices.
> > > >
> > > > The typical architecture is to have one device as the frontend devi=
ce which
> > > > can be "linked" against one or multiple backend devices. All the II=
O and
> > > > userspace interface is expected to be registers/managed by the fron=
tend
> > > > device which will callback into the backends when needed (to get/se=
t
> > > > some configuration that it does not directly control).
> > > >
> > > > The basic framework interface is pretty simple:
> > > >  - Backends should register themselves with @devm_iio_backend_regis=
ter()
> > > >  - Frontend devices should get backends with @devm_iio_backend_get(=
)
> > > >
> > > > (typical provider - consumer stuff)
> > > >
> > >
> > > The "typical provider - consumer stuff" seems pretty straight forward
> > > for finding and connecting two different devices, but the definition
> > > of what is a frontend and what is a backend seems a bit nebulous. It
> > > would be nice to seem some example devicetree to be able to get a
> > > better picture of how this will be used in practices (links to the th=
e
> > > hardware docs for those examples would be nice too).
> > >
> >
> > Fulfilling my own request here...
> >
> > Since AD9467 is being use as the example first user of the IIO offload =
framework
> > I did a deep dive into how it is actually being used. It looks like thi=
s:
> >
>
> This is not an offload framework... I think somehow you're connecting thi=
s to the
> spi_engine offload and these are two completely different things. Maybe t=
hey can
> intersect at some point but as of now, I don't see any benefit in doing i=
t. The goal
> of this patchseries is to have a simple and generic framework so we can c=
onnect IIO
> devices (frontends) to a backend device having kind of an IIO aggregate d=
evice so to
> say. Moreover, we just want to have the ad9467 driver in the same state i=
t was before
> to keep things simple. I'm already fixing some things but I don't want ex=
tend that
> too much as the primary goal is to have the framework in. Cleanups can co=
me
> afterwards.
>
> That said, is fine to have this kind of discussion but I honestly think y=
ou're over
> engineering the whole thing. Maybe you're already too ahead of me :), but=
 where we
> stand right now, I don't see any reason for anything so complicated as th=
e below.
> Also note this should be simple and generic. As I already said, this is n=
ot supposed
> to be an ADI only thing and STM also wants to make use of this infrastruc=
ture. But
> see below some of my comments on why I think it's too much...

This is a very fair point. I do have a tendency to overthink things. :-)

At the very least, being able to see the schematic of how it all fits
together filled in the holes of my understanding and now everything
you are doing in this series makes sense to me. And I totally agree
with keeping it simpler is better.