Regarding hw irq to Linux irq mapping on ARM

Regarding hw irq to Linux irq mapping on ARM

[Grant Likely]

On Tue, Sep 21, 2010 at 7:25 AM, Shaju Abraham <shaju.abraham@linaro.org> wrote:
> Hi Grant
>
> Since there does not exist a mechanism to map the hw irq to linux irq
> on ARM (device tree), I would like to discuss ?with you the plans or
> ideas to implement the same.

I don't have any immediate plans, but this topic has come up a lot in
the last two weeks, so I guess I need to focus on it.  :-)  [cc'ing
devicetree-discuss and linux-arm-kernel as well as Lorenzo and Eric
since this is a conversation that should be had publically]

> Can you share with me your thoughts on it?
> I have browsed through the power pc code for the same. But not sure
> the same approach is usable on ARM as well.

I haven't thought deeply about the powerpc implementation of virqs to
determine if it is suitable for other architectures or not, but the
concept behind it is sound.  We need a method of mapping controller
specific IRQ (or hw irq) numbers into the global Linux irq space
(referred to a virqs from this point on).  First it requires a
per-controller reference which can be a pointer to a per-controller
data structure, or any other unique identifier.  It could even be the
interrupt controller device tree node pointer.  Just so long as there
is a reliable method to derive the virq from the controller reference
+ hw irq number.

There also needs to be a method for each interrupt controller to
register itself and allocate a portion of the virq range.  This
shouldn't be too hard.  PowerPC handles this with the irq_map[] flat
table.  This approach is limited to whatever NR_IRQs is set to, and
could potentially be limited by that, but on the other hand the number
of discrete IRQ sources in a system is limited so a flat table
(instead of a dynamic hash table) is probably sufficient.  It is
certainly simpler to implement.

I think the first step is to simply try generalizing the code in
arch/powerpc/kernel/irq.c.  It isn't very complex and it would give a
better impression of what needs to be done.  The ARM interrupt
controller drivers would need to be modified to register with the virq
infrastructure.  None of this is either ARM or OF specific; it would
be useful for any system than need to dynamically allocate IRQ
numbers.  I could see some x86 use cases (Xilinx FPGAs) where this
would be useful.

g.

Regarding hw irq to Linux irq mapping on ARM

[Thomas Gleixner]

On Tue, 21 Sep 2010, Grant Likely wrote:
> On Tue, Sep 21, 2010 at 7:25 AM, Shaju Abraham <shaju.abraham@linaro.org> wrote:
> > Hi Grant
> >
> > Since there does not exist a mechanism to map the hw irq to linux irq
> > on ARM (device tree), I would like to discuss ?with you the plans or
> > ideas to implement the same.
> 
> I don't have any immediate plans, but this topic has come up a lot in
> the last two weeks, so I guess I need to focus on it.  :-)  [cc'ing
> devicetree-discuss and linux-arm-kernel as well as Lorenzo and Eric
> since this is a conversation that should be had publically]
> 
> > Can you share with me your thoughts on it?
> > I have browsed through the power pc code for the same. But not sure
> > the same approach is usable on ARM as well.
> 
> I haven't thought deeply about the powerpc implementation of virqs to
> determine if it is suitable for other architectures or not, but the
> concept behind it is sound.  We need a method of mapping controller
> specific IRQ (or hw irq) numbers into the global Linux irq space
> (referred to a virqs from this point on).  First it requires a
> per-controller reference which can be a pointer to a per-controller
> data structure, or any other unique identifier.  It could even be the
> interrupt controller device tree node pointer.  Just so long as there
> is a reliable method to derive the virq from the controller reference
> + hw irq number.
> 
> There also needs to be a method for each interrupt controller to
> register itself and allocate a portion of the virq range.  This
> shouldn't be too hard.  PowerPC handles this with the irq_map[] flat
> table.  This approach is limited to whatever NR_IRQs is set to, and
> could potentially be limited by that, but on the other hand the number
> of discrete IRQ sources in a system is limited so a flat table
> (instead of a dynamic hash table) is probably sufficient.  It is
> certainly simpler to implement.
> 
> I think the first step is to simply try generalizing the code in
> arch/powerpc/kernel/irq.c.  It isn't very complex and it would give a
> better impression of what needs to be done.  The ARM interrupt
> controller drivers would need to be modified to register with the virq
> infrastructure.  None of this is either ARM or OF specific; it would
> be useful for any system than need to dynamically allocate IRQ
> numbers.  I could see some x86 use cases (Xilinx FPGAs) where this
> would be useful.

