From: Ben Dooks <ben-linux@fluff.org>
To: Greg KH <greg@kroah.com>
Cc: Ben Dooks <ben-linux@fluff.org>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: device driver probe return codes
Date: Fri, 19 Dec 2008 08:16:36 +0000 [thread overview]
Message-ID: <20081219081636.GK12431@fluff.org.uk> (raw)
In-Reply-To: <20081219051436.GA29543@kroah.com>
On Thu, Dec 18, 2008 at 09:14:36PM -0800, Greg KH wrote:
> On Tue, Dec 16, 2008 at 11:41:28PM -0800, Andrew Morton wrote:
> > On Tue, 16 Dec 2008 21:53:31 +0000 Ben Dooks <ben-linux@fluff.org> wrote:
> >
> > > I would like some feedback on the following regarding some
> > > form of standardising return codes from a device driver probe
> > > to try and stop some basic mistakes.
> > >
> > > This document is not complete, any additions would be welcone.
>
> Hm, shouldn't you have at least copied me on this?
Sorry, assumed you'd be reading linux-kernel.
> What is this for? Each of the different busses treat return codes for
> their probe functions a bit differently, are you wanting to unify them?
> And if so, why?
I was trying to make a guide for people to try and avoid the general
mistakes such as returning -ENODEV when it clearly isn't the right
thing to do. There are a number of drivers which return this causing
confusion as to why devices are not being bound as they neither print
an error nor cause the driver core to print anything [1].
The idea is to provide a guide to what error numbers are acceptable
to return and what the best return code for the common situations
that drivers tend to do and what to avoid.
As a note, having looked at the base driver, pci, platform and i2c
they all pass the error straight back to the core driver probe.
[1] There is a case to be put that drivers such as the i2c bus where
the machine specific support has declared a device to be present
to report an error if the probe then returns an -ENODEV or -ENXIO
to say the device is not there.
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
next prev parent reply other threads:[~2008-12-19 8:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-16 21:53 device driver probe return codes Ben Dooks
2008-12-17 7:41 ` Andrew Morton
2008-12-18 10:14 ` Ben Dooks
2008-12-19 8:17 ` Ben Dooks
2008-12-19 5:14 ` Greg KH
2008-12-19 8:16 ` Ben Dooks [this message]
2008-12-19 16:52 ` Greg KH
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=20081219081636.GK12431@fluff.org.uk \
--to=ben-linux@fluff.org \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
/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.