linux-kernel - Re: [patch 01/16] irqdomain: Introduce new interfaces to support hierarchy irqdomains

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.1411181048110.3909@nanos>
Date:	Tue, 18 Nov 2014 10:54:56 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Yun Wu (Abel)" <wuyun.wu@...wei.com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Grant Likely <grant.likely@...aro.org>,
	Marc Zyngier <marc.zyngier@....com>,
	Yingjoe Chen <yingjoe.chen@...iatek.com>,
	Yijing Wang <wangyijing@...wei.com>
Subject: Re: [patch 01/16] irqdomain: Introduce new interfaces to support
 hierarchy irqdomains

On Tue, 18 Nov 2014, Yun Wu (Abel) wrote:
> Hi Thomas, Jiang,
> On 2014/11/12 21:42, Thomas Gleixner wrote:
> 
> > From: Jiang Liu <jiang.liu@...ux.intel.com>
> > Index: tip/kernel/irq/chip.c
> > ===================================================================
> > --- tip.orig/kernel/irq/chip.c
> > +++ tip/kernel/irq/chip.c
> > @@ -15,6 +15,7 @@
> >  #include <linux/module.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/kernel_stat.h>
> > +#include <linux/irqdomain.h>
> >  
> >  #include <trace/events/irq.h>
> >  
> > @@ -178,6 +179,7 @@ int irq_startup(struct irq_desc *desc, b
> >  	irq_state_clr_disabled(desc);
> >  	desc->depth = 0;
> >  
> > +	irq_domain_activate_irq(&desc->irq_data);
> 
> I'm not sure why this is needed, please help me out.. :)

Because it makes the whole error handling in stacked allocations way
simpler.

We allocate and reserve resources, but do not program the hardware up
to the point where request_irq and therefor irq_startup() is invoked.

So when in the allocation/reservation phase any of the stack level
fails we just have to undo the allocations/reservations and not any
hardware settings.

That also solves the issue that depending on the stacking we might not
be able to program the hardware during the allocation because all
stack levels need to be allocated/reserved before we can figure out
which hardware configuration we need for the various levels.

So we decided to postpone the actual hardware programming to the point
where the interrupt actually gets used.

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/