Groups > linux.kernel > #1683709 > unrolled thread

[GIT pull] irq updates for 4.13

Started by	Thomas Gleixner <tglx@linutronix.de>
First post	2017-07-09 11:00 +0200
Last post	2017-07-11 16:50 +0200
Articles	20 on this page of 43 — 9 participants

Back to article view | Back to linux.kernel

  [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-09 11:00 +0200
    Re: [GIT pull] irq updates for 4.13 Sebastian Reichel <sebastian.reichel@collabora.co.uk> - 2017-07-10 15:40 +0200
      Re: [GIT pull] irq updates for 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-10 19:10 +0200
        Re: [GIT pull] irq updates for 4.13 Pavel Machek <pavel@ucw.cz> - 2017-07-10 21:40 +0200
        Re: [GIT pull] irq updates for 4.13 Sebastian Reichel <sebastian.reichel@collabora.co.uk> - 2017-07-10 22:20 +0200
          Re: [GIT pull] irq updates for 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-10 23:30 +0200
        Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 09:00 +0200
          Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 11:50 +0200
            Re: [GIT pull] irq updates for 4.13 Tony Lindgren <tony@atomide.com> - 2017-07-11 16:00 +0200
              Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 16:50 +0200
                Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 17:10 +0200
                  Re: [GIT pull] irq updates for 4.13 Tony Lindgren <tony@atomide.com> - 2017-07-11 17:50 +0200
                Re: [GIT pull] irq updates for 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-11 17:50 +0200
                  Re: [GIT pull] irq updates for 4.13 Sebastian Reichel <sebastian.reichel@collabora.co.uk> - 2017-07-11 18:20 +0200
                  Re: [GIT pull] irq updates for 4.13 Tony Lindgren <tony@atomide.com> - 2017-07-11 18:20 +0200
                    Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 19:20 +0200
                      Re: [GIT pull] irq updates for 4.13 Tony Lindgren <tony@atomide.com> - 2017-07-11 19:40 +0200
                  Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 18:30 +0200
                    Re: [GIT pull] irq updates for 4.13 Tony Lindgren <tony@atomide.com> - 2017-07-11 18:40 +0200
                    Re: [GIT pull] irq updates for 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-11 18:40 +0200
                      Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 20:00 +0200
                        Re: [GIT pull] irq updates for 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-11 20:20 +0200
                          Re: [GIT pull] irq updates for 4.13 Sebastian Reichel <sebastian.reichel@collabora.co.uk> - 2017-07-11 23:40 +0200
                          Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@tglx.de> - 2017-07-12 00:10 +0200
                            Re: [GIT pull] irq updates for 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-12 00:10 +0200
                            Re: [GIT pull] irq updates for 4.13 Sebastian Reichel <sebastian.reichel@collabora.co.uk> - 2017-07-12 01:00 +0200
                              Re: [GIT pull] irq updates for 4.13 Tony Lindgren <tony@atomide.com> - 2017-07-12 07:30 +0200
                                Re: [GIT pull] irq updates for 4.13 Pavel Machek <pavel@ucw.cz> - 2017-07-15 22:30 +0200
                                  Re: [GIT pull] irq updates for 4.13 Tony Lindgren <tony@atomide.com> - 2017-07-17 08:30 +0200
                                  Re: [GIT pull] irq updates for 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-17 22:10 +0200
                                    Re: [GIT pull] irq updates for 4.13 Pavel Machek <pavel@ucw.cz> - 2017-07-17 23:40 +0200
                Re: [GIT pull] irq updates for 4.13 Grygorii Strashko <grygorii.strashko@ti.com> - 2017-07-11 17:50 +0200
                  Re: [GIT pull] irq updates for 4.13 Tony Lindgren <tony@atomide.com> - 2017-07-11 18:20 +0200
                  Re: [GIT pull] irq updates for 4.13 Geert Uytterhoeven <geert@linux-m68k.org> - 2017-07-12 10:10 +0200
              Re: [GIT pull] irq updates for 4.13 Sebastian Reichel <sebastian.reichel@collabora.co.uk> - 2017-07-11 16:50 +0200
                Re: [GIT pull] irq updates for 4.13 Tony Lindgren <tony@atomide.com> - 2017-07-11 18:30 +0200
                  Re: [GIT pull] irq updates for 4.13 Sebastian Reichel <sebastian.reichel@collabora.co.uk> - 2017-07-11 18:40 +0200
          Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 12:00 +0200
            Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 13:00 +0200
              Re: [GIT pull] irq updates for 4.13 Sebastian Reichel <sebastian.reichel@collabora.co.uk> - 2017-07-11 13:30 +0200
                Re: [GIT pull] irq updates for 4.13 Thomas Gleixner <tglx@linutronix.de> - 2017-07-11 15:30 +0200
                Re: [GIT pull] irq updates for 4.13 Marc Zyngier <marc.zyngier@arm.com> - 2017-07-11 16:00 +0200
                  Re: [GIT pull] irq updates for 4.13 Sebastian Reichel <sebastian.reichel@collabora.co.uk> - 2017-07-11 16:50 +0200

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#1685257

From	Thomas Gleixner <tglx@linutronix.de>
Date	2017-07-11 20:00 +0200
Message-ID	<u27C2-5m0-17@gated-at.bofh.it>
In reply to	#1685204

On Tue, 11 Jul 2017, Linus Torvalds wrote:
> On Tue, Jul 11, 2017 at 9:19 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > What I do not understand here is that we have already power management
> > around all of that.
> >
> >        irq_chip_pm_get(&desc->irq_data);
> >        ...
> >        chip_bus_lock(desc);
> >        ...
> >        chip_bus_unlock_sync(desc);
> >        ...
> >        irq_chip_pm_put(&desc->irq_data);
> >
> > So why is that not sufficient and needs extra magic in that GPIO driver?
> 
> Well, irq_chip_pm_get/put() isn't called just over the operation, it's
> called over the *whole* sequence of the irq being enabled at all.
> 
> So the different (right now) is that
> 
>  - chip_bus_lock/unlock_sync() is purely done around the actual
> operations to set up and tear down the irq data.
> 
>    So this just covers the very short setup/teardown.
> 
>  - irq_chip_pm_get/put() is called around the *whole* "irqs can be active" block
> 
>    This covers the whole lifetime of the irq, from setup to free.
> 
> Very different.
> 
> I'd really prefer my simple patch for now, leaving everything working
> the way it used to work. I *think* it's ok for RT too. Yes?

Not completely, because of the free path issues. See the other mail. Tony
confirmed that it works. I wait for Sebastian and queue it with a proper
changelog, ok?

Thanks,

	tglx

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

#1685271

From	Linus Torvalds <torvalds@linux-foundation.org>
Date	2017-07-11 20:20 +0200
Message-ID	<u27Vn-5Hk-5@gated-at.bofh.it>
In reply to	#1685257

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 11, 2017 at 10:52 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Not completely, because of the free path issues. See the other mail. Tony
> confirmed that it works. I wait for Sebastian and queue it with a proper
> changelog, ok?

Ugh, I absolutely detest your ugly "bool buslock" parameter to
irq_release_resources().

And there seems to be no reason for it.

Why don't you just move the

        chip_bus_sync_unlock(desc);

call in __free_irq() down to just before you release the request_mutex?

In fact, looking at __free_irq(), I note that it's locking is
completely broken shit. Look at the

                if (!action) {
                        WARN(1, "Trying to free already-free IRQ %d\n", irq);

error case, and look for where it unlocks request_mutex. Yeah, it doesn't.

So honestly, I think this code is broken, and it's broken partly
because it has some really bad locking and logic rules.

Why not fix those stupid bugs and clean things up at the same time?
Make the rule be that as you take the request_mutex lock, you then
also do the chip_bus_lock().

And when you release the request_mutex lock, you do
chip_bus_sync_unlock() just before.

And no, I have no idea what the locking rules are for
irq_finalize_oneshot() - it does that chip_bus_lock() without having
any external serialization. Is that ok? Are the chip handlers able to
deal with that? Same seems to go for free_percpu_irq().

Anyway, patch attached (AGAIN, TOTALLY UNTESTED) showing what I mean,
and fixing (well, modulo any bugs I introduced by my untested sh*t)
that definite bug in lack of unlocking.

But that "bool buslock" thing really is too disgusting. Conditional
locking should not be done. It's a sign of serious problems, imnsho.

Comments? Even if they are "Linus, you're way out of line, and you
can't just move that chip_bus_sync_unlock() down like that because of
XYZ, you moron".

For example, it's entirely possible that we can't do the
"synchronize_irq()" waiting while we hold that chip_bus_lock().  But
the ones I looked at seemed to all take sleeping locks (or no locks at
all - doing other things), which implies that they certainly can't be
blocking irq delivery.

So I'm *not* claiming that the attached patch is necessarily right. I
just really don't like your conditional lock thing, and this would
seem to possibly be a clean way around it if it works.

                    Linus

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

#1685351

From	Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Date	2017-07-11 23:40 +0200
Message-ID	<u2b2V-7At-1@gated-at.bofh.it>
In reply to	#1685271

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Tue, Jul 11, 2017 at 11:16:03AM -0700, Linus Torvalds wrote:
> On Tue, Jul 11, 2017 at 10:52 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > Not completely, because of the free path issues. See the other mail. Tony
> > confirmed that it works. I wait for Sebastian and queue it with a proper
> > changelog, ok?
>
> Ugh, I absolutely detest your ugly "bool buslock" parameter to
> irq_release_resources().

So /me will skip testing Thomas' patch for now.

> And there seems to be no reason for it.
> 
> Why don't you just move the
> 
>         chip_bus_sync_unlock(desc);
> 
> call in __free_irq() down to just before you release the request_mutex?
> 
> In fact, looking at __free_irq(), I note that it's locking is
> completely broken shit. Look at the
> 
>                 if (!action) {
>                         WARN(1, "Trying to free already-free IRQ %d\n", irq);
> 
> error case, and look for where it unlocks request_mutex. Yeah, it doesn't.
> 
> So honestly, I think this code is broken, and it's broken partly
> because it has some really bad locking and logic rules.
> 
> Why not fix those stupid bugs and clean things up at the same time?
> Make the rule be that as you take the request_mutex lock, you then
> also do the chip_bus_lock().
> 
> And when you release the request_mutex lock, you do
> chip_bus_sync_unlock() just before.
> 
> And no, I have no idea what the locking rules are for
> irq_finalize_oneshot() - it does that chip_bus_lock() without having
> any external serialization. Is that ok? Are the chip handlers able to
> deal with that? Same seems to go for free_percpu_irq().
> 
> Anyway, patch attached (AGAIN, TOTALLY UNTESTED) showing what I mean,
> and fixing (well, modulo any bugs I introduced by my untested sh*t)
> that definite bug in lack of unlocking.
> 
> But that "bool buslock" thing really is too disgusting. Conditional
> locking should not be done. It's a sign of serious problems, imnsho.
> 
> Comments? Even if they are "Linus, you're way out of line, and you
> can't just move that chip_bus_sync_unlock() down like that because of
> XYZ, you moron".
> 
> For example, it's entirely possible that we can't do the
> "synchronize_irq()" waiting while we hold that chip_bus_lock().  But
> the ones I looked at seemed to all take sleeping locks (or no locks at
> all - doing other things), which implies that they certainly can't be
> blocking irq delivery.
> 
> So I'm *not* claiming that the attached patch is necessarily right. I
> just really don't like your conditional lock thing, and this would
> seem to possibly be a clean way around it if it works.

This fixes boot on Droid 4:

Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>

-- Sebastian

>  kernel/irq/manage.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 5624b2dd6b58..c4cbda784ea5 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -1168,17 +1168,17 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
>  		new->flags &= ~IRQF_ONESHOT;
>  
>  	mutex_lock(&desc->request_mutex);
> +	chip_bus_lock(desc);
> +
>  	if (!desc->action) {
>  		ret = irq_request_resources(desc);
>  		if (ret) {
>  			pr_err("Failed to request resources for %s (irq %d) on irqchip %s\n",
>  			       new->name, irq, desc->irq_data.chip->name);
> -			goto out_mutex;
> +			goto out_unlock_chip_bus;
>  		}
>  	}
>  
> -	chip_bus_lock(desc);
> -
>  	/*
>  	 * The following block of code has to be executed atomically
>  	 */
> @@ -1385,12 +1385,11 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
>  out_unlock:
>  	raw_spin_unlock_irqrestore(&desc->lock, flags);
>  
> -	chip_bus_sync_unlock(desc);
> -
>  	if (!desc->action)
>  		irq_release_resources(desc);
>  
> -out_mutex:
> +out_unlock_chip_bus:
> +	chip_bus_sync_unlock(desc);
>  	mutex_unlock(&desc->request_mutex);
>  
>  out_thread:
> @@ -1472,6 +1471,7 @@ static struct irqaction *__free_irq(unsigned int irq, void *dev_id)
>  			WARN(1, "Trying to free already-free IRQ %d\n", irq);
>  			raw_spin_unlock_irqrestore(&desc->lock, flags);
>  			chip_bus_sync_unlock(desc);
> +			mutex_unlock(&desc->request_mutex);
>  			return NULL;
>  		}
>  
> @@ -1498,7 +1498,6 @@ static struct irqaction *__free_irq(unsigned int irq, void *dev_id)
>  #endif
>  
>  	raw_spin_unlock_irqrestore(&desc->lock, flags);
> -	chip_bus_sync_unlock(desc);
>  
>  	unregister_handler_proc(irq, action);
>  
> @@ -1535,6 +1534,7 @@ static struct irqaction *__free_irq(unsigned int irq, void *dev_id)
>  		irq_remove_timings(desc);
>  	}
>  
> +	chip_bus_sync_unlock(desc);
>  	mutex_unlock(&desc->request_mutex);
>  
>  	irq_chip_pm_put(&desc->irq_data);

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

#1685370

From	Thomas Gleixner <tglx@tglx.de>
Date	2017-07-12 00:10 +0200
Message-ID	<u2bvX-81r-9@gated-at.bofh.it>
In reply to	#1685271

On Tue, 11 Jul 2017, Linus Torvalds wrote:

> On Tue, Jul 11, 2017 at 10:52 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > Not completely, because of the free path issues. See the other mail. Tony
> > confirmed that it works. I wait for Sebastian and queue it with a proper
> > changelog, ok?
> 
> Ugh, I absolutely detest your ugly "bool buslock" parameter to
> irq_release_resources().

Yes, that was a knee jerk reaction to avoid the buslock/unlock dance if the
chip does not have a irq_release_resources() callback. Silly in hindsight
as this is really not a fast path.

> And there seems to be no reason for it.
> 
> Why don't you just move the
> 
>         chip_bus_sync_unlock(desc);
> 
> call in __free_irq() down to just before you release the request_mutex?

See below.

> In fact, looking at __free_irq(), I note that it's locking is
> completely broken shit. Look at the
> 
>                 if (!action) {
>                         WARN(1, "Trying to free already-free IRQ %d\n", irq);
> 
> error case, and look for where it unlocks request_mutex. Yeah, it doesn't.

Yes, I noticed that and my patch fixed it already.

> Why not fix those stupid bugs and clean things up at the same time?
> Make the rule be that as you take the request_mutex lock, you then
> also do the chip_bus_lock().
> 
> And when you release the request_mutex lock, you do
> chip_bus_sync_unlock() just before.
> 
> And no, I have no idea what the locking rules are for
> irq_finalize_oneshot() - it does that chip_bus_lock() without having
> any external serialization. Is that ok? Are the chip handlers able to
> deal with that? Same seems to go for free_percpu_irq().

The extra serialization is only required to protect stuff across
request/free. Everything else is serialized via bus_lock (if the irq chip
has it) and the desc->lock spinlock.

> Comments? Even if they are "Linus, you're way out of line, and you
> can't just move that chip_bus_sync_unlock() down like that because of
> XYZ, you moron".
> 
> For example, it's entirely possible that we can't do the
> "synchronize_irq()" waiting while we hold that chip_bus_lock().  But
> the ones I looked at seemed to all take sleeping locks (or no locks at
> all - doing other things), which implies that they certainly can't be
> blocking irq delivery.

We can't do that move for two reasons:

   1) The data which has been changed between bus_lock/un_lock is cached in
      the irq chip driver private data and needs to go out to the irq chip
      via the slow bus (usually SPI or I2C).

      That's the reason why this bus_lock/unlock magic exists in the first
      place, as you cannot do SPI/I2C transactions while holding desc->lock
      with interrupts disabled.

   2) synchronize_irq() will actually deadlock, if there is a handler on
      flight. These chips use threaded handlers for obvious reasons, as
      they allow to do SPI/I2C communication. When the threaded handler
      returns then bus_lock needs to be taken in irq_finalize_oneshot() as
      we need to talk to the actual irq chip once more. After that the
      threaded handler is marked done, which makes synchronize_irq() return.

      So if we hold bus_lock accross the synchronize_irq() call, the
      handler cannot mark itself done because it blocks on the bus
      lock. That in turn makes synchronize_irq() wait forever on the
      threaded handler to complete....

      Preventing that would require even uglier conditional locking in
      irq_finalize_oneshot(). /me runs and hides

