On Thu, Jul 29, 2021 at 7:22 AM Michal Simek <michal.simek@xxxxxxxxxx> wrote: > On 7/28/21 10:51 PM, Gerhard Engleder wrote: > > On Wed, Jul 28, 2021 at 12:59 PM Michal Simek <michal.simek@xxxxxxxxxx> 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
