arm: pxa: clean-up include file order

Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.

Signed-off-by Marcel Ziswiler <[email protected]>

---

 drivers/mmc/tegra_mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/mmc/tegra_mmc.c +3 -4

index 6f8b4d0..078df39 100644
@@ -7,14 +7,14 @@
  * SPDX-License-Identifier:    GPL-2.0+
  */
 
-#include <bouncebuf.h>
 #include <common.h>
-#include <asm/gpio.h>
-#include <asm/io.h>
 #include <asm/arch/clock.h>
 #include <asm/arch-tegra/clk_rst.h>
 #include <asm/arch-tegra/mmc.h>
 #include <asm/arch-tegra/tegra_mmc.h>
+#include <asm/gpio.h>
+#include <asm/io.h>
+#include <bouncebuf.h>
 #include <mmc.h>
 
 DECLARE_GLOBAL_DATA_PTR;
--

2.4.3

Thanks for tidying this up. But the ordering should be:

<common.h>
<others.h>
<asm/...>
<arch/arm/...>
<linux/...>
"local.h"

Quoted 8 lines · Simon Glass

Thanks for tidying this up. But the ordering should be:

<common.h>
<others.h>
<asm/...>
<arch/arm/...>
<linux/...>
"local.h"

Says who? I was only aware that common.h needs to go on top, the local stuff (e.g. in double quotes) on the bottom and the rest I assumed can go alphabetically ordered in between, not?

Quoted 5 lines

Says who? I was only aware that common.h needs to go on top, the local
stuff (e.g. in double quotes) on the bottom and the rest I assumed can
go alphabetically ordered in between, not?

