linux-kernel - Re: [PATCH net-next v2 1/4] dt-bindings: dmaengine: bam

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:   Mon, 18 Oct 2021 14:56:05 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Bhupesh Sharma <bhupesh.sharma@...aro.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Loic Poulain <loic.poulain@...aro.org>,
        Sergey Ryazanov <ryazanov.s.a@...il.com>,
        Johannes Berg <johannes@...solutions.net>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>, Vinod Koul <vkoul@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Aleksander Morgado <aleksander@...ksander.es>,
        netdev@...r.kernel.org, MSM <linux-arm-msm@...r.kernel.org>,
        dmaengine@...r.kernel.org, devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        phone-devel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht,
        Jeffrey Hugo <jeffrey.l.hugo@...il.com>
Subject: Re: [PATCH net-next v2 1/4] dt-bindings: dmaengine: bam_dma: Add
 "powered remotely" mode

On Mon, Oct 18, 2021 at 05:04:31PM +0530, Bhupesh Sharma wrote:
> On Mon, 11 Oct 2021 at 20:12, Stephan Gerhold <stephan@...hold.net> wrote:
> >
> > In some configurations, the BAM DMA controller is set up by a remote
> > processor and the local processor can simply start making use of it
> > without setting up the BAM. This is already supported using the
> > "qcom,controlled-remotely" property.
> >
> > However, for some reason another possible configuration is that the
> > remote processor is responsible for powering up the BAM, but we are
> > still responsible for initializing it (e.g. resetting it etc). Add
> > a "qcom,powered-remotely" property to describe that configuration.
> >
> > Signed-off-by: Stephan Gerhold <stephan@...hold.net>
> > ---
> > Changes since RFC:
> >   - Rename qcom,remote-power-collapse -> qcom,powered-remotely
> >     for consistency with "qcom,controlled-remotely"
> >
> > NOTE: This is *not* a compile-time requirement for the BAM-DMUX driver
> >       so this could also go through the dmaengine tree.
> >
> > Also note that there is an ongoing effort to convert these bindings
> > to DT schema but sadly there were not any updates for a while. :/
> > https://lore.kernel.org/linux-arm-msm/20210519143700.27392-2-bhupesh.sharma@linaro.org/
> 
> Seems you missed the latest series posted last week - [1]. Sorry I got
> a bit delayed posting it due to being caught up in other patches.
> 
> Maybe you can rebase your patch on the same and use the YAML bindings
> for the qcom,bam_dma controller.
> 
> [1]. https://lore.kernel.org/linux-arm-msm/20211013105541.68045-1-bhupesh.sharma@linaro.org/T/#t
> 

Ah, you're right sorry! Seems like you sent it two days after I sent the
v2 of this patch. Thanks a lot for continuing work on this! :)

Since I already sent v3 of this patch earlier, I think it is best if
I wait a bit first and see if Vinod has any comments or still wants to
take it for 5.16. Should be simple to rebase either of our patches on
the other one.

Thanks!
Stephan