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@xxxxxxxxxx> 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:
signature.asc
Description: PGP signature
