From: hch@infradead.org (Christoph Hellwig)
To: linux-riscv@lists.infradead.org
Subject: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver
Date: Mon, 10 Sep 2018 09:11:43 -0700 [thread overview]
Message-ID: <20180910161143.GA1053@infradead.org> (raw)
In-Reply-To: <alpine.DEB.2.21.1809101805110.1419@nanos.tec.linutronix.de>
On Mon, Sep 10, 2018 at 06:07:12PM +0200, Thomas Gleixner wrote:
> > Considering above, it is better to have a distinct irqchip and
> > irq_domain for all local interrupts (just like this patch).
>
> If that's the future usage
It's not, at least there has been no proposal for that so far, and I
don't really think it is how the architecture was intended.
> and that's what my impression was, under which I
> changed my mind, yes, then having a domain model is certainly of advantage
> especially when those things end up being different per SoC.
And even if we went down the way of using the other bits it would
be architectureal in the RISC-V spec - these are not available for
vendor specific uses.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Anup Patel <anup@brainfault.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Jason Cooper <jason@lakedaemon.net>,
Marc Zyngier <marc.zyngier@arm.com>,
Palmer Dabbelt <palmer@sifive.com>,
"linux-kernel@vger.kernel.org List"
<linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Atish Patra <atish.patra@wdc.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver
Date: Mon, 10 Sep 2018 09:11:43 -0700 [thread overview]
Message-ID: <20180910161143.GA1053@infradead.org> (raw)
In-Reply-To: <alpine.DEB.2.21.1809101805110.1419@nanos.tec.linutronix.de>
On Mon, Sep 10, 2018 at 06:07:12PM +0200, Thomas Gleixner wrote:
> > Considering above, it is better to have a distinct irqchip and
> > irq_domain for all local interrupts (just like this patch).
>
> If that's the future usage
It's not, at least there has been no proposal for that so far, and I
don't really think it is how the architecture was intended.
> and that's what my impression was, under which I
> changed my mind, yes, then having a domain model is certainly of advantage
> especially when those things end up being different per SoC.
And even if we went down the way of using the other bits it would
be architectureal in the RISC-V spec - these are not available for
vendor specific uses.
next prev parent reply other threads:[~2018-09-10 16:11 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 12:36 [PATCH v2 0/5] New RISC-V Local Interrupt Controller Driver Anup Patel
2018-09-06 12:36 ` Anup Patel
2018-09-06 12:36 ` [PATCH v2 1/5] RISC-V: self-contained IPI handling routine Anup Patel
2018-09-06 12:36 ` Anup Patel
2018-09-06 12:36 ` [PATCH v2 2/5] RISC-V: No need to pass scause as arg to do_IRQ() Anup Patel
2018-09-06 12:36 ` Anup Patel
2018-09-06 12:36 ` [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver Anup Patel
2018-09-06 12:36 ` Anup Patel
2018-09-06 14:06 ` Christoph Hellwig
2018-09-06 14:06 ` Christoph Hellwig
2018-09-06 14:19 ` Anup Patel
2018-09-06 14:19 ` Anup Patel
2018-09-08 10:46 ` Thomas Gleixner
2018-09-08 10:46 ` Thomas Gleixner
2018-09-10 13:29 ` Christoph Hellwig
2018-09-10 13:29 ` Christoph Hellwig
2018-09-10 13:34 ` Thomas Gleixner
2018-09-10 13:34 ` Thomas Gleixner
2018-09-10 13:37 ` Thomas Gleixner
2018-09-10 13:37 ` Thomas Gleixner
2018-09-10 13:39 ` Christoph Hellwig
2018-09-10 13:39 ` Christoph Hellwig
2018-09-10 13:45 ` Thomas Gleixner
2018-09-10 13:45 ` Thomas Gleixner
2018-09-10 13:49 ` Christoph Hellwig
2018-09-10 13:49 ` Christoph Hellwig
2018-09-10 14:29 ` Anup Patel
2018-09-10 14:29 ` Anup Patel
2018-09-10 16:07 ` Thomas Gleixner
2018-09-10 16:07 ` Thomas Gleixner
2018-09-10 16:11 ` Christoph Hellwig [this message]
2018-09-10 16:11 ` Christoph Hellwig
2018-09-10 16:35 ` Anup Patel
2018-09-10 16:35 ` Anup Patel
2018-09-10 16:39 ` Christoph Hellwig
2018-09-10 16:39 ` Christoph Hellwig
2018-09-10 17:11 ` Anup Patel
2018-09-10 17:11 ` Anup Patel
2018-09-10 19:37 ` Thomas Gleixner
2018-09-10 19:37 ` Thomas Gleixner
2018-09-10 22:19 ` Christoph Hellwig
2018-09-10 22:19 ` Christoph Hellwig
2018-09-11 3:57 ` Anup Patel
2018-09-11 3:57 ` Anup Patel
2018-09-11 6:22 ` Christoph Hellwig
2018-09-11 6:22 ` Christoph Hellwig
2018-09-10 22:16 ` Christoph Hellwig
2018-09-10 22:16 ` Christoph Hellwig
2018-09-10 16:13 ` Christoph Hellwig
2018-09-10 16:13 ` Christoph Hellwig
2018-09-10 16:32 ` Anup Patel
2018-09-10 16:32 ` Anup Patel
2018-09-10 16:35 ` Christoph Hellwig
2018-09-10 16:35 ` Christoph Hellwig
2018-09-10 16:38 ` Anup Patel
2018-09-10 16:38 ` Anup Patel
2018-09-17 14:14 ` Christoph Hellwig
2018-09-17 14:14 ` Christoph Hellwig
2018-09-17 14:28 ` Anup Patel
2018-09-17 14:28 ` Anup Patel
2018-09-26 5:54 ` Anup Patel
2018-09-26 5:54 ` Anup Patel
2018-09-26 5:54 ` Anup Patel
2018-09-26 15:38 ` Palmer Dabbelt
2018-09-26 15:38 ` Palmer Dabbelt
2018-09-26 15:38 ` Palmer Dabbelt
2018-09-06 12:36 ` [PATCH v2 4/5] clocksource: riscv_timer: Make timer interrupt as a per-CPU interrupt Anup Patel
2018-09-06 12:36 ` Anup Patel
2018-09-06 12:36 ` [PATCH v2 5/5] RISC-V: Remove do_IRQ() function Anup Patel
2018-09-06 12:36 ` Anup Patel
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=20180910161143.GA1053@infradead.org \
--to=hch@infradead.org \
--cc=linux-riscv@lists.infradead.org \
/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.