Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1280894 > unrolled thread

Re: [PATCH 1/2] pinctrl: single: Use a separate lockdep class

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/2] pinctrl: single: Use a separate lockdep class Linus Walleij <linus.walleij@linaro.org> - 2015-12-01 15:10 +0100
    Re: [PATCH 1/2] pinctrl: single: Use a separate lockdep class Sudeep Holla <sudeep.holla@arm.com> - 2015-12-01 15:10 +0100
      Re: [PATCH 1/2] pinctrl: single: Use a separate lockdep class Tony Lindgren <tony@atomide.com> - 2015-12-03 19:10 +0100
        Re: [PATCH 1/2] pinctrl: single: Use a separate lockdep class Tony Lindgren <tony@atomide.com> - 2015-12-03 22:50 +0100

#1280894 — Re: [PATCH 1/2] pinctrl: single: Use a separate lockdep class

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1280897

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.

-- 
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283229

* 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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283410

* 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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web