From: =?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?= <shc_work@mail.ru>
To: =?UTF-8?B?QXJuZCBCZXJnbWFubg==?= <arnd@arndb.de>
Cc: =?UTF-8?B?RG9uZyBBaXNoZW5n?= <b29396@freescale.com>,
        linux-kernel@vger.kernel.org,
        =?UTF-8?B?RG9uZyBBaXNoZW5n?= <dong.aisheng@linaro.org>,
        =?UTF-8?B?U2FtdWVsIE9ydGl6?= <sameo@linux.intel.com>,
        =?UTF-8?B?TWFyayBCcm93bg==?= <broonie@opensource.wolfsonmicro.com>,
        =?UTF-8?B?VGhpZXJyeSBSZWRpbmc=?= <thierry.reding@avionic-design.de>,
        =?UTF-8?B?R3JlZyBLcm9haC1IYXJ0bWFu?= <gregkh@linuxfoundation.org>,
        =?UTF-8?B?RG1pdHJ5IFRvcm9raG92?= <dmitry.torokhov@gmail.com>,
        =?UTF-8?B?U3RlcGhlbiBXYXJyZW4=?= <swarren@wwwdotorg.org>
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSCB2NiAyLzJdIG1mZDogc3lzY29uOiBBZGQgbm9uLURU?=
 =?UTF-8?B?IHN1cHBvcnQ=?=
Mime-Version: 1.0
Date: Mon, 11 Mar 2013 20:17:23 +0400
Reply-To: =?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?= <shc_work@mail.ru>
Message-ID: <1363018643.895028941@f314.mail.ru>
Content-Type: text/plain; charset=utf-8
In-Reply-To: <201303111338.56679.arnd@arndb.de>
References: <1362063434-8318-1-git-send-email-shc_work@mail.ru> <20130311103541.GC6280@b29396-Latitude-E6410> <201303111338.56679.arnd@arndb.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 1562
Lines: 32

> On Monday 11 March 2013, Dong Aisheng wrote:
> > > > > + dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s,
> > > > > +                          syscon_match_pdevname);
> > > > > + if (!dev)
> > > > > +         return ERR_PTR(-ENODEV);
> > > > 
> > > > Should it be ERR_PTR(-EPROBE_DEFER)?
> > > 
> > > I have no idea what better using here. Think that is not so important
> > > since we may have only one possible error code here.
> > 
> > I'm not quite understand your meaning.
> > Since the syscon device may be still not registered,
> > so it may be better to return a EPROBE_DERFER which is the same
> > as dt version.
> 
> I'm guessing that Alexander has not encountered deferred probing yet.
> Alexander, the point here is that returning -EPROBE_DEFER has the
> advantage that a probe() callback calling this function can
> simply return that error code to the driver core. If the driver
> core sees -EPROBE_DEFER, it will retry the same probe function
> later, after all other device probe functions have been called
> and at least one of them was successful. This way you can load the
> syscon driver after loading a driver depending on it and everything
> will still work.

You are right Arnd. I usually try to control the correct order of loading
drivers. Using EPROBE_DEFER in this procedure is more correct.
Probably time for v7... I hope it will finally be the last.

---
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?