All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Arjan van de Ven <arjan@infradead.org>, Greg KH <greg@kroah.com>,
	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: Wed, 16 Feb 2005 12:27:03 +0100	[thread overview]
Message-ID: <s5hhdkcbv94.wl@alsa2.suse.de> (raw)
In-Reply-To: <42115906.3040003@pobox.com>

At Mon, 14 Feb 2005 21:05:58 -0500,
Jeff Garzik wrote:
> 
> Arjan van de Ven wrote:
> >>No.  You also need to consider situations such as out-of-tree drivers 
> >>for the same hardware (might not use PCI API), and situations where you 
> >>have peer devices discovered and used (PCI API doesn't have "hey, <this> 
> >>device is associated with <current driver>, too" capability)
> > 
> > 
> > 
> > there's not a lot you or anyone else can do about such broken (and often
> > proprietary) drivers.... if a device doesn't use the kernel API's its
> > end of game basically. Adding more new API's isn't going to help you ...
> 
> 
> This specific instance isn't about adding a new API, but using an 
> existing one correctly.
> 
> If pci_request_regions() fails, that implies another driver is using the 
> kernel API to let you know the region is unavailable.  You should honor 
> that, by not disabling the hardware in that case.

I guess an enable counter as Alan proposed would fix this problem
well, except for the case that an out-of-tree driver allocates the
resource without calling pci_enable_device().

OTOH this will introduce more buglets to broken drivers which don't
call pci_disable_device() properly.  Consequently, the ad hoc fix to
each driver like Jeff's patch might be most practical...


Takashi

  reply	other threads:[~2005-02-16 11:27 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
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 [this message]
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=s5hhdkcbv94.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=greg@kroah.com \
    --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.