Re: [PATCH 1/2] Documentation: bindings: adi,axi-tdd.yaml: Add new TDD engine driver

[Nuno Sá]

On Thu, 2023-07-27 at 09:46 +0000, Balas, Eliza wrote:
> 
> 
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> > Sent: Thursday, July 27, 2023 12:27
> > To: Balas, Eliza <Eliza.Balas@xxxxxxxxxx>
> > Cc: Rob Herring <robh+dt@xxxxxxxxxx>; Krzysztof Kozlowski
> > <krzysztof.kozlowski+dt@xxxxxxxxxx>; Conor Dooley
> > <conor+dt@xxxxxxxxxx>; Derek Kiernan <derek.kiernan@xxxxxxx>; Dragan Cvetic
> > <dragan.cvetic@xxxxxxx>; Arnd Bergmann
> > <arnd@xxxxxxxx>; Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>;
> > linux-kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx
> > Subject: Re: [PATCH 1/2] Documentation: bindings: adi,axi-tdd.yaml: Add new TDD
> > engine driver
> > 
> > [External]
> > 
> > On 27/07/2023 11:05, Balas, Eliza wrote:
> > > 
> > > > -----Original Message-----
> > > > From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> > > > Sent: Wednesday, July 26, 2023 21:35
> > > > To: Balas, Eliza <Eliza.Balas@xxxxxxxxxx>
> > > > Cc: Rob Herring <robh+dt@xxxxxxxxxx>; Krzysztof Kozlowski
> > > > <krzysztof.kozlowski+dt@xxxxxxxxxx>; Conor Dooley
> > > > <conor+dt@xxxxxxxxxx>; Derek Kiernan <derek.kiernan@xxxxxxx>; Dragan Cvetic
> > > > <dragan.cvetic@xxxxxxx>; Arnd Bergmann
> > > > <arnd@xxxxxxxx>; Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>;
> > > > linux-kernel@xxxxxxxxxxxxxxx;
> > devicetree@xxxxxxxxxxxxxxx
> > > > Subject: Re: [PATCH 1/2] Documentation: bindings: adi,axi-tdd.yaml: Add new
> > > > TDD engine driver
> > > > 
> > > > [External]
> > > > 
> > > > On 26/07/2023 09:11, Eliza Balas wrote:
> > > > > Add device tree documentation for the AXI TDD Core.
> > > > > 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.
> > > > 
> > > > Please use subject prefixes matching the subsystem. You can get them for
> > > > example with `git log --oneline -- DIRECTORY_OR_FILE`
> > on
> > > > the directory your patch is touching.
> > > > 
> > > > Subject: drop driver. Bindings are for hardware, not drivers... unless driver
> > > > is here a hardware term?
> > > 
> > > It is not a hardware term in this case, I will make the changes.
> > > 
> > > > > 
> > > > > Signed-off-by: Eliza Balas <eliza.balas@xxxxxxxxxx>
> > > > > ---
> > > > >  .../devicetree/bindings/misc/adi,axi-tdd.yaml | 51 +++++++++++++++++++
> > > > >  MAINTAINERS                                   |  7 +++
> > > > >  2 files changed, 58 insertions(+)
> > > > >  create mode 100644
> > > > > Documentation/devicetree/bindings/misc/adi,axi-tdd.yaml
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/misc/adi,axi-tdd.yaml
> > > > > b/Documentation/devicetree/bindings/misc/adi,axi-tdd.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..1894c1c34d4f
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/misc/adi,axi-tdd.yaml
> > > > 
> > > > Why is this in misc? No suitable directory?
> > > 
> > > I chose misc because I don't know where it should fit, I did not find a
> > > suitable
> > > subsystem to include this driver because this is a driver for an FPGA IP core.
> > > Do you have an idea where I should put it?
> > 
> > Directory based on what this device does. Whether some device is
> > implemented as FPGA core or dedicated circuitry, it does not matter. Few
> > Time Division Multiplexing devices are related to audio, so they are in
> > sound. I don't know if TDD is something else than TDM. If nothing fits,
> > can be misc, but again - just because device does no fit, not the drivers.
> 
> This device resembles a bit with an IIO device (we are dealing with channels and
> the
> sysfs interface follows the IIO specification), but is not registered into the IIO
> device tree, 
> and does not rely on IIO kernel APIs. 
> Do you think this device is a better fit into the IIO subsystem?
> 

We do have tons of specific attributes (non IIO ones) for this device. The ones
resembling IIO is likely because it feels familiar to us in ADI. Anyways, I have my
doubts this fits (at least as IIO stands right now) but maybe Jonathan thinks
otherwise.

+cc Jonathan...

- Nuno Sá