public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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