All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <87d3vaygik.fsf@deeprootsystems.com>

diff --git a/a/1.txt b/N1/1.txt
index 38f4fa1..b64e016 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -6,13 +6,13 @@ Grant Likely <grant.likely@secretlab.ca> writes:
 >>
 >>> Another way to look at the problem is that these runtime
 >>> customizations are kind of a property of the parent device (the bus,
->>> not the bus_type).  Would it make sense for parent devices to have
->>> runtime ops to perform for each child that is suspended/resumed?  That
+>>> not the bus_type). ?Would it make sense for parent devices to have
+>>> runtime ops to perform for each child that is suspended/resumed? ?That
 >>> would make it simple to register another device that implements the
 >>> bus behaviour and attach it at runtime instead of compile time.
 >>
 >> Maybe I didn't fully understand your idea, but the problem here is
->> devices do not have dev_pm_ops.  Only busses, classes, and types have
+>> devices do not have dev_pm_ops. ?Only busses, classes, and types have
 >> dev_pm_ops.
 >
 > Sorry, I mistyped.  What I meant was for the parent device's
@@ -34,7 +34,7 @@ so this won't get any attention from me until August.
 >> Though I'm horribly unfamiliar with the intended usage of 'struct
 >> device_type', an interesing discovery is that dev->type also has
 >> dev_pm_ops, and it takes precedence over the bus type in the
->> suspend/resume.  IOW, when suspending, when deciding which dev_pm_ops to
+>> suspend/resume. ?IOW, when suspending, when deciding which dev_pm_ops to
 >> use, it checks class, type, then bus in that order.
 >
 > So I guess my suggestion above boils down to somehow inserting
@@ -56,7 +56,3 @@ broaden the audience.
 Thanks again for all your helpful suggestions,
 
 Kevin
---
-To unsubscribe from this list: send the line "unsubscribe linux-omap" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N1/content_digest
index 7d8276d..2421aac 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -5,14 +5,10 @@
  "ref\0AANLkTimMnJvOJrRHDiE6PH1BXpRz2-6pY1M9nKHw7vpn@mail.gmail.com\0"
  "ref\0876316eno5.fsf@deeprootsystems.com\0"
  "ref\0AANLkTimB0_OfLDvtkwwTE-kVeZrardIxVIsD5IEia-vL@mail.gmail.com\0"
- "From\0Kevin Hilman <khilman@deeprootsystems.com>\0"
- "Subject\0Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support\0"
+ "From\0khilman@deeprootsystems.com (Kevin Hilman)\0"
+ "Subject\0[PATCH v2 1/3] OMAP: PM: initial runtime PM core support\0"
  "Date\0Mon, 28 Jun 2010 14:49:23 -0700\0"
- "To\0Grant Likely <grant.likely@secretlab.ca>\0"
- "Cc\0linux-omap@vger.kernel.org"
-  linux-arm-kernel@lists.infradead.org
-  Eric Miao <eric.miao@canonical.com>
- " Nicolas Pitre <nico@fluxnic.net>\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "Grant Likely <grant.likely@secretlab.ca> writes:\n"
@@ -23,13 +19,13 @@
  ">>\n"
  ">>> Another way to look at the problem is that these runtime\n"
  ">>> customizations are kind of a property of the parent device (the bus,\n"
- ">>> not the bus_type). \302\240Would it make sense for parent devices to have\n"
- ">>> runtime ops to perform for each child that is suspended/resumed? \302\240That\n"
+ ">>> not the bus_type). ?Would it make sense for parent devices to have\n"
+ ">>> runtime ops to perform for each child that is suspended/resumed? ?That\n"
  ">>> would make it simple to register another device that implements the\n"
  ">>> bus behaviour and attach it at runtime instead of compile time.\n"
  ">>\n"
  ">> Maybe I didn't fully understand your idea, but the problem here is\n"
- ">> devices do not have dev_pm_ops. \302\240Only busses, classes, and types have\n"
+ ">> devices do not have dev_pm_ops. ?Only busses, classes, and types have\n"
  ">> dev_pm_ops.\n"
  ">\n"
  "> Sorry, I mistyped.  What I meant was for the parent device's\n"
@@ -51,7 +47,7 @@
  ">> Though I'm horribly unfamiliar with the intended usage of 'struct\n"
  ">> device_type', an interesing discovery is that dev->type also has\n"
  ">> dev_pm_ops, and it takes precedence over the bus type in the\n"
- ">> suspend/resume. \302\240IOW, when suspending, when deciding which dev_pm_ops to\n"
+ ">> suspend/resume. ?IOW, when suspending, when deciding which dev_pm_ops to\n"
  ">> use, it checks class, type, then bus in that order.\n"
  ">\n"
  "> So I guess my suggestion above boils down to somehow inserting\n"
@@ -72,10 +68,6 @@
  "\n"
  "Thanks again for all your helpful suggestions,\n"
  "\n"
- "Kevin\n"
- "--\n"
- "To unsubscribe from this list: send the line \"unsubscribe linux-omap\" in\n"
- "the body of a message to majordomo@vger.kernel.org\n"
- More majordomo info at  http://vger.kernel.org/majordomo-info.html
+ Kevin
 
-d4c45f3dbce8a85ebe00e1cec608ab32bba9b2c4c96bfd64c0d50146d87a56bd
+93932906e3279404da2912b0d9d57c614d6b2bdad56baf78408b385a9bc5756b

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.