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á
