All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@austin.ibm.com>
To: Grant Likely <grant.likely@linaro.org>,
	Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: OF_DYNAMIC node lifecycle
Date: Fri, 27 Jun 2014 09:41:26 -0500	[thread overview]
Message-ID: <53AD8296.6040702@austin.ibm.com> (raw)
In-Reply-To: <20140627124101.367F7C40E5E@trevor.secretlab.ca>

On 06/27/2014 07:41 AM, Grant Likely wrote:
> On Thu, 26 Jun 2014 15:01:49 -0500, Nathan Fontenot <nfont@austin.ibm.com> wrote:
>> On 06/25/2014 03:24 PM, Grant Likely wrote:
>>> On Tue, 24 Jun 2014 15:10:55 -0500, Nathan Fontenot <nfont@austin.ibm.com> wrote:
>>>>>> heh! I have often thought about adding reference counting to device tree
>>>>>> properties.
>>>>>
>>>>> You horrible, horrible man.
>>>>
>>>> Yes. I are evil :)
>>>>
>>>> After looking again the work needed to add reference counts to properties
>>>> would be huge. The few properties I am concerned with are specific to powerpc
>>>> so perhaps just adding an arch specific lock around updating those
>>>> properties would work.
>>>
>>> Which code/properties? I'd like to have a look myself.
>>
>> /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory
>>
>> The property is updated in 
>> arch/powerpc/platforms/pseries/hotplug-memory.c:pseries_update_drconf_memory()
> 
> Specifically, what do you need for the locking? Are you wanting to hold
> off additional changes while that function is executing? Pantelis is
> adding a mutex for device tree writers. Holding that mutex would prevent
> any changes from happening in the tree without affecting readers. Would
> that be sufficient?

That would work.

-Nathan

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Fontenot <nfont-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org>
To: Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Tyrel Datwyler
	<tyreld-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Benjamin Herrenschmidt
	<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
	linuxppc-dev
	<linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Pantelis Antoniou
	<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
Subject: Re: OF_DYNAMIC node lifecycle
Date: Fri, 27 Jun 2014 09:41:26 -0500	[thread overview]
Message-ID: <53AD8296.6040702@austin.ibm.com> (raw)
In-Reply-To: <20140627124101.367F7C40E5E-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>

On 06/27/2014 07:41 AM, Grant Likely wrote:
> On Thu, 26 Jun 2014 15:01:49 -0500, Nathan Fontenot <nfont-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org> wrote:
>> On 06/25/2014 03:24 PM, Grant Likely wrote:
>>> On Tue, 24 Jun 2014 15:10:55 -0500, Nathan Fontenot <nfont-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org> wrote:
>>>>>> heh! I have often thought about adding reference counting to device tree
>>>>>> properties.
>>>>>
>>>>> You horrible, horrible man.
>>>>
>>>> Yes. I are evil :)
>>>>
>>>> After looking again the work needed to add reference counts to properties
>>>> would be huge. The few properties I am concerned with are specific to powerpc
>>>> so perhaps just adding an arch specific lock around updating those
>>>> properties would work.
>>>
>>> Which code/properties? I'd like to have a look myself.
>>
>> /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory
>>
>> The property is updated in 
>> arch/powerpc/platforms/pseries/hotplug-memory.c:pseries_update_drconf_memory()
> 
> Specifically, what do you need for the locking? Are you wanting to hold
> off additional changes while that function is executing? Pantelis is
> adding a mutex for device tree writers. Holding that mutex would prevent
> any changes from happening in the tree without affecting readers. Would
> that be sufficient?

That would work.

-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

  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
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 [this message]
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=53AD8296.6040702@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=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.