linux-kernel - Re[2]: [PATCH v6 2/2] mfd: syscon: Add non-DT support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 11 Mar 2013 20:17:23 +0400
From:	Alexander Shiyan <shc_work@...l.ru>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Dong Aisheng <b29396@...escale.com>,
	linux-kernel@...r.kernel.org,
	Dong Aisheng <dong.aisheng@...aro.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Thierry Reding <thierry.reding@...onic-design.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Stephen Warren <swarren@...dotorg.org>
Subject: Re[2]: [PATCH v6 2/2] mfd: syscon: Add non-DT support

> 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.

---