linux-kernel - Re: [PATCH 2/8] irqchip: mips-gic: Use irq_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171030163616.tsti7thormxlnxuo@pburton-laptop>
Date:   Mon, 30 Oct 2017 09:36:16 -0700
From:   Paul Burton <paul.burton@...s.com>
To:     Marc Zyngier <marc.zyngier@....com>
CC:     Paul Burton <paul.burton@...s.com>,
        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

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.

Thanks,
    Paul