Hello Geert,
On Tuesday 03 of May 2022 13:37:46 Geert Uytterhoeven wrote:
> Hi Pavel,
> > --- /dev/null
> > +++ b/drivers/net/can/ctucanfd/ctucanfd_platform.c
> >
> > +/* Match table for OF platform binding */
> > +static const struct of_device_id ctucan_of_match[] = {
> > + { .compatible = "ctu,ctucanfd-2", },
>
> Do you need to match on the above compatible value?
> The driver seems to treat the hardware the same, and the DT
> bindings state the compatible value below should always be present.
I would keep it because there will be newer revisions and releases
of the core and I consider "ctu,ctucanfd" as the match to generic
one with maximal attempt to adjust to the version from provided
info registers but identification with the fixed version
"ctu,ctucanfd-2" ensures that some old hardware which is
in the wild is directly recognized even at /sys level
and if we need to do some workarounds for autodetection
etc. it can be recognized.
I understand that in ideal world that should never be required
if we keep compatability right and if there is really new major
completely incompatible revision we would need to use new
identifier anyway. But we and the world is not perfect, so
I would keep that safety option.
May it be there are designs with 5 years old IP core version
in the wild and may it be even with this ID.... May be they
need some version specific adjustment... Yes version should be
readable from IP, hopefully, but that was experimental version
and I am not sure how much register map changed from that days
(can be analyzed from GIT if support request appears).
You know how it works with feebacks when chain of subcontracted
companies does integration for carmaker etc...
For example there appears questions and interest to update it to actual
Debian for LinCAN after ten or 15 years of silence because that
or origina CAN drivers solution works somewhere...
So I am personally more inclined to keep versionned ID.
Best wishes,
Pavel