Here is a revised version of the previous patch with the conditional
locking removed and a bunch of comments added.

Thanks,

	tglx

8<----------------------------
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1090,6 +1090,16 @@ setup_irq_thread(struct irqaction *new,
 /*
  * Internal function to register an irqaction - typically used to
  * allocate special interrupts that are part of the architecture.
+ *
+ * Locking rules:
+ *
+ * desc->request_mutex	Provides serialization against a concurrent free_irq()
+ *   chip_bus_lock	Provides serialization for slow bus operations
+ *     desc->lock	Provides serialization against hard interrupts
+ *
+ * chip_bus_lock and desc->lock are sufficient for all other management and
+ * interrupt related functions. desc->request_mutex solely serializes
+ * request/free_irq().
  */
 static int
 __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
@@ -1167,20 +1177,35 @@ static int
 	if (desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)
 		new->flags &= ~IRQF_ONESHOT;
 
+	/*
+	 * Protects against a concurrent __free_irq() call which might wait
+	 * for synchronize_irq() to complete without holding the optional
+	 * chip bus lock and desc->lock.
+	 */
 	mutex_lock(&desc->request_mutex);
+
+	/*
+	 * Acquire bus lock as the irq_request_resources() callback below
+	 * might rely on the serialization or the magic power management
+	 * functions which are abusing the irq_bus_lock() callback,
+	 */
+	chip_bus_lock(desc);
+
+	/* First installed action requests resources. */
 	if (!desc->action) {
 		ret = irq_request_resources(desc);
 		if (ret) {
 			pr_err("Failed to request resources for %s (irq %d) on irqchip %s\n",
 			       new->name, irq, desc->irq_data.chip->name);
-			goto out_mutex;
+			goto out_bus_unlock;
 		}
 	}
 
-	chip_bus_lock(desc);
-
 	/*
 	 * The following block of code has to be executed atomically
+	 * protected against a concurrent interrupt and any of the other
+	 * management calls which are not serialized via
+	 * desc->request_mutex or the optional bus lock.
 	 */
 	raw_spin_lock_irqsave(&desc->lock, flags);
 	old_ptr = &desc->action;
@@ -1286,10 +1311,8 @@ static int
 			ret = __irq_set_trigger(desc,
 						new->flags & IRQF_TRIGGER_MASK);
 
-			if (ret) {
-				irq_release_resources(desc);
+			if (ret)
 				goto out_unlock;
-			}
 		}
 
 		desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \
@@ -1385,12 +1408,10 @@ static int
 out_unlock:
 	raw_spin_unlock_irqrestore(&desc->lock, flags);
 
-	chip_bus_sync_unlock(desc);
-
 	if (!desc->action)
 		irq_release_resources(desc);
-
-out_mutex:
+out_bus_unlock:
+	chip_bus_sync_unlock(desc);
 	mutex_unlock(&desc->request_mutex);
 
 out_thread:
@@ -1472,6 +1493,7 @@ static struct irqaction *__free_irq(unsi
 			WARN(1, "Trying to free already-free IRQ %d\n", irq);
 			raw_spin_unlock_irqrestore(&desc->lock, flags);
 			chip_bus_sync_unlock(desc);
+			mutex_unlock(&desc->request_mutex);
 			return NULL;
 		}
 
@@ -1498,6 +1520,20 @@ static struct irqaction *__free_irq(unsi
 #endif
 
 	raw_spin_unlock_irqrestore(&desc->lock, flags);
+	/*
+	 * Drop bus_lock here so the changes which were done in the chip
+	 * callbacks above are synced out to the irq chips which hang
+	 * behind a slow bus (I2C, SPI) before calling synchronize_irq().
+	 *
+	 * Aside of that the bus_lock can also be taken from the threaded
+	 * handler in irq_finalize_oneshot() which results in a deadlock
+	 * because synchronize_irq() would wait forever for the thread to
+	 * complete, which is blocked on the bus lock.
+	 *
+	 * The still held desc->request_mutex() protects against a
+	 * concurrent request_irq() of this irq so the release of resources
+	 * and timing data is properly serialized.
+	 */
 	chip_bus_sync_unlock(desc);
 
 	unregister_handler_proc(irq, action);
@@ -1530,8 +1566,15 @@ static struct irqaction *__free_irq(unsi
 		}
 	}
 
