linux-kernel - Re: [PATCH 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP

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: <CAEnQRZA7SJ5b_JWSk_GynikKC1rkxiB_cz3Ps6TYRQnDpQbyow@mail.gmail.com>
Date:   Tue, 12 Sep 2023 13:58:51 +0300
From:   Daniel Baluta <daniel.baluta@...il.com>
To:     Iuliana Prodan <iuliana.prodan@....com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        "Iuliana Prodan (OSS)" <iuliana.prodan@....nxp.com>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, Shawn Guo <shawnguo@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        "S.J. Wang" <shengjiu.wang@....com>,
        Fabio Estevam <festevam@...il.com>, devicetree@...r.kernel.org,
        Daniel Baluta <daniel.baluta@....com>,
        Mpuaudiosw <Mpuaudiosw@....com>, linux-imx <linux-imx@....com>,
        linux-remoteproc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        LnxRevLi <LnxRevLi@....com>
Subject: Re: [PATCH 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP

On Tue, Sep 12, 2023 at 12:54 PM Iuliana Prodan <iuliana.prodan@....com> wrote:
>
> On 9/12/2023 11:26 AM, Krzysztof Kozlowski wrote:
> > On 12/09/2023 10:13, Iuliana Prodan wrote:
> >> On 9/12/2023 10:07 AM, Krzysztof Kozlowski wrote:
> >>> On 12/09/2023 00:44, Iuliana Prodan (OSS) wrote:
> >>>> From: Iuliana Prodan <iuliana.prodan@....com>
> >>>>
> >>>> Add the reserve-memory nodes used by DSP when the rpmsg
> >>>> feature is enabled.
> >>>> These can be later used in a dsp node, like:
> >>>> dsp: dsp@...e8000 {
> >>>>    compatible = "fsl,imx8mp-dsp";
> >>>>    reg = <0x3b6e8000 0x88000>;
> >>>>    mbox-names = "tx0", "rx0", "rxdb0";
> >>>>    mboxes = <&mu2 2 0>, <&mu2 2 1>,
> >>>>            <&mu2 3 0>, <&mu2 3 1>;
> >>>>    memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>,
> >>>>            <&dsp_vdev0vring1>, <&dsp_reserved>;
> >>>>    status = "okay";
> >>> Drop this example from commit msg, useless and not really correct.
> >> Ok, will drop it. But this is a correct example, is just incomplete.
> > No, status=okay is redundant, thus it is not a correct example.
> ok
> >>>> };
> >>>>
> >>>> Signed-off-by: Iuliana Prodan <iuliana.prodan@....com>
> >>>> ---
> >>>>    arch/arm64/boot/dts/freescale/imx8mp.dtsi | 12 ++++++++++++
> >>>>    1 file changed, 12 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> >>>> index cc406bb338fe..eedc1921af62 100644
> >>>> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> >>>> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> >>>> @@ -210,6 +210,18 @@
> >>>>                    dsp_reserved: dsp@...00000 {
> >>>>                            reg = <0 0x92400000 0 0x2000000>;
> >>>>                            no-map;
> >>> Please test the patches before sending. This does not build.
> >> I've tested on remoteproc tree, but it seems I missed a bracket when
> >> sending upstream. Sorry abut this, will fix it in v2.
> > No, this is not how testing works. You must test this patch. This means
> > you tested something, then ported patch to entirely different tree,
> > resolved conflicts in buggy way and send it without testing. Nope.
> >
> >> Should I test this on other tree(s)?
> > You test the patch on the tree you send it. What is the point to test it
> > on some old code, cherry-pick with bugs and then send?
> >
> > If you have cross-tree dependencies between subsystem, isn't linux-next
> > for this?

linux-next tree is the tree we want.