All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	kernel-team@android.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Jason Cooper <jason@lakedaemon.net>
Subject: Re: [PATCH v2 1/4] genirq: Walk the irq_data hierarchy when resending an interrupt
Date: Sat, 05 Sep 2020 10:26:33 +0100	[thread overview]
Message-ID: <878sdomv5i.wl-maz@kernel.org> (raw)
In-Reply-To: <jhj4kodxrx5.mognet@arm.com>

Hi Valentin,

On Fri, 04 Sep 2020 20:28:38 +0100,
Valentin Schneider <valentin.schneider@arm.com> wrote:
> 
> 
> Hi Marc,
> 
> On 03/09/20 19:32, Marc Zyngier wrote:
> > On resending an interrupt, we only check the topmost irqchip for
> > a irq_retrigger callback. However, this callback could be implemented
> > at a lower level. Use irq_chip_retrigger_hierarchy() in this case.
> >
> 
> Rookie wording question here; re-reading this I'm questioning which way is
> up.
> 
> From an irq_data hierarchy PoV, the topmost chip (i.e. last ->parent)
> should be the root irqchip. However, the irq_desc we get from irq_to_desc()
> ought to hold the irq_data for the lowermost irqchip in that irq_data
> hierarchy.
> 
> Is it that here by "topmost" you instead mean topmost of the irqchip stack
> on top of the root (IOW furthest away from the root)?

That's indeed what I mean, but I agree that the terminology is
confusing, and often used inconsistently (by me included).

<random>
Maybe considering the irqchip stack along a vertical axis is the wrong
thing to do, and that looking at it as a volume would be marginally
better?

How about innermost (close to the CPU) vs outermost (close to the
device)?
</random>

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Jason Cooper <jason@lakedaemon.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	kernel-team@android.com
Subject: Re: [PATCH v2 1/4] genirq: Walk the irq_data hierarchy when resending an interrupt
Date: Sat, 05 Sep 2020 10:26:33 +0100	[thread overview]
Message-ID: <878sdomv5i.wl-maz@kernel.org> (raw)
In-Reply-To: <jhj4kodxrx5.mognet@arm.com>

Hi Valentin,

On Fri, 04 Sep 2020 20:28:38 +0100,
Valentin Schneider <valentin.schneider@arm.com> wrote:
> 
> 
> Hi Marc,
> 
> On 03/09/20 19:32, Marc Zyngier wrote:
> > On resending an interrupt, we only check the topmost irqchip for
> > a irq_retrigger callback. However, this callback could be implemented
> > at a lower level. Use irq_chip_retrigger_hierarchy() in this case.
> >
> 
> Rookie wording question here; re-reading this I'm questioning which way is
> up.
> 
> From an irq_data hierarchy PoV, the topmost chip (i.e. last ->parent)
> should be the root irqchip. However, the irq_desc we get from irq_to_desc()
> ought to hold the irq_data for the lowermost irqchip in that irq_data
> hierarchy.
> 
> Is it that here by "topmost" you instead mean topmost of the irqchip stack
> on top of the root (IOW furthest away from the root)?

That's indeed what I mean, but I agree that the terminology is
confusing, and often used inconsistently (by me included).

<random>
Maybe considering the irqchip stack along a vertical axis is the wrong
thing to do, and that looking at it as a volume would be marginally
better?

How about innermost (close to the CPU) vs outermost (close to the
device)?
</random>

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2020-09-05  9:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-03 18:32 [PATCH v2 0/4] irqchip/gic: Generalize use of HW-based retriggering Marc Zyngier
2020-09-03 18:32 ` Marc Zyngier
2020-09-03 18:32 ` [PATCH v2 1/4] genirq: Walk the irq_data hierarchy when resending an interrupt Marc Zyngier
2020-09-03 18:32   ` Marc Zyngier
2020-09-04 19:28   ` Valentin Schneider
2020-09-04 19:28     ` Valentin Schneider
2020-09-05  9:26     ` Marc Zyngier [this message]
2020-09-05  9:26       ` Marc Zyngier
2020-09-05 12:58       ` Valentin Schneider
2020-09-05 12:58         ` Valentin Schneider
2020-09-03 18:32 ` [PATCH v2 2/4] irqchip/gic-v2, v3: Implement irq_chip->irq_retrigger() Marc Zyngier
2020-09-03 18:32   ` Marc Zyngier
2020-09-03 18:32 ` [PATCH v2 3/4] irqchip/git-v3-its: Implement irq_retrigger callback for device-triggered LPIs Marc Zyngier
2020-09-03 18:32   ` Marc Zyngier
2020-09-03 18:32 ` [PATCH v2 4/4] irqchip/gic-v2, v3: Prevent SW resends entirely Marc Zyngier
2020-09-03 18:32   ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878sdomv5i.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=jason@lakedaemon.net \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=valentin.schneider@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.