diff for duplicates of <688373BE-2C67-4427-91A1-C4C3A725F0CC@codeaurora.org>
diff --git a/a/1.txt b/N2/1.txt
index 3614706..5a1529b 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -37,9 +37,9 @@ On Jan 21, 2015, at 7:53 PM, Bjorn Andersson <bjorn@kryo.se> wrote:
> shared between the two platforms, so either way it seems like the
> right approach to have this moved out to drivers/soc/qcom.
-As Bjorn says the scm interface ends up having a number of qcom specific calls that I don’t think the firmware ops should be implementing. I don’t see any value in adding qcom specific function pointers to the ops struct just to create another level of indirection.
+As Bjorn says the scm interface ends up having a number of qcom specific calls that I don?t think the firmware ops should be implementing. I don?t see any value in adding qcom specific function pointers to the ops struct just to create another level of indirection.
-I’m fine with adding a firmware_ops implementation that uses scm for those things that firmware_ops has today. However, I’m not clear on what the view of extending firmware_ops to arm64 is. If we do this do we move the firmware_ops code into drivers/soc ?
+I?m fine with adding a firmware_ops implementation that uses scm for those things that firmware_ops has today. However, I?m not clear on what the view of extending firmware_ops to arm64 is. If we do this do we move the firmware_ops code into drivers/soc ?
- k
diff --git a/a/content_digest b/N2/content_digest
index 784d7f1..d6ac6a3 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -11,25 +11,16 @@
"ref\0CAJAp7OgtnTN3H+zSazK2Xeob6wxpf9Ws=tibAupzP1cF31G=Mw\@mail.gmail.com\0"
]
[
- "From\0Kumar Gala <galak\@codeaurora.org>\0"
+ "From\0galak\@codeaurora.org (Kumar Gala)\0"
]
[
- "Subject\0Re: [PATCH 8/8] msm: scm: Move the scm driver to drivers/soc/qcom\0"
+ "Subject\0[PATCH 8/8] msm: scm: Move the scm driver to drivers/soc/qcom\0"
]
[
"Date\0Thu, 22 Jan 2015 10:49:56 -0600\0"
]
[
- "To\0Olof Johansson <olof\@lixom.net>\0"
-]
-[
- "Cc\0Stephen Boyd <sboyd\@codeaurora.org>",
- " Bjorn Andersson <bjorn\@kryo.se>",
- " David Brown <davidb\@codeaurora.org>",
- " linux-kernel\@vger.kernel.org <linux-kernel\@vger.kernel.org>",
- " linux-arm-msm <linux-arm-msm\@vger.kernel.org>",
- " linux-arm-kernel\@lists.infradead.org <linux-arm-kernel\@lists.infradead.org>",
- " Lina Iyer <lina.iyer\@linaro.org>\0"
+ "To\0linux-arm-kernel\@lists.infradead.org\0"
]
[
"\0000:1\0"
@@ -77,9 +68,9 @@
"> shared between the two platforms, so either way it seems like the\n",
"> right approach to have this moved out to drivers/soc/qcom.\n",
"\n",
- "As Bjorn says the scm interface ends up having a number of qcom specific calls that I don\342\200\231t think the firmware ops should be implementing. I don\342\200\231t see any value in adding qcom specific function pointers to the ops struct just to create another level of indirection.\n",
+ "As Bjorn says the scm interface ends up having a number of qcom specific calls that I don?t think the firmware ops should be implementing. I don?t see any value in adding qcom specific function pointers to the ops struct just to create another level of indirection.\n",
"\n",
- "I\342\200\231m fine with adding a firmware_ops implementation that uses scm for those things that firmware_ops has today. However, I\342\200\231m not clear on what the view of extending firmware_ops to arm64 is. If we do this do we move the firmware_ops code into drivers/soc ?\n",
+ "I?m fine with adding a firmware_ops implementation that uses scm for those things that firmware_ops has today. However, I?m not clear on what the view of extending firmware_ops to arm64 is. If we do this do we move the firmware_ops code into drivers/soc ?\n",
"\n",
"- k\n",
"\n",
@@ -89,4 +80,4 @@
"a Linux Foundation Collaborative Project"
]
-e60af9b43c0687a684a8072c871883c5c5b7d8b1fa3117627afc4d6dfadad805
+fde5d44f7b0233c2801ea7f1de68f9b0a371d634bcae81912a77b1d1bcdae49c
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.