linux-kernel - Re: [PATCH 2/2] arm64: dts: imx8qxp: Add EDMA0/EDMA1 nodes

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]

Date:   Wed, 27 Mar 2019 10:33:56 +0100
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Daniel Baluta <daniel.baluta@...il.com>,
        Aisheng Dong <aisheng.dong@....com>
Cc:     "mark.rutland@....com" <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Peng Fan <peng.fan@....com>,
        "festevam@...il.com" <festevam@...il.com>,
        Anson Huang <anson.huang@....com>, Teo Hall <teo.hall@....com>,
        Daniel Baluta <daniel.baluta@....com>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "S.j. Wang" <shengjiu.wang@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/2] arm64: dts: imx8qxp: Add EDMA0/EDMA1 nodes

Hi Daniel,

Am Mittwoch, den 27.03.2019, 10:51 +0200 schrieb Daniel Baluta:
[...]
> 
> > or
> > "fsl,imx8qxp-edma", "fsl,imx8qm-edma"?
> 
> One thing that it is not clear for me is why there are places
> where we use two compatible strings?
> 
> I understand the situation where are two distinct drivers, but is there
> any other reason to add multiple compatible strings for a node in dts?

We use 2 compatible string where there should not be any differences
between the IP blocks of this SoC and a version the driver already
supports.

So if the eDMA driver already supports the software interface for
"fsl,imx8qm-edma" and the IP block is compatible with this, we add this
to the DT, so the we don't need any driver changes just to support a
new SoC. But as you can never be sure if there are subtle differences
in the IP block and/or SOC integration when adding the DT support, we
also add a more specific compatible to the DT. If it turns out that
there are software visible differences, we only need to adapt the
driver to check for the more specific compatible to trigger the changed
behavior, allowing to keep the DT stable.

Regards,
Lucas