On Jul 9, 2012, at 3:22 PM, Scott Wood wrote:
> On 07/09/2012 02:03 PM, Kumar Gala wrote:
>>
>> On Jul 9, 2012, at 3:47 AM, Varun Sethi wrote:
>>
>>> +int mpic_err_int_init(struct mpic *mpic, irq_hw_number_t irqnum)
>>> +{
>>
>> Why can't we do this during mpic_init() time?
>
> Are you willing to hardcode that IRQ 16 is the error interrupt, without
> waiting to see an intspec?
I'm torn, but the bit of code in mpic_host_xlate that calls mpic_err_int_init()
is just ugly.
We could consider it similar to how we assume IPIs.
>>> + ret = request_irq(virq, fsl_error_int_handler, IRQF_NO_THREAD,
>>> + "mpic-error-int", mpic);
>>
>> Hmm, should we be using irq_set_chained_handler() instead of request_irq
>
> As I said last time, "that's how Varun initially did it and I asked him
> to change it, because it gets a lot trickier to get things right, and I
> didn't see what it was buying us." That original patch had locking
> problems as a result.
>
> Using the chained handler mechanism puts the responsibility on us to do
> a lot of the generic stuff that's already perfectly well implemented in
> generic code. We're implementing a cascade, not a new flow.
Makes sense.
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
