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: <20130929141137.GW3635@opensource.wolfsonmicro.com>
Date:	Sun, 29 Sep 2013 15:11:37 +0100
From:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To:	Mark Brown <broonie@...nel.org>
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 Sat, Sep 28, 2013 at 11:55:35PM +0100, Mark Brown wrote:
> No, having the supplies bound to the parent is desired (especially given
> that there isn't a child node) - it's the fact that you're bodging this
> in the framework by just randomly peering at the parent device and
> hoping it's an MFD parent when a lookup fails.  That's not a safe thing
> to do.  
> 
> Like I said in the quote above trying to handle this in the child isn't
> a good approach, it's both more idiomatic and more robust to put the
> mappings from the parent device to the child devices in when creating
> the child devices.

Apologies I didn't mean to convey I was still pushing for the
above patch. I am just trying to get a good handle on what needs
to be done here, and thought I best clarify about the gpio
functionality as it is starting to look like changes in quite a
few places and I am wondering if there is a better more central
place to handle the issue.

> > For example, the GPIO driver has a similar issue if anything else
> > wishes to use an Arizona devices GPIO, because the GPIO driver
> > is on a different device to the MFD so again it can't locate it.
> > I haven't checked yet but I am guessing there will be similar
> > issues with the interrupts.
> 
> No, this isn't an issue at all.  Look at how the regulator API resolves
> DT lookups for example, the structure of the driver offering the service
> should have no impact on anything referencing it.  The fact that Linux
> happens to split things up into a particular set of subsystems at the
> current time should have no bearing on the way that the DT bindings are
> written since that's just a detail of how Linux works.

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;

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.

Thanks,
Charles

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/