All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hans J. Koch" <hjk@linutronix.de>
To: Manuel Traut <manut@linutronix.de>
Cc: hjk@linutronix.de, b.spranger@linutronix.de, gregkh@suse.de,
	linux-kernel@vger.kernel.org
Subject: Re: UIO: don't check irq_enabled flag in uio_cif irq handler
Date: Wed, 29 Oct 2008 21:10:54 +0100	[thread overview]
Message-ID: <20081029201054.GB2951@local> (raw)
In-Reply-To: <20081028224137.GA25357@www.tglx.de>

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@linutronix.de>
> 
> --- 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 */

      reply	other threads:[~2008-10-29 20:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 22:41 UIO: don't check irq_enabled flag in uio_cif irq handler Manuel Traut
2008-10-29 20:10 ` Hans J. Koch [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081029201054.GB2951@local \
    --to=hjk@linutronix.de \
    --cc=b.spranger@linutronix.de \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manut@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.