linux-kernel - Re: [PATCH v2 12/29] nios2: Interrupt handling

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1407171555580.24854@nanos>
Date:	Thu, 17 Jul 2014 15:58:46 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ley Foon Tan <lftan@...era.com>
cc:	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Chung-Lin Tang <cltang@...esourcery.com>
Subject: Re: [PATCH v2 12/29] nios2: Interrupt handling

On Thu, 17 Jul 2014, Ley Foon Tan wrote:

> On Tue, Jul 15, 2014 at 5:51 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Tue, 15 Jul 2014, Ley Foon Tan wrote:
> >> +#ifndef _ASM_NIOS2_IRQ_H
> >> +#define _ASM_NIOS2_IRQ_H
> >> +
> >> +#define NIOS2_CPU_NR_IRQS    32
> >> +/* Reserve 32 additional interrupts for GPIO IRQs */
> >> +#define NR_IRQS                      (NIOS2_CPU_NR_IRQS + 32)
> >
> > Please use sparse irqs. Hardcoded limits tend to work out really bad.
> Yes, will change this.
> >
> >> +#include <linux/init.h>
> >> +#include <linux/interrupt.h>
> >> +#include <linux/of.h>
> >> +
> 
> >> +static void chip_unmask(struct irq_data *d)
> >> +{
> >> +     u32 ien;
> >> +     ien = RDCTL(CTL_IENABLE);
> >> +     ien |= (1 << d->hwirq);
> >> +     WRCTL(CTL_IENABLE, ien);
> >
> > So this is UP only, right?
> Yes, this is to enable one interrupt.

The question was, whether this is always a UniProcessor machine.

> > Also why don't you cache the register content so spare the extra read
> > from the hardware?
> Need to make sure nobody modify the register if we cache the register content.
> Will keep as it is.

Sigh.

If this is a uniprocessor only design, then nothing can modify the
cached values as all these functions are always called with interrupts
disabled.

If this should be SMP safe, then you'd need serialization of the
register access as well becasue the read/modify/write sequence is not
atomic.

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/