[1/2] pinctrl: single: Use a separate lockdep class
diff mbox

Message ID 1448644860-29323-1-git-send-email-sudeep.holla@arm.com
State New
Headers show

Commit Message

Sudeep Holla Nov. 27, 2015, 5:20 p.m. UTC
The single pinmux controller can be cascaded to the other interrupt
controllers. Hence when propagating wake-up settings to its parent
interrupt controller, there's possiblity of detecting possible recursive
locking and getting lockdep warning.

This patch avoids this false positive by using a separate lockdep class
for this single pinctrl interrupts.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/pinctrl/pinctrl-single.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Linus Walleij Dec. 1, 2015, 2:06 p.m. UTC | #1
On Fri, Nov 27, 2015 at 6:20 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

> The single pinmux controller can be cascaded to the other interrupt
> controllers. Hence when propagating wake-up settings to its parent
> interrupt controller, there's possiblity of detecting possible recursive
> locking and getting lockdep warning.
>
> This patch avoids this false positive by using a separate lockdep class
> for this single pinctrl interrupts.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-gpio@vger.kernel.org
> Suggested-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

I need Tony's ACK on this patch before applying.

Is it a regression that needs to go into fixes?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sudeep Holla Dec. 1, 2015, 2:09 p.m. UTC | #2
On 01/12/15 14:06, Linus Walleij wrote:
> On Fri, Nov 27, 2015 at 6:20 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>> The single pinmux controller can be cascaded to the other interrupt
>> controllers. Hence when propagating wake-up settings to its parent
>> interrupt controller, there's possiblity of detecting possible recursive
>> locking and getting lockdep warning.
>>
>> This patch avoids this false positive by using a separate lockdep class
>> for this single pinctrl interrupts.
>>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: linux-gpio@vger.kernel.org
>> Suggested-by: Thomas Gleixner <tglx@linutronix.de>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
> I need Tony's ACK on this patch before applying.
>
> Is it a regression that needs to go into fixes?
>

Not really, only needed by PATCH 2/2 to avoid recursive locking.
Tony Lindgren Dec. 3, 2015, 6:07 p.m. UTC | #3
* Sudeep Holla <sudeep.holla@arm.com> [151201 06:10]:
> 
> 
> On 01/12/15 14:06, Linus Walleij wrote:
> >On Fri, Nov 27, 2015 at 6:20 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> >>The single pinmux controller can be cascaded to the other interrupt
> >>controllers. Hence when propagating wake-up settings to its parent
> >>interrupt controller, there's possiblity of detecting possible recursive
> >>locking and getting lockdep warning.
> >>
> >>This patch avoids this false positive by using a separate lockdep class
> >>for this single pinctrl interrupts.
> >>
> >>Cc: Linus Walleij <linus.walleij@linaro.org>
> >>Cc: linux-gpio@vger.kernel.org
> >>Suggested-by: Thomas Gleixner <tglx@linutronix.de>
> >>Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >
> >I need Tony's ACK on this patch before applying.
> >
> >Is it a regression that needs to go into fixes?
> >
> 
> Not really, only needed by PATCH 2/2 to avoid recursive locking.

No problem with this patch, so:

Acked-by: Tony Lindgren <tony@atomide.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Dec. 3, 2015, 9:46 p.m. UTC | #4
* Tony Lindgren <tony@atomide.com> [151203 10:07]:
> * Sudeep Holla <sudeep.holla@arm.com> [151201 06:10]:
> > 
> > 
> > On 01/12/15 14:06, Linus Walleij wrote:
> > >On Fri, Nov 27, 2015 at 6:20 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > >>The single pinmux controller can be cascaded to the other interrupt
> > >>controllers. Hence when propagating wake-up settings to its parent
> > >>interrupt controller, there's possiblity of detecting possible recursive
> > >>locking and getting lockdep warning.
> > >>
> > >>This patch avoids this false positive by using a separate lockdep class
> > >>for this single pinctrl interrupts.
> > >>
> > >>Cc: Linus Walleij <linus.walleij@linaro.org>
> > >>Cc: linux-gpio@vger.kernel.org
> > >>Suggested-by: Thomas Gleixner <tglx@linutronix.de>
> > >>Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > >
> > >I need Tony's ACK on this patch before applying.
> > >
> > >Is it a regression that needs to go into fixes?
> > >
> > 
> > Not really, only needed by PATCH 2/2 to avoid recursive locking.
> 
> No problem with this patch, so:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Actually this needs to be merged together with 1/2 once the pending
issues are fixed as this will add a lockdep warning with 1/2.

So for now:

Un-Acked-by: Tony Lindgren <tony@atomide.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index ef04b962c3d5..945a7d0f0704 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -255,6 +255,13 @@  static enum pin_config_param pcs_bias[] = {
 };
 
 /*
+ * This lock class tells lockdep that irqchip core that this single
+ * pinctrl can be in a different category than its parents, so it won't
+ * report false recursion.
+ */
+static struct lock_class_key pcs_lock_class;
+
+/*
  * REVISIT: Reads and writes could eventually use regmap or something
  * generic. But at least on omaps, some mux registers are performance
  * critical as they may need to be remuxed every time before and after
@@ -1716,6 +1723,7 @@  static int pcs_irqdomain_map(struct irq_domain *d, unsigned int irq,
 	irq_set_chip_data(irq, pcs_soc);
 	irq_set_chip_and_handler(irq, &pcs->chip,
 				 handle_level_irq);
+	irq_set_lockdep_class(irq, &pcs_lock_class);
 	irq_set_noprobe(irq);
 
 	return 0;