From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757393AbcG0RIe (ORCPT ); Wed, 27 Jul 2016 13:08:34 -0400 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:59280 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753179AbcG0RIc (ORCPT ); Wed, 27 Jul 2016 13:08:32 -0400 Date: Wed, 27 Jul 2016 13:08:27 -0400 From: Rich Felker To: Mark Rutland Cc: linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org, devicetree@vger.kernel.org, Jason Cooper , Marc Zyngier , Rob Herring , Thomas Gleixner Subject: Re: [PATCH v4 2/2] irqchip: add J-Core AIC driver Message-ID: <20160727170827.GD15995@brightrain.aerifal.cx> References: <862a5642f4a30f062171bbc14fe95a729eab8ba2.1469595861.git.dalias@libc.org> <20160727101537.GD12880@leverpostej> <20160727130821.GB15995@brightrain.aerifal.cx> <20160727132753.GC17195@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160727132753.GC17195@leverpostej> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 27, 2016 at 02:27:54PM +0100, Mark Rutland wrote: > On Wed, Jul 27, 2016 at 09:08:21AM -0400, Rich Felker wrote: > > 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. > > Ok. > > If the HW ignores it, what's the cost of those one-off spurious writes? > If it's not noticeable, you could allow the kernel to perform them > regardless. Indeed, it essentially costs nothing. My motivation was more just to document that it's not needed/used for aic2. > Otherwise, please add a comment above the check, explaining why we do > the check this way around. Since the intent is documenting this might be the best approach. Rich