diff for duplicates of <521223FA.5050903@arm.com> diff --git a/a/1.txt b/N1/1.txt index 99891e3..1870df7 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,14 +3,14 @@ On 19/08/13 14:02, Rob Herring 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 ... +>>> problems ...=20 >>> >>> Traditionally, UP setups just used "0" as the "reg" property on other >>> architectures, why do differently ? @@ -20,11 +20,11 @@ On 19/08/13 14:02, Rob Herring wrote: >> there's no MPIDR register at all. Given there can only be a single CPU >> in that case, describing a register that wasn't present didn't seem >> necessary or helpful. -> +>=20 > What exactly reg represents is up to the binding definition, but it > still should be present IMO. I don't see any issue with it being > different for pre-v7. -> +>=20 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. diff --git a/a/content_digest b/N1/content_digest index 1b87c88..a47ef4b 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -10,20 +10,19 @@ "Date\0Mon, 19 Aug 2013 14:56:10 +0100\0" "To\0Rob Herring <robherring2@gmail.com>\0" "Cc\0Mark Rutland <Mark.Rutland@arm.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> + 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> + devicetree@vger.kernel.org <devicetree@vger.kernel.org> 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 19/08/13 14:02, Rob Herring wrote:\n" @@ -31,14 +30,14 @@ ">> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote:\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=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" + ">>> problems ...=20\n" ">>>\n" ">>> Traditionally, UP setups just used \"0\" as the \"reg\" property on other\n" ">>> architectures, why do differently ?\n" @@ -48,11 +47,11 @@ ">> there's no MPIDR register at all. Given there can only be a single CPU\n" ">> in that case, describing a register that wasn't present didn't seem\n" ">> necessary or helpful.\n" - "> \n" + ">=20\n" "> What exactly reg represents is up to the binding definition, but it\n" "> still should be present IMO. I don't see any issue with it being\n" "> different for pre-v7.\n" - "> \n" + ">=20\n" "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" @@ -60,4 +59,4 @@ "Regards,\n" Sudeep -c8635ce028afaa7e5530875fe8c498fd9c03b55e11269b20b599bddf10cdb0ab +9b5650d5a47205572f59dbfdee5b4941903e1285d73d833d7cac3f76a83b19f7
diff --git a/a/content_digest b/N2/content_digest index 1b87c88..f951063 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -5,25 +5,10 @@ "ref\01376777376.25016.11.camel@pasglop\0" "ref\020130819101922.GI3719@e106331-lin.cambridge.arm.com\0" "ref\05212177C.8000709@gmail.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\0Mon, 19 Aug 2013 14:56:10 +0100\0" - "To\0Rob Herring <robherring2@gmail.com>\0" - "Cc\0Mark Rutland <Mark.Rutland@arm.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> - 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> - 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 19/08/13 14:02, Rob Herring wrote:\n" @@ -60,4 +45,4 @@ "Regards,\n" Sudeep -c8635ce028afaa7e5530875fe8c498fd9c03b55e11269b20b599bddf10cdb0ab +245e11642e786198753f4c19b4f78630c6b5310b9ca598eead6c650ce5b705a6
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.