From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] omap plat header removal for v3.8 merge window, part1
Date: Sat, 27 Oct 2012 10:02:10 +0100 [thread overview]
Message-ID: <20121027090210.GJ28061@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20121026223848.GY11908@atomide.com>
On Fri, Oct 26, 2012 at 03:38:49PM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [121026 10:57]:
> > * Arnd Bergmann <arnd@arndb.de> [121026 10:30]:
> > >
> > > Well, once CONFIG_MULTIPLATFORM gets enabled, the mach/*.h files are
> > > not visible to drivers any more, but they are still visible to files
> > > in plat-omap if you add a line like
> > >
> > > ccflags-$(CONFIG_ARCH_OMAP2) := -I$(srctree)/arch/arm/mach-omap2/include
> > > ccflags-$(CONFIG_ARCH_OMAP1) := -I$(srctree)/arch/arm/mach-omap1/include
> > >
> > > to arch/arm/plat-omap/Makefile. That is how the other multiplatform
> > > Makefiles do it. If a driver writer really wants to cheat, they can of
> > > course do the same thing in their directory, but they can also do
> > > #include "../../../../arch/arm/mach-omap2/foo.h"
> >
> > OK thanks for clarifying that. Sounds like that can be used to
> > fix up the relative includes for plat-omap. I'll do some patches
> > for that after we have the #include <plat/*.h> and #include <mach/*.h>
> > issue sorted out.
>
> Here's a patch for that. It's against what I have queued up in
> omap-for-v3.8/cleanup-headers. Does that look OK to you?
>
> Regards,
>
> Tony
>
>
> From: Tony Lindgren <tony@atomide.com>
> Date: Fri, 26 Oct 2012 15:06:40 -0700
> Subject: [PATCH] ARM: OMAP: Fix relative includes for plat-omap with ccflags
>
> As suggested by Arnd Bergmann <arnd@arndb.de>, we can keep
> these headers local to arch/arm/*omap*/ by modifying the
> ccflags in plat/omap/Makefile.
>
> Note that eventually even most of these will go away
> as things like SRAM and PRCM become just regular device
> drivers.
>
> Also note that this will not fix plat/cpu.h, but that
> will be removed anyways as soon as the drivers are
> fixed.
>
> While at it, also sort the includes the standard way.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
> index cd169c3..03b1e80 100644
> --- a/arch/arm/mach-omap1/Makefile
> +++ b/arch/arm/mach-omap1/Makefile
> @@ -2,6 +2,8 @@
> # Makefile for the linux kernel.
> #
>
> +ccflags-$(CONFIG_ARCH_OMAP) := -I$(srctree)/arch/arm
> +
Rather than moving all the files from plat-omap/include/plat into plat-omap
and then having all these totally disgusting relative includes, why don't
you add to these makefiles:
ccflags += -I$(srctree)/arch/arm/plat-omap/include
and avoid all that include moving and all the include name fixup?
next prev parent reply other threads:[~2012-10-27 9:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 2:33 [GIT PULL] omap plat header removal for v3.8 merge window, part1 Tony Lindgren
2012-10-26 14:02 ` Arnd Bergmann
2012-10-26 17:09 ` Tony Lindgren
2012-10-26 17:28 ` Arnd Bergmann
2012-10-26 17:55 ` Tony Lindgren
2012-10-26 22:38 ` Tony Lindgren
2012-10-27 8:09 ` Arnd Bergmann
2012-10-27 16:29 ` Tony Lindgren
2012-10-27 9:02 ` Russell King - ARM Linux [this message]
2012-10-27 16:32 ` Tony Lindgren
2012-10-30 23:54 ` Tony Lindgren
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=20121027090210.GJ28061@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).