From: Ian Campbell <ian.campbell@citrix.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
Russell King <linux@arm.linux.org.uk>,
Pawel Moll <Pawel.Moll@arm.com>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Sudeep Holla <Sudeep.Holla@arm.com>,
Liviu Dudau <Liviu.Dudau@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Will Deacon <Will.Deacon@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Kristina Martsenko <Kristina.Martsenko@arm.com>,
Kumar Gala <galak@codeaurora.org>,
Kevin Hilman <khilman@linaro.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] dtb: Create a common home for cross-architecture dtsi files.
Date: Wed, 29 Jul 2015 15:38:12 +0100 [thread overview]
Message-ID: <1438180692.11600.206.camel@citrix.com> (raw)
In-Reply-To: <20150729132758.GR15213@leverpostej>
On Wed, 2015-07-29 at 14:27 +0100, Mark Rutland wrote:
> On Wed, Jul 29, 2015 at 02:22:54PM +0100, Ian Campbell wrote:
> > On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote:
> > > Hi Ian,
> > >
> > >
> > > 2015-07-27 19:35 GMT+09:00 Ian Campbell <ian.campbell@citrix.com>:
> > > > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2
> > > > on
> > > > LogicTile Express 20MG" added a new dts file to arch/arm64 which
> > > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > > > .dtsi supplied by arch/arm.
> > > >
> > > > Unfortunately this causes some issues for the split device tree
> > > > repository[0], since things get moved around there. In that context
> > > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > > > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> > > >
> > > > The sharing of the .dtsi is legitimate since the baseboard is the
> > > > same
> > > > for various vexpress systems whatever processor they use.
> > > >
> > > > Rather than using ../../ tricks to pickup .dtsi files from another
> > > > arch this patch creates a new directory include/dt-dtsi as a
> > > > home for such cross-arch .dtsi files, arranges for it to be in the
> > > > include path when the .dts files are processed by cpp and switches
> > > > the
> > >
> > >
> > > "include/dt-dtsi/" can be referenced from normal C sources.
> > >
> > > I think another possible home for cross-arch DTSI is "kernel/dts/".
> > > This directory can be hidden from C sources.
> >
> > I suppose, I don't really mind and will follow the direction of the
> > other
> > DTB maintainers. It doesn't seem like a big deal to me.
>
> I don't really have a preference either way.
I'm inclined to leave it, "visible to C sources" doesn't seem like that
much of an issue and IMHO the cure (kernel/dts/...) is worse than the
disease.
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
> > > > /* Active high IRQ 0 is connected to GIC's SPI0 */
> > > > interrupt-map = <0 0 0 &gic 0 0 4>;
> > > >
> > > > - /include/ "vexpress-v2m-rs1.dtsi"
> > > > + #include <arm/vexpress-v2m-rs1.dtsi>
> > > > };
> > > > };
> > >
> > >
> > >
> > > You do not have to replace /include/ with #include,
> > > if you add the include path for DTC.
> >
> > Ah, I looked for this but -i is not documented in the man page.
> >
> > Is there any reason to prefer one over the other?
>
> #include allows you to use CPP in the file you're including, /include/
> does not.
>
> I would imagine we have to use #include in case the dtsi itself has
> #include statements...
If it did, yes. I don't think vexpress-v2m-rs1.dtsi does, since it is using
/include/ today. I'm inclined to switch back to /include/ unless someone
objects.
> > > Please add include path for DTC too
> > > so that both /include/ and #include are available.
>
> ... though that does not preclude adding it to the path for /include/.
Indeed, I've done that locally already.
Ian.
WARNING: multiple messages have this Message-ID (diff)
From: ian.campbell@citrix.com (Ian Campbell)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] dtb: Create a common home for cross-architecture dtsi files.
Date: Wed, 29 Jul 2015 15:38:12 +0100 [thread overview]
Message-ID: <1438180692.11600.206.camel@citrix.com> (raw)
In-Reply-To: <20150729132758.GR15213@leverpostej>
On Wed, 2015-07-29 at 14:27 +0100, Mark Rutland wrote:
> On Wed, Jul 29, 2015 at 02:22:54PM +0100, Ian Campbell wrote:
> > On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote:
> > > Hi Ian,
> > >
> > >
> > > 2015-07-27 19:35 GMT+09:00 Ian Campbell <ian.campbell@citrix.com>:
> > > > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2
> > > > on
> > > > LogicTile Express 20MG" added a new dts file to arch/arm64 which
> > > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > > > .dtsi supplied by arch/arm.
> > > >
> > > > Unfortunately this causes some issues for the split device tree
> > > > repository[0], since things get moved around there. In that context
> > > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > > > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> > > >
> > > > The sharing of the .dtsi is legitimate since the baseboard is the
> > > > same
> > > > for various vexpress systems whatever processor they use.
> > > >
> > > > Rather than using ../../ tricks to pickup .dtsi files from another
> > > > arch this patch creates a new directory include/dt-dtsi as a
> > > > home for such cross-arch .dtsi files, arranges for it to be in the
> > > > include path when the .dts files are processed by cpp and switches
> > > > the
> > >
> > >
> > > "include/dt-dtsi/" can be referenced from normal C sources.
> > >
> > > I think another possible home for cross-arch DTSI is "kernel/dts/".
> > > This directory can be hidden from C sources.
> >
> > I suppose, I don't really mind and will follow the direction of the
> > other
> > DTB maintainers. It doesn't seem like a big deal to me.
>
> I don't really have a preference either way.
I'm inclined to leave it, "visible to C sources" doesn't seem like that
much of an issue and IMHO the cure (kernel/dts/...) is worse than the
disease.
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
> > > > /* Active high IRQ 0 is connected to GIC's SPI0 */
> > > > interrupt-map = <0 0 0 &gic 0 0 4>;
> > > >
> > > > - /include/ "vexpress-v2m-rs1.dtsi"
> > > > + #include <arm/vexpress-v2m-rs1.dtsi>
> > > > };
> > > > };
> > >
> > >
> > >
> > > You do not have to replace /include/ with #include,
> > > if you add the include path for DTC.
> >
> > Ah, I looked for this but -i is not documented in the man page.
> >
> > Is there any reason to prefer one over the other?
>
> #include allows you to use CPP in the file you're including, /include/
> does not.
>
> I would imagine we have to use #include in case the dtsi itself has
> #include statements...
If it did, yes. I don't think vexpress-v2m-rs1.dtsi does, since it is using
/include/ today. I'm inclined to switch back to /include/ unless someone
objects.
> > > Please add include path for DTC too
> > > so that both /include/ and #include are available.
>
> ... though that does not preclude adding it to the path for /include/.
Indeed, I've done that locally already.
Ian.
WARNING: multiple messages have this Message-ID (diff)
From: Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Masahiro Yamada
<yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Lorenzo Pieralisi
<Lorenzo.Pieralisi-5wv7dgnIgG8@public.gmane.org>,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
Linux Kbuild mailing list
<linux-kbuild-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
Sudeep Holla <Sudeep.Holla-5wv7dgnIgG8@public.gmane.org>,
Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Kristina Martsenko
<Kristina.Martsenko-5wv7dgnIgG8@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
linux-arm-kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v2] dtb: Create a common home for cross-architecture dtsi files.
Date: Wed, 29 Jul 2015 15:38:12 +0100 [thread overview]
Message-ID: <1438180692.11600.206.camel@citrix.com> (raw)
In-Reply-To: <20150729132758.GR15213@leverpostej>
On Wed, 2015-07-29 at 14:27 +0100, Mark Rutland wrote:
> On Wed, Jul 29, 2015 at 02:22:54PM +0100, Ian Campbell wrote:
> > On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote:
> > > Hi Ian,
> > >
> > >
> > > 2015-07-27 19:35 GMT+09:00 Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>:
> > > > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2
> > > > on
> > > > LogicTile Express 20MG" added a new dts file to arch/arm64 which
> > > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > > > .dtsi supplied by arch/arm.
> > > >
> > > > Unfortunately this causes some issues for the split device tree
> > > > repository[0], since things get moved around there. In that context
> > > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > > > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> > > >
> > > > The sharing of the .dtsi is legitimate since the baseboard is the
> > > > same
> > > > for various vexpress systems whatever processor they use.
> > > >
> > > > Rather than using ../../ tricks to pickup .dtsi files from another
> > > > arch this patch creates a new directory include/dt-dtsi as a
> > > > home for such cross-arch .dtsi files, arranges for it to be in the
> > > > include path when the .dts files are processed by cpp and switches
> > > > the
> > >
> > >
> > > "include/dt-dtsi/" can be referenced from normal C sources.
> > >
> > > I think another possible home for cross-arch DTSI is "kernel/dts/".
> > > This directory can be hidden from C sources.
> >
> > I suppose, I don't really mind and will follow the direction of the
> > other
> > DTB maintainers. It doesn't seem like a big deal to me.
>
> I don't really have a preference either way.
I'm inclined to leave it, "visible to C sources" doesn't seem like that
much of an issue and IMHO the cure (kernel/dts/...) is worse than the
disease.
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
> > > > /* Active high IRQ 0 is connected to GIC's SPI0 */
> > > > interrupt-map = <0 0 0 &gic 0 0 4>;
> > > >
> > > > - /include/ "vexpress-v2m-rs1.dtsi"
> > > > + #include <arm/vexpress-v2m-rs1.dtsi>
> > > > };
> > > > };
> > >
> > >
> > >
> > > You do not have to replace /include/ with #include,
> > > if you add the include path for DTC.
> >
> > Ah, I looked for this but -i is not documented in the man page.
> >
> > Is there any reason to prefer one over the other?
>
> #include allows you to use CPP in the file you're including, /include/
> does not.
>
> I would imagine we have to use #include in case the dtsi itself has
> #include statements...
If it did, yes. I don't think vexpress-v2m-rs1.dtsi does, since it is using
/include/ today. I'm inclined to switch back to /include/ unless someone
objects.
> > > Please add include path for DTC too
> > > so that both /include/ and #include are available.
>
> ... though that does not preclude adding it to the path for /include/.
Indeed, I've done that locally already.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-07-29 14:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 10:35 [PATCH v2] dtb: Create a common home for cross-architecture dtsi files Ian Campbell
2015-07-27 10:35 ` Ian Campbell
2015-07-27 10:35 ` Ian Campbell
2015-07-27 10:41 ` Mark Rutland
2015-07-27 10:41 ` Mark Rutland
2015-07-29 11:07 ` Masahiro Yamada
2015-07-29 11:07 ` Masahiro Yamada
2015-07-29 13:22 ` Ian Campbell
2015-07-29 13:22 ` Ian Campbell
2015-07-29 13:22 ` Ian Campbell
2015-07-29 13:27 ` Mark Rutland
2015-07-29 13:27 ` Mark Rutland
2015-07-29 14:38 ` Ian Campbell [this message]
2015-07-29 14:38 ` Ian Campbell
2015-07-29 14:38 ` Ian Campbell
2015-07-29 15:23 ` Rob Herring
2015-07-29 15:23 ` Rob Herring
2015-07-30 1:30 ` Masahiro Yamada
2015-07-30 1:30 ` Masahiro Yamada
2015-07-31 5:46 ` Masahiro Yamada
2015-07-31 5:46 ` Masahiro Yamada
2015-07-31 5:46 ` Masahiro Yamada
2015-07-31 13:05 ` Rob Herring
2015-07-31 13:05 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1438180692.11600.206.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Catalin.Marinas@arm.com \
--cc=Kristina.Martsenko@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=Pawel.Moll@arm.com \
--cc=Sudeep.Holla@arm.com \
--cc=Will.Deacon@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.