Hello Rob, Thanks for your reply here! > > No. See prior discussions: > > https://lkml.org/lkml/2016/5/18/457 > https://lkml.org/lkml/2017/10/8/238 Just for my clarify; to understand how to move on with the patch: Since UIO is not considered as a real HW and rather a aggregate, which could be used for to wrap virtually any HW block - does that mean no new dt-bindings would be accepted to it? I agree it is really hard (and practically impossible) to create compatible strings for all HW units potentially using UIO as a container, therefore I can see clearly arguments here. But if considered from a driver perspective: there is already DT awareness in the UIO driver (specifically the pdrv-genirq), and we have a "HW-like" functionality (irq handler, iomem and ioreg regions) which could be covered by the DT bindings. What if those "generic" properties that covers only those pieces of the UIO driver code could be assigned corresponding dt-bindings? I believe it is not the best and rather contradictory approach to not have any "compatible" string, but as long as those driver parameters are covered by DT properties, isn't it OK to have them? I can assume a lot of people are using UIO in exactly this way: defining a node in their DTS, assigning "compatible" via kernel command line and having devnode instantiated. Why can't a possibility be provided to them to have a generic description of how they can configure, tweak and use their UIO drivers in the correct and efficient way? This is especially true for people that are using FPGAs and enveloping their Soft-IPs with UIO to have a generic status/control capabilities. I cannot imagine how this tremendous amount of variations could be easily accommodated inside UIO compatible names... Or am I completely missing a point here? -- Regards, Andrey. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