+	/* Last action releases resources */
 	if (!desc->action) {
+		/*
+		 * Reaquire bus lock as irq_release_resources() might
+		 * require it to deallocate resources over the slow bus.
+		 */
+		chip_bus_lock(desc);
 		irq_release_resources(desc);
+		chip_bus_sync_unlock(desc);
 		irq_remove_timings(desc);
 	}

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

#1685371

From	Linus Torvalds <torvalds@linux-foundation.org>
Date	2017-07-12 00:10 +0200
Message-ID	<u2bvX-81r-15@gated-at.bofh.it>
In reply to	#1685370

On Tue, Jul 11, 2017 at 2:41 PM, Thomas Gleixner <tglx@tglx.de> wrote:
>
> Here is a revised version of the previous patch with the conditional
> locking removed and a bunch of comments added.

This one looks good to me. Thanks,

            Linus

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

#1685388

From	Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Date	2017-07-12 01:00 +0200
Message-ID	<u2cil-8jh-3@gated-at.bofh.it>
In reply to	#1685370

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> [...]
>
> Here is a revised version of the previous patch with the conditional
> locking removed and a bunch of comments added.

That one also fixes Droid 4 boot.

Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>

-- Sebastian

> 8<----------------------------
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -1090,6 +1090,16 @@ setup_irq_thread(struct irqaction *new,
>  /*
>   * Internal function to register an irqaction - typically used to
>   * allocate special interrupts that are part of the architecture.
> + *
> + * Locking rules:
> + *
> + * desc->request_mutex	Provides serialization against a concurrent free_irq()
> + *   chip_bus_lock	Provides serialization for slow bus operations
> + *     desc->lock	Provides serialization against hard interrupts
> + *
> + * chip_bus_lock and desc->lock are sufficient for all other management and
> + * interrupt related functions. desc->request_mutex solely serializes
> + * request/free_irq().
>   */
>  static int
>  __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
> @@ -1167,20 +1177,35 @@ static int
>  	if (desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)
>  		new->flags &= ~IRQF_ONESHOT;
>  
> +	/*
> +	 * Protects against a concurrent __free_irq() call which might wait
> +	 * for synchronize_irq() to complete without holding the optional
> +	 * chip bus lock and desc->lock.
> +	 */
>  	mutex_lock(&desc->request_mutex);
> +
> +	/*
> +	 * Acquire bus lock as the irq_request_resources() callback below
> +	 * might rely on the serialization or the magic power management
> +	 * functions which are abusing the irq_bus_lock() callback,
> +	 */
> +	chip_bus_lock(desc);
> +
> +	/* First installed action requests resources. */
>  	if (!desc->action) {
>  		ret = irq_request_resources(desc);
>  		if (ret) {
>  			pr_err("Failed to request resources for %s (irq %d) on irqchip %s\n",
>  			       new->name, irq, desc->irq_data.chip->name);
> -			goto out_mutex;
> +			goto out_bus_unlock;
>  		}
>  	}
>  
> -	chip_bus_lock(desc);
> -
>  	/*
>  	 * The following block of code has to be executed atomically
> +	 * protected against a concurrent interrupt and any of the other
> +	 * management calls which are not serialized via
> +	 * desc->request_mutex or the optional bus lock.
>  	 */
>  	raw_spin_lock_irqsave(&desc->lock, flags);
>  	old_ptr = &desc->action;
> @@ -1286,10 +1311,8 @@ static int
>  			ret = __irq_set_trigger(desc,
>  						new->flags & IRQF_TRIGGER_MASK);
>  
> -			if (ret) {
> -				irq_release_resources(desc);
> +			if (ret)
>  				goto out_unlock;
> -			}
>  		}
>  
>  		desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \
> @@ -1385,12 +1408,10 @@ static int
>  out_unlock:
>  	raw_spin_unlock_irqrestore(&desc->lock, flags);
>  
> -	chip_bus_sync_unlock(desc);
> -
>  	if (!desc->action)
>  		irq_release_resources(desc);
> -
> -out_mutex:
> +out_bus_unlock:
> +	chip_bus_sync_unlock(desc);
>  	mutex_unlock(&desc->request_mutex);
>  
>  out_thread:
> @@ -1472,6 +1493,7 @@ static struct irqaction *__free_irq(unsi
>  			WARN(1, "Trying to free already-free IRQ %d\n", irq);
>  			raw_spin_unlock_irqrestore(&desc->lock, flags);
>  			chip_bus_sync_unlock(desc);
> +			mutex_unlock(&desc->request_mutex);
>  			return NULL;
>  		}
>  
> @@ -1498,6 +1520,20 @@ static struct irqaction *__free_irq(unsi
>  #endif
>  
>  	raw_spin_unlock_irqrestore(&desc->lock, flags);
> +	/*
> +	 * Drop bus_lock here so the changes which were done in the chip
> +	 * callbacks above are synced out to the irq chips which hang
> +	 * behind a slow bus (I2C, SPI) before calling synchronize_irq().
> +	 *
> +	 * Aside of that the bus_lock can also be taken from the threaded
> +	 * handler in irq_finalize_oneshot() which results in a deadlock
> +	 * because synchronize_irq() would wait forever for the thread to
> +	 * complete, which is blocked on the bus lock.
> +	 *
> +	 * The still held desc->request_mutex() protects against a
> +	 * concurrent request_irq() of this irq so the release of resources
> +	 * and timing data is properly serialized.
> +	 */
>  	chip_bus_sync_unlock(desc);
>  
>  	unregister_handler_proc(irq, action);
> @@ -1530,8 +1566,15 @@ static struct irqaction *__free_irq(unsi
>  		}
>  	}
>  
> +	/* Last action releases resources */
>  	if (!desc->action) {
> +		/*
> +		 * Reaquire bus lock as irq_release_resources() might
> +		 * require it to deallocate resources over the slow bus.
> +		 */
> +		chip_bus_lock(desc);
>  		irq_release_resources(desc);
> +		chip_bus_sync_unlock(desc);
>  		irq_remove_timings(desc);
>  	}
>

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

#1685526

From	Tony Lindgren <tony@atomide.com>
Date	2017-07-12 07:30 +0200
Message-ID	<u2inL-3S5-11@gated-at.bofh.it>
In reply to	#1685388

* Sebastian Reichel <sebastian.reichel@collabora.co.uk> [170711 15:51]:
> Hi,
> 
> On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> > [...]
> >
> > Here is a revised version of the previous patch with the conditional
> > locking removed and a bunch of comments added.
> 
> That one also fixes Droid 4 boot.
> 
> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>

Sill works for me too:

Tested-by: Tony Lindgren <tony@atomide.com>

Thanks,

Tony

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

#1687988

From	Pavel Machek <pavel@ucw.cz>
Date	2017-07-15 22:30 +0200
Message-ID	<u3BRo-61b-21@gated-at.bofh.it>
In reply to	#1685526

[Multipart message — attachments visible in raw view] — view raw

Hi!

> > On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> > > [...]
> > >
> > > Here is a revised version of the previous patch with the conditional
> > > locking removed and a bunch of comments added.
> > 
> > That one also fixes Droid 4 boot.
> > 
> > Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> 
> Sill works for me too:
> 
> Tested-by: Tony Lindgren <tony@atomide.com>

I seen the announcement

Date: Wed, 12 Jul 2017 01:18:50 -0700
From: tip-bot for Thomas Gleixner <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Subject: [tip:irq/urgent] genirq: Keep chip buslock across
irq_request/release_resources()

But I don't see the commit in 4.13-rc0. Could we get it in now, so
that problem is fixed in -rc1?

Thanks,
								Pavel
		

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

#1688690

From	Tony Lindgren <tony@atomide.com>
Date	2017-07-17 08:30 +0200
Message-ID	<u47Hz-1mx-3@gated-at.bofh.it>
In reply to	#1687988

* Pavel Machek <pavel@ucw.cz> [170715 13:24]:
> Hi!
> 
> > > On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> > > > [...]
> > > >
> > > > Here is a revised version of the previous patch with the conditional
> > > > locking removed and a bunch of comments added.
> > > 
> > > That one also fixes Droid 4 boot.
> > > 
> > > Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > 
> > Sill works for me too:
> > 
> > Tested-by: Tony Lindgren <tony@atomide.com>
> 
> I seen the announcement
> 
> Date: Wed, 12 Jul 2017 01:18:50 -0700
> From: tip-bot for Thomas Gleixner <tipbot@zytor.com>
> To: linux-tip-commits@vger.kernel.org
> Subject: [tip:irq/urgent] genirq: Keep chip buslock across
> irq_request/release_resources()
> 
> But I don't see the commit in 4.13-rc0. Could we get it in now, so
> that problem is fixed in -rc1?

Seems we missed that for -rc1. In general, I've noticed that the rule
of having code sit in next before the merge window really helps
preventing regressions during the merge window. That is as long
people keep testing next on almost daily basis and report
regressions promptly.. and I do just to avoid chasing regressions
during the -rc cycle.

And the real reason why I think catching the regressions in next
helps is the fact that people react to regressions much faster to
revert patches compared to after things get merged into the mainline
kernel :p

In this case Thomas reacted within hours and fixed the issue, so
no issues there and thanks for doing that. But we still got -rc1
with a regression that probably could have been prevented with
enough time in next. So maybe we should be more strict with the
next requirement? Just sayin.

Tony

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

#1689430

From	Linus Torvalds <torvalds@linux-foundation.org>
Date	2017-07-17 22:10 +0200
Message-ID	<u4kv8-1bl-29@gated-at.bofh.it>
In reply to	#1687988

On Sat, Jul 15, 2017 at 1:24 PM, Pavel Machek <pavel@ucw.cz> wrote:
>
> But I don't see the commit in 4.13-rc0. Could we get it in now, so
> that problem is fixed in -rc1?

It didn't hit rc1, but it's in my tree now.

                Linus

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

#1689505

From	Pavel Machek <pavel@ucw.cz>
Date	2017-07-17 23:40 +0200
Message-ID	<u4lUe-1Ws-5@gated-at.bofh.it>
In reply to	#1689430

[Multipart message — attachments visible in raw view] — view raw

On Mon 2017-07-17 13:01:58, Linus Torvalds wrote:
> On Sat, Jul 15, 2017 at 1:24 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >
> > But I don't see the commit in 4.13-rc0. Could we get it in now, so
> > that problem is fixed in -rc1?
> 
> It didn't hit rc1, but it's in my tree now.

Thanks for head-up. Yes, current tree works ok for me.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

#1685166

From	Grygorii Strashko <grygorii.strashko@ti.com>
Date	2017-07-11 17:50 +0200
Message-ID	<u25Af-48y-19@gated-at.bofh.it>
In reply to	#1685091


