All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20150602100739.GK3329@x1>

diff --git a/a/1.txt b/N1/1.txt
index 87b81da..c72735d 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -7,16 +7,12 @@ On Tue, 02 Jun 2015, Vaibhav Hiremath wrote:
 > >>>>>On Sat, 30 May 2015, Vaibhav Hiremath wrote:
 > >>>>>
 > >>>>>>RTC in pmic 88PM800 can run even the core is powered off, and user
-> >>>>>>can set alarm in RTC. When the alarm is timed out, the PMIC will po=
-wer up
-> >>>>>>the core, and the whole system will boot up. And during PMIC driver=
- probe,
-> >>>>>>it will read some register to find out whether this boot is caused =
-by RTC
+> >>>>>>can set alarm in RTC. When the alarm is timed out, the PMIC will power up
+> >>>>>>the core, and the whole system will boot up. And during PMIC driver probe,
+> >>>>>>it will read some register to find out whether this boot is caused by RTC
 > >>>>>>timeout or not, and pass on this information to the RTC driver.
 > >>>>>>
-> >>>>>>So we need rtc platform data to be existed in PMIC driver to pass t=
-his
+> >>>>>>So we need rtc platform data to be existed in PMIC driver to pass this
 > >>>>>>information.
 > >>>>>>
 > >>>>>>Signed-off-by: Chao Xie <chao.xie@marvell.com>
@@ -29,27 +25,21 @@ his
 > >>>>>>index 8ea4467..34546a1 100644
 > >>>>>>--- a/drivers/mfd/88pm800.c
 > >>>>>>+++ b/drivers/mfd/88pm800.c
