Minor fix for jcooper/for-next
PATCH 1/1 Minor fix for jcooper/for-next
Hello Jason,
Following our discussion yesterday evening/night, I did a test run of jcooper/for-next this morning. It works fine, but requires the following fix, that you can probably stack in mvebu/dt.
Thanks!
Thomas
Thomas Petazzoni (1):
arm: mvebu: ensure PCIe range is propagated in the .dts files
arch/arm/boot/dts/armada-xp-db.dts | 1 + arch/arm/boot/dts/armada-xp-gp.dts | 5 +++-- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 5 +++-- 3 files changed, 7 insertions(+), 4 deletions(-)
Signature · 1 line
1.8.1.2
PATCH 1/1 arm: mvebu: ensure PCIe range is propagated in the .dts files
The ranges DT entry needed by the PCIe controller is defined at the SoC .dtsi level. However, some boards have a NOR flash, and to support it, they need to override the SoC-level ranges property to add an additional range. Since PCIe and NOR support came separately, some boards were not properly changed to include the PCIe range in their ranges property at the .dts level.
This commit fixes those platforms.
--- arch/arm/boot/dts/armada-xp-db.dts | 1 + arch/arm/boot/dts/armada-xp-gp.dts | 5 +++-- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 5 +++-- 3 files changed, 7 insertions(+), 4 deletions(-)
arch/arm/boot/dts/armada-xp-db.dts +1 -0
@@ -31,6 +31,7 @@ soc { ranges = <0 0 0xd0000000 0x100000 /* Internal registers 1MiB */ + 0xe0000000 0 0xe0000000 0x8100000 /* PCIe */ 0xf0000000 0 0xf0000000 0x1000000>; /* Device Bus, NOR 16MiB */ internal-regs {
arch/arm/boot/dts/armada-xp-gp.dts +3 -2
@@ -39,8 +39,9 @@ }; soc { - ranges = <0 0 0xd0000000 0x100000 - 0xf0000000 0 0xf0000000 0x1000000>; + ranges = <0 0 0xd0000000 0x100000 /* Internal registers 1MiB */ + 0xe0000000 0 0xe0000000 0x8100000 /* PCIe */ + 0xf0000000 0 0xf0000000 0x1000000 /* Device Bus, NOR 16MiB */>; internal-regs { serial at 12000 {
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +3 -2
@@ -27,8 +27,9 @@ }; soc { - ranges = <0 0 0xd0000000 0x100000 - 0xf0000000 0 0xf0000000 0x8000000>; + ranges = <0 0 0xd0000000 0x100000 /* Internal registers 1MiB */ + 0xe0000000 0 0xe0000000 0x8100000 /* PCIe */ + 0xf0000000 0 0xf0000000 0x8000000 /* Device Bus, NOR 128MiB */>; internal-regs { serial at 12000 {
Signature · 1 line
1.8.1.2
PATCH 1/1 arm: mvebu: ensure PCIe range is propagated in the .dts files
Quoted 11 lines · Thomas Petazzoni
The ranges DT entry needed by the PCIe controller is defined at the SoC .dtsi level. However, some boards have a NOR flash, and to support it, they need to override the SoC-level ranges property to add an additional range. Since PCIe and NOR support came separately, some boards were not properly changed to include the PCIe range in their ranges property at the .dts level.
This commit fixes those platforms.
Signed-off-by Thomas Petazzoni <[email protected]>---
Can you split this in to two patches, please:
Quoted 1 line
arch/arm/boot/dts/armada-xp-db.dts | 1 +
one for mvebu/dt
Quoted 2 lines
arch/arm/boot/dts/armada-xp-gp.dts | 5 +++-- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 5 +++--
and one for mvebu/fixes?
thx,
Jason.
PATCH 1/1 arm: mvebu: ensure PCIe range is propagated in the .dts files
Quoted 15 lines · Jason Cooper
Quoted 11 lines · Thomas Petazzoni
The ranges DT entry needed by the PCIe controller is defined at the SoC .dtsi level. However, some boards have a NOR flash, and to support it, they need to override the SoC-level ranges property to add an additional range. Since PCIe and NOR support came separately, some boards were not properly changed to include the PCIe range in their ranges property at the .dts level.
This commit fixes those platforms.
Signed-off-by Thomas Petazzoni <[email protected]>---
Can you split this in to two patches, please:
Quoted 8 lines
Quoted 1 line
arch/arm/boot/dts/armada-xp-db.dts | 1 +one for mvebu/dt
Quoted 2 lines
arch/arm/boot/dts/armada-xp-gp.dts | 5 +++-- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 5 +++--and one for mvebu/fixes?
Nevermind, I've got a few minutes and would like to get it in for the last -next this week.
thx,
Jason.
PATCH 1/1 arm: mvebu: ensure PCIe range is propagated in the .dts files
Dear Jason Cooper,
Quoted 6 lines · Jason Cooper
Quoted 6 lines
Can you split this in to two patches, please:
Quoted 1 line
arch/arm/boot/dts/armada-xp-db.dts | 1 +one for mvebu/dt
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
arch/arm/boot/dts/armada-xp-gp.dts | 5 +++-- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 5 +++--and one for mvebu/fixes?
Nevermind, I've got a few minutes and would like to get it in for the last -next this week.
I must admit I don't quite get why the patch had to be split. The three chunks do exactly the same thing for the three boards.
The only difference is that the part touching armada-xp-gp and armada-xp-openblocks-ax3-4 was also adding some comments for each range, while the one for armada-xp-db didn't had to do it because the comments were already there.
So really, the armada-xp-db change is as much of a "fix" than the two other changes.
To be honest, as long as they all go in 3.11, I'm fine, but I'm just curious as to why it would have had to be split.
Thanks!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 arm: mvebu: ensure PCIe range is propagated in the .dts files
Quoted 13 lines · Thomas Petazzoni
Dear Jason Cooper,
Quoted 9 lines · Jason Cooper
Quoted 9 lines
Can you split this in to two patches, please:
Quoted 1 line
arch/arm/boot/dts/armada-xp-db.dts | 1 +one for mvebu/dt
Quoted 2 lines
arch/arm/boot/dts/armada-xp-gp.dts | 5 +++-- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 5 +++--
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
and one for mvebu/fixes?
Nevermind, I've got a few minutes and would like to get it in for the last -next this week.
I must admit I don't quite get why the patch had to be split. The three chunks do exactly the same thing for the three boards.
The _only_ purpose of for-next is to do integration testing against what everyone else has going on for the merge window. There will never be a pull request for it. As such, no patches ever get directly applied on top of it. They need to go against an appropriate branch.
Quoted 10 lines
The only difference is that the part touching armada-xp-gp and armada-xp-openblocks-ax3-4 was also adding some comments for each range, while the one for armada-xp-db didn't had to do it because the comments were already there.
So really, the armada-xp-db change is as much of a "fix" than the two other changes.
To be honest, as long as they all go in 3.11, I'm fine, but I'm just curious as to why it would have had to be split.
the patches in mvebu/fixes:
8eed481 arm: mvebu: fix the 'ranges' property to handle PCIe c6c003a ARM: mvebu: Fix ranges entry on XP GP board 00ed4a0 ARM: mvebu: Add a ranges entry to translate devbus childs
added the ranges property for openblocks-ax3-4, and the gp, but nothing for the db. The patch
b484ff4 ARM: mvebu: Add support for NOR flash device on Armada XP-DB board
went into mvebu/dt because it was adding new capability.
So the choices are to make mvebu/dt depend on mvebu/fixes because of your patch, or to split the patch because there is no real dependency between the two changes.
hth,
Jason.
PATCH 1/1 arm: mvebu: ensure PCIe range is propagated in the .dts files
Dear Jason Cooper,
Quoted 9 lines · Jason Cooper
the patches in mvebu/fixes:
8eed481 arm: mvebu: fix the 'ranges' property to handle PCIe c6c003a ARM: mvebu: Fix ranges entry on XP GP board 00ed4a0 ARM: mvebu: Add a ranges entry to translate devbus childs
added the ranges property for openblocks-ax3-4, and the gp, but nothing for the db. The patch
Quoted 7 lines
b484ff4 ARM: mvebu: Add support for NOR flash device on Armada XP-DB board
went into mvebu/dt because it was adding new capability.
So the choices are to make mvebu/dt depend on mvebu/fixes because of your patch, or to split the patch because there is no real dependency between the two changes.
Ah, ok. That makes sense now. Thanks!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com