Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220811203151.179258-1-mail@conchuod.ie> <CAL_JsqLOGLZD6vrNPqDUqYypkz8xoCPJ4DA4JF-BrG=WHWPurw@mail.gmail.com>
 <46c51365-b4a5-9666-bc3a-24ff833d8fb2@microchip.com>
In-Reply-To: <46c51365-b4a5-9666-bc3a-24ff833d8fb2@microchip.com>
From:   Rob Herring <robh+dt@kernel.org>
Date:   Fri, 12 Aug 2022 10:38:21 -0600
Message-ID: <CAL_JsqKZ2N7rTb0Fm0Y8CjN8XrTkBsu2uU_TFfhU0iwjSz5row@mail.gmail.com>
Subject: Re: [PATCH] dt-bindings: mmc: cdns: add card-detect-delay property
To:     Conor.Dooley@microchip.com
Cc:     mail@conchuod.ie, ulf.hansson@linaro.org,
        krzysztof.kozlowski+dt@linaro.org, yamada.masahiro@socionext.com,
        piotrs@cadence.com, linux-mmc@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-riscv@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Aug 12, 2022 at 9:46 AM <Conor.Dooley@microchip.com> wrote:
>
> On 12/08/2022 16:33, Rob Herring wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > On Thu, Aug 11, 2022 at 2:32 PM Conor Dooley <mail@conchuod.ie> wrote:
> >>
> >> From: Conor Dooley <conor.dooley@microchip.com>
> >>
> >> Upgrading dt-schema to v2022.08 brings with it better handling of
> >> unevaluatedProperties, exposing a previously undetected missing
> >> property in the cadence sdhci dt-binding:
> >> arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dtb: mmc@20008000: Unevaluated properties are not allowed ('card-detect-delay' was unexpected)
> >>         From schema: Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> >>
> >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> >> ---
> >> Should this have a fixes tag? If anything, it'd be
> >> Fixes: 84723eec251d ("dt-bindings: mmc: cdns: document Microchip MPFS MMC/SDHCI controller")
> >> but idk.
> >
> > No, the common property 'cd-debounce-delay-ms' should be used instead.
>
> So it's a case of "what's in the dts is wrong so it needs to change"?

Yes.

> For the future, where is the line drawn between "don't break the dts"
> & "don't use bad properties"?

Depends...

> Only if the property has consumers?
> I don't mind, just want to get it right next time ;)

In this case, there shouldn't be any compatibility issues because the
mmc core has supported the common property longer than the dts
existed. If that was not the case, then we'd probably be stuck with
the property in the dts file. That still depends on usage in the
kernel or elsewhere, in dts files, stability of the platform support,
etc.

Rob