From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org ([63.228.1.57]:47586 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752391AbbENHrw (ORCPT ); Thu, 14 May 2015 03:47:52 -0400 Message-ID: <1431589652.4160.49.camel@kernel.crashing.org> Subject: Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree From: Benjamin Herrenschmidt To: Pantelis Antoniou Cc: Rob Herring , Gavin Shan , linuxppc-dev , "linux-pci@vger.kernel.org" , Bjorn Helgaas , Grant Likely , "devicetree@vger.kernel.org" Date: Thu, 14 May 2015 17:47:32 +1000 In-Reply-To: References: <1430460188-31343-1-git-send-email-gwshan@linux.vnet.ibm.com> <1430460188-31343-20-git-send-email-gwshan@linux.vnet.ibm.com> <1430493730.7979.58.camel@kernel.crashing.org> <1430521038.7979.70.camel@kernel.crashing.org> <1430774063.7979.139.camel@kernel.crashing.org> <1431560124.20218.91.camel@kernel.crashing.org> <1431564871.4160.8.camel@kernel.crashing.org> <53EAE361-0015-4702-97C6-9F67B87963C2@antoniou-consulting.com> <1431585994.4160.32.camel@kernel.crashing.org> <3988EABE-3DE9-4E1C-9778-22E35138E359@antoniou-consulting.com> <1431587657.4160.37.camel@kernel.crashing.org> <75F026CA-5AC1-4106-B2F0-AB0D006DEF5A@antoniou-consulting.com> <1431588358.4160.42.camel@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org List-ID: On Thu, 2015-05-14 at 10:34 +0300, Pantelis Antoniou wrote: > >> What you describe is inserting a bunch of properties and nodes under > >> a slot’s device node. Reverting the overlay removes them all just fine. > > > > Except that still doesn't work for boot time :-) > > > > So I would have to do a special case on unplug: > > > > if (slot->dt_is_overlay) /* set to false at boot */ > > remove_subtree_myself(); > > else > > undo_overlay(slot->overlay); > > > > OK, in that case you do require removal. But in any case it’s the ‘negative’ > of an already applied one, either at boot time or not. Sort-of, unless we have a way in the overlay to simply specify node removal statements so we don't have to explicitly remove all properties (or even all children). > Modifying the overlay code to apply a ‘negative’ property should do the trick. > > Is that correct? I would do negatives node and let Linux imply the properties (or even children). But yes, that would probably do. .../... > I will probably need that generation count myself for my PCI use case. > > > However that requires supporting removal of nodes/properties. So I'm > > tempted to keep that feature on the back burner and go with an ad-hoc > > interface for PCI for now. > > > > I see. Bonne chance :) Merci :) Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 677B31A03A4 for ; Thu, 14 May 2015 17:47:50 +1000 (AEST) Message-ID: <1431589652.4160.49.camel@kernel.crashing.org> Subject: Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree From: Benjamin Herrenschmidt To: Pantelis Antoniou Date: Thu, 14 May 2015 17:47:32 +1000 In-Reply-To: References: <1430460188-31343-1-git-send-email-gwshan@linux.vnet.ibm.com> <1430460188-31343-20-git-send-email-gwshan@linux.vnet.ibm.com> <1430493730.7979.58.camel@kernel.crashing.org> <1430521038.7979.70.camel@kernel.crashing.org> <1430774063.7979.139.camel@kernel.crashing.org> <1431560124.20218.91.camel@kernel.crashing.org> <1431564871.4160.8.camel@kernel.crashing.org> <53EAE361-0015-4702-97C6-9F67B87963C2@antoniou-consulting.com> <1431585994.4160.32.camel@kernel.crashing.org> <3988EABE-3DE9-4E1C-9778-22E35138E359@antoniou-consulting.com> <1431587657.4160.37.camel@kernel.crashing.org> <75F026CA-5AC1-4106-B2F0-AB0D006DEF5A@antoniou-consulting.com> <1431588358.4160.42.camel@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: "devicetree@vger.kernel.org" , "linux-pci@vger.kernel.org" , Gavin Shan , Grant Likely , Rob Herring , Bjorn Helgaas , linuxppc-dev List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2015-05-14 at 10:34 +0300, Pantelis Antoniou wrote: > >> What you describe is inserting a bunch of properties and nodes under > >> a slot’s device node. Reverting the overlay removes them all just fine. > > > > Except that still doesn't work for boot time :-) > > > > So I would have to do a special case on unplug: > > > > if (slot->dt_is_overlay) /* set to false at boot */ > > remove_subtree_myself(); > > else > > undo_overlay(slot->overlay); > > > > OK, in that case you do require removal. But in any case it’s the ‘negative’ > of an already applied one, either at boot time or not. Sort-of, unless we have a way in the overlay to simply specify node removal statements so we don't have to explicitly remove all properties (or even all children). > Modifying the overlay code to apply a ‘negative’ property should do the trick. > > Is that correct? I would do negatives node and let Linux imply the properties (or even children). But yes, that would probably do. .../... > I will probably need that generation count myself for my PCI use case. > > > However that requires supporting removal of nodes/properties. So I'm > > tempted to keep that feature on the back burner and go with an ad-hoc > > interface for PCI for now. > > > > I see. Bonne chance :) Merci :) Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree Date: Thu, 14 May 2015 17:47:32 +1000 Message-ID: <1431589652.4160.49.camel@kernel.crashing.org> References: <1430460188-31343-1-git-send-email-gwshan@linux.vnet.ibm.com> <1430460188-31343-20-git-send-email-gwshan@linux.vnet.ibm.com> <1430493730.7979.58.camel@kernel.crashing.org> <1430521038.7979.70.camel@kernel.crashing.org> <1430774063.7979.139.camel@kernel.crashing.org> <1431560124.20218.91.camel@kernel.crashing.org> <1431564871.4160.8.camel@kernel.crashing.org> <53EAE361-0015-4702-97C6-9F67B87963C2@antoniou-consulting.com> <1431585994.4160.32.camel@kernel.crashing.org> <3988EABE-3DE9-4E1C-9778-22E35138E359@antoniou-consulting.com> <1431587657.4160.37.camel@kernel.crashing.org> <75F026CA-5AC1-4106-B2F0-AB0D006DEF5A@antoniou-consulting.com> <1431588358.4160.42.camel@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Pantelis Antoniou Cc: Rob Herring , Gavin Shan , linuxppc-dev , "linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Bjorn Helgaas , Grant Likely , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org On Thu, 2015-05-14 at 10:34 +0300, Pantelis Antoniou wrote: > >> What you describe is inserting a bunch of properties and nodes und= er > >> a slot=E2=80=99s device node. Reverting the overlay removes them a= ll just fine. > >=20 > > Except that still doesn't work for boot time :-) > >=20 > > So I would have to do a special case on unplug: > >=20 > > if (slot->dt_is_overlay) /* set to false at boot */ > > remove_subtree_myself(); > > else > > undo_overlay(slot->overlay); > >=20 >=20 > OK, in that case you do require removal. But in any case it=E2=80=99s= the =E2=80=98negative=E2=80=99 > of an already applied one, either at boot time or not. Sort-of, unless we have a way in the overlay to simply specify node removal statements so we don't have to explicitly remove all properties (or even all children). > Modifying the overlay code to apply a =E2=80=98negative=E2=80=99 prop= erty should do the trick. >=20 > Is that correct? I would do negatives node and let Linux imply the properties (or even children). But yes, that would probably do. .../... > I will probably need that generation count myself for my PCI use case= =2E >=20 > > However that requires supporting removal of nodes/properties. So I'= m > > tempted to keep that feature on the back burner and go with an ad-h= oc > > interface for PCI for now. > >=20 >=20 > I see. Bonne chance :) Merci :) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html