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:   Wed, 17 Nov 2021 15:07:51 +0200
From:   Laurentiu Tudor <laurentiu.tudor@....com>
To:     Daniel Thompson <daniel.thompson@...aro.org>,
        Jon Nettleton <jon@...id-run.com>
Cc:     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 11/12/2021 7:31 PM, Daniel Thompson wrote:
> 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.

The "iommu.passthrough=1" kernel arg shouldn't be needed. By chance, do
you remember what errors were you seeing? What was failing?

---
Thanks & Best Regards, Laurentiu