-> >>>>>>@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *clie=
-nt,
+> >>>>>>@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *client,
 > >>>>>>  			return ret;
 > >>>>>>  	}
 > >>>>>>
 > >>>>>>+	/*
-> >>>>>>+	 * RTC in pmic can run even the core is powered off, and user can=
- set
-> >>>>>>+	 * alarm in RTC. When the alarm is time out, the PMIC will power =
-up
-> >>>>>>+	 * the core, and the whole system will boot up. When PMIC driver =
-is
-> >>>>>>+	 * probed, it will read out some register to find out whether thi=
-s
+> >>>>>>+	 * RTC in pmic can run even the core is powered off, and user can set
+> >>>>>>+	 * alarm in RTC. When the alarm is time out, the PMIC will power up
+> >>>>>>+	 * the core, and the whole system will boot up. When PMIC driver is
+> >>>>>>+	 * probed, it will read out some register to find out whether this
 > >>>>>>+	 * boot is caused by RTC timeout or not, and it need pass this
 > >>>>>>+	 * information to RTC driver.
-> >>>>>>+	 * So we need rtc platform data to be existed to pass this inform=
-ation.
+> >>>>>>+	 * So we need rtc platform data to be existed to pass this information.
 > >>>>>>+	 */
 > >>>>>>+	if (!pdata->rtc) {
-> >>>>>>+		pdata->rtc =3D devm_kzalloc(&client->dev,
+> >>>>>>+		pdata->rtc = devm_kzalloc(&client->dev,
 > >>>>>>+					  sizeof(*(pdata->rtc)), GFP_KERNEL);
 > >>>>>>+		if (!pdata->rtc) {
 > >>>>>>+			dev_err(&client->dev,
@@ -97,7 +87,7 @@ ation.
 > >that you're not going to do that and I'll remove it altogether.
 > >Likewise for rtc_wakeup.
 > >
->=20
+> 
 > I am ok with vrtc field, we can remove it.
 
 Okay, I will do so, thanks.
@@ -105,39 +95,26 @@ Okay, I will do so, thanks.
 > But,
 > I would recommend _not_ to remove rtc_wakeup, as it may not be used
 > immediately, but still have logical significance.
->=20
+> 
 > Consuming rtc_wakeup in the code is dependant on overall power
 > management support, which is always long pole for development. As you
 > would have seen, we have just started with baseport for pxa1928 and I
 > am starting on upstreaming driver part.
->=20
->=20
+> 
+> 
 > From hardware perspective, this is important feature, where it indicate
 > whether the boot was triggered by reset assertion or by RTC wakeup. So
 > as of now from driver perspective I feel no harm to have one field for
 > this.
->=20
+> 
 > Finally, its your call. I will let you decide.
 > The field can be added later when it actually gets consumed.
 
 I will not remove the wake-up field.  Equally, I will not accept code
 which allocates memory for it whilst it is not being used.
 
---=20
+-- 
 Lee Jones
 Linaro STMicroelectronics Landing Team Lead
-Linaro.org =E2=94=82 Open source software for ARM SoCs
+Linaro.org ? Open source software for ARM SoCs
 Follow Linaro: Facebook | Twitter | Blog
-
---=20
---=20
-You received this message because you are subscribed to "rtc-linux".
-Membership options at http://groups.google.com/group/rtc-linux .
-Please read http://groups.google.com/group/rtc-linux/web/checklist
-before submitting a driver.
----=20
-You received this message because you are subscribed to the Google Groups "=
-rtc-linux" group.
-To unsubscribe from this group and stop receiving emails from it, send an e=
-mail to rtc-linux+unsubscribe@googlegroups.com.
-For more options, visit https://groups.google.com/d/optout.
diff --git a/a/content_digest b/N1/content_digest
index fd30ba1..b832275 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,19 +6,10 @@
  "ref\0556D71F6.4030608@linaro.org\0"
  "ref\020150602093323.GI3329@x1\0"
  "ref\0556D7C32.9080806@linaro.org\0"
- "From\0Lee Jones <lee.jones@linaro.org>\0"
- "Subject\0[rtc-linux] Re: [PATCH 4/4] mfd: 88pm800: allocate pdata->rtc if not allocated earlier\0"
+ "From\0lee.jones@linaro.org (Lee Jones)\0"
+ "Subject\0[PATCH 4/4] mfd: 88pm800: allocate pdata->rtc if not allocated earlier\0"
  "Date\0Tue, 2 Jun 2015 11:07:39 +0100\0"
- "To\0Vaibhav Hiremath <vaibhav.hiremath@linaro.org>\0"
- "Cc\0linux-arm-kernel@lists.infradead.org"
-  robh+dt@kernel.org
-  devicetree@vger.kernel.org
-  linux-kernel@vger.kernel.org
-  rtc-linux@googlegroups.com
-  sameo@linux.intel.com
-  a.zummo@towertech.it
-  alexandre.belloni@free-electrons.com
- " Chao Xie <chao.xie@marvell.com>\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Tue, 02 Jun 2015, Vaibhav Hiremath wrote:\n"
@@ -30,16 +21,12 @@
  "> >>>>>On Sat, 30 May 2015, Vaibhav Hiremath wrote:\n"
  "> >>>>>\n"
  "> >>>>>>RTC in pmic 88PM800 can run even the core is powered off, and user\n"
- "> >>>>>>can set alarm in RTC. When the alarm is timed out, the PMIC will po=\n"
- "wer up\n"
- "> >>>>>>the core, and the whole system will boot up. And during PMIC driver=\n"
- " probe,\n"
- "> >>>>>>it will read some register to find out whether this boot is caused =\n"
- "by RTC\n"
+ "> >>>>>>can set alarm in RTC. When the alarm is timed out, the PMIC will power up\n"
+ "> >>>>>>the core, and the whole system will boot up. And during PMIC driver probe,\n"
+ "> >>>>>>it will read some register to find out whether this boot is caused by RTC\n"
  "> >>>>>>timeout or not, and pass on this information to the RTC driver.\n"
  "> >>>>>>\n"
- "> >>>>>>So we need rtc platform data to be existed in PMIC driver to pass t=\n"
- "his\n"
+ "> >>>>>>So we need rtc platform data to be existed in PMIC driver to pass this\n"
  "> >>>>>>information.\n"
  "> >>>>>>\n"
  "> >>>>>>Signed-off-by: Chao Xie <chao.xie@marvell.com>\n"
@@ -52,27 +39,21 @@
  "> >>>>>>index 8ea4467..34546a1 100644\n"
  "> >>>>>>--- a/drivers/mfd/88pm800.c\n"
  "> >>>>>>+++ b/drivers/mfd/88pm800.c\n"
- "> >>>>>>@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *clie=\n"
- "nt,\n"
+ "> >>>>>>@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *client,\n"
  "> >>>>>>  \t\t\treturn ret;\n"
  "> >>>>>>  \t}\n"
  "> >>>>>>\n"
  "> >>>>>>+\t/*\n"
- "> >>>>>>+\t * RTC in pmic can run even the core is powered off, and user can=\n"
- " set\n"
- "> >>>>>>+\t * alarm in RTC. When the alarm is time out, the PMIC will power =\n"
- "up\n"
- "> >>>>>>+\t * the core, and the whole system will boot up. When PMIC driver =\n"
- "is\n"
- "> >>>>>>+\t * probed, it will read out some register to find out whether thi=\n"
- "s\n"
+ "> >>>>>>+\t * RTC in pmic can run even the core is powered off, and user can set\n"
+ "> >>>>>>+\t * alarm in RTC. When the alarm is time out, the PMIC will power up\n"
+ "> >>>>>>+\t * the core, and the whole system will boot up. When PMIC driver is\n"
+ "> >>>>>>+\t * probed, it will read out some register to find out whether this\n"
  "> >>>>>>+\t * boot is caused by RTC timeout or not, and it need pass this\n"
  "> >>>>>>+\t * information to RTC driver.\n"
- "> >>>>>>+\t * So we need rtc platform data to be existed to pass this inform=\n"
- "ation.\n"
+ "> >>>>>>+\t * So we need rtc platform data to be existed to pass this information.\n"
  "> >>>>>>+\t */\n"
  "> >>>>>>+\tif (!pdata->rtc) {\n"
- "> >>>>>>+\t\tpdata->rtc =3D devm_kzalloc(&client->dev,\n"
+ "> >>>>>>+\t\tpdata->rtc = devm_kzalloc(&client->dev,\n"
  "> >>>>>>+\t\t\t\t\t  sizeof(*(pdata->rtc)), GFP_KERNEL);\n"
  "> >>>>>>+\t\tif (!pdata->rtc) {\n"
  "> >>>>>>+\t\t\tdev_err(&client->dev,\n"
@@ -120,7 +101,7 @@
  "> >that you're not going to do that and I'll remove it altogether.\n"
  "> >Likewise for rtc_wakeup.\n"
  "> >\n"
- ">=20\n"
+ "> \n"
  "> I am ok with vrtc field, we can remove it.\n"
  "\n"
  "Okay, I will do so, thanks.\n"
@@ -128,41 +109,28 @@
  "> But,\n"
  "> I would recommend _not_ to remove rtc_wakeup, as it may not be used\n"
  "> immediately, but still have logical significance.\n"
- ">=20\n"
+ "> \n"
  "> Consuming rtc_wakeup in the code is dependant on overall power\n"
  "> management support, which is always long pole for development. As you\n"
  "> would have seen, we have just started with baseport for pxa1928 and I\n"
  "> am starting on upstreaming driver part.\n"
- ">=20\n"
- ">=20\n"
+ "> \n"
+ "> \n"
  "> From hardware perspective, this is important feature, where it indicate\n"
  "> whether the boot was triggered by reset assertion or by RTC wakeup. So\n"
  "> as of now from driver perspective I feel no harm to have one field for\n"
  "> this.\n"
- ">=20\n"
+ "> \n"
  "> Finally, its your call. I will let you decide.\n"
  "> The field can be added later when it actually gets consumed.\n"
  "\n"
  "I will not remove the wake-up field.  Equally, I will not accept code\n"
  "which allocates memory for it whilst it is not being used.\n"
  "\n"
- "--=20\n"
+ "-- \n"
  "Lee Jones\n"
  "Linaro STMicroelectronics Landing Team Lead\n"
- "Linaro.org =E2=94=82 Open source software for ARM SoCs\n"
- "Follow Linaro: Facebook | Twitter | Blog\n"
- "\n"
- "--=20\n"
- "--=20\n"
- "You received this message because you are subscribed to \"rtc-linux\".\n"
- "Membership options at http://groups.google.com/group/rtc-linux .\n"
- "Please read http://groups.google.com/group/rtc-linux/web/checklist\n"
- "before submitting a driver.\n"
- "---=20\n"
- "You received this message because you are subscribed to the Google Groups \"=\n"
- "rtc-linux\" group.\n"
- "To unsubscribe from this group and stop receiving emails from it, send an e=\n"
- "mail to rtc-linux+unsubscribe@googlegroups.com.\n"
- For more options, visit https://groups.google.com/d/optout.
+ "Linaro.org ? Open source software for ARM SoCs\n"
+ Follow Linaro: Facebook | Twitter | Blog
 
-be92e68eeedd263a00d263704ec9d8199ad5705bb4f766bd7441ddeda35f4976
+4ca4e7a18f4d2bb72d175fd2a0414348459215e20421267a29be47da6e789261

diff --git a/a/1.txt b/N2/1.txt
index 87b81da..d080e77 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -7,16 +7,12 @@ On Tue, 02 Jun 2015, Vaibhav Hiremath wrote:
 > >>>>>On Sat, 30 May 2015, Vaibhav Hiremath wrote:
 > >>>>>
 > >>>>>>RTC in pmic 88PM800 can run even the core is powered off, and user
-> >>>>>>can set alarm in RTC. When the alarm is timed out, the PMIC will po=
-wer up
-> >>>>>>the core, and the whole system will boot up. And during PMIC driver=
- probe,
-> >>>>>>it will read some register to find out whether this boot is caused =
-by RTC
+> >>>>>>can set alarm in RTC. When the alarm is timed out, the PMIC will power up
+> >>>>>>the core, and the whole system will boot up. And during PMIC driver probe,
+> >>>>>>it will read some register to find out whether this boot is caused by RTC
 > >>>>>>timeout or not, and pass on this information to the RTC driver.
 > >>>>>>
-> >>>>>>So we need rtc platform data to be existed in PMIC driver to pass t=
-his
+> >>>>>>So we need rtc platform data to be existed in PMIC driver to pass this
 > >>>>>>information.
 > >>>>>>
 > >>>>>>Signed-off-by: Chao Xie <chao.xie@marvell.com>
@@ -29,27 +25,21 @@ his
 > >>>>>>index 8ea4467..34546a1 100644
 > >>>>>>--- a/drivers/mfd/88pm800.c
 > >>>>>>+++ b/drivers/mfd/88pm800.c
-> >>>>>>@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *clie=
-nt,
+> >>>>>>@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *client,
 > >>>>>>  			return ret;
 > >>>>>>  	}
 > >>>>>>
 > >>>>>>+	/*
-> >>>>>>+	 * RTC in pmic can run even the core is powered off, and user can=
- set
-> >>>>>>+	 * alarm in RTC. When the alarm is time out, the PMIC will power =
-up
-> >>>>>>+	 * the core, and the whole system will boot up. When PMIC driver =
-is
-> >>>>>>+	 * probed, it will read out some register to find out whether thi=
-s
+> >>>>>>+	 * RTC in pmic can run even the core is powered off, and user can set
+> >>>>>>+	 * alarm in RTC. When the alarm is time out, the PMIC will power up
+> >>>>>>+	 * the core, and the whole system will boot up. When PMIC driver is
+> >>>>>>+	 * probed, it will read out some register to find out whether this
 > >>>>>>+	 * boot is caused by RTC timeout or not, and it need pass this
 > >>>>>>+	 * information to RTC driver.
-> >>>>>>+	 * So we need rtc platform data to be existed to pass this inform=
-ation.
+> >>>>>>+	 * So we need rtc platform data to be existed to pass this information.
 > >>>>>>+	 */
 > >>>>>>+	if (!pdata->rtc) {
-> >>>>>>+		pdata->rtc =3D devm_kzalloc(&client->dev,
+> >>>>>>+		pdata->rtc = devm_kzalloc(&client->dev,
 > >>>>>>+					  sizeof(*(pdata->rtc)), GFP_KERNEL);
 > >>>>>>+		if (!pdata->rtc) {
 > >>>>>>+			dev_err(&client->dev,
@@ -97,7 +87,7 @@ ation.
 > >that you're not going to do that and I'll remove it altogether.
 > >Likewise for rtc_wakeup.
 > >
->=20
+> 
 > I am ok with vrtc field, we can remove it.
 
 Okay, I will do so, thanks.
@@ -105,39 +95,26 @@ Okay, I will do so, thanks.
 > But,
 > I would recommend _not_ to remove rtc_wakeup, as it may not be used
 > immediately, but still have logical significance.
->=20
+> 
 > Consuming rtc_wakeup in the code is dependant on overall power
 > management support, which is always long pole for development. As you
 > would have seen, we have just started with baseport for pxa1928 and I
 > am starting on upstreaming driver part.
->=20
->=20
+> 
+> 
 > From hardware perspective, this is important feature, where it indicate
 > whether the boot was triggered by reset assertion or by RTC wakeup. So
 > as of now from driver perspective I feel no harm to have one field for
 > this.
->=20
+> 
 > Finally, its your call. I will let you decide.
 > The field can be added later when it actually gets consumed.
 
 I will not remove the wake-up field.  Equally, I will not accept code
 which allocates memory for it whilst it is not being used.
 
---=20
+-- 
 Lee Jones
 Linaro STMicroelectronics Landing Team Lead
-Linaro.org =E2=94=82 Open source software for ARM SoCs
+Linaro.org │ Open source software for ARM SoCs
 Follow Linaro: Facebook | Twitter | Blog
-
---=20
---=20
-You received this message because you are subscribed to "rtc-linux".
-Membership options at http://groups.google.com/group/rtc-linux .
-Please read http://groups.google.com/group/rtc-linux/web/checklist
-before submitting a driver.
----=20
-You received this message because you are subscribed to the Google Groups "=
-rtc-linux" group.
-To unsubscribe from this group and stop receiving emails from it, send an e=
-mail to rtc-linux+unsubscribe@googlegroups.com.
-For more options, visit https://groups.google.com/d/optout.
diff --git a/a/content_digest b/N2/content_digest
index fd30ba1..b2b10b7 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -7,7 +7,7 @@
  "ref\020150602093323.GI3329@x1\0"
  "ref\0556D7C32.9080806@linaro.org\0"
  "From\0Lee Jones <lee.jones@linaro.org>\0"
- "Subject\0[rtc-linux] Re: [PATCH 4/4] mfd: 88pm800: allocate pdata->rtc if not allocated earlier\0"
+ "Subject\0Re: [PATCH 4/4] mfd: 88pm800: allocate pdata->rtc if not allocated earlier\0"
  "Date\0Tue, 2 Jun 2015 11:07:39 +0100\0"
  "To\0Vaibhav Hiremath <vaibhav.hiremath@linaro.org>\0"
  "Cc\0linux-arm-kernel@lists.infradead.org"
@@ -30,16 +30,12 @@
  "> >>>>>On Sat, 30 May 2015, Vaibhav Hiremath wrote:\n"
  "> >>>>>\n"
  "> >>>>>>RTC in pmic 88PM800 can run even the core is powered off, and user\n"
- "> >>>>>>can set alarm in RTC. When the alarm is timed out, the PMIC will po=\n"
- "wer up\n"
- "> >>>>>>the core, and the whole system will boot up. And during PMIC driver=\n"
- " probe,\n"
- "> >>>>>>it will read some register to find out whether this boot is caused =\n"
- "by RTC\n"
+ "> >>>>>>can set alarm in RTC. When the alarm is timed out, the PMIC will power up\n"
+ "> >>>>>>the core, and the whole system will boot up. And during PMIC driver probe,\n"
+ "> >>>>>>it will read some register to find out whether this boot is caused by RTC\n"
  "> >>>>>>timeout or not, and pass on this information to the RTC driver.\n"
  "> >>>>>>\n"
- "> >>>>>>So we need rtc platform data to be existed in PMIC driver to pass t=\n"
- "his\n"
+ "> >>>>>>So we need rtc platform data to be existed in PMIC driver to pass this\n"
  "> >>>>>>information.\n"
  "> >>>>>>\n"
  "> >>>>>>Signed-off-by: Chao Xie <chao.xie@marvell.com>\n"
@@ -52,27 +48,21 @@
  "> >>>>>>index 8ea4467..34546a1 100644\n"
  "> >>>>>>--- a/drivers/mfd/88pm800.c\n"
  "> >>>>>>+++ b/drivers/mfd/88pm800.c\n"
- "> >>>>>>@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *clie=\n"
- "nt,\n"
+ "> >>>>>>@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *client,\n"
  "> >>>>>>  \t\t\treturn ret;\n"
  "> >>>>>>  \t}\n"
  "> >>>>>>\n"
  "> >>>>>>+\t/*\n"
- "> >>>>>>+\t * RTC in pmic can run even the core is powered off, and user can=\n"
- " set\n"
- "> >>>>>>+\t * alarm in RTC. When the alarm is time out, the PMIC will power =\n"
- "up\n"
- "> >>>>>>+\t * the core, and the whole system will boot up. When PMIC driver =\n"
- "is\n"
- "> >>>>>>+\t * probed, it will read out some register to find out whether thi=\n"
- "s\n"
+ "> >>>>>>+\t * RTC in pmic can run even the core is powered off, and user can set\n"
+ "> >>>>>>+\t * alarm in RTC. When the alarm is time out, the PMIC will power up\n"
+ "> >>>>>>+\t * the core, and the whole system will boot up. When PMIC driver is\n"
+ "> >>>>>>+\t * probed, it will read out some register to find out whether this\n"
  "> >>>>>>+\t * boot is caused by RTC timeout or not, and it need pass this\n"
  "> >>>>>>+\t * information to RTC driver.\n"
- "> >>>>>>+\t * So we need rtc platform data to be existed to pass this inform=\n"
- "ation.\n"
+ "> >>>>>>+\t * So we need rtc platform data to be existed to pass this information.\n"
  "> >>>>>>+\t */\n"
  "> >>>>>>+\tif (!pdata->rtc) {\n"
- "> >>>>>>+\t\tpdata->rtc =3D devm_kzalloc(&client->dev,\n"
+ "> >>>>>>+\t\tpdata->rtc = devm_kzalloc(&client->dev,\n"
  "> >>>>>>+\t\t\t\t\t  sizeof(*(pdata->rtc)), GFP_KERNEL);\n"
  "> >>>>>>+\t\tif (!pdata->rtc) {\n"
  "> >>>>>>+\t\t\tdev_err(&client->dev,\n"
@@ -120,7 +110,7 @@
  "> >that you're not going to do that and I'll remove it altogether.\n"
  "> >Likewise for rtc_wakeup.\n"
  "> >\n"
- ">=20\n"
+ "> \n"
  "> I am ok with vrtc field, we can remove it.\n"
  "\n"
  "Okay, I will do so, thanks.\n"
@@ -128,41 +118,28 @@
  "> But,\n"
  "> I would recommend _not_ to remove rtc_wakeup, as it may not be used\n"
  "> immediately, but still have logical significance.\n"
- ">=20\n"
+ "> \n"
  "> Consuming rtc_wakeup in the code is dependant on overall power\n"
  "> management support, which is always long pole for development. As you\n"
  "> would have seen, we have just started with baseport for pxa1928 and I\n"
  "> am starting on upstreaming driver part.\n"
- ">=20\n"
- ">=20\n"
+ "> \n"
+ "> \n"
  "> From hardware perspective, this is important feature, where it indicate\n"
  "> whether the boot was triggered by reset assertion or by RTC wakeup. So\n"
  "> as of now from driver perspective I feel no harm to have one field for\n"
  "> this.\n"
- ">=20\n"
+ "> \n"
  "> Finally, its your call. I will let you decide.\n"
  "> The field can be added later when it actually gets consumed.\n"
  "\n"
  "I will not remove the wake-up field.  Equally, I will not accept code\n"
  "which allocates memory for it whilst it is not being used.\n"
  "\n"
- "--=20\n"
+ "-- \n"
  "Lee Jones\n"
  "Linaro STMicroelectronics Landing Team Lead\n"
- "Linaro.org =E2=94=82 Open source software for ARM SoCs\n"
- "Follow Linaro: Facebook | Twitter | Blog\n"
- "\n"
- "--=20\n"
- "--=20\n"
- "You received this message because you are subscribed to \"rtc-linux\".\n"
- "Membership options at http://groups.google.com/group/rtc-linux .\n"
- "Please read http://groups.google.com/group/rtc-linux/web/checklist\n"
- "before submitting a driver.\n"
- "---=20\n"
- "You received this message because you are subscribed to the Google Groups \"=\n"
- "rtc-linux\" group.\n"
- "To unsubscribe from this group and stop receiving emails from it, send an e=\n"
- "mail to rtc-linux+unsubscribe@googlegroups.com.\n"
- For more options, visit https://groups.google.com/d/optout.
+ "Linaro.org \342\224\202 Open source software for ARM SoCs\n"
+ Follow Linaro: Facebook | Twitter | Blog
 
-be92e68eeedd263a00d263704ec9d8199ad5705bb4f766bd7441ddeda35f4976
+d4921b95200df9616b53598db10bee7d98d9badf8556f4d188ebcf8795c0f163

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.