On 07/11/2017 09:41 AM, Thomas Gleixner wrote:
> On Tue, 11 Jul 2017, Tony Lindgren wrote:
>> * Thomas Gleixner <tglx@linutronix.de> [170711 02:48]:
>> And "external abort on non-linefetch" means something is not clocked
>> in this case. The following alone makes things boot for me again, but I don't
>> quite follow what has now changed with the ordering.. Thomas, any ideas?
> 
> Ah. Now that makes sense.
> 
> Unpatched the ordering is:
> 
> 	  chip_bus_lock(desc);
> 	  irq_request_resources(desc);
> 
> Now the offending change reordered the calls. OMAP gpio has:
> 
>      omap_gpio_irq_bus_lock()
>         pm_runtime_get_sync(bank->chip.parent);
> 
> So that at least explains the error. So that omap gpio irq chip (ab)uses
> the bus_lock() callback to do runtime power management. Sigh, I did not
> expect that. Let me have a deeper look if that's OMAP only or whether this
> happens in other places as well.

It was the only one way to power on GPIO bank when the first GPIO IRQ is requested,
as all other irqchip callbacks are under raw_lock while pm_runtime uses spinlock, as
result on -RT it was not possible to use PM runtime in other irqchip callbacks.

Now, I think, It might be possible to use irq_chip_pm_get(), but there is one problem -
OMAP Power management platform code can call omap2_gpio_prepare_for_idle()/omap2_gpio_resume_after_idle()
which expected to disable GPIO banks using PM runtime and current driver implementation
expect to have PM runtime usage_count = 1.

Tony, Potentially we can use pm_runtime_force_suspend()/resume() there, but they are not compatible with
irqoff context (CPUIdle late stages).

In other words, below patch should fix this issue, but will break CPUIdle on OMAP :(

--
From dfca1c806f03ad6bdd72b634d71c96d39bda2046 Mon Sep 17 00:00:00 2001
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Tue, 11 Jul 2017 10:36:23 -0500
Subject: [PATCH] gpio: omap: switch to use irq_chip_pm_get/put()

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
 drivers/gpio/gpio-omap.c | 23 +----------------------
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index ba58c8b..b614475 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -787,26 +787,6 @@ static void omap_gpio_irq_shutdown(struct irq_data *d)
 	raw_spin_unlock_irqrestore(&bank->lock, flags);
 }
 
