All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomas Henzl <thenzl@redhat.com>
To: scameron@beardog.cce.hp.com, Andrew Morton <akpm@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	stephenmcameron@gmail.com, mikem@beardog.cce.hp.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cciss: return 0 from driver probe function on success, not 1
Date: Fri, 01 Nov 2013 17:27:48 +0100	[thread overview]
Message-ID: <5273D684.90306@redhat.com> (raw)
In-Reply-To: <20131101140837.GO31390@beardog.cce.hp.com>

On 11/01/2013 03:08 PM, scameron@beardog.cce.hp.com wrote:
> On Fri, Nov 01, 2013 at 06:31:10AM -0700, Andrew Morton wrote:
>> On Fri, 01 Nov 2013 14:06:45 +0100 Tomas Henzl <thenzl@redhat.com> wrote:
>>
>>> The problem in kernel is that the error handling in local_pci_probe
>>> and  in __pci_device_probe is different for ret values > 0,
>>> so we should fix it somewhere so it is in sync.
>>> The documentation states that the probe function should return zero on success
>>> so what about this -
>>>
>>> This would bring the handling to sync
>>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>>> index 98f7b9b..200a071 100644
>>> --- a/drivers/pci/pci-driver.c
>>> +++ b/drivers/pci/pci-driver.c
>>> @@ -317,8 +317,6 @@ __pci_device_probe(struct pci_driver *drv, struct pci_dev *pci_dev)
>>>  		id = pci_match_device(drv, pci_dev);
>>>  		if (id)
>>>  			error = pci_call_probe(drv, pci_dev, id);
>>> -		if (error >= 0)
>>> -			error = 0;
>>>  	}
>>>  	return error;
>>>  }
>> ah, there it is.
>>
>> This change would turn semi-kaput drivers into kaput-kaput drivers.  It
>> would be better to add a runtime warning here so those drivers get
>> fixed.  Such a warning would need to reliably identify the offending
>> probe function so a simple WARN_ON() wouldn't be sufficient.
>>
> FWIW, I just booted up with the following change:
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 98f7b9b..ef71bb5 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -264,9 +264,16 @@ static long local_pci_probe(void *_ddi)
>  	pm_runtime_get_sync(dev);
>  	pci_dev->driver = pci_drv;
>  	rc = pci_drv->probe(pci_dev, ddi->id);
> -	if (rc) {
> +	if (rc < 0) {
>  		pci_dev->driver = NULL;
>  		pm_runtime_put_sync(dev);
> +	} else {
> +		if (rc > 0) {
> +			dev_warn(dev,
> +				"Driver probe function returned %d, greater than 0\n", rc);
> +			rc = 0;
> +			
> +		}
>  	}
>  	return rc;
>  }
>
>
> And,
>
> [scameron@localhost linux-3.12-rc6]$ dmesg | grep 'Driver probe'
> [scameron@localhost linux-3.12-rc6]$
>
> Not that it means all that much since I don't have hardware for
> the majority of drivers, obviously.
>
> I think the above should make drivers with probe functions
> returning > 0 "work" again, but with a warning.
>
> The question would be, are there drivers which return > 0 and
> by this value intend to convey that the probe function has failed?

I think that this is unlikely and the patch is fine, but I can't speak for the drivers..

Please repost your patch so it gets more attention than in this thread. 

>
> -- steve
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2013-11-01 16:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-29 18:41 [PATCH] cciss: return 0 from driver probe function on success, not 1 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 [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-11-01 16:06 Stephen M. Cameron
2013-11-01 16:06 ` Stephen M. Cameron
2013-11-01 16:20   ` Jens Axboe

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=5273D684.90306@redhat.com \
    --to=thenzl@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikem@beardog.cce.hp.com \
    --cc=scameron@beardog.cce.hp.com \
    --cc=stephenmcameron@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.