On 27/08/14 16:59, Adam Thomson wrote: > 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. Yes, that stuff (I think) predates deferred probing and no one has gotten around to bringing it up to date as yet.
All contributions welcome! J > 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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
