Hi Geert, On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote: > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote: > > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote: > > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote: > > > > > If we want to be more strict and require the definition of all the > > > > > supplies, there will be many more DTs changes in the series, and I'm not > > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking > > > > > at them and it's not always clear which regulators to use or if they are > > > > > even defined. > > > > > > > > We can decouple the two though (I think). The bindings should reflect > > > > what we consider right, and the dts files could be fixed on top. > > > > > > Do you have a suggestion on how to do this? If we decouple the two > > > tasks most of the work would be searching for DTs to fix and finding a > > > way to fix each one of them, and unless I do this _before_ the binding > > > conversion I'll get a lot of dtbs_check errors. > > > > Rob should answer this question as it will be his decision, but I've > > personally never considered non-compliant DT sources to be an obstacle > > to bindings conversion to YAML. The DT sources should be fixed, but I > > don't see it as a prerequisite (although it's a good practice). > > I do my best to avoid introducing regressions when the binding conversions > go upstream. Please note that we're not talking about runtime regressions, as drivers are not updated. It's "only" dtbs_check that would produce new errors. > FTR, hence patches 1-3 are already in v5.7-rc7. -- Regards, Laurent Pinchart
