linux-kernel - Re: [PATCH v17 00/14] Add support for MT8195 SCP 2nd core

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]

Message-ID: <89047de8d44838425a4f6f783223364dc05e5834.camel@mediatek.com>
Date:   Wed, 20 Sep 2023 08:51:14 +0000
From:   TingHan Shen (沈廷翰) 
        <TingHan.Shen@...iatek.com>
To:     "wenst@...omium.org" <wenst@...omium.org>,
        "mathieu.poirier@...aro.org" <mathieu.poirier@...aro.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "kernel@...labora.com" <kernel@...labora.com>,
        Project_Global_Chrome_Upstream_Group 
        <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "laura.nao@...labora.com" <laura.nao@...labora.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "andersson@...nel.org" <andersson@...nel.org>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH v17 00/14] Add support for MT8195 SCP 2nd core

On Tue, 2023-09-19 at 13:07 +0800, Chen-Yu Tsai wrote:
> On Tue, Sep 19, 2023 at 9:17 AM Mathieu Poirier
> <mathieu.poirier@...aro.org> wrote:
> > 
> > On Mon, Sep 18, 2023 at 06:44:25PM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Sep 18, 2023 at 6:32 PM Laura Nao <laura.nao@...labora.com> wrote:
> > > > 
> > > > > Other than patch 2 and 14, I have applied this set.  The remaining patches will
> > > > > have to be resent to Matthias.
> > > > > Thanks,
> > > > > Mathieu
> > > > 
> > > > Hello,
> > > > 
> > > > With patch 2 missing, the SCP is not probed correctly anymore on asurada (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and MT8183 are multicore, leading to the following errors during initialization:
> > > > 
> > > > 10696 04:33:59.126671  <3>[   15.465714] platform 10500000.scp:cros-ec: invalid resource (null)
> > > > 10697 04:33:59.142855  <3>[   15.478560] platform 10500000.scp:cros-ec: Failed to parse and map sram memory
> > > > 10698 04:33:59.149650  <3>[   15.486121] mtk-scp 10500000.scp: Failed to initialize core 0 rproc
> > > > 
> > > > The issue was caught by KernelCI, complete logs can be found here:
> > > > - asurada: https://urldefense.com/v3/__https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig*arm64-chromebook*videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html__;Kys!!CTRNKA9wMg0ARbw!iEMruK4bVWfCmhRmyauJtkTioHdQbYP3DwhnGUZNxbKYhMzusmoIjYOnpVNALoMobUdKhooUYw6OxUmrqNE$ 
> > > > - kukui: https://urldefense.com/v3/__https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig*arm64-chromebook*videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html__;Kys!!CTRNKA9wMg0ARbw!iEMruK4bVWfCmhRmyauJtkTioHdQbYP3DwhnGUZNxbKYhMzusmoIjYOnpVNALoMobUdKhooUYw6OhRxz6NQ$ 
> > > > 
> > > > Reporting the issue so that patch 2 and 14 can be resent and merged soon.
> > > 
> > > This being a backward incompatible DT binding change, maybe we should revert
> > > the node name change. Or, the driver could simply count the number of child
> > > nodes that have the "mediatek,rpmsg-name" property, which is required.
> > > 
> > 
> > You have a point.  Can someone send a patch that makes this patchset backward
> > compatible?  Please do so as quickly as possible to that it can go in the next
> > merge window with the rest of this feature.  Otherwize I'll have to back out the
> > whole thing.
> 
> I sent out a patch [1] implementing my proposed change.
> 
> ChenYu
> 
> [1] https://lore.kernel.org/linux-remoteproc/20230919050305.3817347-1-wenst@chromium.org/

My version[1] is inspired by Angelo's work[2].

[1] https://lore.kernel.org/all/20230920084611.30890-1-tinghan.shen@mediatek.com/
[2] https://lore.kernel.org/all/20230919092336.51007-1-angelogioacchino.delregno@collabora.com/
 
Best regards,
TingHan