Re: UIO: don't check irq_enabled flag in uio_cif irq handler

[Hans J. Koch]

On Tue, Oct 28, 2008 at 11:41:37PM +0100, Manuel Traut wrote:
> Below patch ignores INT1_ENABLED flag in the uio_cif irq handler.
> 
> On a Hilscher DeviceNet Slave card, the INT_ENABLE flag is (probably) reseted 
> by the firmware.

If this is actually the case, then this definetly a firmware bug. If
firmware clears the interrupt enable bit, you have no chance of knowing
if the irq was enabled or not. As a consequence, you cannot find out
whether your card caused the interrupt or not.
A hardware with such a behaviour is simply not a decent PCI card, which
should support shared interrupts.

Send a bug report to the firmware author.

> Without this patch, every interrupt produced by this card is
> dropped.

Yes, probably you'll need that patch if you want to make a card with
such broken behaviour work. But _with_ this patch, you'll run into
problems if you have two such PCI cards that share the same interrupt.

I consider this a workaround that might be OK for your usecase, but it's
not something that should go to mainline.

So, NAK to this.

Thanks,
Hans

> 
> This patch is tested and works with a DeviceNet Slave and a Profibus Slave card.
> 
> Signed-off-by: Manuel Traut <manut@xxxxxxxxxxxxx>
> 
> --- linux-git/drivers/uio/uio_cif.c	2008-10-28 23:42:18.000000000 +0100
> +++ uio/drivers/uio/uio_cif.c	2008-10-28 23:41:43.000000000 +0100
> @@ -18,7 +18,6 @@
>  #define PLX9030_INTCSR		0x4C
>  #define INTSCR_INT1_ENABLE	0x01
>  #define INTSCR_INT1_STATUS	0x04
> -#define INT1_ENABLED_AND_ACTIVE	(INTSCR_INT1_ENABLE | INTSCR_INT1_STATUS)
>  
>  #define PCI_SUBVENDOR_ID_PEP	0x1518
>  #define CIF_SUBDEVICE_PROFIBUS	0x430
> @@ -30,8 +29,8 @@
>  	void __iomem *plx_intscr = dev_info->mem[0].internal_addr
>  					+ PLX9030_INTCSR;
>  
> -	if ((ioread8(plx_intscr) & INT1_ENABLED_AND_ACTIVE)
> -	    != INT1_ENABLED_AND_ACTIVE)
> +	if ((ioread8(plx_intscr) & INT1_STATUS)
> +	    != INT1_STATUS)
>  		return IRQ_NONE;
>  
>  	/* Disable interrupt */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/