linux-kernel - Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

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:	Tue, 23 Jul 2013 18:14:27 +0100
From:	Pawel Moll <pawel.moll@....com>
To:	Rob Herring <robherring2@...il.com>
Cc:	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Rutland <Mark.Rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Olof Johansson <olof@...om.net>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

On Mon, 2013-07-22 at 21:03 +0100, Rob Herring wrote:
> On 07/22/2013 11:50 AM, Pawel Moll wrote:
> > On Sat, 2013-07-20 at 04:19 +0100, Grant Likely wrote:
> >> +F:	include/dt-bindings
> > 
> > One thing we didn't finish talking about was the question if this
> > directory is supposed to contain *.dtsi files as well? The obvious
> > problem I have is a vexpress motherboard being (well, actually not bein
> > right now) shared between arch/arm/boot/dts and arch/arm64/boot/dts.
> 
> Please no. 

No as in: no don't put *.dtsi files into include/dt-bindings; or: no, do
not duplicate the motherboard file?

It you meant the latter, this is exactly what I wanted to say: I don't
want to do that, but there's no way of avoiding it right now.

> When we move dts files out of the kernel, 

And when would this happen? Don't get me wrong, I'm in favour of doing
this as well (I really don't want to push all 15-or-so DTSes for all the
different models and SMMs I have into the kernel)

> we will still need
> to copy dt-bindings into the kernel. Also, I think we should move all
> dts files out of arch subdirs and arrange by vendor or soc family. I'm
> sure there are some cases that structure doesn't fit well, but there is
> very little in a dts tied to a cpu architecture.

I couldn't agree more. So:

<root>/include/dt-bindings/vendor/*?
<root>/dts/vendor/*?
<root>/of/vendor/*?
<root>/dt/vendor/*?
<root>/drivers/of/vendor/*?

Paweł


--
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/