GIC DT binding support

GIT PULL Rob Herring 5 participants 22 messages Oct 14, 2011 – Oct 21, 2011 Arm (32-bit)

Share & tools

Rob Herring

author

2011-10-14 03:01 UTC #0 lore raw

Arnd,

Please pull GIC device tree support. This is the first of 2 pull requests. You can ignore this one if there are no other dependencies on GIC DT support.

This is based on rmk's for-next branch and v3.1-rc9. rc9 was needed for this dependency:

commit eef24afb28561a5a9f4be8f8da97735b7e6a826f
irq: Fix check for already initialized irq_domain in irq_domain_add

Regards,
Rob

The following changes since commit dd5e9eb0d051606ee3eda0c30222429c74e23f00:

Merge commit 'v3.1-rc9' into upstream/base (2011-10-13 20:30:42 -0500)

are available in the git repository at:

http://sources.calxeda.com/git/kernel/linux.git gic-dt

Rob Herring (4):
of/irq: introduce of_irq_init
irq: support domains with non-zero hwirq base
ARM: gic: add irq_domain support
ARM: gic: add OF based initialization

 Documentation/devicetree/bindings/arm/gic.txt |   55 ++++++++++
 arch/arm/common/Kconfig                       |    1 +
 arch/arm/common/gic.c                         |  142
+++++++++++++++++++------
 arch/arm/include/asm/hardware/gic.h           |    5 +-
 drivers/of/irq.c                              |  107 +++++++++++++++++++
 include/linux/irqdomain.h                     |   16 +++-
 include/linux/of_irq.h                        |    3 +
 kernel/irq/irqdomain.c                        |   12 +-
 8 files changed, 299 insertions(+), 42 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

Shawn Guo

2011-10-14 03:18 UTC #1 lore raw

Quoted 6 lines · Rob Herring

Arnd,
Please pull GIC device tree support. This is the first of 2 pull requests. You can ignore this one if there are no other dependencies on GIC DT support.

My imx6q series depends on it.

Signature · 2 lines

Regards,
Shawn

Rob Herring

author

2011-10-18 14:50 UTC #3 lore raw

Quoted 8 lines · Domenico Andreoli

Quoted 7 lines · Rob Herring
The following changes since commit dd5e9eb0d051606ee3eda0c30222429c74e23f00:
Merge commit 'v3.1-rc9' into upstream/base (2011-10-13 20:30:42 -0500)
are available in the git repository at:

Quoted 7 lines

Quoted 1 line
http://sources.calxeda.com/git/kernel/linux.git gic-dt
I got this when I tried to pick you patch.
$ git fetch calxeda
fatal: http://sources.calxeda.com/git/kernel/linux.git/info/refs not found: did you run git update-server-info on the server?
$

Strange. I had tested it out and it worked at the time.

The git protocol is setup now, so use it:

git://sources.calxeda.com/kernel/linux.git

Rob

Domenico Andreoli

2011-10-18 14:58 UTC #4 lore raw

Quoted 17 lines · Rob Herring

Quoted 8 lines · Domenico Andreoli
Quoted 7 lines · Rob Herring
The following changes since commit dd5e9eb0d051606ee3eda0c30222429c74e23f00:
Merge commit 'v3.1-rc9' into upstream/base (2011-10-13 20:30:42 -0500)
are available in the git repository at:
Quoted 7 lines
Quoted 1 line
http://sources.calxeda.com/git/kernel/linux.git gic-dt
I got this when I tried to pick you patch.
$ git fetch calxeda
fatal: http://sources.calxeda.com/git/kernel/linux.git/info/refs not found: did you run git update-server-info on the server?
$

Quoted 5 lines

Strange. I had tested it out and it worked at the time.
The git protocol is setup now, so use it:
git://sources.calxeda.com/kernel/linux.git

yes, this works. what about gitweb? ;)

thanks,
Domenico

Rob Herring

author

2011-10-18 15:10 UTC #5 lore raw

Quoted 18 lines · Domenico Andreoli

Quoted 17 lines · Rob Herring
Quoted 15 lines · Domenico Andreoli
Quoted 8 lines · Rob Herring
The following changes since commit dd5e9eb0d051606ee3eda0c30222429c74e23f00:
Merge commit 'v3.1-rc9' into upstream/base (2011-10-13 20:30:42 -0500)
are available in the git repository at:
http://sources.calxeda.com/git/kernel/linux.git gic-dt
I got this when I tried to pick you patch.
$ git fetch calxeda
fatal: http://sources.calxeda.com/git/kernel/linux.git/info/refs not found: did you run git update-server-info on the server?
$

Quoted 8 lines

Quoted 5 lines
Strange. I had tested it out and it worked at the time.
The git protocol is setup now, so use it:
git://sources.calxeda.com/kernel/linux.git
yes, this works. what about gitweb? ;)

sources.calxeda.com/gitweb

Rob

Shawn Guo

2011-10-20 12:48 UTC #6 lore raw

In reply to Rob Herring

Quoted 21 lines · Rob Herring

Arnd,
Please pull GIC device tree support. This is the first of 2 pull requests. You can ignore this one if there are no other dependencies on GIC DT support.
This is based on rmk's for-next branch and v3.1-rc9. rc9 was needed for this dependency:
commit eef24afb28561a5a9f4be8f8da97735b7e6a826f
irq: Fix check for already initialized irq_domain in irq_domain_add
Regards,
Rob
The following changes since commit dd5e9eb0d051606ee3eda0c30222429c74e23f00:
Merge commit 'v3.1-rc9' into upstream/base (2011-10-13 20:30:42 -0500)
are available in the git repository at:

Quoted 8 lines

http://sources.calxeda.com/git/kernel/linux.git gic-dt
Rob Herring (4):
of/irq: introduce of_irq_init
irq: support domains with non-zero hwirq base
ARM: gic: add irq_domain support
ARM: gic: add OF based initialization

Hi Rob,

Russell is going to take Marc Zyngier's ppi series for v3.2 merge window. I just noticed your patch 'ARM: gic: add irq_domain support' gets some conflict with Marc's series on function gic_dist_init(), which is not so obvious to resolve. You may want to take a look.

Regards,
Shawn

Russell King - ARM Linux

2011-10-20 12:50 UTC #7 lore raw

Quoted 7 lines · Shawn Guo

Quoted 6 lines · Rob Herring
Rob Herring (4):
of/irq: introduce of_irq_init
irq: support domains with non-zero hwirq base
ARM: gic: add irq_domain support
ARM: gic: add OF based initialization

Quoted 6 lines

Hi Rob,
Russell is going to take Marc Zyngier's ppi series for v3.2 merge window. I just noticed your patch 'ARM: gic: add irq_domain support' gets some conflict with Marc's series on function gic_dist_init(), which is not so obvious to resolve. You may want to take a look.

Don't be so sure - Marc has rebased commits which exist in Thomas' tree, so I can't pull it as-is. That needs to be resolving - but unfortunately Thomas is not responding (I suspect he's busy elsewhere also because of the proximity of the kernel summit.)

Given that this is my _last_ full working day before the kernel summit, time is running very short to resolve these problems. So, I think that all this GIC stuff may have to wait until after the KS, and maybe for the following merge window too.

Arnd Bergmann

2011-10-20 13:07 UTC #8 lore raw

In reply to Rob Herring

Quoted 6 lines · Rob Herring

Please pull GIC device tree support. This is the first of 2 pull requests. You can ignore this one if there are no other dependencies on GIC DT support.
This is based on rmk's for-next branch and v3.1-rc9. rc9 was needed for this dependency:

I don't see the for-next branch in the history. Do you mean it requires the for-next branch as well in order to actually build?

Can you be more specific so I can watch for the dependencies to get upstream first?

Quoted 7 lines

