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@xxxxxxxxx>
> > > > >
> > > > > 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-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
