linux-kernel - Re: [RFC 2/5] gpio: add support for Technologic Systems TS-5500 GPIOs

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]

Date:	Fri, 13 May 2011 23:03:04 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Jerome Oufella <jerome.oufella@...oirfairelinux.com>,
	platform-driver-x86 <platform-driver-x86@...r.kernel.org>,
	linux-serial <linux-serial@...r.kernel.org>,
	lm-sensors <lm-sensors@...sensors.org>
Subject: Re: [RFC 2/5] gpio: add support for Technologic Systems TS-5500
 GPIOs

On Fri, 13 May 2011 17:33:52 -0400
Vivien Didelot <vivien.didelot@...oirfairelinux.com> wrote:

> Excerpts from Alan Cox's message of sam avr 30 06:15:36 -0400 2011:
> > > +    /* Enable IRQ generation */
> > > +    mutex_lock(&drvdata->gpio_lock);
> > > +    PORT_BIT_SET(0x7A, 7); /* DIO1_13 on IRQ7 */
> > > +    PORT_BIT_SET(0x7D, 7); /* DIO2_13 on IRQ6 */
> > > +    if (use_lcdio) {
> > > +        PORT_BIT_CLEAR(0x7D, 4); /* Enable LCD header usage as DIO */
> > > +        PORT_BIT_SET(0x7D, 6);   /* LCD_RS on IRQ1 */
> > > +    }
> > 
> > What happens if an IRQ occurs at this point, you have no handler for it ?
> 
> The IRQ is just not handled. What would be the proper way to handle
> that? Would it be possible to write those registers when the IRQ is
> requested?

The underlying rules are
-	The moment you request_irq your IRQ handler may be called
-	If you have a level triggered IRQ you must have a handler
		before it is ever enabled (or you can get stuck)

Likewise mask it before free_irq

The only other deeply horrid and subtle going on with some PC hardware
especially is that your IRQ handler may be called *after* you mask the
IRQ on the hardware, but not after free_irq. This is because IRQ delivery
is effectively asynchronous to other bus traffic on some systems. [1]

You need things to happen in the following order ideally

	Ensure IRQ cannot be generated
		(most hardware default this way)
	Register IRQ handler
	Initialize all data structures to handle an IRQ
	Enable IRQ

Sometimes when you just can't get that to occur you find drivers have to
do

	Init some minimal data structures
		foo->ready = 0;
	Register IRQ handler
	Enable IRQ
	Initialize the rest

and the irq handler does

	if (foo->ready == 0) {
		clear IRQ source
		return IRQ_HANDLED;
	}

Alan
[1] An alternate view is that it's because hardware engineers have a very
black sense of humour
--
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/