From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: question about DOMAIN_BUS_ANY
Date: Wed, 9 Sep 2015 09:07:22 +0100 [thread overview]
Message-ID: <20150909090722.0dd9fa7e@arm.com> (raw)
In-Reply-To: <CY1PR0301MB07485D964A46A10E1F80154D87530@CY1PR0301MB0748.namprd03.prod.outlook.com>
On Tue, 8 Sep 2015 22:41:37 +0000
Stuart Yoder <stuart.yoder@freescale.com> wrote:
Hi Stuart,
> Marc,
>
> Have a question about DOMAIN_BUS_ANY. Based on your comment in
> include/linux/irqdomain.h:
>
> /*
> * Should several domains have the same device node, but serve
> * different purposes (for example one domain is for PCI/MSI, and the
> * other for wired IRQs), they can be distinguished using a
> * bus-specific token. Most domains are expected to only carry
> * DOMAIN_BUS_ANY.
> */
>
> ...if there are 2 domains that are based on the same GIC ITS node,
> for example PCI and the new Freescale "fsl-mc" bus, we should
> be extending irq_domain_bus_token with a new token, correct?
If you have a new bus type that is neither PCI nor PLATFORM, then you
will indeed need a new token to disambiguate the domain.
> The reason "most" domains are expected to have BUS_ANY is because
> most domains have 1 associated device node and there is no ambiguity,
> right?
The opposite, actually. Most devices (MSI controllers) only implement a
single domain, while the ITS already implements two (PCI and
platform) - well technically three, as we also have DOMAIN_NEXUS to
implement the global identifier allocator.
> Currently the fsl-mc bus driver is in drivers/staging. Is that
> an issue with respect to extending the enum? (not 100% sure
> what the rules are regarding drivers in staging and other
> dependencies like this enum which are outside of staging).
If there is a convincing effort to move this code out of staging, then
I can't see why we couldn't extend the enum.
> Another related question... we are implementing a fsl-mc
> bus specific support in a irq-gic-v3-its-fsl-mc-msi.c file,
> similar to what you did for PCI and platform buses. Do you
> want to see that file in drivers/staging for now, or should
> we put it under drivers/irqchip?
I think it can stay with the rest of the code until it is ready to be
merged back to where it belongs. You will also need to implement a
generic fsl-mc-msi domain that acts as the high level interface (you
can probably reuse most of what has already been done on the PCI and
PLATFORM fronts).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
prev parent reply other threads:[~2015-09-09 8:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 22:41 question about DOMAIN_BUS_ANY Stuart Yoder
2015-09-09 8:07 ` Marc Zyngier [this message]
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=20150909090722.0dd9fa7e@arm.com \
--to=marc.zyngier@arm.com \
--cc=linux-arm-kernel@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 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).