public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/PATCH 1/4 PATCH] ARM: mvebu: use dt_fixup to provide fallback for enable-method
Date: Mon, 15 Dec 2014 11:37:59 +0100	[thread overview]
Message-ID: <7947240.7yktm8fT2X@wuerfel> (raw)
In-Reply-To: <548E3209.20307@alliedtelesis.co.nz>

On Monday 15 December 2014 00:57:49 Chris Packham wrote:
> On 12/15/2014 10:11 AM, Chris Packham wrote:
> >>> +
> >>> +CFLAGS_board-v7.o = -I$(src)/../../../scripts/dtc/libfdt
> >>> \ No newline at end of file
> >>
> >> Why is this needed? Can't you just include <linux/libfdt.h> ?
> >>
> >
> > I am already including linux/libfdt.h. Without the CFLAGS change I get
> > the following compile error.
> >
> >    In file included from include/linux/libfdt.h:6:0,
> >                     from arch/arm/mach-mvebu/board-v7.c:21:
> >    include/linux/../../scripts/dtc/libfdt/libfdt.h:54:24: fatal error:
> > libfdt_env.h: No such file or directory
> >
> > There seems to be precedence in other architectures/drivers
> >
> >    $ git grep -e '-I.*libfdt'
> >    arch/mips/cavium-octeon/Makefile:CFLAGS_octeon-platform.o =
> > -I$(src)/../../../scripts/dtc/libfdt
> >    arch/mips/cavium-octeon/Makefile:CFLAGS_setup.o =
> > -I$(src)/../../../scripts/dtc/libfdt
> >    arch/mips/mti-sead3/Makefile:CFLAGS_sead3-setup.o =
> > -I$(src)/../../../scripts/dtc/libfdt
> >    arch/powerpc/kernel/Makefile:CFLAGS_prom.o              =
> > -I$(src)/../../../scripts/dtc/libfdt
> >    drivers/firmware/efi/libstub/Makefile:CFLAGS_fdt.o    +=
> > -I$(srctree)/scripts/dtc/libfdt/
> >    drivers/of/Makefile:CFLAGS_fdt.o = -I$(src)/../../scripts/dtc/libfdt
> >    drivers/of/Makefile:CFLAGS_fdt_address.o =
> > -I$(src)/../../scripts/dtc/libfdt
> >

I still think we should not duplicate this but instead change the
header files to make the include hack unnecessary in all those places.

Looking at the header file, it only contains

#include <linux/libfdt_env.h>
#include "../../scripts/dtc/libfdt/fdt.h"
#include "../../scripts/dtc/libfdt/libfdt.h"

so two of them get the headers from exactly that place, while the
libfdt_env.h file contains the linux-specific implementation of
a couple of functions instead of the baremetal implementation.

It looks like the intention was that when you already include the
linux version of the header, you no longer need the other one, but
that assumption is broken by current implementation.

One way to solve this would be

diff --git a/scripts/dtc/libfdt/libfdt.h b/scripts/dtc/libfdt/libfdt.h
index 73f49759a5e7..23c55baa8e18 100644
--- a/scripts/dtc/libfdt/libfdt.h
+++ b/scripts/dtc/libfdt/libfdt.h
@@ -51,7 +51,7 @@
  *     EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include <libfdt_env.h>
+#include "libfdt_env.h"
 #include <fdt.h>
 
 #define FDT_FIRST_SUPPORTED_VERSION	0x10


but I'm not sure if that is the best way.

> >> I think it would be good to first check whether you are running on
> >> Armada XP
> >> or Armada 370, because the latter does not require this.
> >>
> >>     Arnd
> >>
> >
> > Any suggestion as to what to check for. Based on the dts files in the
> > current source seem compatible == "marvell,armada370" seems like a good
> > choice. But I don't know for sure that there isn't a armada-xp variant
> > out using a .dts with this set.
> 
> Adding the following at the top will do the trick (assuming
> "marvell,armada370" is the right compatible string to use).
> 
>         unsigned long root = of_get_flat_dt_root();
> 
>         if (of_flat_dt_is_compatible(root, "marvell,armada370"))
>                 return;

Right. You could also add 

	if (!IS_ENABLED(CONFIG_SMP) || !of_flat_dt_is_compatible(root, "marvell,armadaxp")))

to again eliminate that check for uniprocessor kernels, and to not
propagate the fixup to future machines but make it clear that
it is only needed for armadaxp.

	Arnd

  reply	other threads:[~2014-12-15 10:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10  2:39 [RFC/PATCH 0/4] Add support for Marvell's RD-DXBC2 Chris Packham
2014-12-10  2:39 ` [RFC/PATCH 1/4] ARM: mvebu: use dt_fixup to provide fallback for enable-method Chris Packham
2014-12-10  9:44   ` Arnd Bergmann
2014-12-10 19:45     ` Chris Packham
2014-12-12  4:53       ` [RFC/PATCH 1/4 PATCH] " Chris Packham
2014-12-12 11:35         ` Arnd Bergmann
2014-12-14 21:11           ` Chris Packham
2014-12-15  0:57             ` Chris Packham
2014-12-15 10:37               ` Arnd Bergmann [this message]
2014-12-15 20:12                 ` Chris Packham
2014-12-16  2:21                   ` Chris Packham
2014-12-16  8:57                     ` Arnd Bergmann
2014-12-16  2:13                 ` [PATCH] dtc: Use quotes to include header files Chris Packham
2014-12-16 14:44                   ` Jon Loeliger
2015-01-29 15:56                   ` Grant Likely
2015-01-29 16:30                     ` Rob Herring
2015-01-30 16:21                     ` Chris Packham
2014-12-10  2:39 ` [RFC/PATCH 2/4] clk: mvebu: armada-xp: Support for 98DX4251 Chris Packham
2014-12-10  2:39 ` [RFC/PATCH 3/4] ARM: mvebu: Initial support for rd-dxbc2 Chris Packham
2014-12-10  2:39 ` [RFC/PATCH 4/4] ARM: mvebu: Custom smp_ops for 98DX4251 Chris Packham

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=7947240.7yktm8fT2X@wuerfel \
    --to=arnd@arndb.de \
    --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