linux-kernel - Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node

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: <CAMLZHHQU-eMAtvBQJj6+WrMjkWWA+ET=z5NdQCEgXxh=m10d3Q@mail.gmail.com>
Date:	Tue, 27 Sep 2011 17:44:04 +0100
From:	Daniel Drake <dsd@...top.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	sameo@...ux.intel.com, devicetree-discuss@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org, dilinger@...ued.net
Subject: Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node

On Tue, Sep 27, 2011 at 4:05 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> What is a hard rule is that the code creating the children needs to
> know what the binding is and populate the child's of_node
> appropriately.  Similarly, the child driver needs to know something
> about the kinds of nodes it will be passed (can be tested by the
> compatible property).

Thanks for your input.
Here is an updated patch which takes account of this hard rule.

It uses the dynamic mfd cell creation like before. Mark isn't keen on
this, but its how the driver works already, so I don't think it should
be a blocker. I don't know how else we can make the mfd framework meet
Grant's hard rule.

However, it does take Mark's suggestion into account that the mfd
should have some clear representation in the device tree. For us it
already did have (naturally), but this wasn't reflected in my earlier
patch. It is now - the location of the vx855-gpio node is based on
finding the mfd node and going from there.

Comments?
It obviously needs to be tested and split up into individual patches -
I'll do that shortly if this doesn't get shot down.

cheers
Daniel

View attachment "vx855-2.txt" of type "text/plain" (3286 bytes)