From: Jens Axboe <axboe@kernel.dk>
To: "Stephen M. Cameron" <scameron@beardog.cce.hp.com>
Cc: stephenmcameron@gmail.com, akpm@linux-foundation.org,
mikem@beardog.cce.hp.com, linux-kernel@vger.kernel.org,
thenzl@redhat.com
Subject: Re: [PATCH] cciss: return 0 from driver probe function on success, not 1
Date: Fri, 01 Nov 2013 10:20:46 -0600 [thread overview]
Message-ID: <5273D4DE.6060802@kernel.dk> (raw)
In-Reply-To: <20131101160638.17867.37792.stgit@beardog.cce.hp.com>
On 11/01/2013 10:06 AM, Stephen M. Cameron wrote:
> From: Stephen M. Cameron <scameron@beardog.cce.hp.com>
>
> A return value of 1 is interpreted as an error. See pci_driver.
> in local_pci_probe(). If you're wondering how this ever could
> have worked, it's because it used to be the case that only return
> values less than zero were interpreted as failure. But even in
> the current kernel if the driver registers its various entry
> points with the kernel, and then returns a value which is
> interpreted as failure, those registrations aren't undone, so
> the driver still mostly works. However, the driver's remove
> function wouldn't be called on rmmod, and pci power management
> functions wouldn't work. In the case of Smart Array, since it
> has a battery backed cache (or else no cache) even if the driver
> is not shut down properly as long as there is no outstanding
> i/o, nothing too bad happens, which is why it took so long to
> notice.
>
> Requesting backport to stable because the change to pci-driver.c
> which requires driver probe functions to return 0 occurred between
> 2.6.35 and 2.6.36 (the pci power management breakage) and again
> between 3.7 and 3.8 (pci_dev->driver getting set to NULL in
> local_pci_probe() preventing driver remove function from being
> called on rmmod.)
The original patch went in two days ago, so it's a little difficult for
me to update it unfortunately. But you can include lots of this in the
pci-driver.c warning print patch instead.
--
Jens Axboe
next prev parent reply other threads:[~2013-11-01 16:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-01 16:06 [PATCH] cciss: return 0 from driver probe function on success, not 1 Stephen M. Cameron
2013-11-01 16:06 ` Stephen M. Cameron
2013-11-01 16:20 ` Jens Axboe [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-10-29 18:41 Stephen M. Cameron
2013-10-29 18:58 ` Jens Axboe
2013-10-31 21:42 ` Andrew Morton
2013-10-31 21:54 ` scameron
2013-10-31 22:06 ` Andrew Morton
2013-11-01 13:06 ` Tomas Henzl
2013-11-01 13:31 ` Andrew Morton
2013-11-01 14:08 ` scameron
2013-11-01 16:27 ` Tomas Henzl
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=5273D4DE.6060802@kernel.dk \
--to=axboe@kernel.dk \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikem@beardog.cce.hp.com \
--cc=scameron@beardog.cce.hp.com \
--cc=stephenmcameron@gmail.com \
--cc=thenzl@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox