* Re: [PATCH] powerpc: disable MSI using new interface if possible
From: Joe Perches @ 2011-03-10 0:28 UTC (permalink / raw)
To: michael; +Cc: Nishanth Aravamudan, linuxppc-dev, Florian Mickler
In-Reply-To: <1299712336.6272.22.camel@concordia>
On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
> True my last patch may have been two years ago, but I _wrote the entire
> file_, and essentially no one else has ever touched it.
>
> > $ ./scripts/get_maintainer.pl -f arch/powerpc/platforms/pseries/msi.c
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> (supporter:LINUX FOR POWERPC...)
> > Paul Mackerras <paulus@samba.org> (supporter:LINUX FOR POWERPC...)
> > Grant Likely <grant.likely@secretlab.ca> (maintainer:OPEN FIRMWARE AND...)
> > linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
> > linux-kernel@vger.kernel.org (open list)
> > devicetree-discuss@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)
> >
> > If you don't like how it currently works, suggest
> > improvements.
>
> I think I was suggesting that I should be in that list :)
$ ./scripts/get_maintainer.pl -f --git-blame arch/powerpc/platforms/pseries/msi.c
Benjamin Herrenschmidt <benh@kernel.crashing.org> (supporter:LINUX FOR POWERPC...,commits:8/11=73%)
Paul Mackerras <paulus@samba.org> (supporter:LINUX FOR POWERPC...,commits:4/11=36%)
Grant Likely <grant.likely@secretlab.ca> (maintainer:OPEN FIRMWARE AND...)
Michael Ellerman <michael@ellerman.id.au> (authored lines:481/481=100%,commits:11/11=100%)
Linas Vepstas <linas@austin.ibm.com> (commits:1/11=9%)
linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
linux-kernel@vger.kernel.org (open list)
devicetree-discuss@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)
cheers, Joe
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-03-09 23:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a pair of regression fixes for 2.6.38. One fixes a 2.6.37
regression (I'll send it to -stable separately) that breaks booting on
legacy iSeries, and the other one disables a newly introduced features
as it triggers nasty races in the scheduler that causes hangs and seem
to be too much to fix for this release (working with PeterZ on it).
Cheers,
Ben.
The following changes since commit a5abba989deceb731047425812d268daf7536575:
Linux 2.6.38-rc8 (2011-03-07 21:09:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (2):
powerpc/iseries: Fix early init access to lppaca
powerpc/pseries: Disable VPNH feature
arch/powerpc/include/asm/lppaca.h | 16 ++++++++++++++++
arch/powerpc/kernel/paca.c | 14 --------------
arch/powerpc/mm/numa.c | 3 ++-
arch/powerpc/platforms/iseries/dt.c | 6 +++---
arch/powerpc/platforms/iseries/setup.c | 1 +
5 files changed, 22 insertions(+), 18 deletions(-)
^ permalink raw reply
* Re: [PATCH] powerpc: disable MSI using new interface if possible
From: Michael Ellerman @ 2011-03-09 23:12 UTC (permalink / raw)
To: Joe Perches; +Cc: Nishanth Aravamudan, linuxppc-dev, Florian Mickler
In-Reply-To: <1299209359.4338.220.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]
On Thu, 2011-03-03 at 19:29 -0800, Joe Perches wrote:
> On Fri, 2011-03-04 at 14:06 +1100, Michael Ellerman wrote:
> > On Thu, 2011-03-03 at 17:41 -0800, Nishanth Aravamudan wrote:
> > > On 04.03.2011 [12:05:29 +1100], Michael Ellerman wrote:
> > > > Cc: Me :)
> > > Sorry! I was in a hurry to get this out the door, my fault. Note, you
> > > don't show up per scripts/get_maintainer.pl :)
> > No worries, though I will remember never to use get_maintainer.pl, it is
> > obviously utterly broken:
>
> Blah, blah, stupid tool doesn't work exactly as I want,
> and it doesn't credit me for my over 2 year old patches,
> therefore it's not only stupid, it's broken...
I do not give two shits about being given "credit" for this horrible
code, but if someone changes it I may have input.
True my last patch may have been two years ago, but I _wrote the entire
file_, and essentially no one else has ever touched it.
> $ ./scripts/get_maintainer.pl -f arch/powerpc/platforms/pseries/msi.c
> Benjamin Herrenschmidt <benh@kernel.crashing.org> (supporter:LINUX FOR POWERPC...)
> Paul Mackerras <paulus@samba.org> (supporter:LINUX FOR POWERPC...)
> Grant Likely <grant.likely@secretlab.ca> (maintainer:OPEN FIRMWARE AND...)
> linuxppc-dev@lists.ozlabs.org (open list:LINUX FOR POWERPC...)
> linux-kernel@vger.kernel.org (open list)
> devicetree-discuss@lists.ozlabs.org (open list:OPEN FIRMWARE AND...)
>
> If you don't like how it currently works, suggest
> improvements.
I think I was suggesting that I should be in that list :)
In the life of this file there have been 553 lines changed (added or
deleted), of which I have written 551, and I signed off the other 2.
So I guess I'm suggesting that when someone has written a large number
of the changes to a file they should be CC'ed. I don't know what the cut
off for "large number" should be, but anything > 50% would seem
reasonable (in terms of lines, not commits).
> How nice for you. Last patch from you was 2 years ago.
Last patch from _anyone_ was 2 years ago. As much as I may have tried to
banish that code from my mind I can still remember some of the details,
even after 2 years :)
> CC'ing inactive non named maintainers via git
> history also draws complaints btw.
Yeah I can imagine. But that is a case of someone who is no longer
interested getting one extra email, ie. a false positive, whereas in
this case it's someone who does care _not_ seeing the patch, ie. a false
negative.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: Disable VPNH feature
From: Benjamin Herrenschmidt @ 2011-03-09 23:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jesse Larrew
In-Reply-To: <1299711614.22236.392.camel@pasglop>
On Thu, 2011-03-10 at 10:00 +1100, Benjamin Herrenschmidt wrote:
> This feature triggers nasty races in the scheduler between the
> rebuilding of the topology and the load balancing code, causing
> the machine to hang.
>
> Disable it for now until the races are fixed.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Jesse: I'm sending that to Linus now. We'll sort things out for the
> next release.
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index fd48123..74f1baa 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1516,6 +1516,7 @@ int start_topology_update(void)
> {
> int rc = 0;
>
> +#if 0 /* Disabled until races with load balancing are fixed */
> if (firmware_has_feature(FW_FEATURE_VPHN) &&
> get_lppaca()->shared_proc) {
> vphn_enabled = 1;
> @@ -1524,6 +1525,7 @@ int start_topology_update(void)
> set_topology_timer();
> rc = 1;
> }
> +#endif
Turning that into if (0 && instead to avoid compiler warnings
and thus build failures
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/pseries: Disable VPNH feature
From: Benjamin Herrenschmidt @ 2011-03-09 23:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jesse Larrew
This feature triggers nasty races in the scheduler between the
rebuilding of the topology and the load balancing code, causing
the machine to hang.
Disable it for now until the races are fixed.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Jesse: I'm sending that to Linus now. We'll sort things out for the
next release.
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index fd48123..74f1baa 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1516,6 +1516,7 @@ int start_topology_update(void)
{
int rc = 0;
+#if 0 /* Disabled until races with load balancing are fixed */
if (firmware_has_feature(FW_FEATURE_VPHN) &&
get_lppaca()->shared_proc) {
vphn_enabled = 1;
@@ -1524,6 +1525,7 @@ int start_topology_update(void)
set_topology_timer();
rc = 1;
}
+#endif
return rc;
}
^ permalink raw reply related
* Re: [PATCH] powerpc: disable MSI using new interface if possible
From: Michael Ellerman @ 2011-03-09 22:54 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <20110308053413.GA26971@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
On Mon, 2011-03-07 at 21:34 -0800, Nishanth Aravamudan wrote:
> On 03.03.2011 [23:24:44 -0800], Nishanth Aravamudan wrote:
> > On 04.03.2011 [14:01:24 +1100], Michael Ellerman wrote:
> > > Looking closer at your patch, now I don't understand :)
> > >
> > > + /*
> > > + * disabling MSI with the explicit interface also disables MSI-X
> > > + */
> > > + if (rtas_change_msi(pdn, RTAS_CHANGE_MSI_FN, 0) != 0) {
> > >
> > >
> > > So we first disable using function 3, which should:
> > >
> > > 3: Request to set to a new number of MSI interrupts (including set to 0)
> > >
> > > Which does not mention MSI-X at all, implying it has no effect on them.
> > > Which contradicts what you see, and the comment in the code?
> >
> > Thanks for the thorough review!
> >
> > Per PAPR 2.4 from Power.org, look at the page before that table, page
> > 169:
> >
> > "Specifying Function 3 (MSI) also disables MSI-X for the specified IOA
> > function, and likewise specifying Function 4 (MSI-X) disables MSI for
> > the IOA function....Specifying the Requested Number of Interrupts to
> > zero for either Function 3 or 4 removes all MSI & MSI-X interrupts from
> > the IOA function."
> >
> > So I'm relying on this aspect of PAPR being enforced by the firmware,
> > which I think it is in my testing.
>
> Given all that, do I have your Ack? :)
Indeed. Thanks for clarifying it.
Acked-by: Michael Ellerman <michael@ellerman.id.au>
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [5200B/slightly ot] MPC52xx LPB FIFO memory requirements
From: Albrecht Dreß @ 2011-03-09 20:45 UTC (permalink / raw)
To: Linux PPC Development
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
Hi all,
I have a slightly off-topic question regarding the use of mpc52xx_lpbfifo_submit() & friends...
In struct mpc52xx_lpbfifo_request, the element 'data' (with address 'data_phys') is apparently the chunk of data which is transferred through bestcomm, right? Dumb question: has this chunk of memory to be DMA mem (i.e. allocated via dma_alloc_coherent), or is "normal" kernel memory (kmalloc) sufficient?
Thanks,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Steven Rostedt @ 2011-03-09 15:26 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Martin Schwidefsky, linuxppc-dev, linux-kernel@vger.kernel.org,
Jesse Larrew
In-Reply-To: <1299670429.2308.2834.camel@twins>
On Wed, Mar 09, 2011 at 12:33:49PM +0100, Peter Zijlstra wrote:
>
> That is of course aside from the fact that we have a real bug there that
> needs fixing, but really guys, WTF!
They just wanted to give you a very nice reproducer for that bug ;)
-- Steve
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Américo Wang @ 2011-03-09 14:21 UTC (permalink / raw)
To: Anton Blanchard
Cc: Mahesh Jagannath Salgaonkar, kexec, linux-kernel, linuxppc-dev,
Eric W. Biederman, Américo Wang, akpm
In-Reply-To: <20110309234657.264d3080@kryten>
On Wed, Mar 09, 2011 at 11:46:57PM +1100, Anton Blanchard wrote:
>
>Hi,
>
>> The crashkernel region is specified via kernel cmdline, so why
>> not just drop a failure when it overlaps with RMO region?
>> Am I missing something?
>
>Unfortunately a ppc64 kernel requires a chunk of RMO memory. We would
>need the ability to specify multiple crashkernel regions - about 32MB
>in the RMO and the rest can be anywhere. That sounds pretty fragile for
>a user to configure successfully on the cmdline.
>
>Thats why the ppc64 crashkernel region begins mid way through the RMO
>region. It means both kernels get a chunk of RMO and we only have to
>deal with one crashkernel reservation in all the tools and
>documentation.
>
So, when I specify 128M in cmdline, 32M of them are RMO, and the
rest 96M are normal memory? And when I want to free all of them,
actually the 32M RMO will never be freed?
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
From: Stephen Wilson @ 2011-03-09 14:14 UTC (permalink / raw)
To: Michel Lespinasse
Cc: linux-s390, Andi Kleen, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, H. Peter Anvin, Martin Schwidefsky, linux390,
Thomas Gleixner, linuxppc-dev, Andrew Morton
In-Reply-To: <AANLkTikTEi8uKeCfPLoenNx9g6fLyAqNqfVdR=4KzNB3@mail.gmail.com>
On Wed, Mar 09, 2011 at 05:09:09AM -0800, Michel Lespinasse wrote:
> On Tue, Mar 8, 2011 at 4:31 PM, Stephen Wilson <wilsons@start.ca> wrote:
> > Morally, the question of whether an address lies in a gate vma should be asked
> > with respect to an mm, not a particular task.
> >
> > Practically, dropping the dependency on task_struct will help make current and
> > future operations on mm's more flexible and convenient. In particular, it
> > allows some code paths to avoid the need to hold task_lock.
>
> Reviewed-by: Michel Lespinasse <walken@google.com>
>
> May I suggest ia32_compat instead of just compat for the flag name ?
Yes, sounds good to me. Will change in the next iteration.
Thanks for the review!
> --
> Michel "Walken" Lespinasse
> A program is never fully debugged until the last user dies.
--
steve
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 13:54 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <20110309144636.3f0899d1@mschwide.boeblingen.de.ibm.com>
On Wed, 2011-03-09 at 14:46 +0100, Martin Schwidefsky wrote:
> On Wed, 09 Mar 2011 14:33:56 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> > On Wed, 2011-03-09 at 14:31 +0100, Martin Schwidefsky wrote:
> > > > But if you don't also update the cpu->node memory mappings (which I
> > > > think it near impossible) what good is it to change the scheduler
> > > > topology?
> > >=20
> > > The memory for the different LPARs is striped over all nodes (or book=
s as we
> > > call them). We heavily rely on the large shared cache between the boo=
ks to hide
> > > the different memory access latencies.=20
> >=20
> > Right, so effectively you don't have NUMA due to that striping. So why
> > then change the CPU topology? Simply create a topology without NUMA and
> > keep it static, that accurately reflects the memory topology.
>=20
> Well the CPU topology can change due to different grouping of logical CPU=
s
> dependent on which LPARs are activated. And we effectively do not have a
> memory topology, only CPU. Its basically all about caches, we want to
> reflect the distance between CPUs over the up to 4 cache levels.
Right, so I consider caches to be part of the memory topology, anyway,
if this all is very rare then yeah, that works out.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Martin Schwidefsky @ 2011-03-09 13:46 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <1299677636.2308.2960.camel@twins>
On Wed, 09 Mar 2011 14:33:56 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2011-03-09 at 14:31 +0100, Martin Schwidefsky wrote:
> > > But if you don't also update the cpu->node memory mappings (which I
> > > think it near impossible) what good is it to change the scheduler
> > > topology?
> >
> > The memory for the different LPARs is striped over all nodes (or books as we
> > call them). We heavily rely on the large shared cache between the books to hide
> > the different memory access latencies.
>
> Right, so effectively you don't have NUMA due to that striping. So why
> then change the CPU topology? Simply create a topology without NUMA and
> keep it static, that accurately reflects the memory topology.
Well the CPU topology can change due to different grouping of logical CPUs
dependent on which LPARs are activated. And we effectively do not have a
memory topology, only CPU. Its basically all about caches, we want to
reflect the distance between CPUs over the up to 4 cache levels.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 13:33 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <20110309143152.3cc6c191@mschwide.boeblingen.de.ibm.com>
On Wed, 2011-03-09 at 14:31 +0100, Martin Schwidefsky wrote:
> > But if you don't also update the cpu->node memory mappings (which I
> > think it near impossible) what good is it to change the scheduler
> > topology?
>=20
> The memory for the different LPARs is striped over all nodes (or books as=
we
> call them). We heavily rely on the large shared cache between the books t=
o hide
> the different memory access latencies.=20
Right, so effectively you don't have NUMA due to that striping. So why
then change the CPU topology? Simply create a topology without NUMA and
keep it static, that accurately reflects the memory topology.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Martin Schwidefsky @ 2011-03-09 13:31 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <1299676769.2308.2944.camel@twins>
On Wed, 09 Mar 2011 14:19:29 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2011-03-09 at 14:15 +0100, Martin Schwidefsky wrote:
> > On Wed, 09 Mar 2011 12:33:49 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > > On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > > > > It appears that this corresponds to one CPU deciding to rebuild the
> > > > > sched domains. There's various reasons why that can happen, the typical
> > > > > one in our case is the new VPNH feature where the hypervisor informs us
> > > > > of a change in node affinity of our virtual processors. s390 has a
> > > > > similar feature and should be affected as well.
> > > >
> > > > Ahh, so that's triggering it :-), just curious, how often does the HV do
> > > > that to you?
> > >
> > > OK, so Ben told me on IRC this can happen quite frequently, to which I
> > > must ask WTF were you guys smoking? Flipping the CPU topology every time
> > > the HV scheduler does something funny is quite insane. And you did that
> > > without ever talking to the scheduler folks, not cool.
> > >
> > > That is of course aside from the fact that we have a real bug there that
> > > needs fixing, but really guys, WTF!
> >
> > Just for info, on s390 the topology change events are rather infrequent.
> > They do happen e.g. after an LPAR has been activated and the LPAR
> > hypervisor needs to reshuffle the CPUs of the different nodes.
>
> But if you don't also update the cpu->node memory mappings (which I
> think it near impossible) what good is it to change the scheduler
> topology?
The memory for the different LPARs is striped over all nodes (or books as we
call them). We heavily rely on the large shared cache between the books to hide
the different memory access latencies.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 13:19 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <20110309141548.722e4f56@mschwide.boeblingen.de.ibm.com>
On Wed, 2011-03-09 at 14:15 +0100, Martin Schwidefsky wrote:
> On Wed, 09 Mar 2011 12:33:49 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> > On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > > > It appears that this corresponds to one CPU deciding to rebuild the
> > > > sched domains. There's various reasons why that can happen, the typ=
ical
> > > > one in our case is the new VPNH feature where the hypervisor inform=
s us
> > > > of a change in node affinity of our virtual processors. s390 has a
> > > > similar feature and should be affected as well.
> > >=20
> > > Ahh, so that's triggering it :-), just curious, how often does the HV=
do
> > > that to you?=20
> >=20
> > OK, so Ben told me on IRC this can happen quite frequently, to which I
> > must ask WTF were you guys smoking? Flipping the CPU topology every tim=
e
> > the HV scheduler does something funny is quite insane. And you did that
> > without ever talking to the scheduler folks, not cool.
> >=20
> > That is of course aside from the fact that we have a real bug there tha=
t
> > needs fixing, but really guys, WTF!
>=20
> Just for info, on s390 the topology change events are rather infrequent.
> They do happen e.g. after an LPAR has been activated and the LPAR
> hypervisor needs to reshuffle the CPUs of the different nodes.
But if you don't also update the cpu->node memory mappings (which I
think it near impossible) what good is it to change the scheduler
topology?
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Martin Schwidefsky @ 2011-03-09 13:15 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Jesse Larrew
In-Reply-To: <1299670429.2308.2834.camel@twins>
On Wed, 09 Mar 2011 12:33:49 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > > It appears that this corresponds to one CPU deciding to rebuild the
> > > sched domains. There's various reasons why that can happen, the typical
> > > one in our case is the new VPNH feature where the hypervisor informs us
> > > of a change in node affinity of our virtual processors. s390 has a
> > > similar feature and should be affected as well.
> >
> > Ahh, so that's triggering it :-), just curious, how often does the HV do
> > that to you?
>
> OK, so Ben told me on IRC this can happen quite frequently, to which I
> must ask WTF were you guys smoking? Flipping the CPU topology every time
> the HV scheduler does something funny is quite insane. And you did that
> without ever talking to the scheduler folks, not cool.
>
> That is of course aside from the fact that we have a real bug there that
> needs fixing, but really guys, WTF!
Just for info, on s390 the topology change events are rather infrequent.
They do happen e.g. after an LPAR has been activated and the LPAR
hypervisor needs to reshuffle the CPUs of the different nodes.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
From: Michel Lespinasse @ 2011-03-09 13:09 UTC (permalink / raw)
To: Stephen Wilson
Cc: linux-s390, Andi Kleen, Paul Mundt, linux-sh, x86, Heiko Carstens,
linux-kernel, linux-mm, Ingo Molnar, Paul Mackerras,
Alexander Viro, H. Peter Anvin, Martin Schwidefsky, linux390,
Thomas Gleixner, linuxppc-dev, Andrew Morton
In-Reply-To: <1299630721-4337-1-git-send-email-wilsons@start.ca>
On Tue, Mar 8, 2011 at 4:31 PM, Stephen Wilson <wilsons@start.ca> wrote:
> Morally, the question of whether an address lies in a gate vma should be =
asked
> with respect to an mm, not a particular task.
>
> Practically, dropping the dependency on task_struct will help make curren=
t and
> future operations on mm's more flexible and convenient. =A0In particular,=
it
> allows some code paths to avoid the need to hold task_lock.
Reviewed-by: Michel Lespinasse <walken@google.com>
May I suggest ia32_compat instead of just compat for the flag name ?
--=20
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 13:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Martin Schwidefsky, linuxppc-dev, linux-kernel@vger.kernel.org,
Jesse Larrew
In-Reply-To: <1299665998.2308.2753.camel@twins>
On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> No, the domain stuff is good, we allocate new domains and have a
> synchronize_sched() between us installing the new ones and freeing the
> old ones.=20
Gah, if only..
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Anton Blanchard @ 2011-03-09 12:46 UTC (permalink / raw)
To: Américo Wang
Cc: Mahesh Jagannath Salgaonkar, kexec, linux-kernel, linuxppc-dev,
Eric W. Biederman, akpm
In-Reply-To: <20110309122046.GC16951@cr0.redhat.com>
Hi,
> The crashkernel region is specified via kernel cmdline, so why
> not just drop a failure when it overlaps with RMO region?
> Am I missing something?
Unfortunately a ppc64 kernel requires a chunk of RMO memory. We would
need the ability to specify multiple crashkernel regions - about 32MB
in the RMO and the rest can be anywhere. That sounds pretty fragile for
a user to configure successfully on the cmdline.
Thats why the ppc64 crashkernel region begins mid way through the RMO
region. It means both kernels get a chunk of RMO and we only have to
deal with one crashkernel reservation in all the tools and
documentation.
Anton
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Américo Wang @ 2011-03-09 12:20 UTC (permalink / raw)
To: Mahesh Jagannath Salgaonkar
Cc: kexec, linux-kernel, linuxppc-dev, Eric W. Biederman, akpm,
Anton Blanchard
In-Reply-To: <4D771EE6.5050404@linux.vnet.ibm.com>
On Wed, Mar 09, 2011 at 12:02:06PM +0530, Mahesh Jagannath Salgaonkar wrote:
>On 08/25/2010 06:07 AM, Eric W. Biederman wrote:
>> Anton Blanchard <anton@samba.org> writes:
>>
>>> On ppc64 the crashkernel region almost always overlaps an area of firmware.
>>> This works fine except when using the sysfs interface to reduce the kdump
>>> region. If we free the firmware area we are guaranteed to crash.
>>
>> That is ppc64 bug. firmware should not be in the reserved region. Any
>> random kernel like thing can be put in to that region at any valid
>> address and the fact that shrinking the region frees your firmware means
>> that using that region could also stomp your firmware (which I assume
>> would be a bad thing).
>The issue only happens while shrinking the region using sysfs interface.
>We already have checks in kexec for not to stomp over on the firmware
>overlap area while loading capture kernel. Currently we do a top-down
>allocation for the firmware region which means it sits at the top of the
>RMO, right in the middle of the crashdump region. We can not move the
>crashkernel region beyond firmware region because kernel needs its some
>of memory in RMO region.
The crashkernel region is specified via kernel cmdline, so why
not just drop a failure when it overlaps with RMO region?
Am I missing something?
Thanks.
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 11:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Martin Schwidefsky, linuxppc-dev, linux-kernel@vger.kernel.org,
Jesse Larrew
In-Reply-To: <1299665998.2308.2753.camel@twins>
On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > It appears that this corresponds to one CPU deciding to rebuild the
> > sched domains. There's various reasons why that can happen, the typical
> > one in our case is the new VPNH feature where the hypervisor informs us
> > of a change in node affinity of our virtual processors. s390 has a
> > similar feature and should be affected as well.
>=20
> Ahh, so that's triggering it :-), just curious, how often does the HV do
> that to you?=20
OK, so Ben told me on IRC this can happen quite frequently, to which I
must ask WTF were you guys smoking? Flipping the CPU topology every time
the HV scheduler does something funny is quite insane. And you did that
without ever talking to the scheduler folks, not cool.
That is of course aside from the fact that we have a real bug there that
needs fixing, but really guys, WTF!
^ permalink raw reply
* Re: [BUG] rebuild_sched_domains considered dangerous
From: Peter Zijlstra @ 2011-03-09 10:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Martin Schwidefsky, linuxppc-dev, linux-kernel@vger.kernel.org,
Jesse Larrew
In-Reply-To: <1299639487.22236.256.camel@pasglop>
On Wed, 2011-03-09 at 13:58 +1100, Benjamin Herrenschmidt wrote:
> So I've been experiencing hangs shortly after boot with recent kernels
> on a Power7 machine. I was testing with PREEMPT & HZ=3D1024 which might
> increase the frequency of the problem but I don't think they are
> necessary to expose it.
>=20
> From what I've figured out, when the machine hangs, it's essentially
> looping forever in update_sd_lb_stats(), due to a corrupted sd->groups
> list (in my cases, the list contains a loop that doesn't loop back
> the the first element).
>=20
> It appears that this corresponds to one CPU deciding to rebuild the
> sched domains. There's various reasons why that can happen, the typical
> one in our case is the new VPNH feature where the hypervisor informs us
> of a change in node affinity of our virtual processors. s390 has a
> similar feature and should be affected as well.
Ahh, so that's triggering it :-), just curious, how often does the HV do
that to you?
> I suspect the problem could be reproduced on x86 by hammering the sysfs
> file that can be used to trigger a rebuild as well on a sufficently
> large machine.
Should, yeah, regular hotplug is racy too.
> From what I can tell, there's some missing locking here between
> rebuilding the domains and find_busiest_group.=20
init_sched_build_groups() races against pretty much all sched_group
iterations, like the one in update_sd_lb_stats() which is the most
common one and the one you're getting stuck in.
> I haven't quite got my
> head around how that -should- be done, though, as I an really not very
> familiar with that code.=20
:-)
> For example, I don't quite get when domains are
> attached to an rq, and whether code like build_numa_sched_groups() which
> allocates groups and attach them to sched domains sd->groups does it on
> a "live" domain or not (in that case, there's a problem since it kmalloc
> and attaches the uninitialized result immediately).
No, the domain stuff is good, we allocate new domains and have a
synchronize_sched() between us installing the new ones and freeing the
old ones.
But the sched_group list is as said rather icky.
> I don't believe I understand enough of the scheduler to fix that quickly
> and I'm really bogged down with some other urgent stuff, so I would very
> much appreciate if you could provide some assistance here, even if it's
> just in the form of suggestions/hints.
Yeah, sched_group rebuild is racy as hell, I haven't really managed to
come up with a sane fix yet, will poke at it.
^ permalink raw reply
* [PATCH v2 26/28] powerpc: sysdev/xilinx_intc irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110308000018.GE16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/sysdev/xilinx_intc.c | 48 +++++++++++++++++++-----------------
1 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
index 1e0ccfa..7436f3e 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -69,17 +69,17 @@ static unsigned char xilinx_intc_map_senses[] = {
*
* IRQ Chip common (across level and edge) operations
*/
-static void xilinx_intc_mask(unsigned int virq)
+static void xilinx_intc_mask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void * regs = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void * regs = irq_data_get_irq_chip_data(d);
pr_debug("mask: %d\n", irq);
out_be32(regs + XINTC_CIE, 1 << irq);
}
-static int xilinx_intc_set_type(unsigned int virq, unsigned int flow_type)
+static int xilinx_intc_set_type(struct irq_data *d, unsigned int flow_type)
{
- struct irq_desc *desc = irq_to_desc(virq);
+ struct irq_desc *desc = irq_to_desc(d->irq);
desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
@@ -91,10 +91,10 @@ static int xilinx_intc_set_type(unsigned int virq, unsigned int flow_type)
/*
* IRQ Chip level operations
*/
-static void xilinx_intc_level_unmask(unsigned int virq)
+static void xilinx_intc_level_unmask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void * regs = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void * regs = irq_data_get_irq_chip_data(d);
pr_debug("unmask: %d\n", irq);
out_be32(regs + XINTC_SIE, 1 << irq);
@@ -107,37 +107,37 @@ static void xilinx_intc_level_unmask(unsigned int virq)
static struct irq_chip xilinx_intc_level_irqchip = {
.name = "Xilinx Level INTC",
- .mask = xilinx_intc_mask,
- .mask_ack = xilinx_intc_mask,
- .unmask = xilinx_intc_level_unmask,
- .set_type = xilinx_intc_set_type,
+ .irq_mask = xilinx_intc_mask,
+ .irq_mask_ack = xilinx_intc_mask,
+ .irq_unmask = xilinx_intc_level_unmask,
+ .irq_set_type = xilinx_intc_set_type,
};
/*
* IRQ Chip edge operations
*/
-static void xilinx_intc_edge_unmask(unsigned int virq)
+static void xilinx_intc_edge_unmask(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void *regs = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void *regs = irq_data_get_irq_chip_data(d);
pr_debug("unmask: %d\n", irq);
out_be32(regs + XINTC_SIE, 1 << irq);
}
-static void xilinx_intc_edge_ack(unsigned int virq)
+static void xilinx_intc_edge_ack(struct irq_data *d)
{
- int irq = virq_to_hw(virq);
- void * regs = get_irq_chip_data(virq);
+ int irq = virq_to_hw(d->irq);
+ void * regs = irq_data_get_irq_chip_data(d);
pr_debug("ack: %d\n", irq);
out_be32(regs + XINTC_IAR, 1 << irq);
}
static struct irq_chip xilinx_intc_edge_irqchip = {
.name = "Xilinx Edge INTC",
- .mask = xilinx_intc_mask,
- .unmask = xilinx_intc_edge_unmask,
- .ack = xilinx_intc_edge_ack,
- .set_type = xilinx_intc_set_type,
+ .irq_mask = xilinx_intc_mask,
+ .irq_unmask = xilinx_intc_edge_unmask,
+ .irq_ack = xilinx_intc_edge_ack,
+ .irq_set_type = xilinx_intc_set_type,
};
/*
@@ -229,12 +229,14 @@ int xilinx_intc_get_irq(void)
*/
static void xilinx_i8259_cascade(unsigned int irq, struct irq_desc *desc)
{
+ struct irq_chip *chip = get_irq_desc_chip(desc);
unsigned int cascade_irq = i8259_irq();
+
if (cascade_irq)
generic_handle_irq(cascade_irq);
/* Let xilinx_intc end the interrupt */
- desc->chip->unmask(irq);
+ chip->irq_unmask(&desc->irq_data);
}
static void __init xilinx_i8259_setup_cascade(void)
--
1.7.4
^ permalink raw reply related
* [PATCH v2 25/28] powerpc: sysdev/uic irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110308000015.GD16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/sysdev/uic.c | 59 +++++++++++++++++++++++----------------------
1 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 0038fb7..835f795 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -55,11 +55,11 @@ struct uic {
struct irq_host *irqhost;
};
-static void uic_unmask_irq(unsigned int virq)
+static void uic_unmask_irq(struct irq_data *d)
{
- struct irq_desc *desc = irq_to_desc(virq);
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
+ struct irq_desc *desc = irq_to_desc(d->irq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
unsigned long flags;
u32 er, sr;
@@ -74,10 +74,10 @@ static void uic_unmask_irq(unsigned int virq)
spin_unlock_irqrestore(&uic->lock, flags);
}
-static void uic_mask_irq(unsigned int virq)
+static void uic_mask_irq(struct irq_data *d)
{
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
unsigned long flags;
u32 er;
@@ -88,10 +88,10 @@ static void uic_mask_irq(unsigned int virq)
spin_unlock_irqrestore(&uic->lock, flags);
}
-static void uic_ack_irq(unsigned int virq)
+static void uic_ack_irq(struct irq_data *d)
{
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
unsigned long flags;
spin_lock_irqsave(&uic->lock, flags);
@@ -99,11 +99,11 @@ static void uic_ack_irq(unsigned int virq)
spin_unlock_irqrestore(&uic->lock, flags);
}
-static void uic_mask_ack_irq(unsigned int virq)
+static void uic_mask_ack_irq(struct irq_data *d)
{
- struct irq_desc *desc = irq_to_desc(virq);
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
+ struct irq_desc *desc = irq_to_desc(d->irq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
unsigned long flags;
u32 er, sr;
@@ -125,18 +125,18 @@ static void uic_mask_ack_irq(unsigned int virq)
spin_unlock_irqrestore(&uic->lock, flags);
}
-static int uic_set_irq_type(unsigned int virq, unsigned int flow_type)
+static int uic_set_irq_type(struct irq_data *d, unsigned int flow_type)
{
- struct uic *uic = get_irq_chip_data(virq);
- unsigned int src = uic_irq_to_hw(virq);
- struct irq_desc *desc = irq_to_desc(virq);
+ struct uic *uic = irq_data_get_irq_chip_data(d);
+ unsigned int src = uic_irq_to_hw(d->irq);
+ struct irq_desc *desc = irq_to_desc(d->irq);
unsigned long flags;
int trigger, polarity;
u32 tr, pr, mask;
switch (flow_type & IRQ_TYPE_SENSE_MASK) {
case IRQ_TYPE_NONE:
- uic_mask_irq(virq);
+ uic_mask_irq(d);
return 0;
case IRQ_TYPE_EDGE_RISING:
@@ -178,11 +178,11 @@ static int uic_set_irq_type(unsigned int virq, unsigned int flow_type)
static struct irq_chip uic_irq_chip = {
.name = "UIC",
- .unmask = uic_unmask_irq,
- .mask = uic_mask_irq,
- .mask_ack = uic_mask_ack_irq,
- .ack = uic_ack_irq,
- .set_type = uic_set_irq_type,
+ .irq_unmask = uic_unmask_irq,
+ .irq_mask = uic_mask_irq,
+ .irq_mask_ack = uic_mask_ack_irq,
+ .irq_ack = uic_ack_irq,
+ .irq_set_type = uic_set_irq_type,
};
static int uic_host_map(struct irq_host *h, unsigned int virq,
@@ -220,6 +220,7 @@ static struct irq_host_ops uic_host_ops = {
void uic_irq_cascade(unsigned int virq, struct irq_desc *desc)
{
+ struct irq_chip *chip = get_irq_desc_chip(desc);
struct uic *uic = get_irq_data(virq);
u32 msr;
int src;
@@ -227,9 +228,9 @@ void uic_irq_cascade(unsigned int virq, struct irq_desc *desc)
raw_spin_lock(&desc->lock);
if (desc->status & IRQ_LEVEL)
- desc->chip->mask(virq);
+ chip->irq_mask(&desc->irq_data);
else
- desc->chip->mask_ack(virq);
+ chip->irq_mask_ack(&desc->irq_data);
raw_spin_unlock(&desc->lock);
msr = mfdcr(uic->dcrbase + UIC_MSR);
@@ -244,9 +245,9 @@ void uic_irq_cascade(unsigned int virq, struct irq_desc *desc)
uic_irq_ret:
raw_spin_lock(&desc->lock);
if (desc->status & IRQ_LEVEL)
- desc->chip->ack(virq);
- if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
- desc->chip->unmask(virq);
+ chip->irq_ack(&desc->irq_data);
+ if (!(desc->status & IRQ_DISABLED) && chip->irq_unmask)
+ chip->irq_unmask(&desc->irq_data);
raw_spin_unlock(&desc->lock);
}
--
1.7.4
^ permalink raw reply related
* [PATCH v2 23/28] powerpc: sysdev/qe_lib/qe_ic irq_data conversion.
From: Lennert Buytenhek @ 2011-03-09 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <20110308000010.GB16649@mail.wantstofly.org>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/include/asm/qe_ic.h | 19 +++++++++++--------
arch/powerpc/sysdev/qe_lib/qe_ic.c | 25 +++++++++++++++----------
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/qe_ic.h b/arch/powerpc/include/asm/qe_ic.h
index cf51966..9e2cb20 100644
--- a/arch/powerpc/include/asm/qe_ic.h
+++ b/arch/powerpc/include/asm/qe_ic.h
@@ -81,7 +81,7 @@ int qe_ic_set_high_priority(unsigned int virq, unsigned int priority, int high);
static inline void qe_ic_cascade_low_ipic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
if (cascade_irq != NO_IRQ)
@@ -91,7 +91,7 @@ static inline void qe_ic_cascade_low_ipic(unsigned int irq,
static inline void qe_ic_cascade_high_ipic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
if (cascade_irq != NO_IRQ)
@@ -101,32 +101,35 @@ static inline void qe_ic_cascade_high_ipic(unsigned int irq,
static inline void qe_ic_cascade_low_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
+ struct irq_chip *chip = get_irq_desc_chip(desc);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- desc->chip->eoi(irq);
+ chip->irq_eoi(&desc->irq_data);
}
static inline void qe_ic_cascade_high_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
+ struct irq_chip *chip = get_irq_desc_chip(desc);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- desc->chip->eoi(irq);
+ chip->irq_eoi(&desc->irq_data);
}
static inline void qe_ic_cascade_muxed_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = desc->handler_data;
+ struct qe_ic *qe_ic = get_irq_desc_data(desc);
unsigned int cascade_irq;
+ struct irq_chip *chip = get_irq_desc_chip(desc);
cascade_irq = qe_ic_get_high_irq(qe_ic);
if (cascade_irq == NO_IRQ)
@@ -135,7 +138,7 @@ static inline void qe_ic_cascade_muxed_mpic(unsigned int irq,
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- desc->chip->eoi(irq);
+ chip->irq_eoi(&desc->irq_data);
}
#endif /* _ASM_POWERPC_QE_IC_H */
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 541ba98..8c9ded8 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -189,15 +189,20 @@ static inline void qe_ic_write(volatile __be32 __iomem * base, unsigned int reg
static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
{
- return irq_to_desc(virq)->chip_data;
+ return get_irq_chip_data(virq);
+}
+
+static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
+{
+ return irq_data_get_irq_chip_data(d);
}
#define virq_to_hw(virq) ((unsigned int)irq_map[virq].hwirq)
-static void qe_ic_unmask_irq(unsigned int virq)
+static void qe_ic_unmask_irq(struct irq_data *d)
{
- struct qe_ic *qe_ic = qe_ic_from_irq(virq);
- unsigned int src = virq_to_hw(virq);
+ struct qe_ic *qe_ic = qe_ic_from_irq_data(d);
+ unsigned int src = virq_to_hw(d->irq);
unsigned long flags;
u32 temp;
@@ -210,10 +215,10 @@ static void qe_ic_unmask_irq(unsigned int virq)
raw_spin_unlock_irqrestore(&qe_ic_lock, flags);
}
-static void qe_ic_mask_irq(unsigned int virq)
+static void qe_ic_mask_irq(struct irq_data *d)
{
- struct qe_ic *qe_ic = qe_ic_from_irq(virq);
- unsigned int src = virq_to_hw(virq);
+ struct qe_ic *qe_ic = qe_ic_from_irq_data(d);
+ unsigned int src = virq_to_hw(d->irq);
unsigned long flags;
u32 temp;
@@ -238,9 +243,9 @@ static void qe_ic_mask_irq(unsigned int virq)
static struct irq_chip qe_ic_irq_chip = {
.name = "QEIC",
- .unmask = qe_ic_unmask_irq,
- .mask = qe_ic_mask_irq,
- .mask_ack = qe_ic_mask_irq,
+ .irq_unmask = qe_ic_unmask_irq,
+ .irq_mask = qe_ic_mask_irq,
+ .irq_mask_ack = qe_ic_mask_irq,
};
static int qe_ic_host_match(struct irq_host *h, struct device_node *node)
--
1.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox