From: Maxime Ripard <maxime.ripard@bootlin.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Chen-Yu Tsai <wens@csie.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
linux-arm-kernel@lists.infradead.org, linux-rtc@vger.kernel.org
Subject: Re: [PATCH 01/10] dt-bindings: rtc: Move trivial RTC over to trivial devices
Date: Tue, 28 May 2019 14:20:25 +0200 [thread overview]
Message-ID: <20190528122025.vv4oyt5cwetj2hzp@flea> (raw)
In-Reply-To: <20190527160657.GN3274@piout.net>
Hi,
On Mon, May 27, 2019 at 06:06:57PM +0200, Alexandre Belloni wrote:
> On 27/05/2019 14:18:32+0200, Maxime Ripard wrote:
> > Hi Alex,
> >
> > On Mon, May 27, 2019 at 02:06:26PM +0200, Alexandre Belloni wrote:
> > > On 27/05/2019 14:00:33+0200, Maxime Ripard wrote:
> > > > The RTC generic bindings has a bunch of devices that have a pretty simple
> > > > binding, with just compatible, reg and optional interrupts properties.
> > > >
> > >
> > > This is not true, they all also support the star-year property, this is
> > > why they are not in the trivial-devices file anymore.
> >
> > Ok, I misunderstood the binding then.
> >
> > Should we create a separate file for the trivial RTC, on the model of
> > the trivial-devices but supporting all the RTC properties?
>
> I would say that this is the way forward. Note that all the RTCs
> support start-year but you will have to check for the other
> properties.
The way this will work is that it's a two layers thing. Patch 2
creates a generic RTC binding schema that will match on two things:
- Schemas including it directly,
- any devicetree node following the node name pattern.
The point of that schema is to validate that every node (or binding),
if it has those properties, the schemas will make sure that it's the
proper type, (and if we would have any) ranges, etc.
Then, it's up for the driver schemas to do a more on-point validation,
with whatever constraints they have. They can choose to restrict the
set of properties, or not to, it's really up to the device schema.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-05-28 12:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-27 12:00 [PATCH 01/10] dt-bindings: rtc: Move trivial RTC over to trivial devices Maxime Ripard
2019-05-27 12:00 ` [PATCH 02/10] dt-bindings: rtc: Add YAML schemas for the generic RTC bindings Maxime Ripard
2019-05-27 12:00 ` [PATCH 03/10] dt-bindings: rtc: Convert Allwinner A10 RTC to a schema Maxime Ripard
2019-05-28 3:33 ` Chen-Yu Tsai
2019-05-27 12:00 ` [PATCH 04/10] dt-bindings: rtc: Convert Allwinner A31 " Maxime Ripard
2019-05-28 3:37 ` Chen-Yu Tsai
2019-05-28 3:45 ` Chen-Yu Tsai
2019-05-27 12:00 ` [PATCH 05/10] dt-bindings: rtc: sun6i: Add the R40 RTC compatible Maxime Ripard
2019-05-28 3:45 ` Chen-Yu Tsai
2019-05-27 12:00 ` [PATCH 06/10] rtc: sun6i: Add R40 compatible Maxime Ripard
2019-05-28 3:46 ` Chen-Yu Tsai
2019-05-27 12:00 ` [PATCH 07/10] ARM: dts: sun6i: Fix RTC node Maxime Ripard
2019-05-28 3:46 ` Chen-Yu Tsai
2019-05-27 12:00 ` [PATCH 08/10] ARM: dts: sun6i: Add external crystals accuracy Maxime Ripard
2019-05-28 3:35 ` Chen-Yu Tsai
2019-05-27 12:00 ` [PATCH 09/10] ARM: dts: sun8i: v3s: Fix the RTC node Maxime Ripard
2019-05-28 3:47 ` Chen-Yu Tsai
2019-05-27 12:00 ` [PATCH 10/10] ARM: dts: r40: Change the RTC compatible Maxime Ripard
2019-05-28 3:47 ` Chen-Yu Tsai
2019-05-27 12:06 ` [PATCH 01/10] dt-bindings: rtc: Move trivial RTC over to trivial devices Alexandre Belloni
2019-05-27 12:18 ` Maxime Ripard
2019-05-27 16:06 ` Alexandre Belloni
2019-05-28 12:20 ` Maxime Ripard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190528122025.vv4oyt5cwetj2hzp@flea \
--to=maxime.ripard@bootlin.com \
--cc=alexandre.belloni@bootlin.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox