[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B488B3A5-C455-4DD2-BBB9-8C02E0851D17@antoniou-consulting.com>
Date: Tue, 19 Mar 2013 13:42:32 +0200
From: Pantelis Antoniou <panto@...oniou-consulting.com>
To: Grant Likely <grant.likely@...retlab.ca>
Cc: Rob Herring <rob.herring@...xeda.com>,
Rob Landley <rob@...dley.net>, Jon Loeliger <jdl@....com>,
Tony Lindgren <tony@...mide.com>,
Stephen Warren <swarren@...dotorg.org>,
David Gibson <david@...son.dropbear.id.au>,
Benoit Cousson <b-cousson@...com>,
Mitch Bradley <wmb@...mworks.com>,
Alan Tull <atull@...era.com>, linux-omap@...r.kernel.org,
devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, Matt Porter <mporter@...com>,
Russ Dill <Russ.Dill@...com>,
Koen Kooi <koen@...inion.thruhere.net>,
Joel A Fernandes <agnel.joel@...il.com>,
Rob Clark <robdclark@...il.com>,
Jason Kridner <jkridner@...gleboard.org>,
Matt Ranostay <mranostay@...il.com>
Subject: Re: [PATCH 3/6] OF: Export all DT proc update functions
Hi Grant,
The 3rd patch is in preparation for some patches I have in WIP that would allow
drivers to set notifications for properties that are changed in runtime.
I think that since you have the all configuration taking place via DT and you
have a method to alter DT properties in run-time via /proc/device-tree, it's quite
straightforward to be able to alter runtime behavior via the same mechanism.
I.e. if you have some property that controls a devices behavior, it's intuitive that
when you modify that property, the device's state changes accordingly.
Regards
-- Pantelis
On Mar 16, 2013, at 11:45 AM, Grant Likely wrote:
> On Fri, 4 Jan 2013 21:31:07 +0200, Pantelis Antoniou <panto@...oniou-consulting.com> wrote:
>> There are other users for the proc DT functions.
>> Export them.
>>
>> Signed-off-by: Pantelis Antoniou <panto@...oniou-consulting.com>
>
> Hi Pantelis.
>
> Patches 1 & 2 look good. No comments there.
>
> This patch bothers me. The manipulation of the proc entries is part and
> parcel of adding and removing nodes. The real problem seems to be that
> the node addition/removal APIs need to be made usable by the overlay
> code.
>
> g.
--
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/
Powered by blists - more mailing lists