From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760073AbcHEQ1T (ORCPT ); Fri, 5 Aug 2016 12:27:19 -0400 Received: from outbound1.eu.mailhop.org ([52.28.251.132]:33405 "EHLO outbound1.eu.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759941AbcHEQ1R (ORCPT ); Fri, 5 Aug 2016 12:27:17 -0400 X-MHO-User: 7bd9c192-5b29-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 74.99.77.15 X-Mail-Handler: DuoCircle Outbound SMTP X-DKIM: OpenDKIM Filter v2.6.8 io 8FF718006D Date: Fri, 5 Aug 2016 16:27:03 +0000 From: Jason Cooper To: Thomas Petazzoni Cc: Thomas Gleixner , Marc Zyngier , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Rob Herring , Ian Campbell , Pawel Moll , Mark Rutland , Kumar Gala , Andrew Lunn , Sebastian Hesselbarth , Gregory Clement , linux-arm-kernel@lists.infradead.org, Shadi Ammouri , Yehuda Yitschak , Omri Itach , Hanna Hawa , Nadav Haklai , Neta Zur Hershkovits Subject: Re: [PATCH 2/4] irqchip: irq-mvebu-pic: new driver for Marvell Armada 7K/8K PIC Message-ID: <20160805162703.GZ4541@io.lakedaemon.net> References: <1470408921-447-1-git-send-email-thomas.petazzoni@free-electrons.com> <1470408921-447-3-git-send-email-thomas.petazzoni@free-electrons.com> <20160805153113.GW4541@io.lakedaemon.net> <20160805175812.55162108@free-electrons.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160805175812.55162108@free-electrons.com> 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 Hi Thomas, On Fri, Aug 05, 2016 at 05:58:12PM +0200, Thomas Petazzoni wrote: > On Fri, 5 Aug 2016 15:31:13 +0000, Jason Cooper wrote: > > > > +config MVEBU_PIC > > > + bool > > > > tri-state? Is there anything else attached to the PIC besides the PMU? > > tri-state would be fine I believe, it's indeed a secondary interrupt > controller, not essential for booting the platform. > > But then I probably need to rework PATCH 3/4 and not have it > unconditionally selected by the platform Kconfig option, right? meh. I have no preference either way. It's what works best for your platform. I've just seen one or two people on a tear lately regarding module.h/MODULE_* and being boolean. I figured I'd address it while I was here. :-) > Regarding what else is attached to the PIC, I have no idea, I don't > have this information. Ok, then which ever way you go is fine by me. > > > +static const struct of_device_id mvebu_pic_of_match[] = { > > > + { .compatible = "marvell,armada-8k-pic", }, > > > > You mention 7k in $subject, should you use that here as the youngest > > compatible SoC generation? > > There isn't anything youngest or oldest between 7K and 8K, they both > got released at the same time. They are really the same family of SoCs, > the 7K having only one CP110, the 8K having two of them, which provides > more I/Os. > > For several other IPs, we're using armada-8k as the compatible string: > > * marvell,armada8k-pcie > * marvell,armada-8k-xhci Ok, sure. That was just a nit. I know human nature, despite logic, will assume 8k is newer that 7k, like SSLv3 being better than TLS v1.x because the number is bigger. :-/ Consistency is better at this point. The rest of it looks fine. thx, Jason.