public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox