linux-kernel - Re: [PATCH v4 2/2] irqchip: add J-Core AIC driver

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]

Date:	Wed, 27 Jul 2016 09:08:21 -0400
From:	Rich Felker <dalias@...c.org>
To:	Mark Rutland <mark.rutland@....com>
Cc:	linux-kernel@...r.kernel.org, linux-sh@...r.kernel.org,
	devicetree@...r.kernel.org, Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <marc.zyngier@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v4 2/2] irqchip: add J-Core AIC driver

On Wed, Jul 27, 2016 at 11:15:38AM +0100, Mark Rutland wrote:
> On Wed, Jul 27, 2016 at 05:35:09AM +0000, Rich Felker wrote:
> > For simplicity, there is no aic1-specific logic in the driver beyond
> > setting the priority register, which is necessary for interrupts to
> > work at all. Eventually aic1 will likely be phased out, but it's
> > currently in use in deployments and all released bitstream binaries.
> 
> [...]
> 
> > +	if (!of_device_is_compatible(node, "jcore,aic2")) {
> 
> If this is only meant to run for AIC1, it would be better to check for
> the "jcore,aic1" compatible string explicitly.
> 
> While that shouldn't matter much currently, it better matches the intent
> described in the commit message, and avoids surprises and/or churn in
> future if you have AIC3+.

My intent in doing this was to support a DT that might claim an aic2
is aic1-compatible as a fallback "compatible" property. The hardware
is designed such that this works (ignoring the spurious writes to
unused prio registers) as long as the DT still has the right irq
numbers for attached devices. I'm not sure we actually need to do that
for compatibility with any existing software but I thought it better
not to preclude it.

Rich