Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] kbuild: Don't assume dts files live in arch/*/boot/dts

1 view
Skip to first unread message

Matthijs Kooijman

unread,
May 8, 2013, 7:50:36 AM5/8/13
to Michal Marek, Grant Likely, Rob Herring, linux-...@vger.kernel.org, devicetre...@lists.ozlabs.org, linux-...@vger.kernel.org, linux...@linux-mips.org, Stephen Warren, Matthijs Kooijman
In commit b40b25ff (kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp),
dts building was changed to always use the C preprocessor. This meant
that the .dts file passed to dtc is not the original, but the
preprocessed one.

When compiling with a separate build directory (i.e., with O=), this
preprocessed file will not live in the same directory as the original.
When the .dts file includes .dtsi files, dtc will look for them in the
build directory, not in the source directory and compilation will fail.

The commit referenced above tried to fix this by passing arch/*/boot/dts
as an include path to dtc. However, for mips, the .dts files are not in
this directory, so dts compilation on mips breaks for some targets.

Instead of hardcoding this particular include path, this commit just
uses the directory of the .dts file that is being compiled, which
effectively restores the previous behaviour wrt includes. For most .dts
files, this path is just the same as the previous hardcoded
arch/*/boot/dts path.

This was tested on a mips (rt3052) and an arm (bcm2835) target.

