From: Dan Carpenter <error27@gmail.com>
To: Vasiliy Kulikov <segooon@gmail.com>
Cc: kernel-janitors@vger.kernel.org,
Greg Kroah-Hartman <gregkh@suse.de>,
Alan Cox <alan@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Rakib Mullick <rakib.mullick@gmail.com>,
Ben Hutchings <ben@decadent.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/18] char: moxa: call disable_pci_device() if
Date: Sat, 07 Aug 2010 09:58:52 +0000 [thread overview]
Message-ID: <20100807095852.GX9031@bicker> (raw)
In-Reply-To: <20100807085512.GA5783@albatros>
On Sat, Aug 07, 2010 at 12:55:12PM +0400, Vasiliy Kulikov wrote:
> On Sat, Aug 07, 2010 at 09:22 +0200, Dan Carpenter wrote:
> > On Fri, Aug 06, 2010 at 11:49:10PM +0400, Kulikov Vasiliy wrote:
> > > Driver should call disable_pci_device() if it returns from pci_probe()
> > > with error. Also it must not be called if pci_request_region() fails as
> > > it means that somebody uses device resources and rules the device.
> > >
> >
> > I think we should disable it actually. The comments on
> > pci_enable_device() and pci_disable_device() say that only the first and
> > last callers actually enable and disable it. The others just increment
> > or decrement a counter.
>
> See this thread: http://lkml.org/lkml/2005/2/13/82
>
> Specifically this mail:
>
> Date Mon, 14 Feb 2005 14:51:26 -0500
> From Jeff Garzik <>
>
> ...
> 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).
> ...
>
> Searching for 'pci_disable_device() inurl:lkml' doesn't give me newer info
> aboud this problem, so I think it's better to play safe.
>
That's ancient. That's a couple months before the start of git.
git show v2.6.12:drivers/pci/pci.c
In those days pci_enable/disable_device() were not nestable. These days
we can just unwind normally so it's a big improvement.
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <error27@gmail.com>
To: Vasiliy Kulikov <segooon@gmail.com>
Cc: kernel-janitors@vger.kernel.org,
Greg Kroah-Hartman <gregkh@suse.de>,
Alan Cox <alan@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Rakib Mullick <rakib.mullick@gmail.com>,
Ben Hutchings <ben@decadent.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/18] char: moxa: call disable_pci_device() if pci_probe() failed
Date: Sat, 7 Aug 2010 11:58:52 +0200 [thread overview]
Message-ID: <20100807095852.GX9031@bicker> (raw)
In-Reply-To: <20100807085512.GA5783@albatros>
On Sat, Aug 07, 2010 at 12:55:12PM +0400, Vasiliy Kulikov wrote:
> On Sat, Aug 07, 2010 at 09:22 +0200, Dan Carpenter wrote:
> > On Fri, Aug 06, 2010 at 11:49:10PM +0400, Kulikov Vasiliy wrote:
> > > Driver should call disable_pci_device() if it returns from pci_probe()
> > > with error. Also it must not be called if pci_request_region() fails as
> > > it means that somebody uses device resources and rules the device.
> > >
> >
> > I think we should disable it actually. The comments on
> > pci_enable_device() and pci_disable_device() say that only the first and
> > last callers actually enable and disable it. The others just increment
> > or decrement a counter.
>
> See this thread: http://lkml.org/lkml/2005/2/13/82
>
> Specifically this mail:
>
> Date Mon, 14 Feb 2005 14:51:26 -0500
> From Jeff Garzik <>
>
> ...
> 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).
> ...
>
> Searching for 'pci_disable_device() inurl:lkml' doesn't give me newer info
> aboud this problem, so I think it's better to play safe.
>
That's ancient. That's a couple months before the start of git.
git show v2.6.12:drivers/pci/pci.c
In those days pci_enable/disable_device() were not nestable. These days
we can just unwind normally so it's a big improvement.
regards,
dan carpenter
next prev parent reply other threads:[~2010-08-07 9:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-06 19:49 [PATCH 01/18] char: moxa: call disable_pci_device() if pci_probe() failed Kulikov Vasiliy
2010-08-06 19:49 ` Kulikov Vasiliy
2010-08-07 7:22 ` [PATCH 01/18] char: moxa: call disable_pci_device() if Dan Carpenter
2010-08-07 7:22 ` [PATCH 01/18] char: moxa: call disable_pci_device() if pci_probe() failed Dan Carpenter
2010-08-07 8:55 ` [PATCH 01/18] char: moxa: call disable_pci_device() if Vasiliy Kulikov
2010-08-07 8:55 ` [PATCH 01/18] char: moxa: call disable_pci_device() if pci_probe() failed Vasiliy Kulikov
2010-08-07 9:58 ` Dan Carpenter [this message]
2010-08-07 9:58 ` Dan Carpenter
2010-08-07 18:02 ` [PATCH 01/18] char: moxa: call disable_pci_device() if Vasiliy Kulikov
2010-08-07 18:02 ` [PATCH 01/18] char: moxa: call disable_pci_device() if pci_probe() failed Vasiliy Kulikov
2010-08-07 19:08 ` [PATCH 01/18] char: moxa: call disable_pci_device() if Dan Carpenter
2010-08-07 19:08 ` [PATCH 01/18] char: moxa: call disable_pci_device() if pci_probe() failed Dan Carpenter
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=20100807095852.GX9031@bicker \
--to=error27@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=ben@decadent.org.uk \
--cc=gregkh@suse.de \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rakib.mullick@gmail.com \
--cc=segooon@gmail.com \
/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.