From: Conor Dooley <conor.dooley@microchip.com>
To: Binbin Zhou <zhoubb.aaron@gmail.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: Fri, 26 May 2023 13:06:43 +0100 [thread overview]
Message-ID: <20230526-dolly-reheat-06c4d5658415@wendy> (raw)
In-Reply-To: <CAMpQs4LuGAUfMNB93B=vgwJaLqEM6Cq5KyaCtnHOL7RWGuZy-w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4434 bytes --]
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.
> > 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-05-26 12:07 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 [this message]
2023-05-26 12:22 ` Jiaxun Yang
2023-05-26 12:38 ` Conor Dooley
2023-05-27 9:22 ` Binbin Zhou
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=20230526-dolly-reheat-06c4d5658415@wendy \
--to=conor.dooley@microchip.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@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=zhoubb.aaron@gmail.com \
--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