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: <1553679236.2561.27.camel@pengutronix.de>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