Message-ID: <CANr-f5yuZ0t782fX_6w3ksKXVdObGWxFHA9Lg+tUQwrXkUh2ng@mail.gmail.com>
Date:   Thu, 29 Jul 2021 08:47:08 +0200
From:   Gerhard Engleder <gerhard@...leder-embedded.com>
To:     Michal Simek <michal.simek@...inx.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH net-next 5/5] arm64: dts: zynqmp: Add ZCU104 based TSN endpoint

On Thu, Jul 29, 2021 at 7:22 AM Michal Simek <michal.simek@...inx.com> wrote:
> On 7/28/21 10:51 PM, Gerhard Engleder wrote:
> > On Wed, Jul 28, 2021 at 12:59 PM Michal Simek <michal.simek@...inx.com> wrote:
> >>>> In past we said that we won't be accepting any FPGA description in
> >>>> u-boot/linux projects. I don't think anything has changed from that time
> >>>> and I don't want to end up in situation that we will have a lot of
> >>>> configurations which none else can try and use.
> >> You have to share to customers bitstream. Likely also boot.bin with
> >> PS/PL configuration and other files in it. That's why it will be quite
> >> simple to also share them full DT or DT overlay just for your IP in the
> >> same image.
> >
> > That's possible of course.
> >
> >> Till now I didn't hear any strong argument why this should be accepted.
> >
> > I want to try a new argument:
> >
> > For new bindings a schema is used. The goal is to ensure that the binding
> > schema and the driver fit together. The validation chain is the following:
> > 1) The binding schema is used to validate the device tree.
> > 2) The device tree is used to "validate" the driver by booting.
> >
> > So the kernel tree needs to contain a device tree which uses the binding
> > to build up the complete validation chain. The validation of the driver against
> > the binding is not possible without a device tree. The only option would be
> > to compare driver and binding manually, which is error prone.
> >
> > If device trees with FPGA descriptions are not allowed in the kernel tree, then
> > the kernel tree will never contain complete validation chains für FPGA based
> > IPs. The validation of bindings for FPGA based IPs has to rely on device trees
> > which are maintained out of tree. It is possible/likely that schema
> > validation is
> > not done out of tree. As a result it is more likely that binding and
> > driver do not
> > fit together for FPGA based IPs. In the end the quality of the support for FPGA
> > based IPs would suffer.
> >
> > I suggest allowing a single device tree with FPGA descriptions for a binding
> > of FPGA based IPs. This will build up the complete validation chain in the
> > kernel tree and ensures that binding and driver fit together. This single device
> > tree would form the reference platform for the FPGA based IP.
>
> This is good theory but the only person who can do this validation is
> you or your customer who is interested in TSN. I am doing this for quite
> a long time and even people are giving me commitments that they will
> support the whole custom board but they stop to do at some point and
> then silently disappear. Then it is up to me to deal with this and I
> really don't want to do it.
> When your driver is merged you should start to do regression testing
> against linux-next, rc versions. When you convince me that you are
> regularly doing this for 2 years or so we can restart this discussion.
>
> Till that time you can simply keep rebasing one patch with your DT on
> the top which is quite easy to do and you get all
> functionality/advantages you are asking about above.

Ok, I give up.

Gerhard

Powered by blists - more mailing lists