Re: [PATCH 4/9] cpuidle: Introduce .abbr (abbrevation) for cpuidle states
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 you actually read a /sys
file, you know it's one string, that fact can get easily lost and cause issues
down the road. Consider this code:
foo=`cat /sys/some/file`
bar=`cat /sys/other/file`
baz=`cat /sys/third/file`
echo $foo $bar $baz | awk '{print $2 $3}'
Suddenly your output isn't what you expected...
pgpoKvq0hG1oS.pgp
Description: PGP signature
Re: [PATCH 00/15] change default_llseek action
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 Christoph Hellwig. I don't suppose there's any clean way to throw a build error or a printk_on_once() or something if we encounter an unconverted 'struct file_operations', is there? I have this creeping fear that this patch will go upstream during the merge window - as will 12 new staging/ drivers from authors who didn't get the memo yet. Other than the "missed converting a new usage" issue, it looks OK to me. pgpxEkcNJDXEM.pgp Description: PGP signature
Re: [PATCH 1/5] drivercore: add new error value for deferred probe
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? > According to Arnd, yes this is okay. > > Isn't this some user/kernel api here? > > What's wrong with just "overloading" on top of an existing error code? > > Surely one of the other 516 types could be used here, right? > overloading makes it really hard to find the users at a later date. Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That would allow overloading EAGAIN, but still make it easy to tell the usages apart if we need to separate them later... pgprB35gbjXki.pgp Description: PGP signature
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
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, Tero Kristo wrote: > > > On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote: > > >> On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava > > >> wrote: > > >> > On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo wrote: > > >> >> On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote: > > >> >> Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: > > >> >> 0115040-6. Kotipaikka: Helsinki > > > Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business > > > ID: 0115040-6. Domicile: Helsinki > Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: > 0115040-6. Domicile: Helsinki Moral: Just leave current street addresses out of it. :) And can we *please* trim irrelevant stuff? You top-posted a 2 line reply, followed by the entire note, which a bunch of kernel developers got to scroll through and wonder if they missed an in-line comment. *Especially* after the top part had one line that it wasn't clear if it was a top-posted sig line gone wrong, or 3 attempts to get an address right for inclusion in a patch. pgpPuwI7FKr6i.pgp Description: PGP signature
Re: [PATCH/RESEND #3 5/7] arm: omap: smartreflex: clean ups all over
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; > + struct voltagedomain*voltdm; As long as you're de-tabifying the function names that caused the problem... > int nvalue_count; > - boolautocomp_active; > - boolis_suspended; Why are you leaveing the rest of the struct tabified out to East Podunk? pgpBSmOgFjmVF.pgp Description: PGP signature
Re: [linux-pm] suspend blockers & Android integration
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, still yielding the same > performance? Or is there some discovered limitation with current > interfaces, that everybody ought to know? Not an Android person, but... How expensive is a userspace->kernel transition on Android-class hardware? There's certainly something to be said for short-circuiting the path source_process -> kernel -> broker_process -> kernel -> dest_process down to the shorter source->kernel->dest pgpWR2QCzXuiD.pgp Description: PGP signature
Re: [PATCHv9 00/18] omap PRCM chain handler
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 runtime handling and they will be replaced by work done > by Govindraj Raja. What do we do with these TEMP patches if the UART patches don't make the same merge window, or have other issues? I'm always leery of "will be replaced" code, because I've seen too many times when it *didn't* get replaced. (I really don't care what the 'Plan B' is, as long as we have one...) pgpprmOWHQJUp.pgp Description: PGP signature
Re: [PATCHv9 00/18] omap PRCM chain handler
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 clarification... pgpy6RReAWKiK.pgp Description: PGP signature
Re: cpuidle - minimum time for sleep
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/cpu/cpu*/cpuidle/state*/latency pgpNPLCCaPNRr.pgp Description: PGP signature
