linux-kernel - RE: [PATCH] arm64: dts: imx8mm: fix dma peripheral type for SAI 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] [day] [month] [year] [list]

Date:   Mon, 20 Apr 2020 07:21:59 +0000
From:   Robin Gong <yibin.gong@....com>
To:     Matt Porter <mporter@...sulko.com>,
        Daniel Baluta <daniel.baluta@...il.com>
CC:     Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Anson Huang <anson.huang@....com>,
        Leonard Crestez <leonard.crestez@....com>,
        Daniel Baluta <daniel.baluta@....com>,
        Devicetree List <devicetree@...r.kernel.org>,
        Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] arm64: dts: imx8mm: fix dma peripheral type for SAI nodes

On 2020/04/16 Matt Porter <mporter@...sulko.com> wrote:d
> On Wed, Apr 15, 2020 at 09:04:43PM +0300, Daniel Baluta wrote:
> > On Tue, Mar 31, 2020 at 11:36 PM Matt Porter <mporter@...sulko.com>
> wrote:
> > >
> > > The peripheral type specified in the dma phandle for each SAI node
> > > is incorrect. Change it to specify the SAI peripheral.
> > >
> > > Signed-off-by: Matt Porter <mporter@...sulko.com>
> >
> > Hi Matt,
> >
> > Why do you think this is incorrect?  AFAIK script number 2 works fine
> > for SAI. Can you add more details on what bug are you encountering?
> >
> > Adding Robin the owner of SDMA.
> 
> Hi Daniel,
> 
> Thanks for the response. I was experiencing timeouts that were traced back to
> dma incompletions. Changing the script at the time fixed that issue. Now, given
> your response I went back and checked this again and verified that script 2
> does work for me now. I did change firmware to the latest v4.4 from something
> quite old so now I'm suspecting I had bad firmware loaded up. Does that sound
> plausible? In any case, I can confirm this is not needed.
No, that's not related with firmware version since both scripts are all ROM scripts instead of RAM scripts which's in sdma firmware.