diff for duplicates of <20160414001913.GG14441@codeaurora.org> diff --git a/a/1.txt b/N1/1.txt index 7ffbd77..8bcb6c4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -16,22 +16,22 @@ On 04/08, Sjoerd Simons wrote: > The dtsi we're loooking at has (in pseudo dt): > > device { -> clock-names = "internal", "external"; -> clocks = <&internal, &external> +> � clock-names = "internal", "external"; +> � clocks = <&internal, &external> > }; > > external { -> compatible = "fixed-clock"; -> clock-frequency = <12345>; -> status = "disabled"; +> � compatible = "fixed-clock"; +> � clock-frequency = <12345>; +> � status = "disabled"; > }; > -> Before 3e5dd6f6e690048d ("clk: Ignore disabled DT clock providers") +> Before�3e5dd6f6e690048d ("clk: Ignore�disabled DT�clock providers") > this apparently worked. Afterwards drivers getting all the clocks would > fail to probe with -EPROBE_DEFER. > > Judging by your comment I assume this way of modelling it is broken -> (and the behaviour caused by the patch is correct)? +> (and the behaviour caused by the patch is correct)?� > > And as a follow-up, is modelling unconnected clocks as enabled with a > frequency of 0hz as my proposed patch does seen as the right way of diff --git a/a/content_digest b/N1/content_digest index abd0c5f..12fb3f8 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -35,22 +35,22 @@ "> The dtsi we're loooking at has (in pseudo dt):\n" "> \n" "> device {\n" - "> \302\240 clock-names = \"internal\", \"external\";\n" - "> \302\240 clocks = <&internal, &external>\n" + "> \303\257\302\277\302\275 clock-names = \"internal\", \"external\";\n" + "> \303\257\302\277\302\275 clocks = <&internal, &external>\n" "> };\n" "> \n" "> external {\n" - "> \302\240 compatible = \"fixed-clock\";\n" - "> \302\240 clock-frequency = <12345>;\n" - "> \302\240 status = \"disabled\";\n" + "> \303\257\302\277\302\275 compatible = \"fixed-clock\";\n" + "> \303\257\302\277\302\275 clock-frequency = <12345>;\n" + "> \303\257\302\277\302\275 status = \"disabled\";\n" "> };\n" "> \n" - "> Before\302\2403e5dd6f6e690048d (\"clk: Ignore\302\240disabled DT\302\240clock providers\")\n" + "> Before\303\257\302\277\302\2753e5dd6f6e690048d (\"clk: Ignore\303\257\302\277\302\275disabled DT\303\257\302\277\302\275clock providers\")\n" "> this apparently worked. Afterwards drivers getting all the clocks would\n" "> fail to probe with -EPROBE_DEFER.\n" "> \n" "> Judging by your comment I assume this way of modelling it is broken\n" - "> (and the behaviour caused by the patch is correct)?\302\240\n" + "> (and the behaviour caused by the patch is correct)?\303\257\302\277\302\275\n" "> \n" "> And as a follow-up, is modelling unconnected clocks as enabled with a\n" "> frequency of 0hz as my proposed patch does seen as the right way of\n" @@ -137,4 +137,4 @@ "Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,\n" a Linux Foundation Collaborative Project -75f0dc916d0a0a443589f481b6affe53c25bb8948c9597c9f2c1607758eb56ca +354eddd8186a575fd97664354a66c8c4989241bae5e53532a13406bdbf79bd3c
diff --git a/a/1.txt b/N2/1.txt index 7ffbd77..0853ab6 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -16,22 +16,22 @@ On 04/08, Sjoerd Simons wrote: > The dtsi we're loooking at has (in pseudo dt): > > device { -> clock-names = "internal", "external"; -> clocks = <&internal, &external> +> ? clock-names = "internal", "external"; +> ? clocks = <&internal, &external> > }; > > external { -> compatible = "fixed-clock"; -> clock-frequency = <12345>; -> status = "disabled"; +> ? compatible = "fixed-clock"; +> ? clock-frequency = <12345>; +> ? status = "disabled"; > }; > -> Before 3e5dd6f6e690048d ("clk: Ignore disabled DT clock providers") +> Before?3e5dd6f6e690048d ("clk: Ignore?disabled DT?clock providers") > this apparently worked. Afterwards drivers getting all the clocks would > fail to probe with -EPROBE_DEFER. > > Judging by your comment I assume this way of modelling it is broken -> (and the behaviour caused by the patch is correct)? +> (and the behaviour caused by the patch is correct)?? > > And as a follow-up, is modelling unconnected clocks as enabled with a > frequency of 0hz as my proposed patch does seen as the right way of diff --git a/a/content_digest b/N2/content_digest index abd0c5f..d969eeb 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -3,18 +3,10 @@ "ref\01459949826.23936.19.camel@collabora.co.uk\0" "ref\020160407232155.GH18567@codeaurora.org\0" "ref\01460112654.31245.20.camel@collabora.co.uk\0" - "From\0Stephen Boyd <sboyd@codeaurora.org>\0" - "Subject\0Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks\0" + "From\0sboyd@codeaurora.org (Stephen Boyd)\0" + "Subject\0[PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks\0" "Date\0Wed, 13 Apr 2016 17:19:13 -0700\0" - "To\0Sjoerd Simons <sjoerd.simons@collabora.co.uk>\0" - "Cc\0Geert Uytterhoeven <geert@linux-m68k.org>" - Simon Horman <horms@verge.net.au> - linux-renesas-soc@vger.kernel.org - devicetree@vger.kernel.org <devicetree@vger.kernel.org> - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> - linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> - Michael Turquette <mturquette@baylibre.com> - " linux-clk <linux-clk@vger.kernel.org>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On 04/08, Sjoerd Simons wrote:\n" @@ -35,22 +27,22 @@ "> The dtsi we're loooking at has (in pseudo dt):\n" "> \n" "> device {\n" - "> \302\240 clock-names = \"internal\", \"external\";\n" - "> \302\240 clocks = <&internal, &external>\n" + "> ? clock-names = \"internal\", \"external\";\n" + "> ? clocks = <&internal, &external>\n" "> };\n" "> \n" "> external {\n" - "> \302\240 compatible = \"fixed-clock\";\n" - "> \302\240 clock-frequency = <12345>;\n" - "> \302\240 status = \"disabled\";\n" + "> ? compatible = \"fixed-clock\";\n" + "> ? clock-frequency = <12345>;\n" + "> ? status = \"disabled\";\n" "> };\n" "> \n" - "> Before\302\2403e5dd6f6e690048d (\"clk: Ignore\302\240disabled DT\302\240clock providers\")\n" + "> Before?3e5dd6f6e690048d (\"clk: Ignore?disabled DT?clock providers\")\n" "> this apparently worked. Afterwards drivers getting all the clocks would\n" "> fail to probe with -EPROBE_DEFER.\n" "> \n" "> Judging by your comment I assume this way of modelling it is broken\n" - "> (and the behaviour caused by the patch is correct)?\302\240\n" + "> (and the behaviour caused by the patch is correct)??\n" "> \n" "> And as a follow-up, is modelling unconnected clocks as enabled with a\n" "> frequency of 0hz as my proposed patch does seen as the right way of\n" @@ -137,4 +129,4 @@ "Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,\n" a Linux Foundation Collaborative Project -75f0dc916d0a0a443589f481b6affe53c25bb8948c9597c9f2c1607758eb56ca +023c33ec7e72782278c92e3ae7ff881366b61b0f7ecbcbd27acb6c6ec38fcfc9
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.