On Sun, Sep 29, 2013 at 03:11:37PM +0100, Charles Keepax wrote:

There is currently only one other MFD driver (tps65910) which defines
the GPIOs on the main MFD node as we do in the Arizona driver and it
uses the 'hack' that I suggested in my first email of copying the
of_node.

tps65910_gpio->gpio_chip.of_node = tps65910->dev->of_node;

Look where it's copying it to - this isn't the hack you were suggesting
before.  What you were suggesting before was setting the of_node of the
child struct device which is a managed thing that the driver core knows
about, the device is the owner of the of_node hanging off it.  You would
end up with the same of_node referenced from two struct devices which
isn't clever.  The above is putting a pointer into the gpio_chip which
is just telling gpiolib that it should use this of_node when it needs
one, gpiolib won't try and lifecycle manage the of_node.

Looking around there seem to be quite a few drivers that copy
of_node pointers like this are we sure this isn't an acceptable
solution? I mean the arizona driver we know the components will
always be loaded as part of the MFD and thus will be freed before
the parent node.

It's fine to reference an of_node, that's obviously something that will
need to happen at some point in order to do anything useful with the
data.