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: <20230517144144.365631-1-romain.perier@gmail.com>
 <20230517144144.365631-3-romain.perier@gmail.com> <669d7b79-71a6-e1f9-8d7a-71c4b64de28d@kernel.org>
In-Reply-To: <669d7b79-71a6-e1f9-8d7a-71c4b64de28d@kernel.org>
From:   Romain Perier <romain.perier@gmail.com>
Date:   Mon, 22 May 2023 13:27:21 +0200
Message-ID: <CABgxDoKaVip=T5=s2Gd8qpX15cLD=_0TZtQoNodK1CCf+GTYZw@mail.gmail.com>
Subject: Re: [PATCH 2/3] dt-bindings: rtc: Add Mstar SSD20xD RTC devicetree
 bindings documentation
To:     Krzysztof Kozlowski <krzk@kernel.org>
Cc:     Alessandro Zummo <a.zummo@towertech.it>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Daniel Palmer <daniel@0x0f.com>,
        Rob Herring <robh+dt@kernel.org>, linux-rtc@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Le jeu. 18 mai 2023 =C3=A0 10:24, Krzysztof Kozlowski <krzk@kernel.org> a =
=C3=A9crit :
>
> On 17/05/2023 16:41, Romain Perier wrote:
> > This adds the documentation for the devicetree bindings of the Mstar
> > SSD20xD RTC driver.
> >
>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC.  It might happen, that command when run on an older
> kernel, gives you outdated entries.  Therefore please be sure you base
> your patches on recent Linux kernel.

Hi,

This is usually what I do for all patches series, but possible I have
missed some person

>
> A nit, subject: drop second/last, redundant "devicetree bindings
> documentation". The "dt-bindings" prefix is already stating that these
> are bindings. You actually repeated everything...

Originally, it was just to write a simple sentence with words... it
gives context, you know...

Like here:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-nex=
t.git/commit/?id=3D7647204c2e81b28b4a7c4eec7d539f998d48eaf0
or here:  https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.g=
it/commit/?id=3Ddd49cbedde8a0f1e0d09698f9cad791d37a8e03e

But honestly, I don't want to debate about this, yes I can remove
redundant "devicetree bindings documentation" ^^


>
> > Signed-off-by: Romain Perier <romain.perier@gmail.com>
> > ---
> >  .../bindings/rtc/mstar,ssd20xd-rtc.yaml       | 37 +++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/rtc/mstar,ssd20xd=
-rtc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.ya=
ml b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> > new file mode 100644
> > index 000000000000..2acd86cce69f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/mstar,ssd20xd-rtc.yaml
> > @@ -0,0 +1,37 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/rtc/mstar,ssd20xd-rtc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mstar SSD20xD RTC
> > +
> > +allOf:
> > +  - $ref: rtc.yaml#
>
> This goes just above properties:
>

ack

> > +
> > +maintainers:
> > +  - Daniel Palmer <daniel@0x0f.com>
> > +  - Romain Perier <romain.perier@gmail.com>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - mstar,ssd20xd-rtc
>
> Why rtc suffix? Can it be anything else?

Well, it is the dt-bindings for an RTC block ? suppose tomorrow we
have an ethernet block specific to the SoC SSD202D, it should be
"mstar,ssd202d-ethernet" , how do you make
the difference if you just put "mstar,sd202d" ? Plus a lot of rtc
dt-bindings have this suffix (when it is not an IP name). This is
exactly the case for rtc-msc313e and it was not an issue.

>
> Missing blank line

ack

>
> > +  reg:
> > +    maxItems: 1
> > +
> > +  start-year: true
>
> Drop
>
> What about interrupt line?

There is currently no interrupt right now, we have not yet the irqchip
code for handling the alarm irq of this rtc block.


>
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: false
>
> instead
> unevaluatedProperties: false

ack

Thanks,
Romain