linux-kernel - Re: [PATCH v8 5/7] can: ctucanfd: CTU CAN FD open-source IP core

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <202205031707.21405.pisa@cmp.felk.cvut.cz>
Date:   Tue, 3 May 2022 17:07:21 +0200
From:   Pavel Pisa <pisa@....felk.cvut.cz>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     linux-can@...r.kernel.org,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "Marc Kleine-Budde" <mkl@...gutronix.de>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        David Miller <davem@...emloft.net>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Carsten Emde <c.emde@...dl.org>, armbru@...hat.com,
        netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Marin Jerabek <martin.jerabek01@...il.com>,
        Ondrej Ille <ondrej.ille@...il.com>,
        Jiri Novak <jnovak@....cvut.cz>,
        Jaroslav Beran <jara.beran@...il.com>,
        Petr Porazil <porazil@...ron.com>, Pavel Machek <pavel@....cz>,
        Drew Fustini <pdp7pdp7@...il.com>
Subject: Re: [PATCH v8 5/7] can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support.

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