Add all the I2C, SPI based irq extenders to that list. They seem to
pop up all over the place in rapid speed even in x86. We are happy
citizens of the embedded horror^Wuniverse now.

Thanks,

	tglx

Regarding hw irq to Linux irq mapping on ARM

[Benjamin Herrenschmidt]

On Tue, 2010-09-21 at 16:57 -0300, Grant Likely wrote:
> On Tue, Sep 21, 2010 at 7:25 AM, Shaju Abraham <shaju.abraham@linaro.org> wrote:
> > Hi Grant
> >
> > Since there does not exist a mechanism to map the hw irq to linux irq
> > on ARM (device tree), I would like to discuss  with you the plans or
> > ideas to implement the same.

Note that the powerpc hw -> linux IRQ mapping (virtualized irq numbering
scheme) is orthogonal to the device-tree. It can be used without the
device-tree and the device-tree doesn't mandate such a scheme.

However, when used together, it does provide some nice features such as
making most cases of cascaded controllers totally trivial.

> I don't have any immediate plans, but this topic has come up a lot in
> the last two weeks, so I guess I need to focus on it.  :-)  [cc'ing
> devicetree-discuss and linux-arm-kernel as well as Lorenzo and Eric
> since this is a conversation that should be had publically]
> 
> > Can you share with me your thoughts on it?
> > I have browsed through the power pc code for the same. But not sure
> > the same approach is usable on ARM as well.
> 
> I haven't thought deeply about the powerpc implementation of virqs to
> determine if it is suitable for other architectures or not, but the
> concept behind it is sound.  We need a method of mapping controller
> specific IRQ (or hw irq) numbers into the global Linux irq space
> (referred to a virqs from this point on).  First it requires a
> per-controller reference which can be a pointer to a per-controller
> data structure, or any other unique identifier.  It could even be the
> interrupt controller device tree node pointer.  Just so long as there
> is a reliable method to derive the virq from the controller reference
> + hw irq number.

I like keeping it somewhat orthogonal. See how I do that on powerpc.
That way, you can still exploit it, map interrupts etc... even if your
device-tree happens to be deficient or missing.

The main grief one could have with my scheme is the naming of irq_host
which has confused people in the past. It should probably be irq_domain
to make clear what it is. It generally have a 1:1 relationship to the
irq_chip but there are cases where that isn't the case (essentially
where you have multiple irq_chip per domain) for various reasons so it's
better to keep those separate.

> There also needs to be a method for each interrupt controller to
> register itself and allocate a portion of the virq range.  This
> shouldn't be too hard.  PowerPC handles this with the irq_map[] flat
> table.  This approach is limited to whatever NR_IRQs is set to, and
> could potentially be limited by that, but on the other hand the number
> of discrete IRQ sources in a system is limited so a flat table
> (instead of a dynamic hash table) is probably sufficient.  It is
> certainly simpler to implement.

It's an implementation detail. We can make sure nothing accesses the
table directly so we can turn it into something else if needed.

> I think the first step is to simply try generalizing the code in
> arch/powerpc/kernel/irq.c.  It isn't very complex and it would give a
> better impression of what needs to be done.  The ARM interrupt
> controller drivers would need to be modified to register with the virq
> infrastructure.  None of this is either ARM or OF specific; it would
> be useful for any system than need to dynamically allocate IRQ
> numbers.  I could see some x86 use cases (Xilinx FPGAs) where this
> would be useful.

Right.

Cheers
Ben.

Regarding hw irq to Linux irq mapping on ARM

[Grant Likely]

