linux-kernel - Re: [PATCH 00/12] iio: add new backend framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMknhBEg+cFrm9kQh1G+8nxGPCFsBaca3rnLEnXZ1h=XDS1aeQ@mail.gmail.com>
Date:   Sat, 2 Dec 2023 10:16:52 -0600
From:   David Lechner <dlechner@...libre.com>
To:     Nuno Sá <noname.nuno@...il.com>
Cc:     nuno.sa@...log.com, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, linux-iio@...r.kernel.org,
        Olivier MOYSAN <olivier.moysan@...s.st.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Michael Hennerich <Michael.Hennerich@...log.com>
Subject: Re: [PATCH 00/12] iio: add new backend framework

On Sat, Dec 2, 2023 at 3:37 AM Nuno Sá <noname.nuno@...il.com> wrote:
>
> On Fri, 2023-12-01 at 21:53 -0600, David Lechner wrote:
> > On Thu, Nov 30, 2023 at 5:54 PM David Lechner <dlechner@...libre.com> wrote:
> > >
> > > On Tue, Nov 21, 2023 at 4:17 AM Nuno Sa via B4 Relay
> > > <devnull+nuno.sa.analog.com@...nel.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 device which
> > > > can be "linked" against one or multiple backend devices. All the IIO and
> > > > userspace interface is expected to be registers/managed by the frontend
> > > > device which will callback into the backends when needed (to get/set
> > > > some configuration that it does not directly control).
> > > >
> > > > The basic framework interface is pretty simple:
> > > >  - Backends should register themselves with @devm_iio_backend_register()
> > > >  - 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 the
> > > 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 this:
> >
>
> This is not an offload framework... I think somehow you're connecting this to the
> spi_engine offload and these are two completely different things. Maybe they can
> intersect at some point but as of now, I don't see any benefit in doing it. The goal
> of this patchseries is to have a simple and generic framework so we can connect IIO
> devices (frontends) to a backend device having kind of an IIO aggregate device so to
> say. Moreover, we just want to have the ad9467 driver in the same state it was before
> to keep things simple. I'm already fixing some things but I don't want extend that
> too much as the primary goal is to have the framework in. Cleanups can come
> afterwards.
>
> That said, is fine to have this kind of discussion but I honestly think you'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 the below.
> Also note this should be simple and generic. As I already said, this is not supposed
> to be an ADI only thing and STM also wants to make use of this infrastructure. 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.