linux-kernel - Re: [PATCH v2.1 1/9] dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding

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:	Fri, 22 Apr 2016 11:22:25 -0500
From:	Rob Herring <robh+dt@...nel.org>
To:	Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Suman Anna <s-anna@...com>,
	John Stultz <john.stultz@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	linux-remoteproc@...r.kernel.org,
	Bjorn Andersson <bjorn.andersson@...ymobile.com>
Subject: Re: [PATCH v2.1 1/9] dt-binding: remoteproc: Introduce Qualcomm WCNSS
 loader binding

On Thu, Apr 21, 2016 at 12:20 PM, Bjorn Andersson
<bjorn.andersson@...aro.org> wrote:
> From: Bjorn Andersson <bjorn.andersson@...ymobile.com>
>
> The document defines the binding for a component that loads firmware for
> and boots the Qualcomm WCNSS core.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@...ymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> ---
>
> Rob,
>
> I got your Ack on v2, but I would like to make a small amendment before merging
> this.
>
>
> As we discussed related to the WiFi binding I should reference the mmio
> registers by a phandle to a DT node specifying the two necessary register
> blocks (ccu & dxe).
>
> These two register blocks are part of the riva/pronto (the two major versions)
> subsystem, that also contains the "pmu" register block, which is what I access
> here.
>
> Further more, the ccu block contains valuable information for debugging
> purposes that the implementation of this binding would find useful.
>
>
> I would therefor like to double this node (in the dts) as both the
> riva/pronto-pil and the target for the mmio phandle reference from the WiFi
> node.
>
> This works fine, but unless using reg-names for defining the order or the regs
> I get a messy ordering dependency between the two bindings. I do not know which
> of the other 7-8 register blocks we will add for debugging, but with the below
> change I can keep them in block order regardless of the order we implement them
> in.

You should know based on the compatible string what the number and
order of register ranges are. reg is not something we want evolving
over time.

> So, can I update the "reg" and add "reg-names" as below to the binding and
> depend on reg-names for the ordering of reg? Or should I speculatively add all
> ranges I know of to keep the order sane?

I'm okay with using this for convenience of the client not having to
care which compatible the block is, but the above should still be met.

Also, you could add a cell which is the index to the register range you need.

Rob