This driver supports the PCA9550, PCA9551, PCA9552, and PCA9553 LED driver chips. Signed-off-by: Nate Case <ncase@xes-inc.com> --- drivers/leds/Kconfig | 8 + drivers/leds/Makefile | 1 + drivers/leds/leds-pca955x.c | 384 +++++++++++++++++++++++++++++++++++++++++++ include/linux/leds.h | 14 ++ 4 files changed, 407 insertions(+), 0 deletions(-) create mode 100644 drivers/leds/leds-pca955x.c diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 86...

From: Greg Kroah-Hartman <gregkh@suse.de> This driver was originally written by James McKenzie but forward ported and cleaned up by me to get it to work with modern kernel versions. Tested on my mac mini and it actually works! Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- Jiri, is it ok for this quirks addtion to go through Dmitry's triee? Or do you want me to split it out into two different patches? Dmitry, is this ok to go through your tree? Or I can take it as w...

I know nothing about that device, sorry. I think it is a totally Ah, didn't realize that, nice to know, we should have a wider userbase then :) thanks, greg k-h --

Something in the PCI department attempted to take a lock with interrupts disabled, but that lock had previously been held with interrupts enabled, or so it seems. That something was called from pci_device_resume_early and it was a VIA quirk, AFAICS. I always need some help from people who actually understand these messages, Thanks, Rafael --

From: Alan Cox <alan@redhat.com> The atomic_t type is 32bit but a 64bit system can have more than 2^32 pages of virtual address space available. Without this we overflow on ludicrously large mappings --- fs/proc/proc_misc.c | 2 +- include/linux/mman.h | 4 ++-- mm/mmap.c | 4 ++-- mm/nommu.c | 4 ++-- mm/swap.c | 4 ++-- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/fs/proc/proc_misc.c b/fs/proc/proc_misc.c index 74a...

From: Franck Bui-Huu <fbuihuu@gmail.com> This patch moves rcu-protected lists from list.h into a new header file rculist.h. This is done because list are a very used primitive structure all over the kernel and it's currently impossible to include other header files in this list.h without creating some circular dependencies. For example, list.h implements rcu-protected list and uses rcu_dereference() without including rcupdate.h. It actually compiles because users of rcu_dereference() are...

