All of lore.kernel.org
 help / color / mirror / Atom feed
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.

      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 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.