All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <3BF01B6C.496179@mvista.com>

diff --git a/a/1.txt b/N1/1.txt
index 26b10f8..9abdf99 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,5 +1,6 @@
+
 Jun Sun wrote:
-> 
+>
 > Pete Popov wrote:
 > >
 > > On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote:
@@ -18,9 +19,9 @@ Jun Sun wrote:
 > > I agree.  We don't have arch specific network drivers so why have arch
 > > specific rtc drivers.
 > >
-> 
+>
 > Because we can have a free RTC driver working once you get kernel working.
-> 
+>
 
 Actually there is a longer answer with a little bit of the background info.
 
@@ -36,7 +37,7 @@ Before CONFIG_NEW_TIME_C is introduced, each MIPS board has its own time
 service routine, which means, even if RTC driver wants to utilize the
 abstraction, it will be only for that board only.
 
-After CONFIG_NEW_TIME_C is introduced, that RTC abstract becomes MIPS-common. 
+After CONFIG_NEW_TIME_C is introduced, that RTC abstract becomes MIPS-common.
 Therefore, we can afford a MIPS-common generic RTC driver.
 
 If that abstraction ever becomes Linux-common code, then the generic RTC
@@ -47,3 +48,5 @@ generic driver should suffice.  Otherwire, you can wirte a complete one for a
 specific board or a specific chip.
 
 Jun
+
+** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
diff --git a/a/content_digest b/N1/content_digest
index d514328..03d076c 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -12,8 +12,9 @@
  " Linux/PPC Development <linuxppc-dev@lists.linuxppc.org>\0"
  "\00:1\0"
  "b\0"
+ "\n"
  "Jun Sun wrote:\n"
- "> \n"
+ ">\n"
  "> Pete Popov wrote:\n"
  "> >\n"
  "> > On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote:\n"
@@ -32,9 +33,9 @@
  "> > I agree.  We don't have arch specific network drivers so why have arch\n"
  "> > specific rtc drivers.\n"
  "> >\n"
- "> \n"
+ ">\n"
  "> Because we can have a free RTC driver working once you get kernel working.\n"
- "> \n"
+ ">\n"
  "\n"
  "Actually there is a longer answer with a little bit of the background info.\n"
  "\n"
@@ -50,7 +51,7 @@
  "service routine, which means, even if RTC driver wants to utilize the\n"
  "abstraction, it will be only for that board only.\n"
  "\n"
- "After CONFIG_NEW_TIME_C is introduced, that RTC abstract becomes MIPS-common. \n"
+ "After CONFIG_NEW_TIME_C is introduced, that RTC abstract becomes MIPS-common.\n"
  "Therefore, we can afford a MIPS-common generic RTC driver.\n"
  "\n"
  "If that abstraction ever becomes Linux-common code, then the generic RTC\n"
@@ -60,6 +61,8 @@
  "generic driver should suffice.  Otherwire, you can wirte a complete one for a\n"
  "specific board or a specific chip.\n"
  "\n"
- Jun
+ "Jun\n"
+ "\n"
+ ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
 
-595cfea51f76ac5e1810079b6dc262c53ff3fdea0d8d94d19df8238d9a93f659
+02be02e9f332cf4d69f178ae524529777f1fc7bde36ed7a2c00054417c9ee920

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.