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] [thread-next>] [day] [month] [year] [list]
Message-ID: <2E89032DDAA8B9408CB92943514A0337AB5113C5@SW-EX-MBX01.diasemi.com>
Date:	Wed, 27 Aug 2014 15:59:05 +0000
From:	Adam Thomson <Adam.Thomson@...semi.com>
To:	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>,
	"Ivan T. Ivanov" <iivanov@...sol.com>,
	Guenter Roeck <linux@...ck-us.net>
CC:	Jonathan Cameron <jic23@...nel.org>,
	"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 15:36, Adam Thomson wrote:

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

On August 26, 2014 15:36, Adam Thomson wrote:

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

In testing patch code for one of our devices, I've verified what Guenter
mentioned previously in this thread, in that iio_channel_get_sys() doesn't
return -EPROBE_DEFER. This means that drivers using the default map approach of
accessing IIO channels will fail to instantiate as they do not know they
need to defer their probe (have seen this with my driver too).

Haven't looked in detail yet as to how, but I guess this is something that will
also need to be addressed.
Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

Please consider the environment before printing this e-mail


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