linux.kernel Google Group

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-28T10:50:02Z

Given that kmalloc only does power-of-two allocations, you can limit
the resize operations to when you go beyond the current allocation
limit. You can also choose a reasonable minimum table size (e.g. 32
or 64 entries) and avoid resizes for many of the common cases entirely.
Arnd <><

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-28T10:40:02Z

[scancode-to-keycode map size]
[...]
It is not a performance sensitive task, is it? If you can trade ABI
simplicity for performance (which shouldn't actually matter), that'd be
a better deal.
Besides, some of the necessary kernel-internal house-keeping can also be
deferred until close().
OTOH, an additional "forget all current mappings" ioctl sounds like an

Re: Backlight device class redesign

2009-11-28T10:40:01Z

W dniu 28 listopada 2009 01:30 użytkownik Rafał Miłecki
<zaj...@gmail.com> napisał:
Just in case I was not clear enough. We should make ACPI, platform and
GPU drivers register same panel backlight control under same name like
"panel-0". Backlight class device would create
/sys/class/backlight/panel-0 only. When touching files in this

Re: XD/smartmedia - how to implement it right?

2009-11-28T10:40:02Z

Hi,
First of all, thank you very much for your contributions.
Could you explain, why we need an asynchronous mtd driver?
Also, as I understand the command interface more and more, it seems that
'magically' xD card had same interface as standard NAND flash chip.
I think I can implement the driver for each controller just like an nand

Re: linux-next: manual merge of the rr tree with the kbuild tree

2009-11-28T10:30:01Z

OK, I've taken this into my tree and adjusted accordingly. As you say,
it's trivial.
Thanks!
Rusty.

Re: [PATCH 0/2] staging/android fixes

2009-11-28T10:20:01Z

Arve's done a few revisions of the wakelock code with the linux-pm
list, and I know he's planning on trying to work through the remaining
issues (as I recall there was some discussion on read/write vs ioctl
interfaces to userspace) in the near future.
This really is the one piece that has the most impact on everything

Re: [PATCH 1/2] hw_random: core updates to allow more efficient drivers

2009-11-28T10:10:02Z

And might as well just #defube RNG_BUFFSIZE SMP_CACHE_BYTES (or use
SMP_CACHE_BYTES here and sizeof() elsewhere).
Naah, I like the separation; it matches the rest of the kernel and means we
can get funky with buffer management in 10 years time when we rewrite this
again.
Thanks,
Rusty.

Re: [PATCH 2/2] virtio: Convert virtio-rng to the new API

2009-11-28T10:10:02Z

Hi Ian,
Looks good. Minor comments below:
Gratuitous hunk?
I prefer bool and true/false for booleans these days.
This comment belongs above register_buffer() now I think.
(But I'm glad you kept it!)
Thanks,
Rusty.

Re: linux-next: percpu tree build warning

2009-11-28T10:00:01Z

That's foolish. We can now have generic per-cpu function for counters
and the like.
__percpu. Again, I'm explaining what you should already know before sending
email about this stuff.
OK, you convince Linus to change __user vars to use a prefix. Then I'll
agree that per_cpu_## is more kernely.
Stupidest debate ever.

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-28T09:50:02Z

For your reference, the code where EVIOGKEYCODE/EVIOSKEYCODE handling is done is at
this changeset:
[link]
Dynamic resizing can be done, but there are a few different use cases for
someone to touch on the keymaps:
1. People want to change the key assignment for a key at the shipped IR. In this case,

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-11-28T09:40:01Z

> A user friendly GUI tool to configure the mapping of the remote
buttons is
> essential for good user experience. I hope noone here considers that
users
> learn command line or bash to configure their remotes.
oh please no
the major, major problem with bluetooth is that there is *only* a gui
the core system should use the command line and then a gui (or guis) can

[PATCH 2/2] staging/android: remove BROKEN flag

2009-11-28T09:00:02Z

Signed-off-by: Corentin Chary <corenti...@iksaif.net>
---
drivers/staging/android/Kconfi g | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/android/Kcon fig b/drivers/staging/android/Kcon fig
index eb67563..2471949 100644
--- a/drivers/staging/android/Kcon fig
+++ b/drivers/staging/android/Kcon fig

[PATCH 1/2] staging/android: fix build issues

2009-11-28T09:00:01Z

Signed-off-by: Corentin Chary <corenti...@iksaif.net>
---
drivers/staging/android/logger .c | 1 +
drivers/staging/android/lowmem orykiller.c | 6 ++++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/logg er.c b/drivers/staging/android/logg er.c
index 6c10b45..64cc2a1 100644

[PATCH 0/2] staging/android fixes

2009-11-28T09:00:01Z

Hi,
Here is a patch to fix build for android specifics drivers.
What we should do next to prevent them from being removed in 2.6.23 ?
Is there any chance that all android stuff would be merged one day ?
Actually, we got a working 2.6.32 kernel for android here (with wakelock, ashm, etc..):
[link]

Re: [PATCH v3 16/27] PPC: use helpers for rlimits

2009-11-28T08:50:02Z

Are you sure? The previous version with ACCESS_ONCE was generally
NACKed. This one uses a newly added helper which is much more cleaner
way to do it.
thanks,