[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190206141034.GA5833@basecamp>
Date: Wed, 6 Feb 2019 09:10:34 -0500
From: Brian Masney <masneyb@...tation.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Stephen Boyd <sboyd@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Andy Gross <andy.gross@...aro.org>,
Marc Zyngier <marc.zyngier@....com>,
Lee Jones <lee.jones@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Shawn Guo <shawnguo@...nel.org>,
Doug Anderson <dianders@...omium.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Nicolas Dechesne <nicolas.dechesne@...aro.org>,
Niklas Cassel <niklas.cassel@...aro.org>,
David Brown <david.brown@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
"thierry.reding@...il.com" <thierry.reding@...il.com>,
linux-arm-msm@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>
Subject: Re: [PATCH 3/9] mfd: pm8xxx: convert to v2 irq interfaces to support
hierarchical IRQ chips
Hi Linus,
On Wed, Feb 06, 2019 at 02:07:52PM +0100, Linus Walleij wrote:
> > +struct pm_irq_data {
> > + int num_irqs;
> > + struct irq_chip *irq_chip;
> > + void (*irq_handler)(struct irq_desc *desc);
> > +};
> > +
> > struct pm_irq_chip {
> > struct regmap *regmap;
> > spinlock_t pm_irq_lock;
> > struct irq_domain *irqdomain;
> > - unsigned int num_irqs;
> > unsigned int num_blocks;
> > unsigned int num_masters;
> > u8 config[0];
> > -};
> > -
> > -struct pm_irq_data {
> > - int num_irqs;
> > - const struct irq_domain_ops *irq_domain_ops;
> > - void (*irq_handler)(struct irq_desc *desc);
> > + const struct pm_irq_data *pm_irq_data;
> > };
>
> This doesn't work: the config[0] must be the tail element
> of the struct since we allocate dynamically the trailing
> config[] bytes.
>
> As it looks now, the *pm_irq_data gets overwritten by
> the configs and it crashes.
Thank you for testing all of this on actual hardware. You can either
send out the little issues like this that need corrected and I'll
collect everything up, and send out a V2 once you are done with testing.
Or, you can just take my patches, incorporate the fixes, and add me
with a Co-developed-by tag to the relevant patches. Whatever is easier
for you. I assume that the latter approach may be easier since you're
already making the changes in your tree for testing.
Brian
Powered by blists - more mailing lists