linux-kernel - Re: [PATCH v4 14/18] ARM64 / ACPI: Add GICv2 specific ACPI boot support

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: <20140918160029.GB25330@e104818-lin.cambridge.arm.com>
Date:	Thu, 18 Sep 2014 17:00:29 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Tomasz Nowicki <tomasz.nowicki@...aro.org>,
	"jcm@...hat.com" <jcm@...hat.com>,
	"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Mark Rutland <Mark.Rutland@....com>,
	Olof Johansson <olof@...om.net>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Will Deacon <Will.Deacon@....com>,
	"graeme.gregory@...aro.org" <graeme.gregory@...aro.org>,
	Sudeep Holla <Sudeep.Holla@....com>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Robert Richter <rric@...nel.org>,
	Lv Zheng <lv.zheng@...el.com>,
	Robert Moore <robert.moore@...el.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Liviu Dudau <Liviu.Dudau@....com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Charles Garcia-Tobin <Charles.Garcia-Tobin@....com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 14/18] ARM64 / ACPI: Add GICv2 specific ACPI boot
 support

On Thu, Sep 18, 2014 at 03:25:29AM +0100, Arnd Bergmann wrote:
> On Wednesday 17 September 2014, Catalin Marinas wrote:
> > > > I think it gets worse, this function is called from irqchip_init(). I
> > > > would have been slightly happier if it was called from the arm64
> > > > init_IRQ(). But putting an ARM specific GIC initialisation call in a
> > > > generic irqchip_init() just looks weird. Can we do anything better here?
> > > 
> > > Yes this was discussed, please have a look at: 
> > > https://lkml.org/lkml/2014/9/1/555
> > > We had this in init_IRQ() in previous patch set, then we got feedback 
> > > irqchip_init() is more appropriate. We can move it back to init_IRQ() 
> > > and I am sold on this.
> > 
> > The irqchip_init() is indeed the place to call other interrupt
> > controller initialisation functions but what I don't particularly like
> > is calling the GIC one directly while the OF ones are checked against a
> > match string. For GICv3 and later, do you plan to use the same
> > acpi_gic_init() functions? Otherwise we could do something like
> > ACPI_IRQCHIP_DECLARE() similar to the OF ones and a common function that
> > probes whatever is built into the kernel.
> 
> I talked abouto this with Marc Z the other day, and I think it really
> comes down to how we expect this to develop in the future:
> 
> If this is going to stay with the GICv2/v3/v4 line of interrupt controllers,
> I see the ACPI_IRQCHIP_DECLARE() as total overdesign, since we wouldn't
> ever need more than two entry points.

I agree, if we are going to have a single acpi_gic_init() function
handling all versions of GIC then a macro isn't needed.

> Doing ACPI_IRQCHIP_DECLARE() makes it possible to deal with other
> incompatible irqchips as they come along, but also seems to invite
> those.
> 
> Marc believes that it's inevitable that people will add lots of crazy
> interrupt controllers to systems using ACPI and at that point I agree
> it would be the right way to deal with it. However, I also think that
> as long as people expect to be able to add lots of crazy interrupt
> controller drivers, we are not ready to merge ACPI in the first place,
> because it must first be clear to everybody that we are not going to
> allow those nonstandard controller drivers to get merged.

Sounds fine to me. So we leave this call in irqchip_init() and ignore
ACPI for platforms with non-standard interrupt controllers.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/