Hello; I've compiled the latest git 2.6.26-rc2-** and really like what I see and feel(heat and noise) the problem I have is I'm forced to use 3rd party video drivers for dri : - ( So with this in mind I'm trying to compile my video card module, and am confused is to as or why startx results in a blank screen!! I've reverted drm and agpgart, and also tried to convert the video module to use drm_minor(drmP.h), but still the same results, Where in the kernel might I find some useful info on why st...

From: Dean Anderson <dean@sensoray.com> This driver adds support for the Sensoray 2255 devices. It was primarily developed by Dean Anderson with only a little bit of guidance and cleanup by Greg. From: Dean Anderson <dean@sensoray.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/media/video/Kconfig | 9 drivers/media/video/Makefile | 1 drivers/media/video/s2255drv.c | 2719 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 2729 i...

Yes. S4 looks interesting. Especially the weird fans don't work on restore from S5 case. S4 still appears to be a premature optimization, that ads lots of complexity and reduces the reliability of the code. Software hibernation to disk should be a rock solid proposition, that needs little if any cooperation from drivers, and it should work on every box, because fundamentally it is hardware agnostic. The only cooperation we need from drivers is for devices that we can't tolerate at upper l...

From: Adrian Bunk <bunk@kernel.org> Applied, thanks a lot Adrian.

I'm trying to get a new set of UWB patches from David that should hopefully fix this issue. thanks, greg k-h --

Hello, I'd like to optimize my driver, which receives data through a fifo and gives them to a user space application. In turns this application moves this data into a file. To avoid several useless copies, I'd like the application to pass to the driver a file descriptor (?) to the driver and then the driver can directly move the received data to that file. Could anybody give me some example of such scheme ? Thanks, -- Francis --

If the application memory mapped the file, would it be able to simply pass a pointer to that mapped file as part of the call to the driver and the driver would place the data directly at the requested location which would then be directly to the file? -- Len Sorensen --

There's something called the NMI watchdog, that will print debugging messages out if it finds the system has hard locked. The short version is that you should add "nmi_watchdog=1" (no quotes) to the line in GRUB that has the kernel options. That assumes you have an APIC on the system. If that's not the case (you're on Uniprocessor, and no APIC) then you can try nmi_watchdog=2 instead. That'll only work on some systems, though. Better docs (than my cheesy writeup) are in Documentation/nmi_watchdog.txt in t...

On Wed, May 14, 2008 at 4:00 AM, Tetsuo Handa Hi Tetsuo, Can you try the patch attached with this mail, I made this on top of 2.6.24.7 but should fit on any other 2.6.24 based distro kernel. If the attached patch still gives you the same problem, please send me your config file and the boot time dmesg's. Thanks, Alok

As some of the latency junkies on lkml already know it, commit 8e3e076 ("BKL: revert back to the old spinlock implementation") in v2.6.26-rc2 removed the preemptible BKL feature and made the Big Kernel Lock a spinlock and thus turned it into non-preemptible code again. This commit returned the BKL code to the 2.6.7 state of affairs in essence. Linus also indicated that pretty much the only acceptable way to change this (to us -rt folks rather unfortunate) latency source and to get rid of th...

yeah. This is just a first approximation. It might be v2.6.27 stuff, if hm, we'll got more ideas about other debug helpers, but i dont think warning in the scheduler is realistic or useful: lots and lots of code _does_ reschedule with the BKL held and always did - we never knew this before in a reliable way due to the auto-release. Sleeping locks that purely nest inside the BKL are the norm in the VFS, in the tty code and in most other places - they should be fine and are frequently take...

It's a reasonable start, but have you considered doing this work in tree instead? As in just add all the warnings, but don't actually change the semantics yet. I suspect you would get far more users this way and the work would go faster. It would be reasonable to enable this in -mm if it the warnings are not too intrusive (self disable itself etc.) Also for fixing the ioctls I'm not sure that dynamic instrumentation will really work because it would be tough to execute them all. I suspect ...

So you just stick unlock_kernel()/lock_kernel() around the call to TTY (or similar to the entry points) -Andi --

And procfs and between the tty and the net config code and ... Keeping the BKL just in legacy places doesn't work. A counting mutex (ie one you can self multi-lock) might be very useful to fix some of these however as once we push it down to the point of being a driver specific lock we can just give it a driver mutex --

The good news is that I suspect they are going away. It probably is mainly tty and /proc by now, and /proc is pretty close to done. It's hard to have too many inter-module dependencies when most of the core modules no longer even take the kernel lock any more. In the VFS layer, we still have - the ioctl thing, obviously. That's just mind-numbing "move things down", not hard per se. But there's a *lot* of them (and I suspect the huge majority of them don't actually need it, sin...

There's also every char device open() method - a rather long list in its own right. I'd be surprised if one in ten of them really needs it, but one has to look... I've been looking at the chrdev code anyway, and pondering on how this might be addressed. Here's some thoughts on alternatives, I'd be curious what people think: 1: We could add an unlocked_open() to the file_operations structure; drivers could be converted over as they are verified not to need the BKL on open. Disadvantage...

There's the drivers calling cdev_add() directly as well - another This is all certainly doable, but it leaves me with one concern: there will be no signal to external module maintainers that the change needs to be made. So, beyond doubt, quite a few of them will just continue to be shipped unfixed - and they will still run. If any of them actually *need* the BKL, something awful may happen to somebody someday. jon --

In general when changing semantics drastically you should force compile errors by renaming the respective entry point. That has been the standard Linux method for this for years. I doubt it will be very interesting, but it would be useful. The goal less being to get rid of BKL in old drivers, but not requiring BKL in new drivers. Basically all BKL assumptions in interfaces really should go. -Andi --

In the interfaces definitely yes and all subsystems should have their own lock_kernel calls, but why in the old drivers? For those it's very unlikely they are used on any SMP system anyways (e.g. anything depending on CONFIG_ISA) or if they do only on 2 CPU systems. Of course if you can find someone to do the work it wouldn't be bad, just wouldn't seem like a particularly useful investment of time to me. Also it would be bad if the people who did such conversions didn't actually test it and th...