Hi Mateusz,
On Tue, Oct 6, 2020 at 9:01 AM Mateusz Holenko <mholenko@xxxxxxxxxxxx> wrote:
> On Fri, Sep 25, 2020 at 3:16 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > On Wed, Sep 23, 2020 at 12:10 PM Mateusz Holenko <mholenko@xxxxxxxxxxxx> wrote:
> > > From: Filip Kokosinski <fkokosinski@xxxxxxxxxxxx>
> > >
> > > Add documentation for LiteUART devicetree bindings.
> > >
> > > Signed-off-by: Filip Kokosinski <fkokosinski@xxxxxxxxxxxx>
> > > Signed-off-by: Mateusz Holenko <mholenko@xxxxxxxxxxxx>
> > > Reviewed-by: Rob Herring <robh@xxxxxxxxxx>
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
> > > +properties:
> > > + compatible:
> > > + const: litex,liteuart
> >
> > Have you already decided how to handle future LiteUART variants that add
> > new features (e.g. CTS/RTS, DMA)?
>
> We were thinking of adding KConfig options, like
>
> [ ] LiteUART serial port support
> < > LiteUART DMA support
>
> and using ifdefs in the code.
That is the driver part, not the DT part.
If enabled, the driver still needs to know if the feature is present and
to be used, or not.
> The other option could be to extend LiteX itself so that the UART core
> provides information about its configuration via the capabilities register.
> That way the driver could configure itself automatically at runtime.
>
> This is, however, not decided yet.
A capabilities register sounds good to me.
That means everything is handled automatically by the driver
However, it does mean the DT schema checker cannot validate the
use of optional DT properties related to optional features, if any.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