On Tue, Sep 21, 2010 at 7:02 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2010-09-21 at 16:57 -0300, Grant Likely wrote:
>> I don't have any immediate plans, but this topic has come up a lot in
>> the last two weeks, so I guess I need to focus on it. ?:-) ?[cc'ing
>> devicetree-discuss and linux-arm-kernel as well as Lorenzo and Eric
>> since this is a conversation that should be had publically]
>>
>> > Can you share with me your thoughts on it?
>> > I have browsed through the power pc code for the same. But not sure
>> > the same approach is usable on ARM as well.
>>
>> I haven't thought deeply about the powerpc implementation of virqs to
>> determine if it is suitable for other architectures or not, but the
>> concept behind it is sound. ?We need a method of mapping controller
>> specific IRQ (or hw irq) numbers into the global Linux irq space
>> (referred to a virqs from this point on). ?First it requires a
>> per-controller reference which can be a pointer to a per-controller
>> data structure, or any other unique identifier. ?It could even be the
>> interrupt controller device tree node pointer. ?Just so long as there
>> is a reliable method to derive the virq from the controller reference
>> + hw irq number.
>
> I like keeping it somewhat orthogonal. See how I do that on powerpc.
> That way, you can still exploit it, map interrupts etc... even if your
> device-tree happens to be deficient or missing.

Good point.

> The main grief one could have with my scheme is the naming of irq_host
> which has confused people in the past. It should probably be irq_domain
> to make clear what it is. It generally have a 1:1 relationship to the
> irq_chip but there are cases where that isn't the case (essentially
> where you have multiple irq_chip per domain) for various reasons so it's
> better to keep those separate.

Maybe I'll look at crafting a patch to rename it to irq_domain.  It
will be a large patch (about 250 matches), but it would be worth it
for the clarity if the code gets generalized.

g.

Regarding hw irq to Linux irq mapping on ARM

[Grant Likely]

On Tue, Sep 21, 2010 at 6:45 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 21 Sep 2010, Grant Likely wrote:
>> On Tue, Sep 21, 2010 at 7:25 AM, Shaju Abraham <shaju.abraham@linaro.org> wrote:
>> > Hi Grant
>> >
>> > Since there does not exist a mechanism to map the hw irq to linux irq
>> > on ARM (device tree), I would like to discuss ?with you the plans or
>> > ideas to implement the same.
>>
>> I don't have any immediate plans, but this topic has come up a lot in
>> the last two weeks, so I guess I need to focus on it. ?:-) ?[cc'ing
>> devicetree-discuss and linux-arm-kernel as well as Lorenzo and Eric
>> since this is a conversation that should be had publically]
>>
>> > Can you share with me your thoughts on it?
>> > I have browsed through the power pc code for the same. But not sure
>> > the same approach is usable on ARM as well.
>>
>> I haven't thought deeply about the powerpc implementation of virqs to
>> determine if it is suitable for other architectures or not, but the
>> concept behind it is sound. ?We need a method of mapping controller
>> specific IRQ (or hw irq) numbers into the global Linux irq space
>> (referred to a virqs from this point on). ?First it requires a
>> per-controller reference which can be a pointer to a per-controller
>> data structure, or any other unique identifier. ?It could even be the
>> interrupt controller device tree node pointer. ?Just so long as there
>> is a reliable method to derive the virq from the controller reference
>> + hw irq number.
>>
>> There also needs to be a method for each interrupt controller to
>> register itself and allocate a portion of the virq range. ?This
>> shouldn't be too hard. ?PowerPC handles this with the irq_map[] flat
>> table. ?This approach is limited to whatever NR_IRQs is set to, and
>> could potentially be limited by that, but on the other hand the number
>> of discrete IRQ sources in a system is limited so a flat table
>> (instead of a dynamic hash table) is probably sufficient. ?It is
>> certainly simpler to implement.
>>
>> I think the first step is to simply try generalizing the code in
>> arch/powerpc/kernel/irq.c. ?It isn't very complex and it would give a
>> better impression of what needs to be done. ?The ARM interrupt
>> controller drivers would need to be modified to register with the virq
>> infrastructure. ?None of this is either ARM or OF specific; it would
>> be useful for any system than need to dynamically allocate IRQ
>> numbers. ?I could see some x86 use cases (Xilinx FPGAs) where this
>> would be useful.
>
> Add all the I2C, SPI based irq extenders to that list. They seem to
> pop up all over the place in rapid speed even in x86. We are happy
> citizens of the embedded horror^Wuniverse now.

