linux-kernel - Re: [PATCH v3 1/3] dt-bindings: remoteproc: k3-m4f: Add bindings for K3 AM64x SoCs

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: <c2bebcbf9d463d656ae69d489e0e5a88f2540c2e.camel@collabora.com>
Date:   Tue, 07 Mar 2023 18:26:25 +0000
From:   Martyn Welch <martyn.welch@...labora.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Hari Nagalla <hnagalla@...com>
Cc:     kernel@...labora.com, linux-remoteproc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: remoteproc: k3-m4f: Add bindings
 for K3 AM64x SoCs

On Fri, 2023-03-03 at 09:06 +0100, Krzysztof Kozlowski wrote:
> On 02/03/2023 18:14, Martyn Welch wrote:
> 
> > +
> > +  mboxes:
> > +    description: |
> > +      OMAP Mailbox specifier denoting the sub-mailbox, to be used
> > for
> 
> OMAP?
> 

This device uses a mailbox compatible with the OMAP Mailbox, as defined
in Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml.

I note that documents title reads "TI OMAP2+ and K3 Mailbox devices".
I'll drop the "OMAP" here.

> > +      communication with the remote processor. This property
> > should match
> > +      with the sub-mailbox node used in the firmware image.
> > +    maxItems: 1
> > +
> > +  memory-region:
> > +    description: |
> > +      phandle to the reserved memory nodes to be associated with
> > the
> > +      remoteproc device. There should be at least two reserved
> > memory nodes
> > +      defined. 
> 
> Don't repeat constraints in free form text.
> 
> > The reserved memory nodes should be carveout nodes, and
> > +      should be defined with a "no-map" property as per the
> > bindings in
> > +      Documentation/devicetree/bindings/reserved-memory/reserved-
> > memory.yaml
> > +    minItems: 2
> > +    maxItems: 8
> > +    items:
> > +      - description: region used for dynamic DMA allocations like
> > vrings and
> > +                     vring buffers
> > +      - description: region reserved for firmware image sections
> > +    additionalItems: true
> 
> And what is the purpose of the rest of reserved nodes?
> 

Up to 8 regions can be specified with their purpose determined by the
firmware running on the M4F core. The suggestion (and the
implementation in the example firmware) is to use the first 2 regions
as defined above for remoteproc with the others available to be used
for other purposes if necessary. The address translation module used
can cope with up to 8 regions.

> 

Martyn