From: Stephen Warren <swarren@wwwdotorg.org>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: tglx@linutronix.de, jason@lakedaemon.net,
linux-rpi-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] irqchip: bcm2835: Add FIQ support
Date: Fri, 10 Jul 2015 22:09:52 -0600 [thread overview]
Message-ID: <55A09710.3030509@wwwdotorg.org> (raw)
In-Reply-To: <5582C87C.20008@tronnes.org>
(Sorry for the slow reply; I was on vacation)
On 06/18/2015 07:32 AM, Noralf Trønnes wrote:
> Den 18.06.2015 04:26, skrev Stephen Warren:
>> On 06/12/2015 11:26 AM, Noralf Trønnes wrote:
>>> Add a duplicate irq range with an offset on the hwirq's so the
>>> driver can detect that enable_fiq() is used.
>>> Tested with downstream dwc_otg USB controller driver.
>> This basically looks OK, but a few comments/thoughts:
>> b) Doesn't the driver need to refuse some operation (handler
>> registration, IRQ setup, IRQ enable, ...?) for more than 1 IRQ in the
>> FIQ range, since the FIQ control register only allows routing 1 IRQ to
>> FIQ.
>
> claim_fiq() protects the FIQ. See d) answer below.
That assumes the IRQ is "accessed" via the fiq-specific APIs. Since this
patch changes the IRQ domain from having n IRQs to having 2*n IRQs, and
doesn't do anything special to prevent clients from using IRQs n..2n-1
via the existing IRQ APIs, it's quite possible the a buggy client would.
(From another email):
>>> c) The DT binding needs updating to describe the extra IRQs:
>>>
>>>> Documentation/devicetree/bindings/interrupt-controller/brcm,bcm28armctrl-ic.txt
>>
>> Ok.
>
> I have seconds thoughts on this:
> This patch does not change the DT bindings so I don't see what update
> I should make. This patch only adds support for the Linux way of
> handling FIQ's through enable_fiq(). It doesn't change how interrupts
> are described in the DT.
The intention of the patch may not be to expand the set of IRQs
available via DT, but it does in practice. I think you need to add a
custom of_xlate for the IRQ domain to ensure that only IRQs 0..n-1 can
be translated from DT, and not IRQs n..2n-1. If you do that, then I
agree that no DT binding update should be required.
Even with a custom of_xlate function, some code could hard-code an IRQ
number and hence end up registering a FIQ handler that way. However, I
guess that's a bug that the driver doesn't need to solve. We can just
fix that bug in the kernel code in that case. The same argument doesn't
apply to bad DTs; we need to more aggressively protect against that case.
>> d) I wonder how the FIQ handler actually gets routed to this controller
>> and hooked to its handler etc. I assume there's a separate patch for
>> that coming?
>
> set_fiq_handler() sets the handler and enable_fiq() enables it:
>
> if (claim_fiq(&fh))
> ERROR;
> set_fiq_handler(...)
> set_fiq_regs(®s);
> enable_fiq(irq);
> local_fiq_enable();
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] irqchip: bcm2835: Add FIQ support
Date: Fri, 10 Jul 2015 22:09:52 -0600 [thread overview]
Message-ID: <55A09710.3030509@wwwdotorg.org> (raw)
In-Reply-To: <5582C87C.20008@tronnes.org>
(Sorry for the slow reply; I was on vacation)
On 06/18/2015 07:32 AM, Noralf Tr?nnes wrote:
> Den 18.06.2015 04:26, skrev Stephen Warren:
>> On 06/12/2015 11:26 AM, Noralf Tr?nnes wrote:
>>> Add a duplicate irq range with an offset on the hwirq's so the
>>> driver can detect that enable_fiq() is used.
>>> Tested with downstream dwc_otg USB controller driver.
>> This basically looks OK, but a few comments/thoughts:
>> b) Doesn't the driver need to refuse some operation (handler
>> registration, IRQ setup, IRQ enable, ...?) for more than 1 IRQ in the
>> FIQ range, since the FIQ control register only allows routing 1 IRQ to
>> FIQ.
>
> claim_fiq() protects the FIQ. See d) answer below.
That assumes the IRQ is "accessed" via the fiq-specific APIs. Since this
patch changes the IRQ domain from having n IRQs to having 2*n IRQs, and
doesn't do anything special to prevent clients from using IRQs n..2n-1
via the existing IRQ APIs, it's quite possible the a buggy client would.
(From another email):
>>> c) The DT binding needs updating to describe the extra IRQs:
>>>
>>>> Documentation/devicetree/bindings/interrupt-controller/brcm,bcm28armctrl-ic.txt
>>
>> Ok.
>
> I have seconds thoughts on this:
> This patch does not change the DT bindings so I don't see what update
> I should make. This patch only adds support for the Linux way of
> handling FIQ's through enable_fiq(). It doesn't change how interrupts
> are described in the DT.
The intention of the patch may not be to expand the set of IRQs
available via DT, but it does in practice. I think you need to add a
custom of_xlate for the IRQ domain to ensure that only IRQs 0..n-1 can
be translated from DT, and not IRQs n..2n-1. If you do that, then I
agree that no DT binding update should be required.
Even with a custom of_xlate function, some code could hard-code an IRQ
number and hence end up registering a FIQ handler that way. However, I
guess that's a bug that the driver doesn't need to solve. We can just
fix that bug in the kernel code in that case. The same argument doesn't
apply to bad DTs; we need to more aggressively protect against that case.
>> d) I wonder how the FIQ handler actually gets routed to this controller
>> and hooked to its handler etc. I assume there's a separate patch for
>> that coming?
>
> set_fiq_handler() sets the handler and enable_fiq() enables it:
>
> if (claim_fiq(&fh))
> ERROR;
> set_fiq_handler(...)
> set_fiq_regs(®s);
> enable_fiq(irq);
> local_fiq_enable();
next prev parent reply other threads:[~2015-07-11 6:49 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 17:26 [PATCH] irqchip: bcm2835: Add FIQ support Noralf Trønnes
2015-06-12 17:26 ` Noralf Trønnes
2015-06-18 2:26 ` Stephen Warren
2015-06-18 2:26 ` Stephen Warren
2015-06-18 13:32 ` Noralf Trønnes
2015-06-18 13:32 ` Noralf Trønnes
2015-06-18 16:23 ` Noralf Trønnes
2015-06-18 16:23 ` Noralf Trønnes
2015-07-11 4:09 ` Stephen Warren [this message]
2015-07-11 4:09 ` Stephen Warren
2015-07-11 15:26 ` Noralf Trønnes
2015-07-11 15:26 ` Noralf Trønnes
2015-07-14 4:50 ` Stephen Warren
2015-07-14 4:50 ` Stephen Warren
2015-07-14 11:48 ` Noralf Trønnes
2015-07-14 11:48 ` Noralf Trønnes
2015-07-22 1:50 ` Stephen Warren
2015-07-22 1:50 ` Stephen Warren
2015-07-22 14:07 ` Noralf Trønnes
2015-07-22 14:07 ` Noralf Trønnes
2015-07-24 4:04 ` Stephen Warren
2015-07-24 4:04 ` Stephen Warren
2015-07-22 21:32 ` Eric Anholt
2015-07-22 21:32 ` Eric Anholt
2015-09-13 19:24 ` Noralf Trønnes
2015-09-13 19:24 ` Noralf Trønnes
2015-09-14 9:08 ` Russell King - ARM Linux
2015-09-14 9:08 ` Russell King - ARM Linux
2015-09-14 14:33 ` Eric Anholt
2015-09-14 14:33 ` Eric Anholt
2015-09-14 14:34 ` Russell King - ARM Linux
2015-09-14 14:34 ` Russell King - ARM Linux
2015-09-16 14:02 ` Eric Anholt
2015-09-16 14:02 ` Eric Anholt
2015-09-16 16:21 ` Russell King - ARM Linux
2015-09-16 16:21 ` Russell King - ARM Linux
2015-09-16 18:48 ` Eric Anholt
2015-09-16 18:48 ` Eric Anholt
2015-09-16 19:13 ` Russell King - ARM Linux
2015-09-16 19:13 ` Russell King - ARM Linux
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=55A09710.3030509@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=noralf@tronnes.org \
--cc=tglx@linutronix.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 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.