linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Tejun Heo <htejun@gmail.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
	gregkh@suse.de, Jeff Garzik <jeff@garzik.org>,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	michal.k.k.piotrowski@gmail.com, linux-ide@vger.kernel.org,
	tglx@linutronix.de, mlord@pobox.com, linux-pm@lists.osdl.org
Subject: Re: [PATCH/RFC] PCI prepare/activate instead of enable to avoid IRQ storm and rogue DMA access
Date: Thu, 15 Mar 2007 00:45:45 -0600	[thread overview]
Message-ID: <20070315064545.GC14839@colo.lackof.org> (raw)
In-Reply-To: <45F8B160.6010603@gmail.com>

On Thu, Mar 15, 2007 at 11:37:20AM +0900, Tejun Heo wrote:
...
> Also, the current implementation doesn't have any arch independent part. 

I thnk you meant "arch dependent" here.

>  It's wholly contained in arch independent PCI layer, but it might be 
> beneficial to have arch dependent hooks (IRQ line enable/disable?) in 
> the future.
> 
> >What if the device with the IRQ problem is never loaded? Sometimes
> >devices aren't loaded until after boot.
> 
> What do you mean by loading a device?  Do you mean loading driver for 
> the device?

Yes, I think that's what he meant.

> >Any change like this has to be done without changing device drivers.
> >Changing the skge/sky2 drivers as special case is not acceptable.

I don't like the idead of changing the driver API for PCI device setup.
But if it's necessary to solve this class of problem, I think it's ok.

> I dunno about that.  What I'm proposing is alternative two-step PCI 
> initialization step - the first step enables the device just enough for 
> initialization/reset and the second one enables full access.  We're 
> doing part of it already for bus master.  I'm proposing to expand that 
> approach and make them handled by generic PCI layer.  As you can see, it 
> doesn't add noticeable complexity to drivers.  I think it's even clearer 
> than doing pci_set_master() explicitly.

Please update Documentation/pci.txt to reflect the API changes too.

> If this way of solving the problem is chosen, eventually most drivers 
> should be converted to new initialization steps.  And there is no way to 
> do this without modifying low level driver.  Only low level driver knows 
> when full blown access can be enabled and such thing must happen before 
> registering the device to upper layer (e.g. ATA/SCSI, netif).

Agreed. ISTR this has been discussed before but don't recall
the exact context. I'll try to find the previous thread.

When I started the parisc port on 2.4 kernels, the policy was to
leave all interrupts enabled even if no interrupt handler was registered.
This is useful for debugging misconfigured IRQ routing.
Did the policy already change or is this a proposal to change the policy?

thanks,
grant

> sky2/skge aren't exceptions.  If this way of solving the problem is 
> chosen, eventually most if not all drivers should be converted to new 
> model.  It may take two years, maybe five, but as a start just 
> converting ATA and network drivers shouldn't take too long and that 
> would help a lot of cases.
> 
> Thanks.
> 
> -- 
> tejun

  reply	other threads:[~2007-03-15  6:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-14 15:23 [PATCH/RFC] PCI prepare/activate instead of enable to avoid IRQ storm and rogue DMA access Tejun Heo
2007-03-14 17:04 ` Alan Stern
2007-03-14 17:07 ` Stephen Hemminger
2007-03-15  2:37   ` Tejun Heo
2007-03-15  6:45     ` Grant Grundler [this message]
2007-03-16 21:21     ` Stephen Hemminger
2007-03-14 21:46 ` Andi Kleen
2007-03-15  2:39   ` Tejun Heo
2007-03-15 10:17     ` Andi Kleen
2007-03-15 11:41   ` Vivek Goyal
2007-03-14 21:56 ` Russell King
2007-03-14 22:34   ` Jeff Garzik
2007-03-14 22:58     ` Russell King
2007-03-14 23:16       ` Jeff Garzik
2007-03-15  5:47       ` Tejun Heo

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=20070315064545.GC14839@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=gregkh@suse.de \
    --cc=htejun@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linux-pm@lists.osdl.org \
    --cc=michal.k.k.piotrowski@gmail.com \
    --cc=mlord@pobox.com \
    --cc=shemminger@linux-foundation.org \
    --cc=tglx@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;
as well as URLs for NNTP newsgroup(s).