linux-kernel - RE: [PATCH] iio: core: Propagate error codes from OF layer to client drivers

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2E89032DDAA8B9408CB92943514A0337AB510FA9@SW-EX-MBX01.diasemi.com>
Date:	Tue, 26 Aug 2014 14:35:45 +0000
From:	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>
To:	"Ivan T. Ivanov" <iivanov@...sol.com>,
	Guenter Roeck <linux@...ck-us.net>
CC:	Jonathan Cameron <jic23@...nel.org>,
	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>,
	"knaack.h@....de" <knaack.h@....de>,
	"lars@...afoo.de" <lars@...afoo.de>,
	"pmeerw@...erw.net" <pmeerw@...erw.net>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] iio: core: Propagate error codes from OF layer to
 client drivers

On August 26, 2014 14:48, Ivan T. Ivanov wrote:

> On Tue, 2014-08-26 at 06:25 -0700, Guenter Roeck wrote:
> > On 08/26/2014 12:51 AM, Ivan T. Ivanov wrote:
> > > Hi,
> > >
> > [ ... ]
> > >
> > > Another, less intrusive, solution will be if we revert last patch and explicitly
> > > check for EPROBE_DEFER on of_ by_name() return. How this sounds?
> > >
> > How is that different to the just accepted patch ?
> 
> You mean this one[1]. I have prepared fix last Friday and forget to
> check again before posting it, sorry. Please ignore my patch.
> 
> Thanks,
> Ivan
> 
> [1] iio:inkern: fix overwritten -EPROBE_DEFER in of_iio_channel_get_by_name
> 

Apologies on my part for fixing one problem and introducing another. Didn't see
that in my testing, and missed that potential return value when examining the
code. At the time It looked like the parent function would only expect NULL
pointers for failure, especially given the non CONFIG_OF definitions of the
functions. Should've delved further. :(