[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <867evc5cc9.fsf@arm.com>
Date: Tue, 31 Oct 2017 01:35:02 +0000
From: Marc Zyngier <marc.zyngier@....com>
To: Paul Burton <paul.burton@...s.com>
Cc: Jason Cooper <jason@...edaemon.net>,
Thomas Gleixner <tglx@...utronix.de>,
<linux-mips@...ux-mips.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/8] irqchip: mips-gic: Use irq_cpu_online to (un)mask all-VP(E) IRQs
On Mon, Oct 30 2017 at 9:36:16 am GMT, Paul Burton <paul.burton@...s.com> wrote:
> Hi Marc,
>
> On Mon, Oct 30, 2017 at 08:00:08AM +0000, Marc Zyngier wrote:
>> > static int __init gic_of_init(struct device_node *node,
>> > struct device_node *parent)
>> > @@ -768,6 +806,8 @@ static int __init gic_of_init(struct device_node *node,
>> > }
>> > }
>> >
>> > - return 0;
>> > + return cpuhp_setup_state(CPUHP_AP_IRQ_GIC_STARTING,
>> > + "irqchip/mips/gic:starting",
>> > + gic_cpu_startup, NULL);
>>
>> I'm wondering about this. CPUHP_AP_IRQ_GIC_STARTING is a symbol that is
>> used on ARM platforms. You're very welcome to use it (as long as nobody
>> builds a system with both an ARM GIC and a MIPS GIC...), but I'm a bit
>> worried that we could end-up breaking things if one of us decides to
>> reorder it in enum cpuhp_state.
>>
>> The safest option would be for you to add your own state value, which
>> would allow the two architecture to evolve independently.
>
> I had figured that if something like that ever happens it'd be easy to split
> into 2 states at that point, but sure - I'm happy to add a MIPS-specific state
> now to avoid anyone needing to worry about it.
That would be my preferred option.
Thanks,
M.
--
Jazz is not dead. It just smells funny.
Powered by blists - more mailing lists