Re: [3/3] hwmon: iio_hwmon: defer probe when no channel is found

[Guenter Roeck <linux@roeck-us.net>]

On 06/30/2016 06:59 AM, Jonathan Cameron wrote:
>
>
> On 30 June 2016 04:47:25 BST, Guenter Roeck <linux@roeck-us.net> wrote:
>> On Tue, Jun 28, 2016 at 10:18:17AM +0200, Quentin Schulz wrote:
>>> iio_channel_get_all returns -ENODEV when it cannot find either
>> phandles and
>>> properties in the Device Tree or channels whose consumer_dev_name
>> matches
>>> iio_hwmon in iio_map_list. The iio_map_list is filled in by iio
>> drivers
>>> which might be probed after iio_hwmon.
>>>
>>> It is better to defer the probe of iio_hwmon if such error is
>> returned by
>>> iio_channel_get_all in order to let a chance to iio drivers to expose
>>> channels in iio_map_list.
>>>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>>> ---
>>>   drivers/hwmon/iio_hwmon.c | 5 ++++-
>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
>>> index b550ba5..c0da4d9 100644
>>> --- a/drivers/hwmon/iio_hwmon.c
>>> +++ b/drivers/hwmon/iio_hwmon.c
>>> @@ -73,8 +73,11 @@ static int iio_hwmon_probe(struct platform_device
>> *pdev)
>>>   		name = dev->of_node->name;
>>>
>>>   	channels = iio_channel_get_all(dev);
>>> -	if (IS_ERR(channels))
>>> +	if (IS_ERR(channels)) {
>>> +		if (PTR_ERR(channels) == -ENODEV)
>>> +			return -EPROBE_DEFER;
>>
>> The problem, as I see it, is with iio, which should return
>> -EPROBE_DEFER
>> in this situation.
> Agreed. New fangled stuff this deferred probing :)
>>
>> We can not convert -ENODEV to -EPROBE_DEFER without risking that the
>> channels are _really_ not there, which would result in endless
>> "deferred"
>> messages.
> Hmm not entirely sure how we prevent that happening wherever it is done..
>

Outch. Better at the source, though. I didn't look at the iio code recently,
but can you detect the defer situation at least with devicetree ?

For non-devicetree situations, the only option I can think of would be
to replace the module initcall with a later initcall. That should solve
the problem if both iio_hwmon and and underlying drivers are built
into the kernel. If iio_hwmon is modular, the only real option I can
see is to make sure that all drivers it needs are loaded first.

Does this make sense ?

Guenter

>>
>> Guenter
>>
>>>   		return PTR_ERR(channels);
>>> +	}
>>>
>>>   	st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
>>>   	if (st == NULL) {
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>