*shudder*

What's the irq handling latency on those?  Glad I haven't had to deal
with any of them yet.

g.

Regarding hw irq to Linux irq mapping on ARM

[Benjamin Herrenschmidt]

On Wed, 2010-09-22 at 00:08 -0300, Grant Likely wrote:
> > Add all the I2C, SPI based irq extenders to that list. They seem to
> > pop up all over the place in rapid speed even in x86. We are happy
> > citizens of the embedded horror^Wuniverse now.
> 
> *shudder*
> 
> What's the irq handling latency on those?  Glad I haven't had to deal
> with any of them yet.

And i2c in many cases want to be called from sleep'able context... might
be a good idea to restrict some of these to threaded interrupts. A whole
different discussion I suppose.

Cheers,
Ben.

Regarding hw irq to Linux irq mapping on ARM

[Eric Miao]

On Wed, Sep 22, 2010 at 1:31 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2010-09-22 at 00:08 -0300, Grant Likely wrote:
>> > Add all the I2C, SPI based irq extenders to that list. They seem to
>> > pop up all over the place in rapid speed even in x86. We are happy
>> > citizens of the embedded horror^Wuniverse now.
>>
>> *shudder*
>>
>> What's the irq handling latency on those? ?Glad I haven't had to deal
>> with any of them yet.
>
> And i2c in many cases want to be called from sleep'able context... might
> be a good idea to restrict some of these to threaded interrupts. A whole
> different discussion I suppose.
>

My problem is that ARM has only one IRQ line, and normally connected to
a SoC specific IRQ controller, the mapping of the controller status bits
into the linux IRQ number is currently handled in an assembly macro for
performance consideration. This can be changed to using a function pointer
for when mutliple SoCs are compiled [1].

All the other IRQs are actually chained to these first level IRQ numbers,
so the other question is how these can be properly mapped. Currently, most
ARM platforms handle this in board level. Taking an example of I2C GPIO
expander pca953x.c, there is a 'irq_base' field in its platform data, this
value could be different from board to board, and the board setup code has
the responsibility to get it right. Other devices having a resource can be
passed the correct IRQ number in its resource array.

My understanding is that this simplest scheme should work in most cases,
the assumption here is that the board setup code knows how to handle the
IRQs, i.e. how many IRQs are used, and how they are actually mapped. The
only requirement is that those external chip driver with IRQ capability
are sanely written with dynamic configuration of its IRQ base and number.

  [1] http://www.spinics.net/lists/arm-kernel/msg88817.html.

> Cheers,
> Ben.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Regarding hw irq to Linux irq mapping on ARM

[Mark Brown]

On Wed, Sep 22, 2010 at 12:08:17AM -0300, Grant Likely wrote:
> On Tue, Sep 21, 2010 at 6:45 PM, Thomas Gleixner <tglx@linutronix.de> wrote:

> > Add all the I2C, SPI based irq extenders to that list. They seem to
> > pop up all over the place in rapid speed even in x86. We are happy
> > citizens of the embedded horror^Wuniverse now.

> *shudder*

> What's the irq handling latency on those?  Glad I haven't had to deal
> with any of them yet.

Milisecondish, but depends on bus congestion and bus type.  You need to
schedule a thread which then does one but typically more register I/O
operations on the device (read one or more IRQ status registers, and
typically write back to acknowledge the interrupts as well).  These tend
for obvious reasons to be for low volume interrupts like jack detection.

Regarding hw irq to Linux irq mapping on ARM

[Mark Brown]

On Wed, Sep 22, 2010 at 11:51:11AM +0100, Mark Brown wrote:
> On Wed, Sep 22, 2010 at 12:08:17AM -0300, Grant Likely wrote:

> > What's the irq handling latency on those?  Glad I haven't had to deal
> > with any of them yet.

> Milisecondish, but depends on bus congestion and bus type.  You need to
> schedule a thread which then does one but typically more register I/O
> operations on the device (read one or more IRQ status registers, and
> typically write back to acknowledge the interrupts as well).  These tend
> for obvious reasons to be for low volume interrupts like jack detection.

