[PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall

From: Quentin Schulz <hidden>
Date: 2016-09-01 07:15:20
Also in: linux-hwmon, linux-iio, lkml

On 15/08/2016 23:35, Jonathan Cameron wrote:


On 15 August 2016 18:07:30 BST, Guenter Roeck [off-list ref] wrote:

quoted

On Mon, Aug 15, 2016 at 04:40:21PM +0100, Jonathan Cameron wrote:

quoted

On 26/07/16 17:04, Guenter Roeck wrote:

quoted

On Tue, Jul 26, 2016 at 12:00:33PM +0200, Alexander Stein wrote:

quoted

On Tuesday 26 July 2016 11:33:59, Quentin Schulz wrote:

quoted

On 26/07/2016 11:05, Alexander Stein wrote:

quoted

On Tuesday 26 July 2016 10:24:48, Quentin Schulz wrote:

quoted

On 26/07/2016 10:21, Alexander Stein wrote:

quoted

On Tuesday 26 July 2016 09:43:44, Quentin Schulz wrote:

quoted

iio_channel_get_all returns -ENODEV when it cannot find

either phandles

quoted

quoted
quoted
quoted
quoted
quoted
quoted
quoted
and
properties in the Device Tree or channels whose

consumer_dev_name

quoted

quoted
quoted
quoted
quoted
quoted
quoted
quoted
matches
iio_hwmon in iio_map_list. The iio_map_list is filled in by

iio drivers

quoted

which might be probed after iio_hwmon.

Would it work if iio_channel_get_all returning ENODEV is used

for

quoted

returning
EPROBE_DEFER in iio_channel_get_all? Using late initcalls for
driver/device
dependencies seems not right for me at this place.

Then what if the iio_channel_get_all is called outside of the

probe of a

quoted

quoted
quoted
quoted
quoted
quoted
driver? We'll have to change the error code, things we are

apparently

quoted

trying to avoid (see v2 patches' discussions).

Maybe I didn't express my idea enough. I don't want to change

the behavior

quoted

of iio_channel_get_all at all. Just the result evaluation of
iio_channel_get_all in iio_hwmon_probe. I have something link

the patch

quoted

below in mind.

Best regards,
Alexander
---

diff --git a/drivers/hwmon/iio_hwmon.c

b/drivers/hwmon/iio_hwmon.c

quoted

index b550ba5..e32d150 100644

--- a/drivers/hwmon/iio_hwmon.c
+++ b/drivers/hwmon/iio_hwmon.c

@@ -73,8 +73,12 @@ static int iio_hwmon_probe(struct

platform_device

quoted

*pdev)

                name = dev->of_node->name;
        
        channels = iio_channel_get_all(dev);

-       if (IS_ERR(channels))
-               return PTR_ERR(channels);
+       if (IS_ERR(channels)) {
+               if (PTR_ERR(channels) == -ENODEV)
+                       return -EPROBE_DEFER;
+               else
+                       return PTR_ERR(channels);
+       }

        st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
        if (st == NULL) {

Indeed, I misunderstood what you told me.

Actually, the patch you proposed is part of my v1
(https://lkml.org/lkml/2016/6/28/203) and v2
(https://lkml.org/lkml/2016/7/15/215).
Jonathan and Guenter didn't really like the idea of changing the

-ENODEV

quoted

in -EPROBE_DEFER.

Thanks for the links.

quoted

What I thought you were proposing was to change the -ENODEV

return code

quoted

inside iio_channel_get_all. This cannot be an option since the

function

quoted

might be called outside of a probe (it is not yet, but might be

in the

quoted

future?).

AFAICS this is a helper function not knowing about device probing

itself. And

quoted

it should stay at that.

quoted

Of what I understood, two possibilities are then possible

(proposed

quoted

either by Guenter or Jonathan): either rework the iio framework

to

quoted

register iio map array earlier or to use late_initcall instead of

init

quoted

for the driver consuming the iio channels.

Interestingly using this problem would not arise due to module

dependencies.

quoted

But using late_initcall would mean this needs to be done on any

driver using

quoted

iio channels? I would rather keep those consumers simple.

Me too, but that would imply a solution in iio. The change you

propose above

quoted

isn't exactly simple either, and would also be needed in each

consumer driver.

quoted

Just for the record, I dislike the late_initcall solution as well,

but I prefer

quoted

it over blindly converting ENODEV to EPROBE_DEFER.

I'm falling on the other side on this one right now. Though I'd be

tempted

quoted

to renaming the function to something like

iio_channel_get_all_or_defer

quoted

to make it explicit that it can result in deferred probing.

Would this new function return -EPROBE_DEFER instead of -ENODEV ?

Yes. Though whether it really adds much over doing that in drivers isn't clear.

Hmm. Needs more thought...

Either we do the exact same "hack" as in the v2[1] in what you call
iio_channel_get_all_or_defer or we duplicate the code from
iio_channel_get_all in iio_channel_get_all_or_defer. Both do not seem
right to me but I really dislike the late_initcall method. With this
method we can only have one level of "channel dependency".

This means if we ever create a new driver which depends on channels from
the driver using late_initcall, we will also have to use late_initcall
and we can't be sure the new driver will always be probed after the
driver he depends on.

[1] https://lkml.org/lkml/2016/7/15/215

Quentin

quoted

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help