linux-kernel - Re: [EXT] [PATCH 2/2] arm64: dts: ls1028a: add "fsl,vf610-edma" compatible

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: <e0be23f7d1307621151594dd66d2b8fd@walle.cc>
Date:   Sat, 07 Mar 2020 10:25:55 +0100
From:   Michael Walle <michael@...le.cc>
To:     Peng Ma <peng.ma@....com>
Cc:     dmaengine@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Vinod Koul <vkoul@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Shawn Guo <shawnguo@...nel.org>, Leo Li <leoyang.li@....com>
Subject: Re: [EXT] [PATCH 2/2] arm64: dts: ls1028a: add "fsl,vf610-edma"
 compatible

Hi Peng,

Am 2020-03-07 03:09, schrieb Peng Ma:
>> -----Original Message-----
>> From: Michael Walle <michael@...le.cc>
>> Sent: 2020年3月7日 4:54
>> To: dmaengine@...r.kernel.org; devicetree@...r.kernel.org;
>> linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org
>> Cc: Vinod Koul <vkoul@...nel.org>; Rob Herring <robh+dt@...nel.org>; 
>> Mark
>> Rutland <mark.rutland@....com>; Shawn Guo <shawnguo@...nel.org>; Leo 
>> Li
>> <leoyang.li@....com>; Peng Ma <peng.ma@....com>; Michael Walle
>> <michael@...le.cc>
>> Subject: [EXT] [PATCH 2/2] arm64: dts: ls1028a: add "fsl,vf610-edma"
>> compatible
>> 
>> Caution: EXT Email
>> 
>> The bootloader does the IOMMU fixup and dynamically adds the "iommus"
>> property to devices according to its compatible string. In case of the 
>> eDMA
>> controller this property is missing. Add it. After that the IOMMU will 
>> work with
>> the eDMA core.
>> 
>> Signed-off-by: Michael Walle <michael@...le.cc>
>> ---
>> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
>> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
>> index b152fa90cf5c..aa467bff2209 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
>> @@ -447,7 +447,7 @@
>> 
>>                edma0: dma-controller@...0000 {
>>                        #dma-cells = <2>;
>> -                       compatible = "fsl,ls1028a-edma";
>> +                       compatible = "fsl,ls1028a-edma",
>> + "fsl,vf610-edma";
> Hi Michael,
> 
> You should change it on bootloader instead of kernel, Some Reg of
> LS1028a is different
> from others, So we used compatible "fsl,ls1028a-edm" to distinguish "
> fsl,vf610-edma".

Yes this might be the right thing to do. So since it is NXPs bootloader
feel free to fix that ;) Looking at the u-boot code right now, I don't
even know it that is the right fix at all. The fixup code in u-boot is
SoC independent (its in fsl_icid.h and is enabled with CONFIG_LSCH3, ie
your chassis version). For example, the sdhc fixup will scan the nodes
for "compatible = fsl,esdhc", which is also the secondary compatible
for the "ls1028a-esdhc" compatible.

And here is another reason to have it this way: we need backwards
compatibility, the are already boards out there whose bootloader will
fix-up the "old" node. Thus I don't see any other possibilty.

-michael

> 
> Thanks,
> Peng
>>                        reg = <0x0 0x22c0000 0x0 0x10000>,
>>                              <0x0 0x22d0000 0x0 0x10000>,
>>                              <0x0 0x22e0000 0x0 0x10000>;
>> --
>> 2.20.1