All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@avionic-design.de>
To: Alex Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Mark Brown
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Subject: Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
Date: Tue, 31 Jul 2012 10:56:40 +0000	[thread overview]
Message-ID: <20120731105640.GD16155@avionic-0098.adnet.avionic-design.de> (raw)
In-Reply-To: <5017B434.2010706-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >I wonder if using the same structure/array as input and output would
> >simplify the API; the platform data would fill in the fields mentioned
> >above, and power_seq_build() would parse those, then set other fields in
> >the same structs to the looked-up handle values?
> 
> The thing is that I am not sure what happens to the platform data
> once probe() is done. Isn't it customary to mark it with __devinit
> and have it freed after probing is successful?

No, platform data should stay around forever. Otherwise, consider what
would happen if your driver is built as a module and you unload and load
it again.

> More generally, I think it is a good practice to have data
> structures tailored right for what they need to do - code with
> members that are meaningful only at given points of an instance's
> life tends to be more confusing.

I agree. Furthermore the driver unload/reload would be another reason
not to reuse platform data as the output of the build() function.

But maybe what Stephen meant was more like filling a structure with data
taken from the platform data and pass that to a resolve() function which
would fill in the missing pieces like pointers to actual resources. I
imagine a managed interface would become a little trickier to do using
such an approach.