The following changes since commit dd5e9eb0d051606ee3eda0c30222429c74e23f00:
Merge commit 'v3.1-rc9' into upstream/base (2011-10-13 20:30:42 -0500)
are available in the git repository at:
http://sources.calxeda.com/git/kernel/linux.git gic-dt

Pulled into my next/dt branch, thanks a lot!

Arnd

Rob Herring

author

2011-10-20 14:34 UTC #9 lore raw

Arnd,

Quoted 10 lines · Arnd Bergmann

Quoted 6 lines · Rob Herring
Please pull GIC device tree support. This is the first of 2 pull requests. You can ignore this one if there are no other dependencies on GIC DT support.
This is based on rmk's for-next branch and v3.1-rc9. rc9 was needed for this dependency:
I don't see the for-next branch in the history. Do you mean it requires the for-next branch as well in order to actually build?

Probably because it is buried by rc9 commits:

git log v3.1-rc9..gic-dt

Quoted 4 lines

Can you be more specific so I can watch for the dependencies to get upstream first?

I believe it conflicts with this commit in rmk/for-next:

commit b166bc3be08b744d2f4b14921a1efee14906b383

Author: Will Deacon <[email protected]>
Date:   Tue Aug 23 22:20:03 2011 +0100

ARM: 7061/1: gic: convert logical CPU numbers into physical numbers

And this one in rmk/devel-stable:

commit 254056f3b12563c11e6dbcfad2fbfce20a4f3302

Author: Colin Cross <[email protected]>
Date:   Thu Feb 10 12:54:10 2011 -0800

ARM: gic: Use cpu pm notifiers to save gic state

BTW, Russell's for-next branch has been rebased. The conflict with the 1st commit is trivial, so I could rebase to merge of rmk/devel-stable and v3.1-rc9.

I still need things from for-next for highbank. So perhaps I should send a pull request after Russell's tree goes in?

Rob

Arnd Bergmann

2011-10-20 16:12 UTC #10 lore raw

Quoted 11 lines · Rob Herring

Arnd,
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · Rob Herring
Please pull GIC device tree support. This is the first of 2 pull requests. You can ignore this one if there are no other dependencies on GIC DT support.
This is based on rmk's for-next branch and v3.1-rc9. rc9 was needed for this dependency:

Quoted 6 lines

Quoted 2 lines
I don't see the for-next branch in the history. Do you mean it requires the for-next branch as well in order to actually build?
Probably because it is buried by rc9 commits:
git log v3.1-rc9..gic-dt

Ah, I see them now. I should make sure I look more closely next time. That definitely explains why I couldn't get this to merge into my for-next branch cleanly.

Quoted 12 lines

Quoted 3 lines
Can you be more specific so I can watch for the dependencies to get upstream first?
I believe it conflicts with this commit in rmk/for-next:
commit b166bc3be08b744d2f4b14921a1efee14906b383
Author: Will Deacon <[email protected]>
Date:   Tue Aug 23 22:20:03 2011 +0100
ARM: 7061/1: gic: convert logical CPU numbers into physical numbers

Quoted 8 lines

And this one in rmk/devel-stable:
commit 254056f3b12563c11e6dbcfad2fbfce20a4f3302
Author: Colin Cross <[email protected]>
Date:   Thu Feb 10 12:54:10 2011 -0800
ARM: gic: Use cpu pm notifiers to save gic state

Ok. Conflicts are not the problem though, I can handle them and sfr can handle them for linux-next, too. Real dependencies are the problem, where you rely on a feature that is part of another tree.

Quoted 6 lines

BTW, Russell's for-next branch has been rebased. The conflict with the 1st commit is trivial, so I could rebase to merge of rmk/devel-stable and v3.1-rc9.
I still need things from for-next for highbank. So perhaps I should send a pull request after Russell's tree goes in?

Yes and no. You simply cannot ask me to merge a branch that is based on top of Russell's for-next branch, since that is getting rebased. It is also bad if the stuff doesn't have any linux-next exposure, so we should try to find another way out.

