From: Nathan Fontenot <nfont@austin.ibm.com>
To: Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
Grant Likely <grant.likely@linaro.org>
Cc: devicetree@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
linuxppc-dev <linuxppc-dev@ozlabs.org>,
Tyrel Datwyler <tyreld@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: OF_DYNAMIC node lifecycle
Date: Fri, 27 Jun 2014 09:41:05 -0500 [thread overview]
Message-ID: <53AD8281.8060505@austin.ibm.com> (raw)
In-Reply-To: <94595B4D-1A58-427C-B9CE-C139048FEDCD@konsulko.com>
On 06/27/2014 07:40 AM, Pantelis Antoniou wrote:
> Hi Grant,
>
> On Jun 27, 2014, at 3:32 PM, Grant Likely wrote:
>
>> On Thu, 26 Jun 2014 14:59:31 -0500, Nathan Fontenot <nfont@austin.ibm.com> wrote:
>>> On 06/25/2014 03:22 PM, Grant Likely wrote:
>>>> On Tue, 24 Jun 2014 15:07:05 -0500, Nathan Fontenot <nfont@austin.ibm.com> wrote:
>>>>> On 06/23/2014 09:58 AM, Grant Likely wrote:
>>>>>> On Thu, 19 Jun 2014 11:33:20 +0300, Pantelis Antoniou <pantelis.antoniou@konsulko.com> wrote:
>>>>>>> Hi Grant,
>>>>>>>
>
> [snip]
>
>>>
>>> This would affect property updates. When doing a property update the
>>> notifier passes a pointer to a struct containing a device node
>>> pointer and a pointer to the new device node property.
>>>
>>> I know specifically in memory property updates we grab the current version
>>> of the device tree property and compare it to the 'new' version that
>>> was passed to us.
>>>
>>> If you want to do the DT update before calling the notifier that should be
>>> fine for the memory update code and would only require very minimal
>>> updates.
>>
>> We could change the notifier to include both the old and new values.
>>
>> I've been thinking about changing the notifier format anyway. With the
>> addition of bulk changes, it would be more efficient to send a single
>> notifier for all the changes with a link to the change set instead of
>> one at a time.
>>
>
> That one has my vote. We also need a bulk change notifier, and for device
> driver use, some kind of wrapper for specific node/properties.
>
> At the moment a notification is fired for any change in the tree, we might
> work something more fine-grained. Like 'watch this node & subnodes', or
> 'watch this property (or set of properties)'
>
Both of these updates would work.
For property updates the only real requirement is that we can get to the new
and the old version of the property value.
I like the idea of being able to watch a single node/property. My experience
is that most code is only interested in updates to a single node or
property. Being able to avoid notifying everyone that has registered a
notifier for DT updates for every change would be nice.
-Nathan
-Nathan
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Fontenot <nfont-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org>
To: Pantelis Antoniou
<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Tyrel Datwyler
<tyreld-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
linuxppc-dev
<linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
Subject: Re: OF_DYNAMIC node lifecycle
Date: Fri, 27 Jun 2014 09:41:05 -0500 [thread overview]
Message-ID: <53AD8281.8060505@austin.ibm.com> (raw)
In-Reply-To: <94595B4D-1A58-427C-B9CE-C139048FEDCD-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
On 06/27/2014 07:40 AM, Pantelis Antoniou wrote:
> Hi Grant,
>
> On Jun 27, 2014, at 3:32 PM, Grant Likely wrote:
>
>> On Thu, 26 Jun 2014 14:59:31 -0500, Nathan Fontenot <nfont-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org> wrote:
>>> On 06/25/2014 03:22 PM, Grant Likely wrote:
>>>> On Tue, 24 Jun 2014 15:07:05 -0500, Nathan Fontenot <nfont-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org> wrote:
>>>>> On 06/23/2014 09:58 AM, Grant Likely wrote:
>>>>>> On Thu, 19 Jun 2014 11:33:20 +0300, Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
>>>>>>> Hi Grant,
>>>>>>>
>
> [snip]
>
>>>
>>> This would affect property updates. When doing a property update the
>>> notifier passes a pointer to a struct containing a device node
>>> pointer and a pointer to the new device node property.
>>>
>>> I know specifically in memory property updates we grab the current version
>>> of the device tree property and compare it to the 'new' version that
>>> was passed to us.
>>>
>>> If you want to do the DT update before calling the notifier that should be
>>> fine for the memory update code and would only require very minimal
>>> updates.
>>
>> We could change the notifier to include both the old and new values.
>>
>> I've been thinking about changing the notifier format anyway. With the
>> addition of bulk changes, it would be more efficient to send a single
>> notifier for all the changes with a link to the change set instead of
>> one at a time.
>>
>
> That one has my vote. We also need a bulk change notifier, and for device
> driver use, some kind of wrapper for specific node/properties.
>
> At the moment a notification is fired for any change in the tree, we might
> work something more fine-grained. Like 'watch this node & subnodes', or
> 'watch this property (or set of properties)'
>
Both of these updates would work.
For property updates the only real requirement is that we can get to the new
and the old version of the property value.
I like the idea of being able to watch a single node/property. My experience
is that most code is only interested in updates to a single node or
property. Being able to avoid notifying everyone that has registered a
notifier for DT updates for every change would be nice.
-Nathan
-Nathan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-06-27 14:41 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 20:07 OF_DYNAMIC node lifecycle Grant Likely
2014-06-18 20:07 ` Grant Likely
2014-06-19 8:33 ` Pantelis Antoniou
2014-06-19 8:33 ` Pantelis Antoniou
2014-06-23 14:58 ` Grant Likely
2014-06-23 14:58 ` Grant Likely
2014-06-23 15:26 ` Pantelis Antoniou
2014-06-23 15:26 ` Pantelis Antoniou
2014-06-23 20:21 ` Grant Likely
2014-06-23 20:21 ` Grant Likely
2014-06-24 20:07 ` Nathan Fontenot
2014-06-24 20:07 ` Nathan Fontenot
2014-06-25 20:22 ` Grant Likely
2014-06-25 20:22 ` Grant Likely
2014-06-26 19:59 ` Nathan Fontenot
2014-06-26 19:59 ` Nathan Fontenot
2014-06-27 12:32 ` Grant Likely
2014-06-27 12:32 ` Grant Likely
2014-06-27 12:40 ` Pantelis Antoniou
2014-06-27 12:40 ` Pantelis Antoniou
2014-06-27 14:41 ` Nathan Fontenot [this message]
2014-06-27 14:41 ` Nathan Fontenot
2014-06-19 15:26 ` Nathan Fontenot
2014-06-19 15:26 ` Nathan Fontenot
2014-06-23 14:48 ` Grant Likely
2014-06-23 14:48 ` Grant Likely
2014-06-24 20:10 ` Nathan Fontenot
2014-06-24 20:10 ` Nathan Fontenot
2014-06-25 20:24 ` Grant Likely
2014-06-25 20:24 ` Grant Likely
2014-06-26 20:01 ` Nathan Fontenot
2014-06-26 20:01 ` Nathan Fontenot
2014-06-27 12:41 ` Grant Likely
2014-06-27 12:41 ` Grant Likely
2014-06-27 14:41 ` Nathan Fontenot
2014-06-27 14:41 ` Nathan Fontenot
2014-07-16 5:33 ` Grant Likely
2014-07-16 5:33 ` Grant Likely
2014-07-16 18:30 ` Tyrel Datwyler
2014-07-16 18:30 ` Tyrel Datwyler
2014-07-16 20:57 ` Grant Likely
2014-07-16 20:57 ` Grant Likely
2014-07-16 22:26 ` Grant Likely
2014-07-16 22:26 ` Grant Likely
2014-07-16 23:12 ` Nathan Fontenot
2014-07-16 23:12 ` Nathan Fontenot
2014-07-17 0:44 ` Grant Likely
2014-07-17 0:44 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53AD8281.8060505@austin.ibm.com \
--to=nfont@austin.ibm.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=pantelis.antoniou@konsulko.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tyreld@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.