> >If the nodes have a unit address (i.e. end in "@n"), which they will
> >have to if all named "step" and there's more than one of them, then they
> >will need a matching reg property. Equally, the parent node will need
> >#address-cells and #size-cells too. So, the last couple lines would be:
> >
> >		power-on-sequence {
> >			#address-cells = <1>;
> >			#size-cells = <0>;
> >			step@0 {
> >				reg = <0>;
> 
> That's precisely what I would like to avoid - I don't need the steps
> to be numbered and I certainly have no use for a reg property. Isn't
> there a way to make it simpler?

It's not technically valid to not have the reg property. Or
#address-cells and #size-cells properties for that matter.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
To: Alex Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Mark Brown
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Subject: Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
Date: Tue, 31 Jul 2012 12:56:40 +0200	[thread overview]
Message-ID: <20120731105640.GD16155@avionic-0098.adnet.avionic-design.de> (raw)
In-Reply-To: <5017B434.2010706-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >I wonder if using the same structure/array as input and output would
> >simplify the API; the platform data would fill in the fields mentioned
> >above, and power_seq_build() would parse those, then set other fields in
> >the same structs to the looked-up handle values?
> 
> The thing is that I am not sure what happens to the platform data
> once probe() is done. Isn't it customary to mark it with __devinit
> and have it freed after probing is successful?

No, platform data should stay around forever. Otherwise, consider what
would happen if your driver is built as a module and you unload and load
it again.

> More generally, I think it is a good practice to have data
> structures tailored right for what they need to do - code with
> members that are meaningful only at given points of an instance's
> life tends to be more confusing.

I agree. Furthermore the driver unload/reload would be another reason
not to reuse platform data as the output of the build() function.

But maybe what Stephen meant was more like filling a structure with data
taken from the platform data and pass that to a resolve() function which
would fill in the missing pieces like pointers to actual resources. I
imagine a managed interface would become a little trickier to do using
such an approach.

> >If the nodes have a unit address (i.e. end in "@n"), which they will
> >have to if all named "step" and there's more than one of them, then they
> >will need a matching reg property. Equally, the parent node will need
> >#address-cells and #size-cells too. So, the last couple lines would be:
> >
> >		power-on-sequence {
> >			#address-cells = <1>;
> >			#size-cells = <0>;
> >			step@0 {
> >				reg = <0>;
> 
> That's precisely what I would like to avoid - I don't need the steps
> to be numbered and I certainly have no use for a reg property. Isn't
> there a way to make it simpler?

It's not technically valid to not have the reg property. Or
#address-cells and #size-cells properties for that matter.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@avionic-design.de>
To: Alex Courbot <acourbot@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
	Stephen Warren <swarren@nvidia.com>,
	Simon Glass <sjg@chromium.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"devicetree-discuss@lists.ozlabs.org" 
	<devicetree-discuss@lists.ozlabs.org>
Subject: Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
Date: Tue, 31 Jul 2012 12:56:40 +0200	[thread overview]
Message-ID: <20120731105640.GD16155@avionic-0098.adnet.avionic-design.de> (raw)
In-Reply-To: <5017B434.2010706@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >I wonder if using the same structure/array as input and output would
> >simplify the API; the platform data would fill in the fields mentioned
> >above, and power_seq_build() would parse those, then set other fields in
> >the same structs to the looked-up handle values?
> 
> The thing is that I am not sure what happens to the platform data
> once probe() is done. Isn't it customary to mark it with __devinit
> and have it freed after probing is successful?

No, platform data should stay around forever. Otherwise, consider what
would happen if your driver is built as a module and you unload and load
it again.

> More generally, I think it is a good practice to have data
> structures tailored right for what they need to do - code with
> members that are meaningful only at given points of an instance's
> life tends to be more confusing.

I agree. Furthermore the driver unload/reload would be another reason
not to reuse platform data as the output of the build() function.

But maybe what Stephen meant was more like filling a structure with data
taken from the platform data and pass that to a resolve() function which
would fill in the missing pieces like pointers to actual resources. I
imagine a managed interface would become a little trickier to do using
such an approach.

> >If the nodes have a unit address (i.e. end in "@n"), which they will
> >have to if all named "step" and there's more than one of them, then they
> >will need a matching reg property. Equally, the parent node will need
> >#address-cells and #size-cells too. So, the last couple lines would be:
> >
> >		power-on-sequence {
> >			#address-cells = <1>;
> >			#size-cells = <0>;
> >			step@0 {
> >				reg = <0>;
> 
> That's precisely what I would like to avoid - I don't need the steps
> to be numbered and I certainly have no use for a reg property. Isn't
> there a way to make it simpler?

It's not technically valid to not have the reg property. Or
#address-cells and #size-cells properties for that matter.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2012-07-31 10:56 UTC|newest]

Thread overview: 173+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-27 12:05 [RFC][PATCH v3 0/3] Power sequences with PWM and DT support Alexandre Courbot
2012-07-27 12:05 ` Alexandre Courbot
2012-07-27 12:05 ` Alexandre Courbot
2012-07-27 12:05 ` [RFC][PATCH v3 1/3] runtime interpreted power sequences Alexandre Courbot
2012-07-27 12:05   ` Alexandre Courbot
2012-07-27 12:05   ` Alexandre Courbot
     [not found]   ` <1343390750-3642-2-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-07-27 18:19     ` Greg Kroah-Hartman
2012-07-27 18:19       ` Greg Kroah-Hartman
2012-07-27 18:19       ` Greg Kroah-Hartman
     [not found]       ` <20120727181923.GB23564-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2012-07-30  1:51         ` Alex Courbot
2012-07-30  1:51           ` Alex Courbot
2012-07-30  1:51           ` Alex Courbot
2012-07-30  2:40           ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runtime Anton Vorontsov
2012-07-30  2:40             ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences) Anton Vorontsov
2012-07-30 20:59             ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runt Rafael J. Wysocki
2012-07-30 20:59               ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences) Rafael J. Wysocki
2012-07-30 20:59               ` Rafael J. Wysocki
     [not found]               ` <201207302259.39396.rjw-KKrjLPT3xs0@public.gmane.org>
2012-08-01  0:51                 ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runt Anton Vorontsov
2012-08-01  0:51                   ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences) Anton Vorontsov
2012-08-01  0:51                   ` Anton Vorontsov
2012-08-06  8:45             ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runt Pihet-XID, Jean
2012-08-06  8:45               ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences) Pihet-XID, Jean
2012-08-06  8:45               ` Pihet-XID, Jean
2012-07-27 18:20     ` [RFC][PATCH v3 1/3] runtime interpreted power sequences Greg Kroah-Hartman
2012-07-27 18:20       ` Greg Kroah-Hartman
2012-07-27 18:20       ` Greg Kroah-Hartman
2012-07-30 11:00     ` Simon Glass
2012-07-30 11:00       ` Simon Glass
2012-07-30 11:00       ` Simon Glass
2012-07-31  8:37       ` Alex Courbot
2012-07-31  8:37         ` Alex Courbot
     [not found]         ` <50179933.9090501-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-07-31  9:13           ` Thierry Reding
2012-07-31  9:13             ` Thierry Reding
2012-07-31  9:13             ` Thierry Reding
     [not found]             ` <20120731091324.GA15557-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-07-31 10:11               ` Alex Courbot
2012-07-31 10:11                 ` Alex Courbot
2012-07-31 10:11                 ` Alex Courbot
     [not found]                 ` <5017AF5D.2010204-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-07-31 10:46                   ` Thierry Reding
2012-07-31 10:46                     ` Thierry Reding
2012-07-31 10:46                     ` Thierry Reding
2012-07-31 14:23         ` Mark Brown
2012-07-31 14:23           ` Mark Brown
2012-07-30 11:33     ` Thierry Reding
2012-07-30 11:33       ` Thierry Reding
2012-07-30 11:33       ` Thierry Reding
2012-07-31  9:51       ` Alex Courbot
2012-07-31  9:51         ` Alex Courbot
     [not found]         ` <5017AA87.2040503-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-07-31 10:19           ` Thierry Reding
2012-07-31 10:19             ` Thierry Reding
2012-07-31 10:19             ` Thierry Reding
     [not found]             ` <20120731101931.GB16155-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-08-01  2:50               ` Alex Courbot
2012-08-01  2:50                 ` Alex Courbot
2012-08-01  2:50                 ` Alex Courbot
     [not found]                 ` <5018997B.7010808-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-01  7:17                   ` Thierry Reding
2012-08-01  7:17                     ` Thierry Reding
2012-08-01  7:17                     ` Thierry Reding
2012-07-31 14:11         ` Mark Brown
2012-07-31 14:11           ` Mark Brown
2012-07-30 15:44     ` Rob Herring
2012-07-30 15:44       ` Rob Herring
2012-07-30 15:44       ` Rob Herring
     [not found]       ` <5016ABDD.5010809-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-07-30 15:47         ` Mark Brown
2012-07-30 15:47           ` Mark Brown
2012-07-30 15:47           ` Mark Brown
     [not found]           ` <20120730154706.GL4468-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-07-31  9:16             ` Thierry Reding
2012-07-31  9:16               ` Thierry Reding
2012-07-31  9:16               ` Thierry Reding
2012-07-30 22:26         ` Stephen Warren
2012-07-30 22:26           ` Stephen Warren
2012-07-30 22:26           ` Stephen Warren
     [not found]           ` <50170A14.6000201-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-31 10:15             ` Alex Courbot
2012-07-31 10:15               ` Alex Courbot
2012-07-31 10:15               ` Alex Courbot
2012-07-30 22:45     ` Stephen Warren
2012-07-30 22:45       ` Stephen Warren
2012-07-30 22:45       ` Stephen Warren
2012-07-31 10:32       ` Alex Courbot
2012-07-31 10:32         ` Alex Courbot
     [not found]         ` <5017B434.2010706-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-07-31 10:56           ` Thierry Reding [this message]
2012-07-31 10:56             ` Thierry Reding
2012-07-31 10:56             ` Thierry Reding
     [not found]             ` <20120731105640.GD16155-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-07-31 12:22               ` Mitch Bradley
2012-07-31 12:22                 ` Mitch Bradley
2012-07-31 12:22                 ` Mitch Bradley
     [not found]                 ` <5017CDF9.2060304-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-07-31 12:38                   ` Thierry Reding
2012-07-31 12:38                     ` Thierry Reding
2012-07-31 12:38                     ` Thierry Reding
     [not found]                     ` <20120731123811.GA25855-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-07-31 12:55                       ` Mitch Bradley
2012-07-31 12:55                         ` Mitch Bradley
2012-07-31 12:55                         ` Mitch Bradley
2012-08-01  1:47                         ` Alex Courbot
2012-08-01  1:47                           ` Alex Courbot
     [not found]                           ` <50188ABB.2060304-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-01  2:15                             ` Mitch Bradley
2012-08-01  2:15                               ` Mitch Bradley
2012-08-01  2:15                               ` Mitch Bradley
2012-08-01  1:42                   ` Alex Courbot
2012-08-01  1:42                     ` Alex Courbot
2012-08-01  1:42                     ` Alex Courbot
2012-07-31 14:13               ` Mark Brown
2012-07-31 14:13                 ` Mark Brown
2012-07-31 14:13                 ` Mark Brown
2012-07-31 14:22                 ` Thierry Reding
2012-07-31 14:22                   ` Thierry Reding
2012-07-31 14:26                   ` Mark Brown
2012-07-31 14:26                     ` Mark Brown
     [not found]                     ` <20120731142607.GV4468-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-07-31 14:32                       ` Thierry Reding
2012-07-31 14:32                         ` Thierry Reding
2012-07-31 14:32                         ` Thierry Reding
     [not found]                         ` <20120731143235.GA21126-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-07-31 15:39                           ` Mark Brown
2012-07-31 15:39                             ` Mark Brown
2012-07-31 15:39                             ` Mark Brown
2012-07-31 16:19                             ` Greg Kroah-Hartman
2012-07-31 16:19                               ` Greg Kroah-Hartman
     [not found]                               ` <20120731161954.GB4941-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2012-07-31 16:22                                 ` Mark Brown
2012-07-31 16:22                                   ` Mark Brown
2012-07-31 16:22                                   ` Mark Brown
     [not found]                                   ` <20120731162230.GE11892-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-07-31 16:42                                     ` Greg Kroah-Hartman
2012-07-31 16:42                                       ` Greg Kroah-Hartman
2012-07-31 16:42                                       ` Greg Kroah-Hartman
2012-07-31 16:50                                       ` Mark Brown
2012-07-31 16:50                                         ` Mark Brown
2012-08-01  7:41                             ` Thierry Reding
2012-08-01  7:41                               ` Thierry Reding
     [not found]                               ` <20120801074113.GF29673-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-08-01 13:26                                 ` Mark Brown
2012-08-01 13:26                                   ` Mark Brown
2012-08-01 13:26                                   ` Mark Brown
     [not found]                                   ` <20120801132651.GU11892-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-08-01 13:38                                     ` Thierry Reding
2012-08-01 13:38                                       ` Thierry Reding
2012-08-01 13:38                                       ` Thierry Reding
     [not found]                                       ` <20120801133814.GA19771-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-08-01 13:55                                         ` Mark Brown
2012-08-01 13:55                                           ` Mark Brown
2012-08-01 13:55                                           ` Mark Brown
     [not found]                                           ` <20120801135531.GW11892-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-08-01 14:01                                             ` Thierry Reding
2012-08-01 14:01                                               ` Thierry Reding
2012-08-01 14:01                                               ` Thierry Reding
2012-07-31 16:34         ` Stephen Warren
2012-07-31 16:34           ` Stephen Warren
2012-08-02  8:00       ` Alex Courbot
2012-08-02  8:00         ` Alex Courbot
     [not found]         ` <501A338D.7080105-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-02  8:21           ` Thierry Reding
2012-08-02  8:21             ` Thierry Reding
2012-08-02  8:21             ` Thierry Reding
     [not found]             ` <20120802082157.GA14866-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-08-02  8:27               ` Alex Courbot
2012-08-02  8:27                 ` Alex Courbot
2012-08-02  8:27                 ` Alex Courbot
2012-08-02  8:45                 ` Thierry Reding
2012-08-02  8:45                   ` Thierry Reding
2012-08-02  9:20                   ` Alex Courbot
2012-08-02  9:20                     ` Alex Courbot
2012-08-02 18:11             ` Mark Brown
2012-08-02 18:11               ` Mark Brown
     [not found]               ` <20120802181111.GM4537-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-08-03  1:15                 ` Alex Courbot
2012-08-03  1:15                   ` Alex Courbot
2012-08-03  1:15                   ` Alex Courbot
     [not found]                   ` <501B2642.4080805-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-04 14:12                     ` Mark Brown
2012-08-04 14:12                       ` Mark Brown
2012-08-04 14:12                       ` Mark Brown
2012-08-06  2:27                       ` Alex Courbot
2012-08-06  2:27                         ` Alex Courbot
     [not found]                         ` <501F2BAA.8000808-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-06 16:16                           ` Stephen Warren
2012-08-06 16:16                             ` Stephen Warren
2012-08-06 16:16                             ` Stephen Warren
2012-08-07  5:10                             ` Alex Courbot
2012-08-07  5:10                               ` Alex Courbot
     [not found] ` <1343390750-3642-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-07-27 12:05   ` [RFC][PATCH v3 2/3] pwm_backlight: use " Alexandre Courbot
2012-07-27 12:05     ` Alexandre Courbot
2012-07-27 12:05     ` Alexandre Courbot
2012-07-27 12:05   ` [RFC][PATCH v3 3/3] tegra: add pwm backlight device tree nodes Alexandre Courbot
2012-07-27 12:05     ` Alexandre Courbot
2012-07-27 12:05     ` Alexandre Courbot
  -- strict thread matches above, loose matches on Subject: below --
2012-07-30  3:04 Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences) 함명주
2012-07-30  3:04 ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runt 함명주
2012-07-30  3:04 ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences) 함명주

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120731105640.GD16155@avionic-0098.adnet.avionic-design.de \
    --to=thierry.reding@avionic-design.de \
    --cc=acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.