I've now rebased your tree on top of 3.1-rc9 plus the stable branches from Russell's tree that I already have as dependencies in arm-soc/for-next (devel-stable, smp, debug). This has caused no conflicts for me, but that doesn't mean that it's correct. Please check that what I have in arm-soc/dt/gic and arm-soc/highbank/soc actually works for you and does not contain branches that you don't actually need.

Arnd

Rob Herring

author

2011-10-20 17:09 UTC #11 lore raw

Quoted 60 lines · Arnd Bergmann

Quoted 11 lines · Rob Herring
Arnd,
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · Rob Herring
Please pull GIC device tree support. This is the first of 2 pull requests. You can ignore this one if there are no other dependencies on GIC DT support.
This is based on rmk's for-next branch and v3.1-rc9. rc9 was needed for this dependency:
Quoted 6 lines
Quoted 2 lines
I don't see the for-next branch in the history. Do you mean it requires the for-next branch as well in order to actually build?
Probably because it is buried by rc9 commits:
git log v3.1-rc9..gic-dt
Ah, I see them now. I should make sure I look more closely next time. That definitely explains why I couldn't get this to merge into my for-next branch cleanly.
Quoted 12 lines
Quoted 3 lines
Can you be more specific so I can watch for the dependencies to get upstream first?
I believe it conflicts with this commit in rmk/for-next:
commit b166bc3be08b744d2f4b14921a1efee14906b383
Author: Will Deacon <[email protected]>
Date:   Tue Aug 23 22:20:03 2011 +0100
ARM: 7061/1: gic: convert logical CPU numbers into physical numbers
Quoted 8 lines
And this one in rmk/devel-stable:
commit 254056f3b12563c11e6dbcfad2fbfce20a4f3302
Author: Colin Cross <[email protected]>
Date:   Thu Feb 10 12:54:10 2011 -0800
ARM: gic: Use cpu pm notifiers to save gic state
Ok. Conflicts are not the problem though, I can handle them and sfr can handle them for linux-next, too. Real dependencies are the problem, where you rely on a feature that is part of another tree.
Quoted 6 lines
BTW, Russell's for-next branch has been rebased. The conflict with the 1st commit is trivial, so I could rebase to merge of rmk/devel-stable and v3.1-rc9.
I still need things from for-next for highbank. So perhaps I should send a pull request after Russell's tree goes in?
Yes and no. You simply cannot ask me to merge a branch that is based on top of Russell's for-next branch, since that is getting rebased. It is also bad if the stuff doesn't have any linux-next exposure, so we should try to find another way out.

Quoted 7 lines

I've now rebased your tree on top of 3.1-rc9 plus the stable branches from Russell's tree that I already have as dependencies in arm-soc/for-next (devel-stable, smp, debug). This has caused no conflicts for me, but that doesn't mean that it's correct. Please check that what I have in arm-soc/dt/gic and arm-soc/highbank/soc actually works for you and does not contain branches that you don't actually need.

dt/gic doesn't need Russell's debug branch, but highbank does.

highbank/soc doesn't build. It needs Russell's l2x0 and io branches. l2x0 has been rebased recently, but the io branch seems to be stable (but not published externally).

Rob

Russell King - ARM Linux

2011-10-20 18:56 UTC #12 lore raw

Quoted 3 lines · Rob Herring

highbank/soc doesn't build. It needs Russell's l2x0 and io branches. l2x0 has been rebased recently, but the io branch seems to be stable (but not published externally).

Actually, l2x0 _hasn't_. Let's be clear about what happened. A load of patches were all merged into the 'misc' branch over time, containing multiple different subjects. At the time they were merged there was no clear separate line of development of each sub-system, so they just ended up in a common branch without any particular ordering or grouping.

People wanted to base work on a select few of those commits. Rather than having the entire set of commits merged into various peoples trees, many of which have nothing to do with what they were working on, I split various commits out of the 'misc' branch and created a set of more fine-grained topic branches.

That is arguably not rebasing - it is re-committing, in such a way that those parts can then be frozen, stabilized and published without unintended dependencies. That's got to be a good thing.

