linux-kernel - Re: [PATCH v2 4/4] irqchip: sun4i: Use handle_fasteoi_late

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] [day] [month] [year] [list]

Date:	Thu, 13 Mar 2014 17:27:21 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Hans de Goede <hdegoede@...hat.com>
cc:	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	linux-arm-kernel@...ts.infradead.org,
	devicetree <devicetree@...r.kernel.org>,
	linux-kernel@...r.kernel.org, linux-sunxi@...glegroups.com
Subject: Re: [PATCH v2 4/4] irqchip: sun4i: Use handle_fasteoi_late_irq for
 the ENMI (irq 0)

On Thu, 13 Mar 2014, Hans de Goede wrote:
> On 03/13/2014 03:46 PM, Thomas Gleixner wrote:
> >>  static int sun4i_irq_map(struct irq_domain *d, unsigned int virq,
> >>  			 irq_hw_number_t hw)
> >>  {
> >> -	irq_set_chip_and_handler(virq, &sun4i_irq_chip,
> >> -				 handle_level_irq);
> >> +	if (hw == 0) /* IRQ 0, the ENMI needs special handling */
> >> +		irq_set_chip_and_handler(virq, &sun4i_irq_chip,
> >> +					 handle_fasteoi_late_irq);
> >> +	else
> >> +		irq_set_chip_and_handler(virq, &sun4i_irq_chip,
> >> +					 handle_level_irq);
> > 
> > I wonder what happens when you use the fasteoi handler for all of
> > them.
> 
> As mentioned in my previous mail doing an ack (or an eio) seems to
> be unnecessary for all but IRQ 0.
> 
> I do wonder if handle_level_irq is the right handle*irq function
> to use in this case, since this is strictly used in the non smp
> case I think that the mask / unmask done by handle_level_irq is
> not necessary for non threaded handlers. So what would be the
> correct handle*irq function to use in this case ?
> 
> Note the irqs are level irqs. IOW they may stay asserted while
> the handler runs because of the handler and a new irq raising.

Right. You could be creative and use fasteoi plus an empty eoi
callback in the chip for irq 1-N. That way you only mask and unmask in
the threaded case.

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/