From: Jeff Garzik <jgarzik@pobox.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: 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: Mon, 14 Feb 2005 14:54:56 -0500 [thread overview]
Message-ID: <42110210.6030900@pobox.com> (raw)
In-Reply-To: <s5h650udiqb.wl@alsa2.suse.de>
Takashi Iwai wrote:
> At Mon, 14 Feb 2005 11:34:13 -0800,
> Greg KH wrote:
>
>>On Mon, Feb 14, 2005 at 08:24:29PM +0100, Takashi Iwai wrote:
>>
>>>At Mon, 14 Feb 2005 11:06:19 -0800,
>>>Greg KH wrote:
>>>
>>>>>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?
>>>
>>>How about to add an exclusiveness check in pci_enable_device()?
>>>Most drivers suppose that the given pci resources are exclusively
>>>available.
>>
>>You mean only allow pci_enable_device() to work for the first caller of
>>it? I don't see how that would help this issue out.
>
>
> Well, for example, add a new pointer to indicate the driver accessing
> exclusively. And pci_enable_device() (maybe a new variant would be
> better for compatibility) checks whether this is free.
>
> The second caller wouldn't reach even to pci_request_regions() because
> of this check. So, no side-effect of pci_disable_device() in the
> error path.
This doesn't work with a driver that is properly using
request_resource(), but not using the PCI API.
Jeff
next prev parent reply other threads:[~2005-02-14 19:55 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 [this message]
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=42110210.6030900@pobox.com \
--to=jgarzik@pobox.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.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.