Arnd Bergmann

2011-10-20 21:04 UTC #13 lore raw

Quoted 4 lines · On Thursday 20 October 2011 19:56:12 Russell King - ARM Linux wrote:

Quoted 3 lines · Rob Herring
highbank/soc doesn't build. It needs Russell's l2x0 and io branches. l2x0 has been rebased recently, but the io branch seems to be stable (but not published externally).

I've kept the dt/gic branch the way I had it now, I guess the extra branch in it doesn't hurt and removing it would cause extra work. I'll just have to wait until it's merged then.

The highbank/soc branch is now rebased on top of dt/gic+depends/rmk/io+depends/rmk/l2x0+depends/rmk/gpio.

I ended up having to add the gpio branch to the ones you mentioned to get it all to compile.

Quoted 13 lines

Actually, l2x0 _hasn't_. Let's be clear about what happened. A load of patches were all merged into the 'misc' branch over time, containing multiple different subjects. At the time they were merged there was no clear separate line of development of each sub-system, so they just ended up in a common branch without any particular ordering or grouping.
People wanted to base work on a select few of those commits. Rather than having the entire set of commits merged into various peoples trees, many of which have nothing to do with what they were working on, I split various commits out of the 'misc' branch and created a set of more fine-grained topic branches.

Quoted 3 lines

That is arguably not rebasing - it is re-committing, in such a way that those parts can then be frozen, stabilized and published without unintended dependencies. That's got to be a good thing.

Yes, this certainly sounds good to me. One can still call it rebasing, since you rebased the misc branch to create the l2x0 branch, but that was of course specifically done to make it possible to create a stable highbank tree, which is what Rob needs.

I'm not sure if I used the intended process to get at those branches. Since they are not published on ftp.arm.linux.org.uk as separate branches, I looked at the big merge changeset in the for-next branch and recreated the branches I needed, which feels like I'm doing something that wasn't your intention. Is there a better way?

Arnd

Russell King - ARM Linux

2011-10-21 18:33 UTC #14 lore raw

Quoted 5 lines · Arnd Bergmann

I'm not sure if I used the intended process to get at those branches. Since they are not published on ftp.arm.linux.org.uk as separate branches, I looked at the big merge changeset in the for-next branch and recreated the branches I needed, which feels like I'm doing something that wasn't your intention. Is there a better way?

The best way is to say "Hey, my work depends on X, Y, Z" and I'll see what can be done to make them stable _and_ say whether they are ripe for that yet (or, eg, whether they're waiting for peoples acks.)

It's actually what I documented a while ago at
http://www.arm.linux.org.uk/developer/git-arm.php

Arnd Bergmann

2011-10-21 19:31 UTC #15 lore raw

Quoted 7 lines · On Friday 21 October 2011 19:33:52 Russell King - ARM Linux wrote:

Quoted 5 lines · Arnd Bergmann
I'm not sure if I used the intended process to get at those branches. Since they are not published on ftp.arm.linux.org.uk as separate branches, I looked at the big merge changeset in the for-next branch and recreated the branches I needed, which feels like I'm doing something that wasn't your intention. Is there a better way?

Quoted 6 lines

The best way is to say "Hey, my work depends on X, Y, Z" and I'll see what can be done to make them stable and say whether they are ripe for that yet (or, eg, whether they're waiting for peoples acks.)
It's actually what I documented a while ago at
http://www.arm.linux.org.uk/developer/git-arm.php

Ok, that is a very useful documentation, but the part I still don't understand is how I should get the commit ID of the stable branches. I noticed that you are publishing an l2x0 branch now, in addition to the pm and smp branches that were already there the last time I looked, but you don't publish the gpio, io and debug branches that I have pulled into the arm-soc/next-soc branch because imx6 and highbank depend on them.

Does that mean you don't consider the latter three branches stable yet, or does it just mean they are stable but you had no reason to publish them?

Arnd

Russell King - ARM Linux

2011-10-21 22:25 UTC #16 lore raw

