[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.11.1409101211170.16533@knanqh.ubzr>
Date: Wed, 10 Sep 2014 12:18:37 -0400 (EDT)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: Jason Cooper <jason@...edaemon.net>
cc: Christoph Lameter <cl@...ux.com>,
Thomas Gleixner <tglx@...utronix.de>,
Tejun Heo <tj@...nel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Mark Brown <broonie@...nel.org>, linux-next@...r.kernel.org,
linux-kernel@...r.kernel.org,
Russell King <rmk+kernel@....linux.org.uk>,
Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: linux-next: Tree for Sep 1
On Wed, 10 Sep 2014, Jason Cooper wrote:
> Christoph,
>
> On Wed, Sep 10, 2014 at 09:15:30AM -0500, Christoph Lameter wrote:
> > On Tue, 9 Sep 2014, Tejun Heo wrote:
> > > On Fri, Sep 05, 2014 at 02:11:23AM +0900, Tejun Heo wrote:
> > > > On Tue, Sep 02, 2014 at 10:00:07AM -0500, Christoph Lameter wrote:
> > > > > Subject: irqchip: Properly fetch the per cpu offset
> > > > >
> > > > > The raw_cpu_read() conversion dropped the fetch of the offset
> > > > > from base->percpu_base in gic_get_percpu_base.
> > > > >
> > > > > Signed-off-by: Christoph Lameter <cl@...ux.com>
> > > > >
> > > > > Index: linux/drivers/irqchip/irq-gic.c
> > > > > ===================================================================
> > > > > --- linux.orig/drivers/irqchip/irq-gic.c
> > > > > +++ linux/drivers/irqchip/irq-gic.c
> > > > > @@ -102,7 +102,7 @@ static struct gic_chip_data gic_data[MAX
> > > > > #ifdef CONFIG_GIC_NON_BANKED
> > > > > static void __iomem *gic_get_percpu_base(union gic_base *base)
> > > > > {
> > > > > - return raw_cpu_read(base->percpu_base);
> > > > > + return raw_cpu_read(*base->percpu_base);
> > > >
> > > > I suppose this should go through percpu/for-3.18-consistent-ops? Can
> > > > we please cc irq folks and get acks?
> > >
> > > Christoph, please drive this forward.
> >
> > CCing IRQ subsystem and IRQCHIP drivers maintainers.
>
> Thanks Chris. I'm a bit behind on irqchip stuff, so I may have missed
> something here... Did we get Cc'd on the original patch that caused the
> regression? I'm fairly certain I haven't seen it to Ack it.
>
> It wouldn't be an issue worth mentioning if it were a vendor-specific
> driver, however, the gic is used by damn near every major ARM SoC.
In fact the problematic code lives in a code path that very few
platform use i.e. CONFIG_GIC_NON_BANKED set by CONFIG_ARCH_EXYNOS4.
And I did ask for a clarification on the proposed fix which produced no
answer so far.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists