> -----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? Thank you, Eliza
