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  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:	Wed, 12 Dec 2007 15:46:29 +0100
From:	"Remy Bohmer" <>
To:	"Daniel Mack" <>
Subject: Re: DM9000_IRQ_FLAGS

Hello Daniel,

> However, request_irq() is called with IRQF_SHARED only, so neither
> IRQT_RISING nor IRQT_FALLING is set and the value defaults to
> IRQT_NOEDGE. How can you get IRQs?

The DM9000 adapter is connected to a GPIO line on the at91sam9261-ek
board, the board-specific code has a generic handler for every GPIO
interrupt. So, the Device driver __does not need to know__ the type of
interrupt, It just installs a handler by request_irq().

So, these flags are dependant on the board where the driver is
installed, and thus everything you want to define fixed in the driver
is not generic and thus wrong.
This is why a NACK your patch.

> Actually, the best way to go is to let the platform resources flags
> decide about that with something like
>         resource->flags = IORESOURCE_IRQ | IRQT_RISING;
These types of flags are never meant to be compatible, and thus they
shall not be stored in the same flags variable. The same is valid for
the flags IRQF_* and IRQT* flags, so request_irq() is also not the
place to do this.

You should look at the routine set_irq_type() in kernel/irq/chip.c.
This routine is supposed to be used for the IRQT_RISING type of flags
Just do a grep of IRQT_RISING in the arch/arm tree and you will find
enough examples.

Kind Regards,

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists