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

[Adam Thomson]

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


N‹§²æ¸›yú²X¬¶ÇvØ–)Þ{.nlj·¥Š{±‘êX§¶›¡Ü}©ž²ÆzÚj:+v‰¨¾«‘êZ+€Êzf£¢·hšˆ§~†­†Ûÿû®w¥¢¸?™¨è&¢)ßf”ùy§m…á«a¶Úÿ0¶ìå