2010/11/8 Ryan Mallon :
> On 11/08/2010 08:49 PM, Marco Stornelli wrote:
>> 2010/11/7 Ryan Mallon :
>>> On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli
---
diff -Nurp linu
On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote:
> It was noted at the summit that several CE companies and embedded
> projects will be using (or are already using) 2.6.35 for upcoming
> products or releases. This includes Sony, Google, Meego, and Linaro. On
> behalf of the CE Linux Forum and a number
On 11/09/2010 03:19 AM, Mike Frysinger wrote:
> On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote:
>> It was noted at the summit that several CE companies and embedded
>> projects will be using (or are already using) 2.6.35 for upcoming
>> products or releases. This includes Sony, Google, Meego, and Lin
On Tue, 09 Nov 2010, Tim Bird wrote:
> On 11/09/2010 03:19 AM, Mike Frysinger wrote:
> > On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote:
> >> It was noted at the summit that several CE companies and embedded
> >> projects will be using (or are already using) 2.6.35 for upcoming
> >> products or rele
On 11/09/2010 09:25 AM, Nicholas Mc Guire wrote:
> I guess one of the key issues is that it would need to be defined beforehand
> what version will be used as the next "flag" version so vendors could make
> sure that there drivers are available.
Yeah. People keep asking about that. Unfortunately
On Tue, 9 Nov 2010, Nicholas Mc Guire wrote:
> On Tue, 09 Nov 2010, Tim Bird wrote:
>
> > On 11/09/2010 03:19 AM, Mike Frysinger wrote:
> > > On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote:
> > >> It was noted at the summit that several CE companies and embedded
> > >> projects will be using (or ar
On 11/09/2010 09:19 PM, Marco Stornelli wrote:
> 2010/11/8 Ryan Mallon :
>> On 11/08/2010 08:49 PM, Marco Stornelli wrote:
>>> 2010/11/7 Ryan Mallon :
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
> From: Marco Stornelli
>
> Definitions for the PRAMFS filesystem.
>
> Sign
On Tue, Nov 9, 2010 at 21:35, Ryan Mallon wrote:
> On 11/09/2010 09:19 PM, Marco Stornelli wrote:
>> 2010/11/8 Ryan Mallon :
>>> On 11/08/2010 08:49 PM, Marco Stornelli wrote:
2010/11/7 Ryan Mallon :
> On 11/06/2010 09:58 PM, Marco Stornelli wrote:
>> From: Marco Stornelli
>>
>>>
Guys:
Let's say that on a given platform, I need to twiddle with a GPIO pin
when a chip enters and exits suspend. One way to do that is to hack
the driver itself; a slightly less-inelegant way is to add a function
pointer in the platform data, and have the driver call back in its
suspend() and r
On Tue, 9 Nov 2010, Bill Gatliff wrote:
> Let's say that on a given platform, I need to twiddle with a GPIO pin
> when a chip enters and exits suspend.
What driver? What platform? This may depend on those.
> One way to do that is to hack the driver itself; a slightly
> less-inelegant way is t
Guys:
Let's say that on a given platform, I need to twiddle with a GPIO pin
when a chip enters and exits suspend. One way to do that is to hack
the driver itself; a slightly less-inelegant way is to add a function
pointer in the platform data, and have the driver call back in its
suspend() an
Nicolas:
On Tue, Nov 9, 2010 at 6:10 PM, Nicolas Pitre wrote:
>
> The pseudo-device could register the
> real device and set itself as the parent.
That little tidbit there is the part I seem to have been missing
before now--- actually doing the physical device registration during
the probing of
Kevin:
On Tue, Nov 9, 2010 at 6:02 PM, Kevin Dankwardt wrote:
> Isn't the general approach to avoid platform-dependencies to abstract the
> behavior? As is used throughout the kernel, an "operations" struct that
> provides the abstractions and each driver fills in its implementation as
> require
13 matches
Mail list logo
