From: Binbin Zhou <zhoubb.aaron@gmail.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Conor Dooley <conor@kernel.org>,
Binbin Zhou <zhoubinbin@loongson.cn>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-rtc@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org, Huacai Chen <chenhuacai@loongson.cn>,
Huacai Chen <chenhuacai@kernel.org>,
Xuerui Wang <kernel@xen0n.name>,
loongarch@lists.linux.dev,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
linux-mips@vger.kernel.org,
Keguang Zhang <keguang.zhang@gmail.com>,
zhao zhang <zhzhl555@gmail.com>, Yang Ling <gnaygnil@gmail.com>,
loongson-kernel@lists.loongnix.cn
Subject: Re: [PATCH V4 1/5] dt-bindings: rtc: Remove the LS2X from the trivial RTCs
Date: Sat, 27 May 2023 17:22:48 +0800 [thread overview]
Message-ID: <CAMpQs4KeHCW+9ssAn-jF0efiUOzERRFDu9Sjz1Mtv5Lk1uFuPA@mail.gmail.com> (raw)
In-Reply-To: <20230526-dolly-reheat-06c4d5658415@wendy>
On Fri, May 26, 2023 at 8:07 PM Conor Dooley <conor.dooley@microchip.com> wrote:
>
> On Fri, May 26, 2023 at 09:37:02AM +0800, Binbin Zhou wrote:
> > On Fri, May 26, 2023 at 1:05 AM Conor Dooley <conor@kernel.org> wrote:
> > > On Thu, May 25, 2023 at 08:55:23PM +0800, Binbin Zhou wrote:
>
> >> > > +properties:
> > > > + compatible:
> > > > + enum:
> > > > + - loongson,ls1b-rtc
> > > > + - loongson,ls1c-rtc
> > > > + - loongson,ls7a-rtc
> > > > + - loongson,ls2k0500-rtc
> > > > + - loongson,ls2k1000-rtc
> > > > + - loongson,ls2k2000-rtc
> > >
> > > |+static const struct of_device_id loongson_rtc_of_match[] = {
> > > |+ { .compatible = "loongson,ls1b-rtc", .data = &ls1x_rtc_config },
> > > |+ { .compatible = "loongson,ls1c-rtc", .data = &ls1x_rtc_config },
> > > |+ { .compatible = "loongson,ls7a-rtc", .data = &generic_rtc_config },
> > > |+ { .compatible = "loongson,ls2k0500-rtc", .data = &generic_rtc_config },
> > > |+ { .compatible = "loongson,ls2k1000-rtc", .data = &ls2k1000_rtc_config },
> > > |+ { .compatible = "loongson,ls2k2000-rtc", .data = &generic_rtc_config },
> > > |+ { /* sentinel */ }
> > > |+};
> > >
> > > This is a sign to me that your compatibles here are could do with some
> > > fallbacks. Both of the ls1 ones are compatible with each other & there
> > > are three that are generic.
> > >
> > > I would allow the following:
> > > "loongson,ls1b-rtc"
> > > "loongson,ls1c-rtc", "loongson,ls1b-rtc"
> > > "loongson,ls7a-rtc"
> > > "loongson,ls2k0500-rtc", "loongson,ls7a-rtc"
> > > "loongson,ls2k2000-rtc", "loongson,ls7a-rtc"
> > > "loongson,ls2k1000-rtc"
> > >
> > > And then the driver only needs:
> > > |+static const struct of_device_id loongson_rtc_of_match[] = {
> > > |+ { .compatible = "loongson,ls1b-rtc", .data = &ls1x_rtc_config },
> > > |+ { .compatible = "loongson,ls7a-rtc", .data = &generic_rtc_config },
> > > |+ { .compatible = "loongson,ls2k1000-rtc", .data = &ls2k1000_rtc_config },
> > > |+ { /* sentinel */ }
> > > |+};
> > >
> > > And ~if~when you add support for more devices in the future that are
> > > compatible with the existing ones no code changes are required.
> >
> > Hi Conor:
> >
> > Thanks for your reply.
> >
> > Yes, this is looking much cleaner. But it can't show every chip that
> > supports that driver.
> >
> > As we know, Loongson is a family of chips:
> > ls1b/ls1c represent the Loongson-1 family of CPU chips;
> > ls7a represents the Loongson LS7A bridge chip;
> > ls2k0500/ls2k1000/ls2k2000 represent the Loongson-2 family of CPU chips.
> >
> > Based on my previous conversations with Krzysztof, it seems that
> > soc-based to order compatible is more popular, so I have listed all
> > the chips that support that RTC driver.
>
> Right. You don't actually have to list them all *in the driver* though,
> just in the binding and in the devicetree. I think what you have missed
> is:
> > > I would allow the following:
> > > "loongson,ls1b-rtc"
> > > "loongson,ls1c-rtc", "loongson,ls1b-rtc"
> > > "loongson,ls7a-rtc"
> > > "loongson,ls2k0500-rtc", "loongson,ls7a-rtc"
> > > "loongson,ls2k2000-rtc", "loongson,ls7a-rtc"
> > > "loongson,ls2k1000-rtc"
>
> This is what you would put in the compatible section of a devicetree
> node, using "fallback compatibles". So for a ls1c you put in
> compatible = "loongson,ls1c-rtc", "loongson,ls1b-rtc";
> and the kernel first tries to find a driver that supports
> "loongson,ls1c-rtc" but if that fails it tries to find one that supports
> "loongson,ls1b-rtc". This gives you the best of both worlds - you can
> add support easily for new systems (when an ls1d comes out, you don't
> even need to change the driver for it to just work!) and you have a
> soc-specific compatible in case you need to add some workaround for
> hardware errata etc in the future.
Hi Conor:
I seem to understand what you are talking about.
I hadn't delved into "fallback compatibles" before, so thanks for the
detailed explanation.
In fact, I have thought before if there is a good way to do it other
than adding comptable to the driver frequently, and "fallback
compatibles" should be the most suitable.
So in the dt-bindings file, should we just write this:
compatible:
oneOf:
- items:
- enum:
- loongson,ls1c-rtc
- const: loongson,ls1b-rtc
- items:
- enum:
- loongson,ls2k0500-rtc
- loongson,ls2k2000-rtc
- const: loongson,ls7a-rtc
- items:
- const: loongson,ls2k1000-rtc
Thanks.
Binbin
>
> > > To maintain compatibility with the existing devicetrees, should the old
> > > "loongson,ls2x-rtc" be kept in the driver?
> >
> > No, It seems that wildcards in compatible are not allowed."
> > loongson,ls2x-rtc" itself was part of this patch series at one time,
> > but apparently it is not the right way to describe these chips.
>
> Right, but it has been merged - you are deleting the driver that supports
> it after all - which means that any dtb with the old compatible will
> stop working.
> I don't disagree with Krzysztof that having wildcard based compatibles
> is bad, but I do not think that regressing rtc support for systems with
> these old devicetrees is the right way to go either.
>
> Thanks,
> Conor.
next prev parent reply other threads:[~2023-05-27 9:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 12:55 [PATCH V4 0/5] rtc: Add rtc driver for the Loongson family chips Binbin Zhou
2023-05-25 12:55 ` [PATCH V4 1/5] dt-bindings: rtc: Remove the LS2X from the trivial RTCs Binbin Zhou
2023-05-25 17:05 ` Conor Dooley
2023-05-26 1:37 ` Binbin Zhou
2023-05-26 12:06 ` Conor Dooley
2023-05-26 12:22 ` Jiaxun Yang
2023-05-26 12:38 ` Conor Dooley
2023-05-27 9:22 ` Binbin Zhou [this message]
2023-05-27 16:13 ` Jiaxun Yang
2023-05-27 16:23 ` Conor Dooley
2023-05-27 21:59 ` Jiaxun Yang
2023-05-27 22:22 ` Conor Dooley
2023-05-29 2:59 ` Keguang Zhang
2023-05-29 6:24 ` Conor Dooley
2023-05-29 8:31 ` Binbin Zhou
2023-05-29 22:20 ` Alexandre Belloni
2023-05-30 6:41 ` Binbin Zhou
2023-05-30 8:17 ` Krzysztof Kozlowski
2023-05-30 8:40 ` Alexandre Belloni
2023-05-30 9:13 ` Keguang Zhang
2023-05-30 9:22 ` Alexandre Belloni
2023-05-30 9:49 ` Keguang Zhang
2023-05-30 11:39 ` Binbin Zhou
2023-05-30 12:02 ` Alexandre Belloni
2023-05-25 12:55 ` [PATCH V4 2/5] rtc: Remove the Loongson-1 RTC driver Binbin Zhou
2023-05-30 8:08 ` Krzysztof Kozlowski
2023-05-30 8:39 ` Alexandre Belloni
2023-05-25 12:55 ` [PATCH V4 3/5] rtc: Add rtc driver for the Loongson family chips Binbin Zhou
2023-05-25 12:55 ` [PATCH V4 4/5] MIPS: Loongson64: DTS: Add RTC support to LS7A PCH Binbin Zhou
2023-05-25 12:55 ` [PATCH V4 5/5] MIPS: Loongson64: DTS: Add RTC support to Loongson-2K1000 Binbin Zhou
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=CAMpQs4KeHCW+9ssAn-jF0efiUOzERRFDu9Sjz1Mtv5Lk1uFuPA@mail.gmail.com \
--to=zhoubb.aaron@gmail.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=conor+dt@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gnaygnil@gmail.com \
--cc=jiaxun.yang@flygoat.com \
--cc=keguang.zhang@gmail.com \
--cc=kernel@xen0n.name \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=loongson-kernel@lists.loongnix.cn \
--cc=robh+dt@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=zhoubinbin@loongson.cn \
--cc=zhzhl555@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).