linux-kernel - Re: [PATCH V2 1/2] pinctrl: tegra: Add devicetree binding document for Tegra124

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: <20131209174859.GC1809@e106331-lin.cambridge.arm.com>
Date:	Mon, 9 Dec 2013 17:48:59 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Laxman Dewangan <ldewangan@...dia.com>,
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Pawel Moll <Pawel.Moll@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"rob@...dley.net" <rob@...dley.net>,
	"thierry.reding@...il.com" <thierry.reding@...il.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 1/2] pinctrl: tegra: Add devicetree binding document
 for Tegra124

On Mon, Dec 09, 2013 at 05:39:42PM +0000, Stephen Warren wrote:
> On 12/09/2013 03:51 AM, Mark Rutland wrote:
> > On Mon, Dec 09, 2013 at 10:32:19AM +0000, Laxman Dewangan wrote:
> >> This device tree binding document describes the Tegra124 pincontrol
> >> DT bindings. This document lists all valid properties, names, mux
> >> options of Tegra124 pins.
> >>
> >> Signed-off-by: Laxman Dewangan <ldewangan@...dia.com>
> >> ---
> >> Changes from V1:
> >> - Referred the dt-binding header file on describing the nodes.
> >>
> >>  .../bindings/pinctrl/nvidia,tegra124-pinmux.txt    |  147 ++++++++++++++++++++
> >>  1 files changed, 147 insertions(+), 0 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt
> >> new file mode 100644
> >> index 0000000..12ef772
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt
> >> @@ -0,0 +1,147 @@
> >> +NVIDIA Tegra124 pinmux controller
> >> +
> >> +The Tegra124 pinctrl binding is very similar to the Tegra20 and Tegra30
> >> +pinctrl binding, as described in nvidia,tegra20-pinmux.txt and
> >> +nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as
> >> +a baseline, and only documents the differences between the two bindings.
> >> +
> >> +Required properties:
> >> +- compatible: "nvidia,tegra124-pinmux"
> >> +- reg: Should contain the register physical address and length for each of
> >> +  the pad control and mux registers. The first bank of address must be the
> >> +  driver strength pad control register address and second bank address must
> >> +  be pinmux register address.
> > 
> > The wording here could be improved. The first sentence implies an entry
> > for each individual register but I assume these are actually banks of
> > registers (the sizes in the exanple imply this). The second sentence is
> > more sepcific.
> > 
> > How about something like:
> > 
> > reg: Should contain a list of base address and size pairs for:
> >  * first entry - the driver strength and pad control registers
> 
> If this patch gets revised, please s/driver/drive/ here.

Whoops. I'm too used to typing the former.

> 
> >  * second entry - the pinmux registers
> > 
> > Are these banks well defined? Where do they end?
> 
> Yes, the SoC includes specific banks of registers for those two types of
> configuration. The banks end at whatever address contains the last
> define register of that type.
> 
> > Is there likely to be anything built as an extension of this? Does it
> > possibly make sense to use reg-names?
> 
> Any new SoC would get a new binding, since all the other configuration
> parameters (lists of valid pins, groups, functions) would be different,
> so there's no need for future compatibility here.
> 

Ok, thanks for the info.

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/