On Sat, Oct 15, 2022 at 2:17 PM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > On 15/10/2022 01:54, Laurent Pinchart wrote: > > Hi Rob, > > > > On Fri, Oct 14, 2022 at 04:40:29PM -0500, Rob Herring wrote: > >> On Fri, Oct 14, 2022 at 10:27:53PM +0100, Lad, Prabhakar wrote: > >>> On Fri, Oct 14, 2022 at 10:05 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > >>>> On Fri, Oct 14, 2022 at 1:35 PM Prabhakar <prabhakar.csengg@xxxxxxxxx> wrote: > >>>>> > >>>>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > >>>>> > >>>>> Convert the simple OV5645 Device Tree binding to json-schema. > >>>>> > >>>>> The previous binding marked the below properties as required which was a > >>>>> driver requirement and not the device requirement so just drop them from > >>>>> the required list during the conversion. > >>>>> - clock-frequency > >>>>> - enable-gpios > >>>>> - reset-gpios > >>>>> > >>>>> Also drop the "clock-names" property as we have a single clock source for > >>>>> the sensor and the driver has been updated to drop the clk referencing by > >>>>> name. > >>>> > >>>> Driver requirements are the ABI! > >>>> > >>>> This breaks a kernel without the driver change and a DTB that has > >>>> dropped the properties. > >>>> > >>> I already have a patch for the driver [0] which I missed to include > >>> along with the series. > >> > >> You completely miss the point. Read the first sentence again. Changing > >> driver requirements changes the ABI. > >> > >> This breaks the ABI. The driver patch does not help that. > > > > I'm not following you here. If the DT binding makes a mandatory property > > optional, it doesn't break any existing platform. The only thing that > > would not work is a new DT that doesn't contain the now optional > > property combined with an older driver that makes it required. That's > > not a regression, as it would be a *new* DT. > > You're right although in-tree DTS are now not compatible with older > kernels. So it is not only about new DTS, it is about our kernel DTS > which requires new kernel to work. > To confirm, we are ok dropping the clock-names property here right? > DTS are exported and used by other systems, thus if someone blindly > takes this new DTS without clock-names, his kernel/OS/bootloader might > stop working. > > That is however a more relaxed requirement than kernel ABI against old DTS. > > > > >>>> Also, with 'clock-names' dropped, you've just introduced a bunch of > >>>> warnings on other people's platforms. Are you going to 'fix' all of > >>>> them? > >>>> > >>> Yes I will fix them, once the patch driver patch [0] is merged in. > >> > >> Why? You are just making extra work. We have enough warnings as-is to > >> fix. > > > > I agree that a DT binding change should patch all in-tree DTS to avoid > > introducing new warnings. > > Yes. > OK, I'll send dts changes along with this patch series. Cheers, Prabhakar
