All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: avoiding pci_disable_device()...
Date: Mon, 14 Feb 2005 11:06:19 -0800	[thread overview]
Message-ID: <20050214190619.GA9241@kroah.com> (raw)
In-Reply-To: <4210021F.7060401@pobox.com>

On Sun, Feb 13, 2005 at 08:42:55PM -0500, Jeff Garzik wrote:
> 
> Currently, in almost every PCI driver, if pci_request_regions() fails -- 
> indicating another driver is using the hardware -- then 
> pci_disable_device() is called on the error path, disabling a device 
> that another driver is using
> 
> To call this "rather rude" is an understatement :)
> 
> Fortunately, the ugliness is mitigated in large part by the PCI layer 
> helping to make sure that no two drivers bind to the same PCI device. 
> Thus, in the vast majority of cases, pci_request_regions() -should- be 
> guaranteed to succeed.
> 
> However, there are oddball cases like mixed PCI/ISA devices (hello IDE) 
> or cases where a driver refers a pci_dev other than the primary, where 
> pci_request_regions() and request_regions() still matter.

But this is a very small subset of pci devices, correct?

> As a result, I have committed the attached patch to libata-2.6.  In many 
> cases, it is a "semantic fix", addressing the case
> 
> 	* pci_request_regions() indicates hardware is in use
> 	* we rudely disable the in-use hardware
> 
> that would not occur in practice.
> 
> But better safe than sorry.  Code cuts cut-n-pasted all over the place.
> 
> I'm hoping one or two things will happen now:
> * janitors fix up the other PCI drivers along these lines
> * improve the PCI API so that pci_request_regions() is axiomatic

Do you have any suggestions for how to do this?

thanks,

greg k-h

  reply	other threads:[~2005-02-14 19:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-14  1:42 avoiding pci_disable_device() Jeff Garzik
2005-02-14 19:06 ` Greg KH [this message]
2005-02-14 18:08   ` Alan Cox
2005-02-14 19:24   ` Takashi Iwai
2005-02-14 19:34     ` Greg KH
2005-02-14 19:50       ` Takashi Iwai
2005-02-14 19:54         ` Jeff Garzik
2005-02-14 19:51   ` Jeff Garzik
2005-02-14 19:58     ` Roland Dreier
2005-02-14 20:00       ` Jeff Garzik
2005-02-14 21:42         ` Roland Dreier
2005-02-14 22:25           ` Jeff Garzik
2005-02-14 22:46             ` Roland Dreier
2005-02-17 23:07               ` Greg KH
2005-02-14 20:02     ` Arjan van de Ven
2005-02-15  2:05       ` Jeff Garzik
2005-02-16 11:27         ` Takashi Iwai
2005-02-16 13:44           ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2005-02-14 10:43 Michal Rokos
2005-02-14 11:08 ` Christoph Hellwig

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=20050214190619.GA9241@kroah.com \
    --to=greg@kroah.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.