Message-ID: <5043c6729e1ffd2dac84b6908b26db11347521b0.camel@gmail.com>
Date:   Thu, 28 Sep 2023 18:35:29 +0200
From:   Nuno Sá <noname.nuno@...il.com>
To:     Arnd Bergmann <arnd@...db.de>, Eliza Balas <Eliza.Balas@...log.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        "derek.kiernan@....com" <derek.kiernan@....com>,
        "dragan.cvetic@....com" <dragan.cvetic@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] drivers: misc: adi-axi-tdd: Add TDD engine

On Thu, 2023-09-28 at 10:19 -0400, Arnd Bergmann wrote:
> On Thu, Sep 28, 2023, at 06:54, Balas, Eliza wrote:
> > > <conor+dt@...nel.org>; derek.kiernan@....com; dragan.cvetic@....com; Greg
> > > Kroah-Hartman <gregkh@...uxfoundation.org>;
> > > linux-kernel@...r.kernel.org; devicetree@...r.kernel.org
> > > Subject: Re: [PATCH v2 2/2] drivers: misc: adi-axi-tdd: Add TDD engine
> > > 
> > > [External]
> > > 
> > > On Thu, Sep 28, 2023, at 11:28, Eliza Balas wrote:
> > > > This patch introduces the driver for the new ADI TDD engine HDL.
> > > > The generic TDD controller is in essence a waveform generator
> > > > capable of addressing RF applications which require Time Division
> > > > Duplexing, as well as controlling other modules of general
> > > > applications through its dedicated 32 channel outputs.
> > > > 
> > > > The reason of creating the generic TDD controller was to reduce
> > > > the naming confusion around the existing repurposed TDD core
> > > > built for AD9361, as well as expanding its number of output
> > > > channels for systems which require more than six controlling signals.
> > > > 
> > > > Signed-off-by: Eliza Balas <eliza.balas@...log.com>
> > > 
> > > Thanks for your submission, I've had a first look at the driver
> > > and the implementation of the interface you have chosen looks
> > > all good to me, so I have no detailed comments on that.
> > > 
> > > It would however help to explain the ideas you had for the
> > > user-space interface design and summarize them in the changelog
> > > text.
> > > 
> > > You have chosen a low-level interface that wraps the individual
> > > device registers and gives user space direct control over them.
> > > The risk here is to lock yourself into the first design,
> > > giving you less flexibility for future extensions, so it would
> > > help to understand what the usage model is here.
> > > 
> > > One risk is that there may be an in-kernel user in the future
> > > when the TDD engine interacts with another device, so you
> > > need a driver level interface, which would in turn break
> > > if any user pokes the registers directly.
> > > 
> > > Another possible problem I see is that an application written
> > > for this driver would be incompatible with similar hardware
> > > that has the same functionality but a different register-level
> > > interface, or even a minor revision of the device that ends up
> > > breaking one of the assumptions about the hardware design.
> > > 
> > > In both cases, the likely answer is to have a higher-level
> > > interface of some sort, but the downside of that would be
> > > that it is much harder to come up with a good interface that
> > > covers all possible use cases.
> > > 
> > > Another question is whether you could fit into some
> > > existing subsystem instead of creating a single-driver
> > > interface. drivers/iio/ might be a good choice, as
> > > it already handles both in-kernel and userspace users,
> > > and provides a common abstraction for multiple classes
> > > of devices that (without any domain knowledge in my case)
> > > look similar enough that this could be added there.
> > > 
> > 
> > We are using this driver with an iio-fake device 
> > https://github.com/analogdevicesinc/linux/blob/master/Documentation/devicetree/bindings/iio/jesd204/adi%2Ciio-fakedev.yaml
> >  
> >  so we can take advantage of the iio user-space interface.
> 
> I don't understand how that works yet: Do you mean that there
> is  user-space application that uses the tdd sysfs interface to
> export an IIO device back into the kernel, or do you mean there
> is a regular IIO device in with a kernel driver that is used
> as the back-end for the tdd device, or something else?
> 

Well, I never used this myself but the iio-fakedev is an out of tree driver that
receives a phandle to a device and a string list of sysfs attributes of that same
device. It then symlinks those to an IIO fake device so they seem like IIO device
attributes. As a said, this is __very__, __very__ hackish and the solely reason it's
being done (I believe), is to use libiio on that fakedev so you can access these kind
of devices (like this TDD core) remotely through the network for example (or USB). In
the past, we would put drivers that are not IIO in IIO for the same reason. So, at
least now, it's a one time ugly hack :sweat_smile: but then we can put drivers in
their right places. Not saying this justifies this fakedev but it is what it is :).

Well, maybe this one is not really in here but the IIO maintainer was also not to
keen to have in there. So I'm not really sure where else it can go.
> 

- Nuno Sá

Powered by blists - more mailing lists