Incidentally, if you want to look at an implementation the wm831x
contains an implementation of such a controller (in drivers/mfd/wm831x-irq.c)
the structure of which has been cloned for quite a few of these chips.

Regarding hw irq to Linux irq mapping on ARM

[Shaju Abraham]

On Wed, Sep 22, 2010 at 3:32 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2010-09-21 at 16:57 -0300, Grant Likely wrote:
>> On Tue, Sep 21, 2010 at 7:25 AM, Shaju Abraham <shaju.abraham@linaro.org> wrote:
>> > Hi Grant
>> >
>> > Since there does not exist a mechanism to map the hw irq to linux irq
>> > on ARM (device tree), I would like to discuss ?with you the plans or
>> > ideas to implement the same.
>
> Note that the powerpc hw -> linux IRQ mapping (virtualized irq numbering
> scheme) is orthogonal to the device-tree. It can be used without the
> device-tree and the device-tree doesn't mandate such a scheme.
>
> However, when used together, it does provide some nice features such as
> making most cases of cascaded controllers totally trivial.
>
>> I don't have any immediate plans, but this topic has come up a lot in
>> the last two weeks, so I guess I need to focus on it. ?:-) ?[cc'ing
>> devicetree-discuss and linux-arm-kernel as well as Lorenzo and Eric
>> since this is a conversation that should be had publically]
>>
>> > Can you share with me your thoughts on it?
>> > I have browsed through the power pc code for the same. But not sure
>> > the same approach is usable on ARM as well.
>>
>> I haven't thought deeply about the powerpc implementation of virqs to
>> determine if it is suitable for other architectures or not, but the
>> concept behind it is sound. ?We need a method of mapping controller
>> specific IRQ (or hw irq) numbers into the global Linux irq space
>> (referred to a virqs from this point on). ?First it requires a
>> per-controller reference which can be a pointer to a per-controller
>> data structure, or any other unique identifier. ?It could even be the
>> interrupt controller device tree node pointer. ?Just so long as there
>> is a reliable method to derive the virq from the controller reference
>> + hw irq number.
>
> I like keeping it somewhat orthogonal. See how I do that on powerpc.
> That way, you can still exploit it, map interrupts etc... even if your
> device-tree happens to be deficient or missing.
>
> The main grief one could have with my scheme is the naming of irq_host
> which has confused people in the past. It should probably be irq_domain
> to make clear what it is. It generally have a 1:1 relationship to the
> irq_chip but there are cases where that isn't the case (essentially
> where you have multiple irq_chip per domain) for various reasons so it's
> better to keep those separate.
>

How do we handle multiplexed interrupts ? For example a single interrupt line
representing multple irq sources.
We have ARM systems with  single interrupt line on a VIC  muxed to
192 different GPIO sources (each capable of generating interrupts). For such a
system the virq to hw irq mapping can get complex.





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

Regarding hw irq to Linux irq mapping on ARM

[Grant Likely]

"Shaju Abraham" <shajuabraham@gmail.com> wrote:

>On Wed, Sep 22, 2010 at 3:32 AM, Benjamin Herrenschmidt
><benh@kernel.crashing.org> wrote:
>> The main grief one could have with my scheme is the naming of irq_host
>> which has confused people in the past. It should probably be irq_domain
>> to make clear what it is. It generally have a 1:1 relationship to the
>> irq_chip but there are cases where that isn't the case (essentially
>> where you have multiple irq_chip per domain) for various reasons so it's
>> better to keep those separate.
>>
>
>How do we handle multiplexed interrupts ? For example a single interrupt line
>representing multple irq sources.
>We have ARM systems with  single interrupt line on a VIC  muxed to
>192 different GPIO sources (each capable of generating interrupts). For such a
>system the virq to hw irq mapping can get complex.

Assign a separate irq number to each gpio.  In effect, this makes the gpio controller an irq controller.

g.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Regarding hw irq to Linux irq mapping on ARM

[Ben Dooks]

