linux-kernel - Re: [PATCH v5 1/3] initialize each mbigen device node as a interrupt controller.

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: <alpine.DEB.2.11.1510141100280.3785@nanos>
Date:	Wed, 14 Oct 2015 11:17:58 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Marc Zyngier <marc.zyngier@....com>
cc:	"majun (F)" <majun258@...wei.com>, Catalin.Marinas@....com,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Will.Deacon@....com, mark.rutland@....com, jason@...edaemon.net,
	lizefan@...wei.com, huxinwei@...wei.com, dingtianhong@...wei.com,
	zhaojunhua@...ilicon.com, liguozhu@...ilicon.com,
	xuwei5@...ilicon.com, wei.chenwei@...ilicon.com,
	guohanjun@...wei.com, wuyun.wu@...wei.com, guodong.xu@...aro.org,
	haojian.zhuang@...aro.org, zhangfei.gao@...aro.org,
	usman.ahmad@...aro.org, klimov.linux@...il.com
Subject: Re: [PATCH v5 1/3] initialize each mbigen device node as a interrupt
 controller.

Marc,

On Wed, 14 Oct 2015, Marc Zyngier wrote:
> To me, it feels like we're spreading the complexity across multiple
> layers instead of keeping it localized. It also means that next time
> some crazy HW dude comes up with a similar idea (and I have little doubt
> this will happen sooner than later), we'll have to replicate the same
> thing again (though we could put all that behind another abstraction layer).
> 
> I would have preferred a solution where the MSI domain is allowed to be
> sandwiched between two non-MSI domains, and expose the top level
> irqchip. This means fixing the following:
> 
> - Either find a way to prevent DT doing these early IRQ allocations
> (this could be easily done by simply not registering the irqchip), or be
> able to elegantly reuse them.

The reuse part makes me shudder. We really should not go there. It's a
blatant layering violation.

> - Add an API allowing an MSI domain to be the parent of another domain.
> 
> Once we have this, we can use the platform MSI layer for the mbigen
> without much complexity (well, not more that any other stacked irqchip,
> the madness of the mbigen programming interface notwithstanding), and
> drivers stay untouched. It would also give us a 'standard' way to deal
> with the above HW dude. I'd be happy to prototype it.

Ok, I have a better understanding of it now.

I have no objections to your approach as long as it provides us a
clean way to use a full hierarchy without weird interfaces to reuse
irq descriptors etc. If you can find a way which just follows the
proper hierarchy design, I'm certainly not in your way.

OTOH, the platform msi driver is not a huge amount of code and from my
understanding of the hardware it looks weird to have this intermediate
layer. Making mbigen a direct child of ITS feels just more natural to
me. I'm pretty sure that this can be done without the earlier proposed
horrible modifications to ITS. It just should fall into place.

It would be really great just to have shell implementations,
i.e. without the mbigen specific stuff - for both models so we can
compare and contrast the results. That means just the interfaces and
the hookup to the various layers.

Thanks,

	tglx
--
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/