On Wed, 12 Jan 2011 17:25:12 EST, Len Brown said:
> > But by sysfs convention a separate file must be used
> > if two data are passed to userspace which is the case here.
>
> what two data?
>
> It is fine for a string to include space characters.
I think Thomas is concerned that although when y
On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:
> This changes *all* instances of struct file_operations in
> the kernel to have a .llseek operation and then changes
> the default to no_llseek, which returns -ESPIPE, which
> is what we had decided some time ago in a discussion
> with Chris
On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
> On Fri, Oct 7, 2011 at 12:43 AM, Greg KH wrote:
> > On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
> >> +#define EPROBE_DEFER 517 /* restart probe again after some time */
> >
> > Can we really do this?
> Accordin
On Fri, 28 Oct 2011 15:03:36 +0300, Tero Kristo said:
> Hi Again,
> I created a new version of the patch which should be better than this
> hack, I'll send it as an RFC to the l-o list in a bit.
> On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote:
> > On Thu, Oct 13, 2011 at 4:58 PM, Ter
On Tue, 15 Nov 2011 10:46:03 +0200, Felipe Balbi said:
> - int srid;
> - int ip_type;
> + struct list_headnode;
> + struct platform_device *pdev;
> + struct omap_sr_nvalue_table *nvalue_table;
On Tue, 08 Jun 2010 01:17:13 +0200, Linus Walleij said:
> So I would really like to know from the Android people why the
> binder is in the kernel, after all. Could it *theoretically* be in
> userspace, on top of some unix domain sockets, running as a
> real-time scheduled daemon or whatever, stil
On Fri, 23 Sep 2011 15:46:08 +0300, Tero Kristo said:
> Following set contains the version 9 of this work. This patch set contains
> a number of patches tagged as 'TEMP', they are only meant for testing
> purposes and to provide proof of concept. Most of the 'TEMP' patches are
> related to UART run
On Sat, 24 Sep 2011 10:54:29 +0530, "Sripathy, Vishwanath" said:
> UART Runtime patches are already posted for review and it's also
> targeted for next merge window. Our intention is to push both the
> features together for next merge window.
Oh, OK. That should work then. Thanks for the clarific
On Thu, 09 Oct 2014 21:28:23 +0300, Ran Shalit said:
> Does anybody know what is the minimum expected time for sleep period
> with the cpuidle ?
Both processor dependent and sleep level dependent. There's a certain
amount of latency induced by the hardware waking up.
Look at /sys/devices/system
