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:	Fri, 5 Sep 2014 22:44:36 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Florian Fainelli <f.fainelli@...il.com>
cc:	Mark Rutland <mark.rutland@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	"jason@...edaemon.net" <jason@...edaemon.net>,
	"computersforpeace@...il.com" <computersforpeace@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 2/2] Documentation: bcm7120-l2: Add Broadcom BCM7120-style
 L2 binding

On Fri, 5 Sep 2014, Florian Fainelli wrote:
> On 09/05/2014 12:21 PM, Thomas Gleixner wrote:
> > So if I understand correctly what you have is:
> > 
> >                           /- GIC------------->   
> >  Device-irq ---- [routing]
> >                           \- BC irq chip ---->
> > 
> > and you implement it as
> > 
> >  Device-irq ---- [BC irq chip] ---- [GIC] --->
> >                             |
> >                             ----------------->
> > 
> > And the fwd mask is to tell the BC chip to use the GIC and which irq
> > of the GIC, so it can fiddle with the GIC under the hood, right?
> 
> The forward mask really is to tell the BCM7120 l2 interrupt controller:
> bypass me, and output the UART interrupts directly at the GIC level, so
> I think this does match your understanding.
> 
> Not setting the forward mask means you would get the UART interrupts at
> the BCM7120 l2 interrupt controller level, and have to handle them here.
> 
> Hope this helps clarify what this funky piece of hardware does.

Sigh, this stacked interrupt chip nonsense is becoming a plague.

So if you set that bit then the UART driver only sees the GIC as its
interrupt controller and not the L2 thingy. So, the L2 chip only
enables its interrupt unconditionally for that line and the
enable/disable happens at the GIC level.

If that's the case, that's fine with me. It's not pretty, but at least
it does not involve L2 fiddling indirectly with the GIC.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