Signed-off-by: Matthijs Kooijman <matt...@stdin.nl>
---
scripts/Makefile.lib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 51bb3de..8337663 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -264,7 +264,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
quiet_cmd_dtc = DTC $@
cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
$(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 \
- -i $(srctree)/arch/$(SRCARCH)/boot/dts $(DTC_FLAGS) \
+ -i $(dir $<) $(DTC_FLAGS) \
-d $(depfile).dtc $(dtc-tmp) ; \
cat $(depfile).pre $(depfile).dtc > $(depfile)

--
1.8.0

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

Stephen Warren

unread,
May 8, 2013, 11:00:37 AM5/8/13
to Matthijs Kooijman, Michal Marek, Grant Likely, Rob Herring, linux-...@vger.kernel.org, devicetre...@lists.ozlabs.org, linux-...@vger.kernel.org, linux...@linux-mips.org, Stephen Warren
On 05/08/2013 04:59 AM, Matthijs Kooijman wrote:
> In commit b40b25ff (kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp),
> dts building was changed to always use the C preprocessor. This meant
> that the .dts file passed to dtc is not the original, but the
> preprocessed one.
>
> When compiling with a separate build directory (i.e., with O=), this
> preprocessed file will not live in the same directory as the original.
> When the .dts file includes .dtsi files, dtc will look for them in the
> build directory, not in the source directory and compilation will fail.
>
> The commit referenced above tried to fix this by passing arch/*/boot/dts
> as an include path to dtc. However, for mips, the .dts files are not in
> this directory, so dts compilation on mips breaks for some targets.
>
> Instead of hardcoding this particular include path, this commit just
> uses the directory of the .dts file that is being compiled, which
> effectively restores the previous behaviour wrt includes. For most .dts
> files, this path is just the same as the previous hardcoded
> arch/*/boot/dts path.
>
> This was tested on a mips (rt3052) and an arm (bcm2835) target.

Reviewed-by: Stephen Warren <swa...@nvidia.com>

(although I wonder if the .dts files shouldn't be in a standard location?)

Matthijs Kooijman

unread,
May 8, 2013, 11:03:21 AM5/8/13
to Stephen Warren, Michal Marek, Grant Likely, Rob Herring, linux-...@vger.kernel.org, devicetre...@lists.ozlabs.org, linux-...@vger.kernel.org, linux...@linux-mips.org, Stephen Warren
Hey Stephen,

On Wed, May 08, 2013 at 08:50:49AM -0600, Stephen Warren wrote:
> On 05/08/2013 04:59 AM, Matthijs Kooijman wrote:
> > ...
> > The commit referenced above tried to fix this by passing arch/*/boot/dts
> > as an include path to dtc. However, for mips, the .dts files are not in
> > this directory, so dts compilation on mips breaks for some targets.
> > ...
>
> (although I wonder if the .dts files shouldn't be in a standard location?)

On mips, I think the dts files are stored together with the soc code in
per-manufacturer directories, which probably works for them.

Regardless of that discussion, I think my patch makes the dts handling
code more generic, so it's probably a good idea to include it anyway.

Matthijs Kooijman

unread,
May 18, 2013, 2:41:41 PM5/18/13
to Stephen Warren, Michal Marek, Grant Likely, Rob Herring, linux-...@vger.kernel.org, devicetre...@lists.ozlabs.org, linux-...@vger.kernel.org, linux...@linux-mips.org, Stephen Warren
Hi Michal,

On Wed, May 08, 2013 at 08:50:49AM -0600, Stephen Warren wrote:
> On 05/08/2013 04:59 AM, Matthijs Kooijman wrote:
> > In commit b40b25ff (kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp),
> > dts building was changed to always use the C preprocessor. This meant
> > that the .dts file passed to dtc is not the original, but the
> > preprocessed one.
> >
> > When compiling with a separate build directory (i.e., with O=), this
> > preprocessed file will not live in the same directory as the original.
> > When the .dts file includes .dtsi files, dtc will look for them in the
> > build directory, not in the source directory and compilation will fail.
> >
> > The commit referenced above tried to fix this by passing arch/*/boot/dts
> > as an include path to dtc. However, for mips, the .dts files are not in
> > this directory, so dts compilation on mips breaks for some targets.
> >
> > Instead of hardcoding this particular include path, this commit just
> > uses the directory of the .dts file that is being compiled, which
> > effectively restores the previous behaviour wrt includes. For most .dts
> > files, this path is just the same as the previous hardcoded
> > arch/*/boot/dts path.
> >
> > This was tested on a mips (rt3052) and an arm (bcm2835) target.
>
> Reviewed-by: Stephen Warren <swa...@nvidia.com>

Did this patch look ok to you? If so, could you pick it up and send it
over to Linus for 3.10 (or should I send it directly)?

Gr.

Matthijs

Michal Marek

unread,
May 23, 2013, 4:16:19 AM5/23/13
to Stephen Warren, Grant Likely, Rob Herring, linux-...@vger.kernel.org, devicetre...@lists.ozlabs.org, linux-...@vger.kernel.org, linux...@linux-mips.org, Stephen Warren
On 18.5.2013 20:41, Matthijs Kooijman wrote:
> Hi Michal,
>
> On Wed, May 08, 2013 at 08:50:49AM -0600, Stephen Warren wrote:
>> On 05/08/2013 04:59 AM, Matthijs Kooijman wrote:
>>> In commit b40b25ff (kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp),
>>> dts building was changed to always use the C preprocessor. This meant
>>> that the .dts file passed to dtc is not the original, but the
>>> preprocessed one.
>>>
>>> When compiling with a separate build directory (i.e., with O=), this
>>> preprocessed file will not live in the same directory as the original.
>>> When the .dts file includes .dtsi files, dtc will look for them in the
>>> build directory, not in the source directory and compilation will fail.
>>>
>>> The commit referenced above tried to fix this by passing arch/*/boot/dts
>>> as an include path to dtc. However, for mips, the .dts files are not in
>>> this directory, so dts compilation on mips breaks for some targets.
>>>
>>> Instead of hardcoding this particular include path, this commit just
>>> uses the directory of the .dts file that is being compiled, which
>>> effectively restores the previous behaviour wrt includes. For most .dts
>>> files, this path is just the same as the previous hardcoded
>>> arch/*/boot/dts path.
>>>
>>> This was tested on a mips (rt3052) and an arm (bcm2835) target.
>>
>> Reviewed-by: Stephen Warren <swa...@nvidia.com>
>
> Did this patch look ok to you? If so, could you pick it up and send it
> over to Linus for 3.10 (or should I send it directly)?

I applied the patch to kbuild.git#rc-fixes now.

Michal
0 new messages