linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/6] irqchip: GIC: Use chip_data instead of handler_data for cascaded interrupts
Date: Fri, 10 Jul 2015 09:21:35 +0100	[thread overview]
Message-ID: <559F808F.7080303@arm.com> (raw)
In-Reply-To: <559F7F8C.8080701@linux.intel.com>

On 10/07/15 09:17, Jiang Liu wrote:
> On 2015/7/10 15:52, Marc Zyngier wrote:
>> On 09/07/15 22:33, Thomas Gleixner wrote:
>>> On Thu, 9 Jul 2015, Marc Zyngier wrote:
>>>
>>>> When used as a primary interrupt controller, the GIC driver uses
>>>> irq_data->chip_data to extract controller-specific information.
>>>>
>>>> When used as a secondary interrupt controller, it uses handler_data
>>>> instead. As this difference is relatively pointless and only creates
>>>> confusion, change the secondary path to match what the rest of the
>>>> driver does.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>> ---
>>>>  drivers/irqchip/irq-gic.c | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>>>> index e264675..3c7f3a4 100644
>>>> --- a/drivers/irqchip/irq-gic.c
>>>> +++ b/drivers/irqchip/irq-gic.c
>>>> @@ -298,7 +298,7 @@ static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)
>>>>  
>>>>  static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
>>>>  {
>>>> -	struct gic_chip_data *chip_data = irq_get_handler_data(irq);
>>>> +	struct gic_chip_data *chip_data = irq_get_chip_data(irq);
>>>>  	struct irq_chip *chip = irq_get_chip(irq);
>>>
>>> You should make that
>>>
>>>     chip_data = irq_desc_get_chip_data(desc);
>>>     chip = irq_desc_get_chip(desc);
>>>
>>> That avoids two pointless lookups of irqdesc ....
>>
>> Ah, very good point.
>>
>> And it turns out that these constructs (use of irq_get_* when the
>> irq_desc is readily available) is actually fairly common in a number of
>> irqchip implementations used as secondary interrupt controllers.
>>
>> Time for another cleanup series, I believe... ;-)
> Hi Marc,
> 	I'm ahead of your request and expect an reviewed-by from
> you then:). Please refer to http://lkml.org/lkml/2015/6/4/743 for
> what we have done to clear up this interfaces.

Ah, let me dig this now (yeah, I've been slacking off on reviewing
lately...). Looks awesome! :-)

Thanks!

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2015-07-10  8:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09 13:19 [PATCH 0/6] irqchip: GICv2/v3: Add support for irq_vcpu_affinity Marc Zyngier
2015-07-09 13:19 ` [PATCH 1/6] irqchip: GICv3: Convert to EOImode == 1 Marc Zyngier
2015-08-11  9:14   ` Eric Auger
2015-08-12 12:38     ` Marc Zyngier
2015-07-09 13:19 ` [PATCH 2/6] irqchip: GIC: " Marc Zyngier
2015-08-11  9:15   ` Eric Auger
2015-08-12 13:31     ` Marc Zyngier
2015-08-12 17:40       ` Catalin Marinas
2015-07-09 13:19 ` [PATCH 3/6] irqchip: GICv3: Skip LPI deactivation Marc Zyngier
2015-08-11  9:42   ` Eric Auger
2015-08-12 13:34     ` Marc Zyngier
2015-08-12 14:28       ` Eric Auger
2015-07-09 13:19 ` [PATCH 4/6] irqchip: GIC: Use chip_data instead of handler_data for cascaded interrupts Marc Zyngier
2015-07-09 21:33   ` Thomas Gleixner
2015-07-10  7:52     ` Marc Zyngier
2015-07-10  8:17       ` Jiang Liu
2015-07-10  8:21         ` Marc Zyngier [this message]
2015-08-11  9:45   ` Eric Auger
2015-08-12 13:41     ` Marc Zyngier
2015-07-09 13:19 ` [PATCH 5/6] irqchip: GICv3: Don't deactivate interrupts forwarded to a guest Marc Zyngier
2015-08-11 10:03   ` Eric Auger
2015-08-12 14:20     ` Marc Zyngier
2015-08-12 15:09       ` Eric Auger
2015-08-12 15:40         ` Marc Zyngier
2015-08-12 15:51           ` Eric Auger
2015-07-09 13:19 ` [PATCH 6/6] irqchip: GIC: " Marc Zyngier
2015-08-11 10:06 ` [PATCH 0/6] irqchip: GICv2/v3: Add support for irq_vcpu_affinity Eric Auger
2015-08-12 14:21   ` Marc Zyngier

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=559F808F.7080303@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).