diff for duplicates of <521641A6.2070503@arm.com> diff --git a/a/1.txt b/N1/1.txt index 0ebff9e..600fca9 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,17 +2,20 @@ On 22/08/13 14:59, Mark Rutland wrote: > On Mon, Aug 19, 2013 at 02:56:10PM +0100, Sudeep KarkadaNagesha wrote: >> On 19/08/13 14:02, Rob Herring wrote: >>> On 08/19/2013 05:19 AM, Mark Rutland wrote: ->>>> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote: +>>>> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote= +: >>>>> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote: >>>>>> I wonder how would this handle uniprocessor ARM (pre-v7) cores, for ->>>>>> which ->>>>>> the updated bindings[1] define #address-cells = <0> and so no reg +>>>>>> which=20 +>>>>>> the updated bindings[1] define #address-cells =3D <0> and so no reg= +=20 >>>>>> property. >>>>>> >>>>>> [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795 >>>>> ->>>>> Why did you do that in the binding ? That sounds like looking to create ->>>>> problems ... +>>>>> Why did you do that in the binding ? That sounds like looking to crea= +te +>>>>> problems ...=20 >>>>> >>>>> Traditionally, UP setups just used "0" as the "reg" property on other >>>>> architectures, why do differently ? @@ -30,12 +33,12 @@ On 22/08/13 14:59, Mark Rutland wrote: >> Yes it's better to have 'reg' with value 0 than not having it. >> Otherwise this generic of_get_cpu_node implementation would need some >> _hack_ to handle that case. -> +>=20 > I'm not sure that having some code to handle a difference in standard > between two architectures is a hack. If anything, I'd argue encoding a > reg of 0 that corresponds to a nonexistent MPIDR value (given that's > what the reg property is defined to map to on ARM) is more of a hack ;) -> +>=20 Agreed. But I am more confused. 1. This raises another question as how much do we follow from ePAPR @@ -48,7 +51,7 @@ marked as required too. > I'm not averse to having a reg value of 0 for this case, but given that > there are existing devicetrees without it, requiring a reg property will > break compatibility with them. -> +>=20 2. What exactly does backward compatibility has to cover ? This can't be considered as breaking of the binding definition. In continuation to the diff --git a/a/content_digest b/N1/content_digest index 224f311..14cd5be 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -11,38 +11,40 @@ "Subject\0Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures\0" "Date\0Thu, 22 Aug 2013 17:51:50 +0100\0" "To\0Mark Rutland <mark.rutland@arm.com>\0" - "Cc\0Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>" - Rob Herring <robherring2@gmail.com> - Benjamin Herrenschmidt <benh@kernel.crashing.org> - Jonas Bonn <jonas@southpole.se> + "Cc\0Jonas Bonn <jonas@southpole.se>" devicetree@vger.kernel.org <devicetree@vger.kernel.org> Michal Simek <monstr@monstr.eu> + Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com> linux-pm@vger.kernel.org <linux-pm@vger.kernel.org> + Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com> Tomasz Figa <tomasz.figa@gmail.com> rob.herring@calxeda.com <rob.herring@calxeda.com> linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> Rafael J. Wysocki <rjw@sisk.pl> + Rob Herring <robherring2@gmail.com> grant.likely@linaro.org <grant.likely@linaro.org> linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> - linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> - " Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>\0" + " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0" "\00:1\0" "b\0" "On 22/08/13 14:59, Mark Rutland wrote:\n" "> On Mon, Aug 19, 2013 at 02:56:10PM +0100, Sudeep KarkadaNagesha wrote:\n" ">> On 19/08/13 14:02, Rob Herring wrote:\n" ">>> On 08/19/2013 05:19 AM, Mark Rutland wrote:\n" - ">>>> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote:\n" + ">>>> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote=\n" + ":\n" ">>>>> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:\n" ">>>>>> I wonder how would this handle uniprocessor ARM (pre-v7) cores, for\n" - ">>>>>> which \n" - ">>>>>> the updated bindings[1] define #address-cells = <0> and so no reg \n" + ">>>>>> which=20\n" + ">>>>>> the updated bindings[1] define #address-cells =3D <0> and so no reg=\n" + "=20\n" ">>>>>> property.\n" ">>>>>>\n" ">>>>>> [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795\n" ">>>>>\n" - ">>>>> Why did you do that in the binding ? That sounds like looking to create\n" - ">>>>> problems ... \n" + ">>>>> Why did you do that in the binding ? That sounds like looking to crea=\n" + "te\n" + ">>>>> problems ...=20\n" ">>>>>\n" ">>>>> Traditionally, UP setups just used \"0\" as the \"reg\" property on other\n" ">>>>> architectures, why do differently ?\n" @@ -60,12 +62,12 @@ ">> Yes it's better to have 'reg' with value 0 than not having it.\n" ">> Otherwise this generic of_get_cpu_node implementation would need some\n" ">> _hack_ to handle that case.\n" - "> \n" + ">=20\n" "> I'm not sure that having some code to handle a difference in standard\n" "> between two architectures is a hack. If anything, I'd argue encoding a\n" "> reg of 0 that corresponds to a nonexistent MPIDR value (given that's\n" "> what the reg property is defined to map to on ARM) is more of a hack ;)\n" - "> \n" + ">=20\n" "Agreed. But I am more confused.\n" "\n" "1. This raises another question as how much do we follow from ePAPR\n" @@ -78,7 +80,7 @@ "> I'm not averse to having a reg value of 0 for this case, but given that\n" "> there are existing devicetrees without it, requiring a reg property will\n" "> break compatibility with them.\n" - "> \n" + ">=20\n" "\n" "2. What exactly does backward compatibility has to cover ? This can't be\n" "considered as breaking of the binding definition. In continuation to the\n" @@ -89,4 +91,4 @@ "Regards,\n" Sudeep -42cf0fd1a7f4454fb78a0b859cafdb4b0674705fe56b366db26b10e799a9d287 +17757e87026f1674ba8e3fc3a26502039a1e48f47602acd07405a8b145427309
diff --git a/a/content_digest b/N2/content_digest index 224f311..3119c82 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -7,25 +7,10 @@ "ref\05212177C.8000709@gmail.com\0" "ref\0521223FA.5050903@arm.com\0" "ref\020130822135930.GC23152@e106331-lin.cambridge.arm.com\0" - "From\0Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>\0" - "Subject\0Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures\0" + "From\0Sudeep.KarkadaNagesha@arm.com (Sudeep KarkadaNagesha)\0" + "Subject\0[RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures\0" "Date\0Thu, 22 Aug 2013 17:51:50 +0100\0" - "To\0Mark Rutland <mark.rutland@arm.com>\0" - "Cc\0Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>" - Rob Herring <robherring2@gmail.com> - Benjamin Herrenschmidt <benh@kernel.crashing.org> - Jonas Bonn <jonas@southpole.se> - devicetree@vger.kernel.org <devicetree@vger.kernel.org> - Michal Simek <monstr@monstr.eu> - linux-pm@vger.kernel.org <linux-pm@vger.kernel.org> - Tomasz Figa <tomasz.figa@gmail.com> - rob.herring@calxeda.com <rob.herring@calxeda.com> - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> - Rafael J. Wysocki <rjw@sisk.pl> - grant.likely@linaro.org <grant.likely@linaro.org> - linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> - linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> - " Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On 22/08/13 14:59, Mark Rutland wrote:\n" @@ -89,4 +74,4 @@ "Regards,\n" Sudeep -42cf0fd1a7f4454fb78a0b859cafdb4b0674705fe56b366db26b10e799a9d287 +ce59a8dda7beef5ca35ba4d5128fb397cb72d29fb4a76915e1dfc0e93b5a4faf
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.