linux-kernel - Re: [PATCH 2/8] bus: fsl-mc: handle DMA config deferral in ACPI case

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: <20211117144636.tu4lbkfs5mlwktnt@maple.lan>
Date:   Wed, 17 Nov 2021 14:46:36 +0000
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Laurentiu Tudor <laurentiu.tudor@....com>
Cc:     gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        diana.craciun@....com, ioana.ciornei@....com, jon@...id-run.com,
        leoyang.li@....com
Subject: Re: [PATCH 2/8] bus: fsl-mc: handle DMA config deferral in ACPI case

On Wed, Nov 17, 2021 at 03:03:04PM +0200, Laurentiu Tudor wrote:
> Hi Daniel,
> 
> Sorry for the late reply, please see some comments inline.
> 
> On 11/11/2021 7:23 PM, Daniel Thompson wrote:
> > Hi Laurentiu
> > 
> > On Thu, Jul 15, 2021 at 05:07:12PM +0300, laurentiu.tudor@....com wrote:
> >> From: Laurentiu Tudor <laurentiu.tudor@....com>
> >>
> >> ACPI DMA configure API may return a defer status code, so handle it.
> >> On top of this, move the MC firmware resume after the DMA setup
> >> is completed to avoid crashing due to DMA setup not being done yet or
> >> being deferred.
> >>
> >> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@....com>
> > 
> > I saw regressions on my Honeycomb LX2 (NXP LX2060A) when I switched to
> > v5.15. It seems like it results in so many sMMU errors that the system
> > cannot function correctly (it's only about a 75% chance the system will
> > boot to GUI and even if it does boot successfully the system will hang
> > up soon after).
> > 
> > Bisect took me up a couple of blind alleys (mostly due to unrelated boot
> > problems in v5.14-rc2) by eventually led me to this patch as the cause.
> > Applying/unapplying this patch to a v5.14-rc3 tree will provoke/fix the
> > problem and reverting it against v5.15 also resolves the problem.
> 
> That's pretty strange. Was the DPAA2 based networking working with this
> patch reverted?

I think so. I haven't studied the LX2K architecture too heavily but I
assume the 1G networking socket at the back of Honeycomb LX2 is DPAA2
baseD? If so, that 1G socket works with the patch reverted.

Note that I was already using "arm-smmu.disable_bypass=0" on this platform
since I was guided into doing that based on the error messages from
older kernels. It was only the new requirement to set iommu.passthrough
that caught me out.


> > Is there some specific firmware version required for this patch to work
> > correctly?
> 
> It's a bit of a long story. As Jon already mentioned, we're waiting for
> maintainers to agree on the IORT RMR support on which we depend to
> declare in UEFI reserved memory regions for the MC firmware.
> For now, the recommended workaround is to use the
> "arm-smmu.disable_bypass=0" kernel boot arg.

I see. Looks like, after the traffic on the ML in October, that this
patch set is pending a v8 revision in order to stimulate the next round
of discussion?


Daniel.