I originally got it from here (and another thread I can't find):

http://lists.denx.de/pipermail/u-boot/2012-January/114965.html

-----Original Message-----
From: Marcel Ziswiler [mailto:marcel at ziswiler.com]
Sent: Sunday, August 16, 2015 2:34 PM
To: Simon Glass
Cc: U-Boot Mailing List; Tom Warren; Pantelis Antoniou; Tom Rini; Albert Aribaud; Stephen Warren
Subject: Re: [PATCH 03/11] arm: tegra: mmc: clean-up include file order

Quoted 7 lines · Simon Glass

Quoted 3 lines

Says who? I was only aware that common.h needs to go on top, the local stuff (e.g. in double quotes) on the bottom and the rest I assumed can go alphabetically ordered in between, not?

I originally got it from here (and another thread I can't find):

http://lists.denx.de/pipermail/u-boot/2012-January/114965.html

Hm, interesting. But that one suggests a different order yet again. Unfortunately it misses giving any reason for any of this. Me seriously wondering now.

BTW: Marek was happy with my order of things for the PXA stuff:

http://git.denx.de/?p=u-boot/u-boot-pxa.git;a=commitdiff;h=940ed38dd673
ecfbe03ed5e36c25bc4238356947

I have no problem with this sort order. Let me know if you want me to take this in to Tegra or if it should go into u-boot-mmc tree via Panto.

Quoted 9 lines · Simon Glass

Quoted 5 lines

Says who? I was only aware that common.h needs to go on top, the local
stuff (e.g. in double quotes) on the bottom and the rest I assumed can
go alphabetically ordered in between, not?

I originally got it from here (and another thread I can't find):

http://lists.denx.de/pipermail/u-boot/2012-January/114965.html

Hm, interesting. But that one suggests a different order yet again. Unfortunately it misses giving any reason for any of this. Me seriously wondering now.

BTW: Marek was happy with my order of things for the PXA stuff:

http://git.denx.de/?p=u-boot/u-boot-pxa.git;a=commitdiff;h=940ed38dd673
ecfbe03ed5e36c25bc4238356947

The nice thing about sorting things in groups is that you can see at a
glance what is missing. It doesn't make sense to have:

<asm/aaa.h>
<bbb.c>
<asm/ccc.h>

since the asm/ includes are quite a different category.

Quoted 9 lines · Simon Glass

The nice thing about sorting things in groups is that you can see at a
glance what is missing. It doesn't make sense to have:

<asm/aaa.h>
<bbb.c>
<asm/ccc.h>

since the asm/ includes are quite a different category.

But that's not at all what I proposed. What I was talking about looks as follows:

<common.h>
<asm/aaa.h>
<asm/ccc.h>
<bbb.c>
<linux/aaa.h>
"local.h"

Which is exactly what I actually did in the patch we are talking about.

OK, I agree that there seems to be one nitty-gritty detail concerning the sort order of - aka dash vs. / aka slash going back to GNU sort (which is what I used) not seeming to enforce the same but I actually see that as a minor detail.

-----Original Message-----
From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
Sent: Tuesday, August 18, 2015 5:44 AM
To: Marcel Ziswiler
Cc: U-Boot Mailing List; Tom Warren; Pantelis Antoniou; Tom Rini; Albert Aribaud; Stephen Warren
Subject: Re: [PATCH 03/11] arm: tegra: mmc: clean-up include file order

Hi Marcel,

Quoted 21 lines · Marcel Ziswiler

Quoted 8 lines · Simon Glass

The nice thing about sorting things in groups is that you can see at a glance what is missing. It doesn't make sense to have:

<asm/aaa.h>
<bbb.c>
<asm/ccc.h>

since the asm/ includes are quite a different category.

But that's not at all what I proposed. What I was talking about looks as follows:

<common.h>
<asm/aaa.h>
<asm/ccc.h>
<bbb.c>
<linux/aaa.h>
"local.h"

Quoted 6 lines

Which is exactly what I actually did in the patch we are talking about.

OK, I agree that there seems to be one nitty-gritty detail concerning the sort order of - aka dash vs. / aka slash going back to GNU sort (which is what I used) not seeming to enforce the same but I actually see that as a minor detail.

No I think you misunderstand. Another way of explaining this is sorting fruit and animals:

apple
grapefruit
orange
elephant
lion
zebra

We don't want to mix up the fruit and animals, so each has its own position in the table.We can then easily see what animals are in the table.

This is not a case of running 'sort' on the includes. The 'asm' files are arch- specific includes and should go after all the 'generic'
includes, like <bbb.c>, etc.

So to repeat, the ordering should be:

<common.h> <- most general
<others.h>
<asm/...>
<arch/arm/...>
<linux/...>
"local.h" <- least general

Regards,
Simon

No I think you misunderstand. Another way of explaining this is sorting fruit and animals:

apple
grapefruit
orange
elephant
lion
zebra

We don't want to mix up the fruit and animals, so each has its own position in the table.We can then easily see what animals are in the table.

This is not a case of running 'sort' on the includes. The 'asm' files are arch-specific includes and should go after all the 'generic' includes, like <bbb.c>, etc.

So to repeat, the ordering should be:

<common.h> <- most general
<others.h>
<asm/...>
<arch/arm/...>
<linux/...>
"local.h" <- least general

Quoted 10 lines · Simon Glass

No I think you misunderstand. Another way of explaining this is sorting fruit and animals:

apple
grapefruit
orange
elephant
lion
zebra

Quoted 3 lines

We don't want to mix up the fruit and animals, so each has its own position in the table.We can then easily see what animals are in the table.

I see but I still don't think your example matches our problem at hand quite that accurately.

Quoted 4 lines

This is not a case of running 'sort' on the includes. The 'asm' files are arch-specific includes and should go after all the 'generic' includes, like <bbb.c>, etc.

Quoted 8 lines

So to repeat, the ordering should be:

<common.h> <- most general
<others.h>
<asm/...>
<arch/arm/...>
<linux/...>
"local.h" <- least general

Your proposal sounds quite honourable but the problem I see with it is that your order is based on some generality rule I don't quite see where it could be looked up.

At the end I believe the order actually does not even matter apart from U-Boot's special common.h having to go first. And even that could be worked around by the build system itself (see e.g. Linux kernel for that matter).

So for me such ordering is just cosmetic and might at best help us humble programmers when comparing stuff or looking through to make sure a certain include is indeed already there or the like.

The only practical way I see to achieve this would be to plain simply alphabetically sort them.

As I don't think this is much worth discussing any further I'm fine with dropping this patch even though I actually think the actual file in question is seriously buggy as it does not put common.h first.

Fix boot hang caused by incompatible libgcc which has been observed when using later Linaro toolchains like gcc-linaro-arm-linux-gnueabihf-2012.09-20120921_linux or gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.

Signed-off-by Marcel Ziswiler <[email protected]>

---

 configs/colibri_pxa270_defconfig | 1 +
 1 file changed, 1 insertion(+)

(quoted diff) +0 -0

b/configs/colibri_pxa270_defconfig index 3963a50..2ef9ccb 100644

On Sunday, August 16, 2015 at 04:16:32 AM, Marcel Ziswiler wrote:

I would suggest that we drop this patch, but I would also suggest that we do
the same thing kernel does and just enable CONFIG_USE_PRIVATE_LIBGCC globally
for everyone to break this constant nonsensical influx of toolchain-related
problems. This nonsense has been dragging on for too long. Tom? Albert?

Quoted 9 lines · Marek Vasut

On Sunday, August 16, 2015 at 04:16:32 AM, Marcel Ziswiler wrote:

I would suggest that we drop this patch, but I would also suggest that we do
the same thing kernel does and just enable CONFIG_USE_PRIVATE_LIBGCC globally
for everyone to break this constant nonsensical influx of toolchain-related
problems. This nonsense has been dragging on for too long. Tom? Albert?

I don't really care how this gets fixed I just don't ever want to have to debug through that one ever again!

Thanks, Marek.

Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.

Signed-off-by Marcel Ziswiler <[email protected]>

I cannot find 03/11 , why ?

I applied all but 03/11 and 07/11 to u-boot-pxa/master though :)

Quoted 1 line · Marek Vasut

I cannot find 03/11 , why ?

Ah, I believe that one is actually meant for Tegra rather than PXA and will hopefully be picked up by Tom.

Quoted 1 line

I applied all but 03/11 and 07/11 to u-boot-pxa/master though :)

Thanks, Marek. I hope we can sort out 07/11 soon as well.

BTW: I just got it booting Linux -next with a preliminary device tree I put together including NFSv4 mounted rootfs. Just wondering why there aren't any PXA device trees mainline yet.

trying to
confuse the enemy with random unrelated patches right in the middle of a
coherent series? :)

I think Daniel Mack was the last one who worked on PXA DT support.