-static void omap_gpio_irq_bus_lock(struct irq_data *data)
-{
-	struct gpio_bank *bank = omap_irq_data_get_bank(data);
-
-	if (!BANK_USED(bank))
-		pm_runtime_get_sync(bank->chip.parent);
-}
-
-static void gpio_irq_bus_sync_unlock(struct irq_data *data)
-{
-	struct gpio_bank *bank = omap_irq_data_get_bank(data);
-
-	/*
-	 * If this is the last IRQ to be freed in the bank,
-	 * disable the bank module.
-	 */
-	if (!BANK_USED(bank))
-		pm_runtime_put(bank->chip.parent);
-}
-
 static void omap_gpio_ack_irq(struct irq_data *d)
 {
 	struct gpio_bank *bank = omap_irq_data_get_bank(d);
@@ -1168,10 +1148,9 @@ static int omap_gpio_probe(struct platform_device *pdev)
 	irqc->irq_unmask = omap_gpio_unmask_irq,
 	irqc->irq_set_type = omap_gpio_irq_type,
 	irqc->irq_set_wake = omap_gpio_wake_enable,
-	irqc->irq_bus_lock = omap_gpio_irq_bus_lock,
-	irqc->irq_bus_sync_unlock = gpio_irq_bus_sync_unlock,
 	irqc->name = dev_name(&pdev->dev);
 	irqc->flags = IRQCHIP_MASK_ON_SUSPEND;
+	irqc->parent_device = dev;
 
 	bank->irq = platform_get_irq(pdev, 0);
 	if (bank->irq <= 0) {
-- 
2.10.1


-- 
regards,
-grygorii

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

#1685177

From	Tony Lindgren <tony@atomide.com>
Date	2017-07-11 18:20 +0200
Message-ID	<u263g-4Bc-11@gated-at.bofh.it>
In reply to	#1685166

* Grygorii Strashko <grygorii.strashko@ti.com> [170711 08:40]:
> Tony, Potentially we can use pm_runtime_force_suspend()/resume() there, but they are not compatible with
> irqoff context (CPUIdle late stages).
> 
> In other words, below patch should fix this issue, but will break CPUIdle on OMAP :(

Thanks, yea let's take a look at it but let's not break cpuidle! People
are using mainline kernel with batteries.

Regards,

Tony

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

#1685586

From	Geert Uytterhoeven <geert@linux-m68k.org>
Date	2017-07-12 10:10 +0200
Message-ID	<u2kSC-5FA-5@gated-at.bofh.it>
In reply to	#1685166

Hi Grygorii,

On Tue, Jul 11, 2017 at 5:39 PM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
> On 07/11/2017 09:41 AM, Thomas Gleixner wrote:
>> On Tue, 11 Jul 2017, Tony Lindgren wrote:
>>> * Thomas Gleixner <tglx@linutronix.de> [170711 02:48]:
>>> And "external abort on non-linefetch" means something is not clocked
>>> in this case. The following alone makes things boot for me again, but I don't
>>> quite follow what has now changed with the ordering.. Thomas, any ideas?
>>
>> Ah. Now that makes sense.
>>
>> Unpatched the ordering is:
>>
>>         chip_bus_lock(desc);
>>         irq_request_resources(desc);
>>
>> Now the offending change reordered the calls. OMAP gpio has:
>>
>>      omap_gpio_irq_bus_lock()
>>         pm_runtime_get_sync(bank->chip.parent);
>>
>> So that at least explains the error. So that omap gpio irq chip (ab)uses
>> the bus_lock() callback to do runtime power management. Sigh, I did not
>> expect that. Let me have a deeper look if that's OMAP only or whether this
>> happens in other places as well.
>
> It was the only one way to power on GPIO bank when the first GPIO IRQ is requested,
> as all other irqchip callbacks are under raw_lock while pm_runtime uses spinlock, as
> result on -RT it was not possible to use PM runtime in other irqchip callbacks.
>
> Now, I think, It might be possible to use irq_chip_pm_get(), but there is one problem -
> OMAP Power management platform code can call omap2_gpio_prepare_for_idle()/omap2_gpio_resume_after_idle()
> which expected to disable GPIO banks using PM runtime and current driver implementation
> expect to have PM runtime usage_count = 1.
>
> Tony, Potentially we can use pm_runtime_force_suspend()/resume() there, but they are not compatible with
> irqoff context (CPUIdle late stages).
>
> In other words, below patch should fix this issue, but will break CPUIdle on OMAP :(
>
> --
> From dfca1c806f03ad6bdd72b634d71c96d39bda2046 Mon Sep 17 00:00:00 2001
> From: Grygorii Strashko <grygorii.strashko@ti.com>
> Date: Tue, 11 Jul 2017 10:36:23 -0500
> Subject: [PATCH] gpio: omap: switch to use irq_chip_pm_get/put()
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

That looks similar to how gpio-rcar was fixed, which used to do the
same trick in its bus_lock() callbacks.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

#1685102

From	Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Date	2017-07-11 16:50 +0200
Message-ID	<u24Eb-3xP-37@gated-at.bofh.it>
In reply to	#1685044

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Tue, Jul 11, 2017 at 06:51:32AM -0700, Tony Lindgren wrote:
> * Thomas Gleixner <tglx@linutronix.de> [170711 02:48]:
> > On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> > 
> > So Tony actually provided the part of dmesg which shows the initial
> > failure, which subsequently leads to the splat Sebastian reported.
> > 
> > Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb050034
> > pgd = c0004000 [fb050034] *pgd=49011452(bad)
> > Internal error: : 1028 [#1] SMP ARM
> > Workqueue: events deferred_probe_work_func
> > task: ce1d41c0 task.stack: ce1fc000
> > PC is at omap_gpio_get_direction+0x2c/0x44
> > LR is at _raw_spin_lock_irqsave+0x40/0x4c
> > pc : [<c0509258>]    lr : [<c08263c4>]    psr: 60000093
> > sp : ce1fdb78  ip : c0dce42c  fp : ce22d810
> > r10: ce22d800  r9 : 00000000  r8 : ce22d900
> > r7 : 00000016  r6 : ce223864  r5 : fb050034  r4 : 00000020
> > r3 : ce1d41c0  r2 : 00000000  r1 : a0000013  r0 : a0000013
> > Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
> > Control: 10c5387d  Table: 80004019  DAC: 00000051
> > Process kworker/0:1 (pid: 14, stack limit = 0xce1fc218)
> > 
> > The callstack is:
> > 
> > omap_gpio_get_direction
> > gpiochip_lock_as_irq
> > gpiochip_irq_reqres
> > __setup_irq
> > request_threaded_irq
> > smc_probe
> > smc_drv_probe
> > platform_drv_probe
> > ....
> > 
> > So the SMC91X network driver request an IRQ, which ends up calling into the
> > GPIO interrupt setup and that fails. I have no idea why that would not fail
> > with the patch reverted. Dusting off a Beaglebone board....
> 
> And "external abort on non-linefetch" means something is not clocked
> in this case. The following alone makes things boot for me again, but I don't
> quite follow what has now changed with the ordering.. Thomas, any ideas?
> 
> Anyways, adding Linus W and Grygorii to Cc since things now point to
> gpio-omap.
> 
> Regards,
> 
> Tony

Ack, that also works for me. The strange thing is, that I added the
following before and it did not print anything.

if (!pm_runtime_enabled(bank->chip.parent))
    dev_err(bank->chip.parent, "runtime pm issue!\n");

-- Sebastian

> 8< ---------------------
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -919,13 +919,24 @@ static int omap_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
>  	struct gpio_bank *bank;
>  	unsigned long flags;
>  	void __iomem *reg;
> -	int dir;
> +	int error, dir;
>  
>  	bank = gpiochip_get_data(chip);
>  	reg = bank->base + bank->regs->direction;
> +	error = pm_runtime_get_sync(bank->chip.parent);
> +	if (error < 0) {
> +		dev_err(bank->chip.parent,
> +			"Could not enable gpio bank %p: %d\n",
> +			bank, error);
> +		pm_runtime_put_noidle(bank->chip.parent);
> +
> +		return error;
> +	}
>  	raw_spin_lock_irqsave(&bank->lock, flags);
>  	dir = !!(readl_relaxed(reg) & BIT(offset));
>  	raw_spin_unlock_irqrestore(&bank->lock, flags);
> +	pm_runtime_put_sync(bank->chip.parent);
> +
>  	return dir;
>  }
>  
> -- 
> 2.13.2

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

#1685192

From	Tony Lindgren <tony@atomide.com>
Date	2017-07-11 18:30 +0200
Message-ID	<u26cV-4Ed-5@gated-at.bofh.it>
In reply to	#1685102

* Sebastian Reichel <sebastian.reichel@collabora.co.uk> [170711 07:41]:
> Ack, that also works for me. The strange thing is, that I added the
> following before and it did not print anything.
> 
> if (!pm_runtime_enabled(bank->chip.parent))
>     dev_err(bank->chip.parent, "runtime pm issue!\n");

Enabled but not active, you should have tested for !pm_runtime_active()?

Regards,

Tony

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

#1685203

From	Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Date	2017-07-11 18:40 +0200
Message-ID	<u26mC-4Hp-25@gated-at.bofh.it>
In reply to	#1685192

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Tue, Jul 11, 2017 at 09:20:44AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel <sebastian.reichel@collabora.co.uk> [170711 07:41]:
> > Ack, that also works for me. The strange thing is, that I added the
> > following before and it did not print anything.
> > 
> > if (!pm_runtime_enabled(bank->chip.parent))
> >     dev_err(bank->chip.parent, "runtime pm issue!\n");
> 
> Enabled but not active, you should have tested for !pm_runtime_active()?

oh right.

-- Sebastian

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

#1684937

From	Thomas Gleixner <tglx@linutronix.de>
Date	2017-07-11 12:00 +0200
Message-ID	<u207w-Cy-11@gated-at.bofh.it>
In reply to	#1684813

On Tue, 11 Jul 2017, Sebastian Reichel wrote:
> There you go (this is basically 9967468c0a10). The referenced
> cpcap is a PMIC, that uses one of OMAP's GPIOs to generate
> interrupts and (among other things) provides an interrupt
> controller.
> 
> [    1.328521] cpcap-core spi1.0: CPCAP vendor: ST rev: 2.10 (1a)
> [    1.336334] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> [    1.343536] pgd = c0004000
> [    1.346282] [00000000] *pgd=00000000
> [    1.349914] Internal error: : 1406 [#1] SMP ARM
> [    1.354492] Modules linked in:
> [    1.357574] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-10625-gcb473a1c6f03 #531
> [    1.365447] Hardware name: Generic OMAP4 (Flattened Device Tree)
> [    1.371520] task: ee8aae00 task.stack: ee8ac000
> [    1.376098] PC is at do_raw_spin_unlock+0x58/0x120
> [    1.380920] LR is at _raw_spin_unlock_irqrestore+0x24/0x44
> [    1.386444] pc : [<c01a02d8>]    lr : [<c0afa6f4>]    psr: 60000093
> [    1.392761] sp : ee8adba0  ip : c10fe40c  fp : eea0ac10
> [    1.398040] r10: eea0ac00  r9 : c061f764  r8 : eea0ad04
> [    1.403289] r7 : 00000007  r6 : eea07e64  r5 : ffffe000  r4 : eea07e64
> [    1.409881] r3 : ffffffff  r2 : 00000000  r1 : ee8aae00  r0 : eea07e64
> [    1.416442] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [    1.423736] Control: 10c5387d  Table: 8000404a  DAC: 00000051
> [    1.429534] Process swapper/0 (pid: 1, stack limit = 0xee8ac218)
> [    1.435577] Stack: (0xee8adba0 to 0xee8ae000)

> [    1.728546] [<c01a02d8>] (do_raw_spin_unlock) from [<c0afa6f4>] (_raw_spin_unlock_irqrestore+0x24/0x44)
> [    1.738037] [<c0afa6f4>] (_raw_spin_unlock_irqrestore) from [<c051ce58>] (omap_gpio_get_direction+0x38/0x44)
> [    1.747955] [<c051ce58>] (omap_gpio_get_direction) from [<c0515e90>] (gpiochip_lock_as_irq+0x98/0xe4)
> [    1.757232] [<c0515e90>] (gpiochip_lock_as_irq) from [<c05163c0>] (gpiochip_irq_reqres+0x2c/0x6c)
> [    1.766174] [<c05163c0>] (gpiochip_irq_reqres) from [<c01ac450>] (__setup_irq+0x478/0x6ec)
> [    1.774536] [<c01ac450>] (__setup_irq) from [<c01ac81c>] (request_threaded_irq+0xcc/0x14c)

So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to
wonder how the raw_spin_lock() succeeded. That does not make any sense.

Thanks,

	tglx

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

#1684962

From	Thomas Gleixner <tglx@linutronix.de>
Date	2017-07-11 13:00 +0200
Message-ID	<u213z-1g3-5@gated-at.bofh.it>
In reply to	#1684937

Sebastian,

On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> On Tue, 11 Jul 2017, Sebastian Reichel wrote:
> So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to
> wonder how the raw_spin_lock() succeeded. That does not make any sense.

can you please apply the patch below on top of 4.12? It's a backport
isolating the resource request changes.

Thanks,

	tglx

8<----------------------
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1198,6 +1198,18 @@ static int
 	if (desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)
 		new->flags &= ~IRQF_ONESHOT;
 
+	mutex_lock(&desc->request_mutex);
+	if (!desc->action) {
+		ret = irq_request_resources(desc);
+		if (ret) {
+			pr_err("Failed to request resources for %s (irq %d) on irqchip %s\n",
+			       new->name, irq, desc->irq_data.chip->name);
+			goto out_mutex;
+		}
+	}
+
+	chip_bus_lock(desc);
+
 	/*
 	 * The following block of code has to be executed atomically
 	 */
@@ -1298,13 +1310,6 @@ static int
 	}
 
 	if (!shared) {
-		ret = irq_request_resources(desc);
-		if (ret) {
-			pr_err("Failed to request resources for %s (irq %d) on irqchip %s\n",
-			       new->name, irq, desc->irq_data.chip->name);
-			goto out_mask;
-		}
-
 		init_waitqueue_head(&desc->wait_for_threads);
 
 		/* Setup the type (level, edge polarity) if configured: */
@@ -1312,10 +1317,8 @@ static int
 			ret = __irq_set_trigger(desc,
 						new->flags & IRQF_TRIGGER_MASK);
 
-			if (ret) {
-				irq_release_resources(desc);
+			if (ret)
 				goto out_mask;
-			}
 		}
 
 		desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \
@@ -1373,6 +1376,8 @@ static int
 	}
 
 	raw_spin_unlock_irqrestore(&desc->lock, flags);
+	chip_bus_sync_unlock(desc);
+	mutex_unlock(&desc->request_mutex);
 
 	/*
 	 * Strictly no need to wake it up, but hung_task complains
@@ -1402,6 +1407,13 @@ static int
 
 out_mask:
 	raw_spin_unlock_irqrestore(&desc->lock, flags);
+	chip_bus_sync_unlock(desc);
+	if (!desc->action)
+		irq_release_resources(desc);
+
+out_mutex:
+	mutex_unlock(&desc->request_mutex);
+
 	free_cpumask_var(mask);
 
 out_thread:
@@ -1443,9 +1455,7 @@ int setup_irq(unsigned int irq, struct i
 	if (retval < 0)
 		return retval;
 
-	chip_bus_lock(desc);
 	retval = __setup_irq(irq, desc, act);
-	chip_bus_sync_unlock(desc);
 
 	if (retval)
 		irq_chip_pm_put(&desc->irq_data);
@@ -1469,6 +1479,7 @@ static struct irqaction *__free_irq(unsi
 	if (!desc)
 		return NULL;
 
+	mutex_lock(&desc->request_mutex);
 	chip_bus_lock(desc);
 	raw_spin_lock_irqsave(&desc->lock, flags);
 
@@ -1501,7 +1512,6 @@ static struct irqaction *__free_irq(unsi
 	if (!desc->action) {
 		irq_settings_clr_disable_unlazy(desc);
 		irq_shutdown(desc);
-		irq_release_resources(desc);
 	}
 
 #ifdef CONFIG_SMP
@@ -1543,6 +1553,11 @@ static struct irqaction *__free_irq(unsi
 		}
 	}
 
+	if (!desc->action)
+		irq_release_resources(desc);
+
+	mutex_unlock(&desc->request_mutex);
+
 	irq_chip_pm_put(&desc->irq_data);
 	module_put(desc->owner);
 	kfree(action->secondary);
@@ -1699,9 +1714,7 @@ int request_threaded_irq(unsigned int ir
 		return retval;
 	}
 
-	chip_bus_lock(desc);
 	retval = __setup_irq(irq, desc, action);
-	chip_bus_sync_unlock(desc);
 
 	if (retval) {
 		irq_chip_pm_put(&desc->irq_data);
@@ -1949,9 +1962,7 @@ int setup_percpu_irq(unsigned int irq, s
 	if (retval < 0)
 		return retval;
 
-	chip_bus_lock(desc);
 	retval = __setup_irq(irq, desc, act);
-	chip_bus_sync_unlock(desc);
 
 	if (retval)
 		irq_chip_pm_put(&desc->irq_data);
@@ -2005,9 +2016,7 @@ int request_percpu_irq(unsigned int irq,
 		return retval;
 	}
 
-	chip_bus_lock(desc);
 	retval = __setup_irq(irq, desc, action);
-	chip_bus_sync_unlock(desc);
 
 	if (retval) {
 		irq_chip_pm_put(&desc->irq_data);
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -3,6 +3,7 @@
 
 #include <linux/rcupdate.h>
 #include <linux/kobject.h>
+#include <linux/mutex.h>
 
 /*
  * Core internal functions to deal with irq descriptors
@@ -45,6 +46,7 @@ struct pt_regs;
  *			IRQF_FORCE_RESUME set
  * @rcu:		rcu head for delayed free
  * @kobj:		kobject used to represent this struct in sysfs
+ * @request_mutex:	mutex to protect request/free before locking desc->lock
  * @dir:		/proc/irq/ procfs entry
  * @name:		flow handler name for /proc/interrupts output
  */
@@ -92,6 +94,7 @@ struct irq_desc {
 	struct rcu_head		rcu;
 	struct kobject		kobj;
 #endif
+	struct mutex		request_mutex;
 	int			parent_irq;
 	struct module		*owner;
 	const char		*name;
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -359,6 +359,7 @@ static struct irq_desc *alloc_desc(int i
 
 	raw_spin_lock_init(&desc->lock);
 	lockdep_set_class(&desc->lock, &irq_desc_lock_class);
+	mutex_init(&desc->request_mutex);
 	init_rcu_head(&desc->rcu);
 
 	desc_set_defaults(irq, desc, node, affinity, owner);

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

#1684980

From	Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Date	2017-07-11 13:30 +0200
Message-ID	<u21wB-1EK-1@gated-at.bofh.it>
In reply to	#1684962

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Tue, Jul 11, 2017 at 12:52:17PM +0200, Thomas Gleixner wrote:
> On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> > On Tue, 11 Jul 2017, Sebastian Reichel wrote:
> > So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to
> > wonder how the raw_spin_lock() succeeded. That does not make any sense.
> 
> can you please apply the patch below on top of 4.12? It's a backport
> isolating the resource request changes.

Full bootlog for v4.12 + your patch is below. I used the same
.config with oldconfig.

-- Sebastian

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.12.0-00001-g2a481f732c4b (sre@earth) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1539 SMP Tue Jul 11 13:13:20 CEST 2017
[    0.000000] CPU: ARMv7 Processor [411fc093] revision 3 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Motorola Droid 4 XT894
[    0.000000] earlycon: omap8250 at MMIO 0x48020000 (options '')
[    0.000000] bootconsole [omap8250] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 16 MiB at 0xbe800000
[    0.000000] OMAP4: Map 0xbfb00000 to fe600000 for dram barrier
[    0.000000] OMAP4430 ES2.3
[    0.000000] percpu: Embedded 18 pages/cpu @ef69b000 s41256 r8192 d24280 u73728
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 259136
[    0.000000] Kernel command line: root=/dev/mmcblk0p1 rootwait rw console=tty0 console=ttyS2,115200 fbcon=rotate:1 earlyprintk earlycon
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 992184K/1043456K available (10240K kernel code, 985K rwdata, 3396K rodata, 1024K init, 8063K bss, 34888K reserved, 16384K cma-reserved, 240640K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0b00000   (11232 kB)
[    0.000000]       .init : 0xc0f00000 - 0xc1000000   (1024 kB)
[    0.000000]       .data : 0xc1000000 - 0xc10f6514   ( 986 kB)
[    0.000000]        .bss : 0xc10f8000 - 0xc18d7f74   (8064 kB)
[    0.000000] Running RCU self tests
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU lockdep checking is enabled.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] L2C: platform modifies aux control register: 0x5e470000 -> 0x7e470000
[    0.000000] L2C: DT/platform modifies aux control register: 0x5e470000 -> 0x7e470000
[    0.000000] L2C-310 erratum 727915 enabled
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 ID prefetch enabled, offset 8 lines
[    0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[    0.000000] L2C-310: CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000
[    0.000000] ti_dt_clocks_register: failed to lookup clock node dss_fck
[    0.000000] OMAP clockevent source: timer1 at 32768 Hz
[    0.000000] clocksource: 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65535999984741ns
[    0.008605] OMAP clocksource: 32k_counter at 32768 Hz
[    0.014862] Console: colour dummy device 80x30
[    0.021179] console [tty0] enabled
[    0.024688] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.032745] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.036956] ... MAX_LOCK_DEPTH:          48
[    0.041320] ... MAX_LOCKDEP_KEYS:        8191
[    0.045806] ... CLASSHASH_SIZE:          4096
[    0.050354] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.054931] ... MAX_LOCKDEP_CHAINS:      65536
[    0.059539] ... CHAINHASH_SIZE:          32768
[    0.064147]  memory used by lock dependency info: 5167 kB
[    0.069732]  per task-struct memory footprint: 1536 bytes
[    0.075347] Calibrating delay loop... 2387.14 BogoMIPS (lpj=11935744)
[    0.136138] pid_max: default: 32768 minimum: 301
[    0.141235] Security Framework initialized
[    0.145568] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.152435] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.161865] CPU: Testing write buffer coherency: ok
[    0.167938] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.173858] smp: CPU1 parked within kernel, needs reset (0x80011ba8 0x80067478)
[    0.182342] Setting up static identity map for 0x80100000 - 0x80100078
[    0.190734] smp: Bringing up secondary CPUs ...
[    0.249481] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.249877] smp: Brought up 1 node, 2 CPUs
[    0.260009] SMP: Total of 2 processors activated (4780.85 BogoMIPS).
[    0.266601] CPU: All CPU(s) started in SVC mode.
[    0.273559] devtmpfs: initialized
[    0.302398] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[    0.312103] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.322357] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.329925] pinctrl core: initialized pinctrl subsystem
[    0.338195] NET: Registered protocol family 16
[    0.346618] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.357208] omap_hwmod: l3_main_3 using broken dt data from ocp
[    0.366516] omap_hwmod: l3_main_2 using broken dt data from ocp
[    0.465270] omap_hwmod: uart1: _wait_target_disable failed
[    0.474456] cpuidle: using governor ladder
[    0.478790] cpuidle: using governor menu
[    0.493927] OMAP GPIO hardware version 0.1
[    0.511169] GPIO line 173 (touchscreen-reset) hogged as output/high
[    0.520660] omap-gpmc 50000000.gpmc: GPMC revision 6.0
[    0.526123] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
[    0.533905] irq: no irq domain found for /ocp/l4@4a000000/scm@100000/pinmux@40 !
[    0.546539] irq: no irq domain found for /ocp/l4@4a000000/scm@100000/pinmux@40 !
[    0.564086] platform 4b501000.aes: Cannot lookup hwmod 'aes'
[    0.570343] platform 480a5000.des: Cannot lookup hwmod 'des'
[    0.580688] No ATAGs?
[    0.580932] hw-breakpoint: Failed to enable monitor mode on CPU 0.
[    0.591308] OMAP DMA hardware revision 0.0
[    0.600067] ARM PMU: not yet supported on OMAP4430 due to missing CTI driver
[    0.640228] omap-dma-engine 4a056000.dma-controller: OMAP DMA engine driver (LinkedList1/2/3 supported)
[    0.655883] omap-iommu 4a066000.mmu: 4a066000.mmu registered
[    0.662139] omap-iommu 55082000.mmu: 55082000.mmu registered
[    0.670227] SCSI subsystem initialized
[    0.674987] usbcore: registered new interface driver usbfs
[    0.680786] usbcore: registered new interface driver hub
[    0.686370] usbcore: registered new device driver usb
[    0.692169] usb_phy_generic hsusb1_phy: hsusb1_phy supply vcc not found, using dummy regulator
[    0.703186] omap_i2c 48070000.i2c: bus 0 rev0.10 at 100 kHz
[    0.709930] omap_i2c 48072000.i2c: bus 1 rev0.10 at 100 kHz
[    0.716308] omap_i2c 48060000.i2c: bus 2 rev0.10 at 100 kHz
[    0.723052] omap_i2c 48350000.i2c: bus 3 rev0.10 at 100 kHz
[    0.729095] media: Linux media interface: v0.10
[    0.733886] Linux video capture interface: v2.00
[    0.739715] omap-mailbox 4a0f4000.mailbox: omap mailbox rev 0x400
[    0.746459] Advanced Linux Sound Architecture Driver Initialized.
[    0.754272] Bluetooth: Core ver 2.22
[    0.758056] NET: Registered protocol family 31
[    0.762695] Bluetooth: HCI device and connection manager initialized
[    0.769348] Bluetooth: HCI socket layer initialized
[    0.774444] Bluetooth: L2CAP socket layer initialized
[    0.779815] Bluetooth: SCO socket layer initialized
[    0.787414] clocksource: Switched to clocksource 32k_counter
[    0.911956] VFS: Disk quotas dquot_6.6.0
[    0.916168] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.942535] NET: Registered protocol family 2
[    0.948486] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.955871] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[    0.964050] TCP: Hash tables configured (established 8192 bind 8192)
[    0.971160] UDP hash table entries: 512 (order: 3, 40960 bytes)
[    0.977539] UDP-Lite hash table entries: 512 (order: 3, 40960 bytes)
[    0.984802] NET: Registered protocol family 1
[    0.990783] RPC: Registered named UNIX socket transport module.
[    0.996948] RPC: Registered udp transport module.
[    1.001892] RPC: Registered tcp transport module.
[    1.006774] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.022338] audit: initializing netlink subsys (disabled)
[    1.028747] audit: type=2000 audit(1.021:1): state=initialized audit_enabled=0 res=1
[    1.029632] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[    1.045257] NFS: Registering the id_resolver key type
[    1.050903] Key type id_resolver registered
[    1.055267] Key type id_legacy registered
[    1.059570] jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[    1.075866] jitterentropy: Initialization failed with host not compliant with requirements: 2
[    1.085021] NET: Registered protocol family 38
[    1.089843] bounce: pool size: 64 pages
[    1.093902] io scheduler noop registered
[    1.098022] io scheduler deadline registered
[    1.102539] io scheduler cfq registered (default)
[    1.107513] io scheduler mq-deadline registered
[    1.112213] io scheduler kyber registered
[    1.120635] pinctrl-single 4a100040.pinmux: 203 pins at pa fc100040 size 406
[    1.128479] pinctrl-single 4a31e040.pinmux: 28 pins at pa fc31e040 size 56
[    1.141876] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.155822] 4806a000.serial: ttyS0 at MMIO 0x4806a000 (irq = 224, base_baud = 3000000) is a 8250
[    1.166656] 4806c000.serial: ttyS1 at MMIO 0x4806c000 (irq = 225, base_baud = 3000000) is a 8250
[    1.177520] 48020000.serial: ttyS2 at MMIO 0x48020000 (irq = 226, base_baud = 3000000) is a 8250
[    1.186889] console [ttyS2] enabled
[    1.186889] console [ttyS2] enabled
[    1.194122] bootconsole [omap8250] disabled
[    1.194122] bootconsole [omap8250] disabled
[    1.204406] 4806e000.serial: ttyS3 at MMIO 0x4806e000 (irq = 227, base_baud = 3000000) is a 8250
[    1.217895] omapdss_dss 58000000.dss: 58000000.dss supply vdda_video not found, using dummy regulator
[    1.227630] DSS: OMAP DSS rev 4.0
[    1.232940] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops)
[    1.242095] omapdss_dss 58000000.dss: bound 58004000.encoder (ops dsi_component_ops)
[    1.251037] omapdss_dss 58000000.dss: bound 58006000.encoder (ops hdmi4_component_ops)
[    1.291046] brd: module loaded
[    1.310607] loop: module loaded
[    1.318725] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.329315] cpcap-core spi1.0: CPCAP vendor: ST rev: 2.10 (1a)
[    1.336914] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
[    1.343994] pgd = c0004000
[    1.346710] [00000000] *pgd=00000000
[    1.350341] Internal error: : 1406 [#1] SMP ARM
[    1.354888] Modules linked in:
[    1.357971] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-00001-g2a481f732c4b #1539
[    1.365936] Hardware name: Generic OMAP4 (Flattened Device Tree)
[    1.371978] task: ee8aadc0 task.stack: ee8ac000
[    1.376556] PC is at lock_release+0x25c/0x360
[    1.380950] LR is at lock_release+0x25c/0x360
[    1.385314] pc : [<c019a4ac>]    lr : [<c019a4ac>]    psr: 20000093
[    1.385314] sp : ee8adb60  ip : c10fc43c  fp : eea05010
[    1.396881] r10: 00000001  r9 : c10f1e70  r8 : 60000093
[    1.402130] r7 : c1007b6c  r6 : c0520658  r5 : ee9fd274  r4 : a0000013
[    1.408691] r3 : ee8aadc0  r2 : 00000003  r1 : 00000003  r0 : 00000000
[    1.415252] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    1.422515] Control: 10c5387d  Table: 8000404a  DAC: 00000051
[    1.428314] Process swapper/0 (pid: 1, stack limit = 0xee8ac218)
[    1.434356] Stack: (0xee8adb60 to 0xee8ae000)
[    1.438751] db60: a0000013 c0520648 00000007 a0000013 ee9fd264 ee9fd264 00000007 eea05100
[    1.446960] db80: c061fe0c eea05000 eea05010 c0add86c 00000000 fc310134 ee9fd264 c0520658
[    1.455200] dba0: 00000020 ee9fd2a4 ee9fd070 00000000 eea05100 c05196f0 ee9fd2a4 eea05010
[    1.463439] dbc0: eef1d580 c0519c20 eea05000 00000021 eef1d580 c01a9508 0000000f c01aa584
[    1.471649] dbe0: ee8000c0 60000013 00000000 eef1d580 00000000 c01a77b8 eef9c400 00000021
[    1.479888] dc00: c061fe0c eea05000 eea05010 c01a9890 00002084 00000204 eef9c400 c10a7bc8
[    1.488128] dc20: 00000001 eef18600 00000000 00000000 00000000 c0620d7c c0d93c60 eef9c400
[    1.496368] dc40: 00000000 efd93038 ef6a85d0 0000014e 00000021 00000084 00000084 eef18600
[    1.504577] dc60: eef1de90 00000021 00000084 eef19000 00000010 eef1e93c c0b613dc c0620f54
[    1.512817] dc80: c10a7bc8 ee8adc8c 00000004 eef19000 eef19000 eef18600 00000021 eef17f90
[    1.521057] dca0: eef1e810 c062bd68 ffffffff c10a7bc8 eef17f98 ee8aadc0 00000001 00000000
[    1.529266] dcc0: c10a7bc8 00000010 00000000 00000000 eef19000 eef19000 eef17f90 00000000
[    1.537506] dce0: 00000010 0000001a 00000013 00000000 00000000 c062bef0 0000000a 0000001a
[    1.545745] dd00: 00000000 00000013 00000000 eef19000 c10a7b78 00000000 c10a7b88 00000000
[    1.553985] dd20: 00000000 c06a06b8 eef19000 c18bfe4c 00000000 c05fcd9c 00000000 ee8add70
[    1.562194] dd40: c05fcee8 00000001 00000000 c18bfe08 00000000 c05fb2d4 ee9eccd4 eef13c54
[    1.570434] dd60: eef19000 eef19034 c10affe0 c05fca58 eef19000 00000001 c18bfe08 eef19008
[    1.578674] dd80: eef19000 c10affe0 00000000 c05fc0d4 eef19008 eecdc000 eef19000 c05fa478
[    1.586914] dda0: 00000000 eef19000 eef19260 00000000 eef19000 eecdc000 00000000 eea61c10
[    1.595123] ddc0: 00000001 00000000 c0d7f208 c06a184c eecdc000 ef6e9a2c ef6e9a7c eef19000
[    1.603363] dde0: 00000001 c06a20ac 00000000 00000002 c0add880 eea61c10 c06a1bd8 002dc6c0
[    1.611602] de00: eea61c10 eef17210 eecdc000 eecdc000 eea61c10 eea61c10 c0da4ba0 c0da4b98
[    1.619812] de20: 000001f0 c06a243c 00000000 eecdc4e0 eecdc000 eecdc000 eea61c10 c06a5e60
[    1.628051] de40: 00000000 60000013 c1897138 00000004 8132535b eea61c10 ffffffed c10b0c74
[    1.636291] de60: fffffdfb 00000000 00000000 c0f66858 c0f005a8 c05fecf8 eea61c10 c18bfe4c
[    1.644531] de80: 00000000 c10b0c74 00000000 c05fcd9c eea61c10 c10b0c74 eea61c44 00000000
[    1.652740] dea0: c10f8000 00000007 c0f66858 c05fcee4 00000000 c10b0c74 c05fce24 c05fb228
[    1.660980] dec0: ee8a58a4 eea5ac50 c10b0c74 eef13580 c10a5720 c05fc2e4 c0d332c0 c0f4365c
[    1.669219] dee0: 00000000 c10b0c74 c0f4365c 00000000 c0e4f6ec c05fdd28 ffffe000 c0f4365c
[    1.677429] df00: 00000000 c0101874 00000134 00000000 efffec00 efffecdd c0e50efc 00000134
[    1.685668] df20: 00000134 c015f5dc c0e4f6ec 00000000 00000006 00000006 efffecdd 00000000
[    1.693908] df40: c0f7f7cc 00000006 c10f8000 c0f6684c c0f7fe74 c10f8000 c0f66850 c10f8000
[    1.702148] df60: 00000007 c0f00eb4 00000006 00000006 00000000 c0f005a8 c0ad652c 00000134
[    1.710357] df80: 00000000 00000000 c0ad652c 00000000 00000000 00000000 00000000 00000000
[    1.718597] dfa0: 00000000 c0ad6534 00000000 c01077d0 00000000 00000000 00000000 00000000
[    1.726837] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.735046] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 c0c0c0c0 c0c0c0c0
[    1.743316] [<c019a4ac>] (lock_release) from [<c0add86c>] (_raw_spin_unlock_irqrestore+0x1c/0x44)
[    1.752258] [<c0add86c>] (_raw_spin_unlock_irqrestore) from [<c0520658>] (omap_gpio_get_direction+0x38/0x44)
[    1.762145] [<c0520658>] (omap_gpio_get_direction) from [<c05196f0>] (gpiochip_lock_as_irq+0x98/0xe4)
[    1.771423] [<c05196f0>] (gpiochip_lock_as_irq) from [<c0519c20>] (gpiochip_irq_reqres+0x2c/0x6c)
[    1.780364] [<c0519c20>] (gpiochip_irq_reqres) from [<c01a9508>] (__setup_irq+0x46c/0x69c)
[    1.788696] [<c01a9508>] (__setup_irq) from [<c01a9890>] (request_threaded_irq+0xcc/0x14c)
[    1.796997] [<c01a9890>] (request_threaded_irq) from [<c0620d7c>] (regmap_add_irq_chip+0x794/0x914)
[    1.806121] [<c0620d7c>] (regmap_add_irq_chip) from [<c0620f54>] (devm_regmap_add_irq_chip+0x58/0xb4)
[    1.815399] [<c0620f54>] (devm_regmap_add_irq_chip) from [<c062bd68>] (cpcap_init_irq_chip+0x138/0x16c)
[    1.824859] [<c062bd68>] (cpcap_init_irq_chip) from [<c062bef0>] (cpcap_probe+0x154/0x264)
[    1.833190] [<c062bef0>] (cpcap_probe) from [<c06a06b8>] (spi_drv_probe+0x7c/0xac)
[    1.840820] [<c06a06b8>] (spi_drv_probe) from [<c05fcd9c>] (driver_probe_device+0x260/0x2e8)
[    1.849334] [<c05fcd9c>] (driver_probe_device) from [<c05fb2d4>] (bus_for_each_drv+0x64/0x98)
[    1.857910] [<c05fb2d4>] (bus_for_each_drv) from [<c05fca58>] (__device_attach+0xb0/0x118)
[    1.866241] [<c05fca58>] (__device_attach) from [<c05fc0d4>] (bus_probe_device+0x88/0x90)
[    1.874450] [<c05fc0d4>] (bus_probe_device) from [<c05fa478>] (device_add+0x3c8/0x57c)
[    1.882446] [<c05fa478>] (device_add) from [<c06a184c>] (spi_add_device+0x90/0x134)
[    1.890136] [<c06a184c>] (spi_add_device) from [<c06a20ac>] (spi_register_master+0x444/0x7a4)
[    1.898742] [<c06a20ac>] (spi_register_master) from [<c06a243c>] (devm_spi_register_master+0x30/0x70)
[    1.908020] [<c06a243c>] (devm_spi_register_master) from [<c06a5e60>] (omap2_mcspi_probe+0x278/0x354)
[    1.917297] [<c06a5e60>] (omap2_mcspi_probe) from [<c05fecf8>] (platform_drv_probe+0x50/0xb0)
[    1.925872] [<c05fecf8>] (platform_drv_probe) from [<c05fcd9c>] (driver_probe_device+0x260/0x2e8)
[    1.934814] [<c05fcd9c>] (driver_probe_device) from [<c05fcee4>] (__driver_attach+0xc0/0xc4)
[    1.943298] [<c05fcee4>] (__driver_attach) from [<c05fb228>] (bus_for_each_dev+0x6c/0xa0)
[    1.951538] [<c05fb228>] (bus_for_each_dev) from [<c05fc2e4>] (bus_add_driver+0x100/0x210)
[    1.959869] [<c05fc2e4>] (bus_add_driver) from [<c05fdd28>] (driver_register+0x78/0xf4)
[    1.967926] [<c05fdd28>] (driver_register) from [<c0101874>] (do_one_initcall+0x3c/0x170)
[    1.976165] [<c0101874>] (do_one_initcall) from [<c0f00eb4>] (kernel_init_freeable+0x210/0x2dc)
[    1.984924] [<c0f00eb4>] (kernel_init_freeable) from [<c0ad6534>] (kernel_init+0x8/0x114)
[    1.993164] [<c0ad6534>] (kernel_init) from [<c01077d0>] (ret_from_fork+0x14/0x24)
[    2.000793] Code: e121f008 eaffffc4 e5993010 eb005645 (e3500000) 
[    2.006927] ---[ end trace 2992a491dcf791c6 ]---
[    2.011627] ------------[ cut here ]------------
[    2.016296] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x21c/0x348
[    2.025482] 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Read): Data Access in User mode during Functional access
[    2.036682] Modules linked in:
[    2.039764] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G      D         4.12.0-00001-g2a481f732c4b #1539
[    2.048950] Hardware name: Generic OMAP4 (Flattened Device Tree)
[    2.054992] [<c0110260>] (unwind_backtrace) from [<c010c2dc>] (show_stack+0x10/0x14)
[    2.062805] [<c010c2dc>] (show_stack) from [<c04d2e20>] (dump_stack+0xac/0xe0)
[    2.070068] [<c04d2e20>] (dump_stack) from [<c013ab90>] (__warn+0xd8/0x104)
[    2.077087] [<c013ab90>] (__warn) from [<c013abf0>] (warn_slowpath_fmt+0x34/0x44)
[    2.084625] [<c013abf0>] (warn_slowpath_fmt) from [<c050df7c>] (l3_interrupt_handler+0x21c/0x348)
[    2.093566] [<c050df7c>] (l3_interrupt_handler) from [<c01a7344>] (__handle_irq_event_percpu+0x48/0x3b4)
[    2.103118] [<c01a7344>] (__handle_irq_event_percpu) from [<c01a76cc>] (handle_irq_event_percpu+0x1c/0x58)
[    2.112823] [<c01a76cc>] (handle_irq_event_percpu) from [<c01a7740>] (handle_irq_event+0x38/0x5c)
[    2.121765] [<c01a7740>] (handle_irq_event) from [<c01aab5c>] (handle_fasteoi_irq+0xcc/0x1ac)
[    2.130340] [<c01aab5c>] (handle_fasteoi_irq) from [<c01a6640>] (generic_handle_irq+0x20/0x34)
[    2.139038] [<c01a6640>] (generic_handle_irq) from [<c01a6ba8>] (__handle_domain_irq+0x64/0xe0)
[    2.147766] [<c01a6ba8>] (__handle_domain_irq) from [<c010155c>] (gic_handle_irq+0x54/0xb8)
[    2.156188] [<c010155c>] (gic_handle_irq) from [<c0addfb0>] (__irq_svc+0x70/0x98)
[    2.163726] Exception stack(0xee8ad898 to 0xee8ad8e0)
[    2.168792] d880:                                                       c0142080 c10f9640
[    2.177032] d8a0: 00000000 00000000 ffffe000 00000000 ee8ac000 00000000 00000001 ee80e400
[    2.185272] d8c0: c10081ac 00000082 00200144 ee8ad8e8 c0142080 c0142084 60000113 ffffffff
[    2.193511] [<c0addfb0>] (__irq_svc) from [<c0142084>] (__do_softirq+0xb4/0x510)
[    2.200958] [<c0142084>] (__do_softirq) from [<c0142860>] (irq_exit+0xe4/0x160)
[    2.208312] [<c0142860>] (irq_exit) from [<c01a6bb0>] (__handle_domain_irq+0x6c/0xe0)
[    2.216217] [<c01a6bb0>] (__handle_domain_irq) from [<c010155c>] (gic_handle_irq+0x54/0xb8)
[    2.224609] [<c010155c>] (gic_handle_irq) from [<c0addfb0>] (__irq_svc+0x70/0x98)
[    2.232147] Exception stack(0xee8ad988 to 0xee8ad9d0)
[    2.237213] d980:                   c0add8b8 ee8aadc0 00000000 00000000 ee8afb44 0000000b
[    2.245452] d9a0: ffffe000 00000000 00000000 00000001 c019a4ae c019a4b0 ee8ac000 ee8ad9d8
[    2.253692] d9c0: c0add8b8 c0add8bc 60000113 ffffffff
[    2.258789] [<c0addfb0>] (__irq_svc) from [<c0add8bc>] (_raw_spin_unlock_irq+0x28/0x2c)
[    2.266845] [<c0add8bc>] (_raw_spin_unlock_irq) from [<c0140e68>] (do_exit+0x810/0xbe4)
[    2.274902] [<c0140e68>] (do_exit) from [<c010c6d0>] (die+0x3f0/0x490)
[    2.281463] [<c010c6d0>] (die) from [<c01013cc>] (do_DataAbort+0xa8/0xb8)
[    2.288299] [<c01013cc>] (do_DataAbort) from [<c0addf04>] (__dabt_svc+0x64/0xa0)
[    2.295745] Exception stack(0xee8adb10 to 0xee8adb58)
[    2.300811] db00:                                     00000000 00000003 00000003 ee8aadc0
[    2.309051] db20: a0000013 ee9fd274 c0520658 c1007b6c 60000093 c10f1e70 00000001 eea05010
[    2.317291] db40: c10fc43c ee8adb60 c019a4ac c019a4ac 20000093 ffffffff
[    2.323944] [<c0addf04>] (__dabt_svc) from [<c019a4ac>] (lock_release+0x25c/0x360)
[    2.331573] [<c019a4ac>] (lock_release) from [<c0add86c>] (_raw_spin_unlock_irqrestore+0x1c/0x44)
[    2.340484] [<c0add86c>] (_raw_spin_unlock_irqrestore) from [<c0520658>] (omap_gpio_get_direction+0x38/0x44)
[    2.350402] [<c0520658>] (omap_gpio_get_direction) from [<c05196f0>] (gpiochip_lock_as_irq+0x98/0xe4)
[    2.359680] [<c05196f0>] (gpiochip_lock_as_irq) from [<c0519c20>] (gpiochip_irq_reqres+0x2c/0x6c)
[    2.368591] [<c0519c20>] (gpiochip_irq_reqres) from [<c01a9508>] (__setup_irq+0x46c/0x69c)
[    2.376922] [<c01a9508>] (__setup_irq) from [<c01a9890>] (request_threaded_irq+0xcc/0x14c)
[    2.385253] [<c01a9890>] (request_threaded_irq) from [<c0620d7c>] (regmap_add_irq_chip+0x794/0x914)
[    2.394348] [<c0620d7c>] (regmap_add_irq_chip) from [<c0620f54>] (devm_regmap_add_irq_chip+0x58/0xb4)
[    2.403656] [<c0620f54>] (devm_regmap_add_irq_chip) from [<c062bd68>] (cpcap_init_irq_chip+0x138/0x16c)
[    2.413085] [<c062bd68>] (cpcap_init_irq_chip) from [<c062bef0>] (cpcap_probe+0x154/0x264)
[    2.421417] [<c062bef0>] (cpcap_probe) from [<c06a06b8>] (spi_drv_probe+0x7c/0xac)
[    2.429046] [<c06a06b8>] (spi_drv_probe) from [<c05fcd9c>] (driver_probe_device+0x260/0x2e8)
[    2.437530] [<c05fcd9c>] (driver_probe_device) from [<c05fb2d4>] (bus_for_each_drv+0x64/0x98)
[    2.446136] [<c05fb2d4>] (bus_for_each_drv) from [<c05fca58>] (__device_attach+0xb0/0x118)
[    2.454437] [<c05fca58>] (__device_attach) from [<c05fc0d4>] (bus_probe_device+0x88/0x90)
[    2.462677] [<c05fc0d4>] (bus_probe_device) from [<c05fa478>] (device_add+0x3c8/0x57c)
[    2.470642] [<c05fa478>] (device_add) from [<c06a184c>] (spi_add_device+0x90/0x134)
[    2.478363] [<c06a184c>] (spi_add_device) from [<c06a20ac>] (spi_register_master+0x444/0x7a4)
[    2.486938] [<c06a20ac>] (spi_register_master) from [<c06a243c>] (devm_spi_register_master+0x30/0x70)
[    2.496215] [<c06a243c>] (devm_spi_register_master) from [<c06a5e60>] (omap2_mcspi_probe+0x278/0x354)
[    2.505523] [<c06a5e60>] (omap2_mcspi_probe) from [<c05fecf8>] (platform_drv_probe+0x50/0xb0)
[    2.514099] [<c05fecf8>] (platform_drv_probe) from [<c05fcd9c>] (driver_probe_device+0x260/0x2e8)
[    2.523040] [<c05fcd9c>] (driver_probe_device) from [<c05fcee4>] (__driver_attach+0xc0/0xc4)
[    2.531524] [<c05fcee4>] (__driver_attach) from [<c05fb228>] (bus_for_each_dev+0x6c/0xa0)
[    2.539764] [<c05fb228>] (bus_for_each_dev) from [<c05fc2e4>] (bus_add_driver+0x100/0x210)
[    2.548065] [<c05fc2e4>] (bus_add_driver) from [<c05fdd28>] (driver_register+0x78/0xf4)
[    2.556152] [<c05fdd28>] (driver_register) from [<c0101874>] (do_one_initcall+0x3c/0x170)
[    2.564361] [<c0101874>] (do_one_initcall) from [<c0f00eb4>] (kernel_init_freeable+0x210/0x2dc)
[    2.573120] [<c0f00eb4>] (kernel_init_freeable) from [<c0ad6534>] (kernel_init+0x8/0x114)
[    2.581359] [<c0ad6534>] (kernel_init) from [<c01077d0>] (ret_from_fork+0x14/0x24)
[    2.588989] ---[ end trace 2992a491dcf791c7 ]---
[    2.593749] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    2.593749] 
[    2.602966] CPU1: stopping
[    2.605682] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D W       4.12.0-00001-g2a481f732c4b #1539
[    2.614898] Hardware name: Generic OMAP4 (Flattened Device Tree)
[    2.620971] [<c0110260>] (unwind_backtrace) from [<c010c2dc>] (show_stack+0x10/0x14)
[    2.628784] [<c010c2dc>] (show_stack) from [<c04d2e20>] (dump_stack+0xac/0xe0)
[    2.636047] [<c04d2e20>] (dump_stack) from [<c010e720>] (handle_IPI+0x300/0x408)
[    2.643524] [<c010e720>] (handle_IPI) from [<c01015a4>] (gic_handle_irq+0x9c/0xb8)
[    2.651153] [<c01015a4>] (gic_handle_irq) from [<c0addfb0>] (__irq_svc+0x70/0x98)
[    2.658691] Exception stack(0xee8d7f70 to 0xee8d7fb8)
[    2.663787] 7f60:                                     c0108224 00000000 00000000 00000000
[    2.672027] 7f80: ee8d6000 c1007bd0 c1007b6c c0f89838 c1007fa4 c10502a9 00000000 00000000
[    2.680297] 7fa0: c1007fa4 ee8d7fc0 c0108224 c0108228 60000013 ffffffff
[    2.686950] [<c0addfb0>] (__irq_svc) from [<c0108228>] (arch_cpu_idle+0x20/0x3c)
[    2.694427] [<c0108228>] (arch_cpu_idle) from [<c0189314>] (do_idle+0x164/0x218)
[    2.701873] [<c0189314>] (do_idle) from [<c0189738>] (cpu_startup_entry+0x18/0x1c)
[    2.709503] [<c0189738>] (cpu_startup_entry) from [<8010164c>] (0x8010164c)
[    2.716552] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    2.716552]

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

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

[GIT pull] irq updates for 4.13

Contents

#1685257

#1685271

#1685351

#1685370

#1685371

#1685388

#1685526

#1687988

#1688690

#1689430

#1689505

#1685166

#1685177

#1685586

#1685102

#1685192

#1685203

#1684937

#1684962

#1684980