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]

Date:   Fri, 12 Nov 2021 17:31:53 +0000
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Jon Nettleton <jon@...id-run.com>
Cc:     Laurentiu Tudor <laurentiu.tudor@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Diana Madalina Craciun <diana.craciun@....com>,
        Ioana Ciornei <ioana.ciornei@....com>, leoyang.li@....com
Subject: Re: [PATCH 2/8] bus: fsl-mc: handle DMA config deferral in ACPI case

On Thu, Nov 11, 2021 at 06:36:58PM +0100, Jon Nettleton wrote:
> On Thu, Nov 11, 2021 at 6:23 PM Daniel Thompson
> <daniel.thompson@...aro.org> 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.
> >
> > Is there some specific firmware version required for this patch to work
> > correctly?
> 
> This patch was merged as a requirement for operational on board networking.
> This was merged as a prerequisite to landing the patches to support MDIO and
> phy initialization in general.

Interesting.

I assumed the change of behaviour comes from properly handling
-EPROBE_DEFER (which can hardly be regarded as a fault with the patch).

Having said that the patch does not seem to be mandatory to get the 1G
networking working on Honeycomb LX2 (running ACPI). By taking v5.15 and
reverting as I shared previously, I am still able to access the network
using the 1G port on the back of the unit (although I didn't do any
performance tests).


> The correct solution for the problem you are seeing is the ACPI
> maintainers figuring out how to land the IORT RMR patchset.  Until
> that is done the only workaround is setting "arm-smmu.disable_bypass=0
> iommu.passthrough=1" on the kernel commandline.  The latter option is
> required since 5.15 and I haven't had time or energy to figure out
> why.  The proper solution is to just land the IORT RMR patchset and
> let HoneyComb run with the SMMU enabled.

Thanks for the update. I'll probably adopt iommu.passthrough=1 for now.
That allows me to adopt a distro kernel when it updates to v5.15.


Daniel.