Aras Vaichas wrote:
> Unfortunately the simple coulomb counting chips have the disadvantage
> that the CPU has to be running to accumulate the pulses. Of course,
> the pulses could wake the CPU from a suspend mode, but I'd rather not
> do that just to add "one" to a counter ...
>
Could you have
Summary: Improve UBIFS mounting time
Proposer: Tim Bird
Description:
UBIFS is a next-generation flash-based file system for Linux.
It is a read/write file system, which supports compression
and has good performance. However, it's mount times are not
very good. This affects overall Linux boot ti
2009/12/15 Pavel Machek :
> Hi!
>
>> > > I'm not sure how familiar you are with the issues surrounding trying to
>> > > do a voltage to charge mapping for a battery but it's much more complex
>> > > than a simple table if you want to get it accurate. There's a lot
>> > > of
>>
>> > Well... current
The decompressors return error by calling a supplied error function, and/or
by returning an error return value. The initramfs code, however, fails to
check the exit code returned by the decompressor, and only checks the error
status set by calling the error function.
This patch adds a return cod
Signed-off-by: Phillip Lougher
---
lib/decompress_bunzip2.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/lib/decompress_bunzip2.c b/lib/decompress_bunzip2.c
index 600f473..a6b836b 100644
--- a/lib/decompress_bunzip2.c
+++ b/lib/decompress_bunzip2.c
@@ -637,6
The trivial malloc implementation used in the pre-boot environment by the
decompressors returns a bad pointer on failure (falling through after
calling error). This is doubly wrong - the callers expect malloc to
return NULL on failure, second the error function is intended to be
used by the decom
Hi,
The following patches fix up a number of NULL pointer bugs amd missing
error checks.
Thanks
Phillip
bzip2/lzma/gzip: pre-boot malloc doesn't return NULL on failure
bzip2: Add missing checks for malloc returning NULL
initramfs: add missing decompressor error check
---
include/linux/
Hi!
> > > I'm not sure how familiar you are with the issues surrounding trying to
> > > do a voltage to charge mapping for a battery but it's much more complex
> > > than a simple table if you want to get it accurate. There's a lot
> > > of
>
> > Well... current zaurus kernels use _huge_ table t
On Mon, Dec 14, 2009 at 12:58:26PM +0100, Pavel Machek wrote:
> On Mon 2009-12-14 11:50:24, Mark Brown wrote:
> > OpenEmbedded is a meta-distribution so doesn't use any particular
> > software here - I suspect you're referring to things like the GPE stack
> > which isn't so actively developed thes
On Sun, Dec 13, 2009 at 02:24:14PM +0100, Pavel Machek wrote:
> > actual charger hardware. My main concern here is that battery
> > performance monitoring has no pressing need to be in kernel and that
> > pushing it into the kernel creates a barrier to implementing more
> > advanced schemes in us
On Mon 2009-12-14 11:50:24, Mark Brown wrote:
> On Sun, Dec 13, 2009 at 02:19:22PM +0100, Pavel Machek wrote:
>
> > ...but then there are all the systems that rely on /proc/apm
> > emulation, like openembedded popular on sharp zaurus...
>
> OpenEmbedded is a meta-distribution so doesn't use any p
On Sun, Dec 13, 2009 at 02:19:22PM +0100, Pavel Machek wrote:
> ...but then there are all the systems that rely on /proc/apm
> emulation, like openembedded popular on sharp zaurus...
OpenEmbedded is a meta-distribution so doesn't use any particular
software here - I suspect you're referring to th
12 matches
Mail list logo
