linux-kernel - Re: [RFC PATCH] mfd: arizona: Update device tree regulator bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130929175236.GV19304@sirena.org.uk>
Date:	Sun, 29 Sep 2013 18:52:36 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
Cc:	devicetree@...r.kernel.org, patches@...nsource.wolfsonmicro.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mfd: arizona: Update device tree regulator bindings

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.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)