From: Christoph Hellwig <hch@infradead.org>
To: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
Bjorn Helgaas <bhelgaas@google.com>,
James Hogan <jhogan@kernel.org>,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
linux-pci@vger.kernel.org,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Paul Burton <paul.burton@mips.com>,
Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH 7/7] MIPS: SGI-IP27: abstract chipset irq from bridge
Date: Mon, 28 Jan 2019 08:27:21 -0800 [thread overview]
Message-ID: <20190128162721.GA25378@infradead.org> (raw)
In-Reply-To: <20190128150135.66f85834ab80813e6dc5ddf5@suse.de>
On Mon, Jan 28, 2019 at 03:01:35PM +0100, Thomas Bogendoerfer wrote:
> On Mon, 28 Jan 2019 05:33:17 -0800
> Christoph Hellwig <hch@infradead.org> wrote:
>
> > Shouldnt this just use chained irqchip drivers instead?
>
> you mean using irq_set_chained_handler() ? If yes, this IMHO doesn't look usefull
> because it's used for adding a secondary interrupt controller. But what I need
> is telling bridge ASIC to direct the xtalk IRQ packet to a specific HUB/HEART/BEDROCK
> from the HUB/HEART/BEDROCK specific code. And want to avoid dragging in bridge details
> to that specific code.
Yes, but don't we have nested interrupt controllers here? Even if they
don't really do much in the fast path the setup does look chained to me.
Then again I'm not really an expert in the irq handling code nor in this
hardware, so maybe Thomas or Marc might have a better idea.
next prev parent reply other threads:[~2019-01-28 16:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-24 17:47 [PATCH 0/7] MIPS: SGI-IP27 rework Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 1/7] MIPS: SGI-IP27: get rid of volatile and hubreg_t Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 2/7] MIPS: SGI-IP27: clean up bridge access and header files Thomas Bogendoerfer
2019-01-28 13:20 ` Christoph Hellwig
2019-01-28 13:24 ` Thomas Bogendoerfer
2019-01-28 13:33 ` Christoph Hellwig
2019-01-24 17:47 ` [PATCH 3/7] MIPS: SGI-IP27: use pr_info/pr_emerg and pr_cont to fix output Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 4/7] MIPS: SGI-IP27: do xtalk scanning later Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 5/7] MIPS: SGI-IP27: rework HUB interrupts Thomas Bogendoerfer
2019-01-28 13:26 ` Christoph Hellwig
2019-01-24 17:47 ` [PATCH 6/7] MIPS: SGI-IP27: use generic PCI driver Thomas Bogendoerfer
2019-01-28 13:32 ` Christoph Hellwig
2019-01-29 15:24 ` Thomas Bogendoerfer
2019-01-30 9:17 ` Christoph Hellwig
2019-01-30 17:25 ` Thomas Bogendoerfer
2019-01-30 17:28 ` Christoph Hellwig
2019-02-18 10:58 ` Thomas Bogendoerfer
2019-02-20 15:10 ` Christoph Hellwig
2019-02-20 15:20 ` Thomas Bogendoerfer
2019-01-24 17:47 ` [PATCH 7/7] MIPS: SGI-IP27: abstract chipset irq from bridge Thomas Bogendoerfer
2019-01-28 13:33 ` Christoph Hellwig
2019-01-28 14:01 ` Thomas Bogendoerfer
2019-01-28 16:27 ` Christoph Hellwig [this message]
2019-02-01 14:37 ` Thomas Bogendoerfer
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=20190128162721.GA25378@infradead.org \
--to=hch@infradead.org \
--cc=bhelgaas@google.com \
--cc=jhogan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=paul.burton@mips.com \
--cc=ralf@linux-mips.org \
--cc=tbogendoerfer@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).