[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54648C95.6020704@arm.com>
Date: Thu, 13 Nov 2014 10:48:53 +0000
From: Marc Zyngier <marc.zyngier@....com>
To: Jiang Liu <jiang.liu@...ux.intel.com>,
Yingjoe Chen <yingjoe.chen@...iatek.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"grant.likely@...aro.org" <grant.likely@...aro.org>,
Yijing Wang <wangyijing@...wei.com>
Subject: Re: [patch 07/16] genirq: Introduce helper irq_domain_set_info()
to reduce duplicated code
On 13/11/14 10:00, Jiang Liu wrote:
> On 2014/11/13 17:57, Yingjoe Chen wrote:
>> On Wed, 2014-11-12 at 13:43 +0000, Thomas Gleixner wrote:
>>> Index: tip/kernel/irq/irqdomain.c
>>> ===================================================================
>>> --- tip.orig/kernel/irq/irqdomain.c
>>> +++ tip/kernel/irq/irqdomain.c
>>> @@ -882,6 +882,16 @@ int irq_domain_set_hwirq_and_chip(struct
>>> return 0;
>>> }
>>>
>>> +void irq_domain_set_info(struct irq_domain *domain, unsigned int virq,
>>> + irq_hw_number_t hwirq, struct irq_chip *chip,
>>> + void *chip_data, irq_flow_handler_t handler,
>>> + void *handler_data, const char *handler_name)
>>> +{
>>> + irq_domain_set_hwirq_and_chip(domain, virq, hwirq, chip, chip_data);
>>> + __irq_set_handler(virq, handler, 0, handler_name);
>>> + irq_set_handler_data(virq, handler_data);
>>> +}
>>> +
>>
>> Hi,
>>
>> While trying to use this function, I'm not sure about its interface.
>> This function have 8 parameters but only save 3 function calls. After
>> checking uses in Jiang's original patch, I think this make code harder
>> to understand.
> Hi Joe,
> It's true, but we also want to reduce duplicated code:(
I'm in two minds about this one.
Yes, it looks horrible (to be fair, I hate anything that has more than 3
or 4 parameters, because I can never remember what they're for).
On the other hand, it gives you a nice check-point in your code, with
all the bits you need to set, or at least consider. Because it depends
on so many things that you may have to construct/obtain, you quickly
realize that there is not that many locations in your stack that fits
these requirements. Yes, this a twisted reasoning.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists