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: <0afd52940147b14db33d4712368c5dcc9ee90882.camel@gmail.com>
Date:   Fri, 01 Dec 2023 09:41:53 +0100
From:   Nuno Sá <noname.nuno@...il.com>
To:     David Lechner <dlechner@...libre.com>, nuno.sa@...log.com
Cc:     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 Thu, 2023-11-30 at 17:54 -0600, David Lechner 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).
> 
> In addition to the backend ops given in this series, what are some
> other expected ops that could be added in the future? Do we need some
> kind of spec to say "I need a backend with feature X and feature Y" or
> "I need a backend with compatible string" rather than just "I need a
> generic backend"?

Bah, I know saw that I messed up in the cover letter. This was the link [1] I wanted
to add. In there, you'll see the RFC patch which already has lots of info. It also
has a link to a previous discussion  had with Jonathan about this kind off
arrangement.

You already more or less figured the frontend + backend story in one of your replies.
So, yes the data is received or transmitted (if we think DAC/DDS) by the actual
converter which makes sense to be seen as the frontend. This connects to another
device capable of handling the high sample rate (typically a core in a FPGA) of these
converters. But this is ADI usecase, note that STM also wants to have something like
this in order to link devices. Ah, and one of the things that Jonathan wants to see
is that only the frontend device exposes the IIO interface to userspace.




[1]: https://lore.kernel.org/linux-iio/20230804145342.1600136-1-nuno.sa@analog.com/

- Nuno Sá