Quoted 2 lines · Arnd Bergmann

Ok, that is a very useful documentation, but the part I still don't understand is how I should get the commit ID of the stable branches.

I'll publish the branch itself.

Quoted 5 lines

I noticed that you are publishing an l2x0 branch now, in addition to the pm and smp branches that were already there the last time I looked, but you don't publish the gpio, io and debug branches that I have pulled into the arm-soc/next-soc branch because imx6 and highbank depend on them.

debug has been published for a while but not the other two. gpio can be done trivially, but (as I've already said) io has an additional commit on top which I'm not publishing yet. So I'd need to fudge stuff in some way to publish that one.

Given the time now, I'm not going to change my tree at this point, with very little time available before having to leave.

Rob Herring

author

2011-10-20 21:08 UTC #17 lore raw

In reply to Russell King - ARM Linux

Russell,

Quoted 18 lines · Russell King - ARM Linux

Quoted 3 lines · Rob Herring
highbank/soc doesn't build. It needs Russell's l2x0 and io branches. l2x0 has been rebased recently, but the io branch seems to be stable (but not published externally).
Actually, l2x0 _hasn't_. Let's be clear about what happened. A load of patches were all merged into the 'misc' branch over time, containing multiple different subjects. At the time they were merged there was no clear separate line of development of each sub-system, so they just ended up in a common branch without any particular ordering or grouping.
People wanted to base work on a select few of those commits. Rather than having the entire set of commits merged into various peoples trees, many of which have nothing to do with what they were working on, I split various commits out of the 'misc' branch and created a set of more fine-grained topic branches.

Quoted 3 lines

That is arguably not rebasing - it is re-committing, in such a way that those parts can then be frozen, stabilized and published without unintended dependencies. That's got to be a good thing.

Understood, but from a git perspective the commit ids have changed. While git can deal with trivial re-commits like this, my understanding is that should be avoided for upstream merges. Otherwise, I could just cherry-pick them and re-commit them in my tree.

Ultimately, the people working off of those branches do need them to be stable to merge their branches. So are you saying your l2x0 branch (91c2ebb90b1890abc648ba9dec5608cbc97e1cb9) is now stable? Can you publish it as a branch. iMX6Q is also dependent on it.

Rob

Russell King - ARM Linux

2011-10-20 21:15 UTC #18 lore raw

Quoted 4 lines · Rob Herring

Understood, but from a git perspective the commit ids have changed. While git can deal with trivial re-commits like this, my understanding is that should be avoided for upstream merges. Otherwise, I could just cherry-pick them and re-commit them in my tree.

It's precisely that need people feel to cherry-pick stuff which is the need to keep my tree 'unstable' so that I _can_ reorganize it to permit people to base work off it.

Quoted 4 lines

Ultimately, the people working off of those branches do need them to be stable to merge their branches. So are you saying your l2x0 branch (91c2ebb90b1890abc648ba9dec5608cbc97e1cb9) is now stable? Can you publish it as a branch. iMX6Q is also dependent on it.

Indeed I can - all it takes is someone to tell me what they require and I can sort it out - and this is especially so as I'm not planning to do anything further with my git tree after this evening (on the assumption that the merge window will open immediately after the kernel summit.)

I already have several 'stable' branches: pm, smp, debug, and now l2x0.

Arnd Bergmann

2011-10-20 21:17 UTC #19 lore raw

In reply to Rob Herring

Quoted 11 lines · On Thursday 20 October 2011 16:08:32 Rob Herring wrote:

Quoted 1 line
unintended dependencies. That's got to be a good thing.
Understood, but from a git perspective the commit ids have changed. While git can deal with trivial re-commits like this, my understanding is that should be avoided for upstream merges. Otherwise, I could just cherry-pick them and re-commit them in my tree.
Ultimately, the people working off of those branches do need them to be stable to merge their branches. So are you saying your l2x0 branch (91c2ebb90b1890abc648ba9dec5608cbc97e1cb9) is now stable? Can you publish it as a branch. iMX6Q is also dependent on it.

The point is that Russell's 'misc' branch is not stable, which helps a lot because it lets him commit stuff early for testing and then take it out again when it turns out to be buggy. The for-next branch in Russell's tree is not stable and gets recreated by pulling in the other branches. This is similar to what I do with the arm-soc for-next branch, which is the sum of the other next/* branches in arm-soc.

My understanding is that the other branches in Russell's tree are stable in the sense that they are never rebased, though it might happen that the entire branch does not get submitted if a problem gets found with the series. That of course implies that all other dependent trees cannot get submitted.

Arnd

Arnd Bergmann

2011-10-21 08:51 UTC #20 lore raw

In reply to Arnd Bergmann

Quoted 6 lines · On Thursday 20 October 2011 18:12:28 Arnd Bergmann wrote:

I've now rebased your tree on top of 3.1-rc9 plus the stable branches from Russell's tree that I already have as dependencies in arm-soc/for-next (devel-stable, smp, debug). This has caused no conflicts for me, but that doesn't mean that it's correct. Please check that what I have in arm-soc/dt/gic and arm-soc/highbank/soc actually works for you and does not contain branches that you don't actually need.

I needed this patch in the end:

8<-----
ARM: gic: fix build error with CONFIG_IRQ_DOMAIN disabled

In file included from arch/arm/mach-msm/timer.c:26:0:
asm/hardware/gic.h:42:50: warning: 'struct device_node' declared inside parameter list [enabled by default] asm/hardware/gic.h:42:50: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] asm/hardware/gic.h:58:20: error: field 'domain' has incomplete type

Signed-off-by Arnd Bergmann <[email protected]>

---
Ok to apply on top?

arch/arm/include/asm/hardware/gic.h +4 -0

index 1a776a1..a06c3ac 100644
@@ -35,6 +35,8 @@
 #ifndef __ASSEMBLY__
 #include <linux/irqdomain.h>
 
+struct device_node;
+
 extern void __iomem *gic_cpu_base_addr;
 extern struct irq_chip gic_arch_extn;

@@ -55,7 +57,9 @@ struct gic_chip_data {
 	u32 __percpu *saved_ppi_enable;
 	u32 __percpu *saved_ppi_conf;
 #endif
+#ifdef CONFIG_IRQ_DOMAIN
 	struct irq_domain domain;
+#endif
 	unsigned int gic_irqs;
 };
 #endif

Rob Herring

author

2011-10-21 20:09 UTC #21 lore raw

Quoted 13 lines · Arnd Bergmann

Quoted 6 lines · On Thursday 20 October 2011 18:12:28 Arnd Bergmann wrote:
I've now rebased your tree on top of 3.1-rc9 plus the stable branches from Russell's tree that I already have as dependencies in arm-soc/for-next (devel-stable, smp, debug). This has caused no conflicts for me, but that doesn't mean that it's correct. Please check that what I have in arm-soc/dt/gic and arm-soc/highbank/soc actually works for you and does not contain branches that you don't actually need.
I needed this patch in the end:
8<-----
ARM: gic: fix build error with CONFIG_IRQ_DOMAIN disabled

Quoted 8 lines

In file included from arch/arm/mach-msm/timer.c:26:0:
asm/hardware/gic.h:42:50: warning: 'struct device_node' declared inside parameter list [enabled by default] asm/hardware/gic.h:42:50: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] asm/hardware/gic.h:58:20: error: field 'domain' has incomplete type
Signed-off-by Arnd Bergmann <[email protected]>
---
Ok to apply on top?

Okay.

arch/arm/include/asm/hardware/gic.h line 39

Quoted 11 lines

arch/arm/include/asm/hardware/gic.h +2 -0

index 1a776a1..a06c3ac 100644
@@ -35,6 +35,8 @@
 #ifndef __ASSEMBLY__
 #include <linux/irqdomain.h>
 
+struct device_node;
+

You don't actually need this line.

Thanks,
Rob