On 22/09/10 09:59, Eric Miao wrote:
> On Wed, Sep 22, 2010 at 1:31 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Wed, 2010-09-22 at 00:08 -0300, Grant Likely wrote:
>>>> Add all the I2C, SPI based irq extenders to that list. They seem to
>>>> pop up all over the place in rapid speed even in x86. We are happy
>>>> citizens of the embedded horror^Wuniverse now.
>>>
>>> *shudder*
>>>
>>> What's the irq handling latency on those?  Glad I haven't had to deal
>>> with any of them yet.

Some new i2c busses can be in the MHz region, so not so slouchy.

>> And i2c in many cases want to be called from sleep'able context... might
>> be a good idea to restrict some of these to threaded interrupts. A whole
>> different discussion I suppose.

The i2c case, it is generally the code decoding the interrupt that needs
to do this, and is part of the i2c specific driver, and is written as
some form of thread or work-queue.

> 
> My problem is that ARM has only one IRQ line, and normally connected to
> a SoC specific IRQ controller, the mapping of the controller status bits
> into the linux IRQ number is currently handled in an assembly macro for
> performance consideration. This can be changed to using a function pointer
> for when mutliple SoCs are compiled [1].
> 
> All the other IRQs are actually chained to these first level IRQ numbers,
> so the other question is how these can be properly mapped. Currently, most
> ARM platforms handle this in board level. Taking an example of I2C GPIO
> expander pca953x.c, there is a 'irq_base' field in its platform data, this
> value could be different from board to board, and the board setup code has
> the responsibility to get it right. Other devices having a resource can be
> passed the correct IRQ number in its resource array.

Well, this is generally because it was (and maybe still is) to
dynamically get an interrupt number. It would be really useful
to update the IRQ system to allow dynamic interrupt addition.

There are times when it would be useful to have a usb driver
detect a plugin, allocate an interrupt and then register that
with some other part of the system, as one exapmple.

Regarding hw irq to Linux irq mapping on ARM

[Mark Brown]

On Fri, Sep 24, 2010 at 12:45:32AM +0100, Ben Dooks wrote:
> On 22/09/10 09:59, Eric Miao wrote:

> >> And i2c in many cases want to be called from sleep'able context... might
> >> be a good idea to restrict some of these to threaded interrupts. A whole
> >> different discussion I suppose.

> The i2c case, it is generally the code decoding the interrupt that needs
> to do this, and is part of the i2c specific driver, and is written as
> some form of thread or work-queue.

The standard thing these days is a threaded IRQ handler.

Regarding hw irq to Linux irq mapping on ARM

[Ben Dooks]

On 24/09/10 16:06, Mark Brown wrote:
> On Fri, Sep 24, 2010 at 12:45:32AM +0100, Ben Dooks wrote:
>> On 22/09/10 09:59, Eric Miao wrote:
> 
>>>> And i2c in many cases want to be called from sleep'able context... might
>>>> be a good idea to restrict some of these to threaded interrupts. A whole
>>>> different discussion I suppose.
> 
>> The i2c case, it is generally the code decoding the interrupt that needs
>> to do this, and is part of the i2c specific driver, and is written as
>> some form of thread or work-queue.
> 
> The standard thing these days is a threaded IRQ handler.

Yes, however my first point was really do we care the method
for the interrupt's detection when talking about mapping them?

Regarding hw irq to Linux irq mapping on ARM

[Mark Brown]

On Sun, Sep 26, 2010 at 12:08:57AM +0100, Ben Dooks wrote:
> On 24/09/10 16:06, Mark Brown wrote:
> > On Fri, Sep 24, 2010 at 12:45:32AM +0100, Ben Dooks wrote:

> >> The i2c case, it is generally the code decoding the interrupt that needs
> >> to do this, and is part of the i2c specific driver, and is written as
> >> some form of thread or work-queue.

> > The standard thing these days is a threaded IRQ handler.

> Yes, however my first point was really do we care the method
> for the interrupt's detection when talking about mapping them?

Not really in the assignment of numbers but the fact that you're in an
interrupt thread rather than primary IRQ context does make a difference
to the IRQ handler, though some don't actually need to worry about it
and could benefit from being able to specify that they don't mind which
context they're in and can accept either context.