On Mon, 2018-12-10 at 17:40 -0800, Linus Torvalds wrote:
> On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski
> wrote:
> > I'm seriously considering sending a patch to remove x32 support
> > from
> > upstream Linux. Here are some problems with it:
>
> I talked to Arnd (I think - we were talking
he emails but not needed to be involved
for a while now, you're doing fine without me! :)
> Cc: Richard Purdie <rpur...@rpsys.net>
> Signed-off-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
Acked-by: Richard Purdie <rpur...@rpsys.net>
> ---
> MAINTAINERS | 1 -
>
he emails but not needed to be involved
for a while now, you're doing fine without me! :)
> Cc: Richard Purdie
> Signed-off-by: Jacek Anaszewski
Acked-by: Richard Purdie
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
&
on 4.13 and 4.14 host kernels where the guest
doesn't have x2apic enabled.
I can confirm this fixes issues the Yocto Project automated testing
infrastructure was seeing.
I'd like to add support for backporting this in stable.
Tested-by: Richard Purdie <richard.pur...@linuxfoundation.org>
Cheers,
Richard
ost kernels where the guest
doesn't have x2apic enabled.
I can confirm this fixes issues the Yocto Project automated testing
infrastructure was seeing.
I'd like to add support for backporting this in stable.
Tested-by: Richard Purdie
Cheers,
Richard
On Fri, 2016-03-11 at 17:28 -0500, Bruce Ashfield wrote:
> On 2016-03-11 5:16 PM, Borislav Petkov wrote:
> > On Fri, Mar 11, 2016 at 08:18:23PM +0100, Paolo Bonzini wrote:
> > > Somebody got it wrong 10-ish years ago, and nobody has ever
> > > checked since.
> > >
> > > But, don't use qemu32 or
On Fri, 2016-03-11 at 17:28 -0500, Bruce Ashfield wrote:
> On 2016-03-11 5:16 PM, Borislav Petkov wrote:
> > On Fri, Mar 11, 2016 at 08:18:23PM +0100, Paolo Bonzini wrote:
> > > Somebody got it wrong 10-ish years ago, and nobody has ever
> > > checked since.
> > >
> > > But, don't use qemu32 or
This may be a silly question however its puzzling me and I don't have
any answer I'm happy with so I'm going to ask.
I have a 'stupid' workload which does a lot of forking, basically
pathologically stupid configure scripts. Its easy to replicate:
$ wget
This may be a silly question however its puzzling me and I don't have
any answer I'm happy with so I'm going to ask.
I have a 'stupid' workload which does a lot of forking, basically
pathologically stupid configure scripts. Its easy to replicate:
$ wget
On Thu, 2014-08-14 at 07:39 +0300, Sakari Ailus wrote:
> Bryan and Richard,
>
> Your opinion would be much appreciated to a question myself and Jacek were
> pondering. Please see below.
>
> On Thu, Aug 07, 2014 at 03:12:09PM +0200, Jacek Anaszewski wrote:
> > Hi Sakari,
> >
> > On 08/04/2014
On Thu, 2014-08-14 at 07:39 +0300, Sakari Ailus wrote:
Bryan and Richard,
Your opinion would be much appreciated to a question myself and Jacek were
pondering. Please see below.
On Thu, Aug 07, 2014 at 03:12:09PM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 08/04/2014 02:50 PM,
ewski
> Acked-by: Kyungmin Park
> Cc: Bryan Wu
> Cc: Richard Purdie
> ---
> drivers/leds/Kconfig|8 +
> drivers/leds/Makefile |1 +
> drivers/leds/led-class.c| 56 +--
> drivers/leds/led-flash.c| 375
>
...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/leds/Kconfig|8 +
drivers/leds/Makefile |1 +
drivers/leds/led-class.c| 56 +--
drivers/leds/led-flash.c| 375
LED class
> device control and communicate with it through the kernel
> internal interface. The LED sysfs interface is made
> unavailable then.
>
> Signed-off-by: Jacek Anaszewski
> Acked-by: Kyungmin Park
> Cc: Bryan Wu
> Cc: Richard
with it through the kernel
internal interface. The LED sysfs interface is made
unavailable then.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/leds/led
On Fri, 2013-12-27 at 18:13 +, One Thousand Gnomes wrote:
> > Well, this one will be really smaller. And yes, it will make some
> > memory non-swappable, but I believe with triggers and infrastructure
> > for N900 (and similar) it will be worth it.
>
> Ah yes thats such a major proportion of
On Fri, 2013-12-27 at 18:13 +, One Thousand Gnomes wrote:
Well, this one will be really smaller. And yes, it will make some
memory non-swappable, but I believe with triggers and infrastructure
for N900 (and similar) it will be worth it.
Ah yes thats such a major proportion of
On Thu, 2013-10-03 at 17:43 -0700, Andrew Morton wrote:
> On Fri, 04 Oct 2013 08:50:57 +0900 Jingoo Han wrote:
>
> > On Friday, October 04, 2013 8:21 AM, Andrew Morton wrote:
> > > On Fri, 27 Sep 2013 12:59:28 +0900 Jingoo Han wrote:
> > >
> > > > Re
On Thu, 2013-10-03 at 17:43 -0700, Andrew Morton wrote:
On Fri, 04 Oct 2013 08:50:57 +0900 Jingoo Han jg1@samsung.com wrote:
On Friday, October 04, 2013 8:21 AM, Andrew Morton wrote:
On Fri, 27 Sep 2013 12:59:28 +0900 Jingoo Han jg1@samsung.com wrote:
Remove Richard Purdie
On Wed, 2012-09-05 at 13:54 -0700, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 24, 2012 at 11:10:39AM +0800, Liang Li escreveu:
> > CFLAGS was previously hard coded to contain "-I/usr/include/slang" to
> > work with hosts that have "/usr/include/slang/slang.h" as well as hosts
> > that have
On Wed, 2012-09-05 at 13:54 -0700, Arnaldo Carvalho de Melo wrote:
Em Fri, Aug 24, 2012 at 11:10:39AM +0800, Liang Li escreveu:
CFLAGS was previously hard coded to contain -I/usr/include/slang to
work with hosts that have /usr/include/slang/slang.h as well as hosts
that have
On Sat, 2012-07-21 at 01:26 -0700, Colin Cross wrote:
> On Sat, Jul 21, 2012 at 12:33 AM, Richard Purdie
> wrote:
> > On Fri, 2012-07-20 at 21:08 -0700, Greg KH wrote:
> >> On Fri, Jul 20, 2012 at 05:46:14PM -0700, Colin Cross wrote:
> >> > I'm trying to use
On Fri, 2012-07-20 at 21:08 -0700, Greg KH wrote:
> On Fri, Jul 20, 2012 at 05:46:14PM -0700, Colin Cross wrote:
> > I'm trying to use the standard ledtrig-timer.c code to handle led
> > blinking for notifications on an Android device, and I'm hitting some
> > issues with setting permissions on
On Fri, 2012-07-20 at 21:08 -0700, Greg KH wrote:
On Fri, Jul 20, 2012 at 05:46:14PM -0700, Colin Cross wrote:
I'm trying to use the standard ledtrig-timer.c code to handle led
blinking for notifications on an Android device, and I'm hitting some
issues with setting permissions on the
On Sat, 2012-07-21 at 01:26 -0700, Colin Cross wrote:
On Sat, Jul 21, 2012 at 12:33 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Fri, 2012-07-20 at 21:08 -0700, Greg KH wrote:
On Fri, Jul 20, 2012 at 05:46:14PM -0700, Colin Cross wrote:
I'm trying to use the standard
On Thu, 2008-02-21 at 12:33 +0100, Kristoffer Ericson wrote:
> I'm reworking a couple of apm drivers and for whatever reason it
> doesn't seem to update my /proc/apm_bios. I was under the impression
> that it should do that when apm_bios was catted? Currently I have a
> value that never change. I
On Thu, 2008-02-21 at 12:33 +0100, Kristoffer Ericson wrote:
I'm reworking a couple of apm drivers and for whatever reason it
doesn't seem to update my /proc/apm_bios. I was under the impression
that it should do that when apm_bios was catted? Currently I have a
value that never change. I
On Sun, 2008-02-10 at 12:52 +0100, Németh Márton wrote:
> Disable any active triggers when the brightness attribute is
> set to zero.
I agree with this approach and will merge this as a clarification of the
interface, thanks. I'll also merge your other two patches into the LED
queue.
Cheers,
On Sun, 2008-02-10 at 12:52 +0100, Németh Márton wrote:
Disable any active triggers when the brightness attribute is
set to zero.
I agree with this approach and will merge this as a clarification of the
interface, thanks. I'll also merge your other two patches into the LED
queue.
Cheers,
On Thu, 2008-02-07 at 19:38 -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 07 Feb 2008, Richard Purdie wrote:
> > Márton Németh:
> > leds: Add support for hardware accelerated LED flashing
> > leds: hw acceleration for Clevo mail LED driver
>
> This on
Linus,
Could you please pull from:
git://git.o-hand.com/linux-rpurdie-backlight for-linus
for the backlight tree updates for 2.6.25. This includes a new driver
and an optimisation for the class. Both changes have been testing in -mm
for quite a while.
Thanks, Richard
support for hardware accelerated LED flashing
leds: hw acceleration for Clevo mail LED driver
Raphael Assenat (1):
leds: Fix led-gpio active_low default brightness
Richard Purdie (1):
leds: Standardise LED naming scheme
Rod Whitby (1):
leds: Remove the now uneeded ixp4xx
On Tue, 2008-02-05 at 19:13 +0100, Kristoffer Ericson wrote:
> Richard, I've been told from paul that I should seek another solution
> for my hd6446x.h merger (perhaps mfd driver). So this patch
> is against linux-2.6.git with the header and defines changed back to
> old style. Tested to compile.
On Tue, 2008-02-05 at 18:38 +0100, Cezary Jackiewicz wrote:
> From: Cezary Jackiewicz <[EMAIL PROTECTED]>
>
> This is driver for Compal Laptop: FL90/IFL90, based on MSI
> driver.
>
> This driver exports a few files in /sys/devices/platform/compal-laptop/:
> lcd_level - screen brightness:
On Tue, 2008-02-05 at 21:51 +0100, Sven Wegener wrote:
> WRAP systems have an additional LED. The power LED is normally lit after boot
> and doesn't serve any other purpose besides showing that the system is powered
> on. Nevertheless, its state is controllable and we can attach a trigger to it.
On Tue, 2008-02-05 at 18:38 +0100, Cezary Jackiewicz wrote:
From: Cezary Jackiewicz [EMAIL PROTECTED]
This is driver for Compal Laptop: FL90/IFL90, based on MSI
driver.
This driver exports a few files in /sys/devices/platform/compal-laptop/:
lcd_level - screen brightness: contains a
On Tue, 2008-02-05 at 21:51 +0100, Sven Wegener wrote:
WRAP systems have an additional LED. The power LED is normally lit after boot
and doesn't serve any other purpose besides showing that the system is powered
on. Nevertheless, its state is controllable and we can attach a trigger to it.
On Tue, 2008-02-05 at 19:13 +0100, Kristoffer Ericson wrote:
Richard, I've been told from paul that I should seek another solution
for my hd6446x.h merger (perhaps mfd driver). So this patch
is against linux-2.6.git with the header and defines changed back to
old style. Tested to compile. I
support for hardware accelerated LED flashing
leds: hw acceleration for Clevo mail LED driver
Raphael Assenat (1):
leds: Fix led-gpio active_low default brightness
Richard Purdie (1):
leds: Standardise LED naming scheme
Rod Whitby (1):
leds: Remove the now uneeded ixp4xx
Linus,
Could you please pull from:
git://git.o-hand.com/linux-rpurdie-backlight for-linus
for the backlight tree updates for 2.6.25. This includes a new driver
and an optimisation for the class. Both changes have been testing in -mm
for quite a while.
Thanks, Richard
On Wed, 2008-02-06 at 17:33 +0100, Kristoffer Ericson wrote:
> Oki, here is attempt #2 (btw, new mail or just keep thread?)
Apart from the issues Russell mentioned,
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,286 @@
+/*
+ * drivers/video/backlight/jornada720_bllcd.c
On Wed, 2008-02-06 at 17:33 +0100, Kristoffer Ericson wrote:
Oki, here is attempt #2 (btw, new mail or just keep thread?)
Apart from the issues Russell mentioned,
--- /dev/null
+++ b/drivers/video/backlight/jornada720_bllcd.c
@@ -0,0 +1,286 @@
+/*
+ * drivers/video/backlight/jornada720_bllcd.c
On Sun, 2008-02-03 at 21:46 +0100, Kristoffer Ericson wrote:
> shortlog:
> The HP Jornada 6xx series have simple leds thats able to produce green or red
> light.
> This patch enables the leds to be used by the kernel and/or userland.
>
> signed-off-by: Kristoffer Ericson <[EMAIL PROTECTED]>
>
>
On Sun, 2008-02-03 at 21:46 +0100, Kristoffer Ericson wrote:
shortlog:
The HP Jornada 6xx series have simple leds thats able to produce green or red
light.
This patch enables the leds to be used by the kernel and/or userland.
signed-off-by: Kristoffer Ericson [EMAIL PROTECTED]
Richard
On Thu, 2007-12-27 at 14:31 +0100, Michael Loeffler wrote:
> The 3rd LED on this board is something like a power-led, it is on all the
> time. With this change to the leds-wrap driver it is possible to use this
> LED too.
>
> Signed-off-by: Michael Loeffler <[EMAIL PROTECTED]>
> ---
> Hi
>
> I
On Thu, 2007-12-27 at 14:31 +0100, Michael Loeffler wrote:
The 3rd LED on this board is something like a power-led, it is on all the
time. With this change to the leds-wrap driver it is possible to use this
LED too.
Signed-off-by: Michael Loeffler [EMAIL PROTECTED]
---
Hi
I wonder why
as a module so the
"hardcoded" policy can easily be removed from the kernel at runtime if
desired too.
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
---
drivers/input/Kconfig | 12
drivers/input/Makefile|1
drivers/input/ap
-locomo.c |2 +-
drivers/leds/leds.h |3 ++-
5 files changed, 13 insertions(+), 12 deletions(-)
Richard Purdie (2):
leds: Fix leds_list_lock locking issues
leds: Fix locomo LED driver oops
--
To unsubscribe from this list: send the line "unsubscribe linux-k
-locomo.c |2 +-
drivers/leds/leds.h |3 ++-
5 files changed, 13 insertions(+), 12 deletions(-)
Richard Purdie (2):
leds: Fix leds_list_lock locking issues
leds: Fix locomo LED driver oops
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
as a module so the
hardcoded policy can easily be removed from the kernel at runtime if
desired too.
Signed-off-by: Richard Purdie [EMAIL PROTECTED]
---
drivers/input/Kconfig | 12
drivers/input/Makefile|1
drivers/input/apm-power.c | 125
a ton more efficient. Certain code was left in case I wanted to
go back to looking at things at a function level too:
#!/usr/bin/python
#
# Copyright 2007 Richard Purdie <[EMAIL PROTECTED]>
# Copyright 2004 Matt Mackall <[EMAIL PROTECTED]>
#
# Based on python Bloat-O-Meter (c) 2004 by
was left in case I wanted to
go back to looking at things at a function level too:
#!/usr/bin/python
#
# Copyright 2007 Richard Purdie [EMAIL PROTECTED]
# Copyright 2004 Matt Mackall [EMAIL PROTECTED]
#
# Based on python Bloat-O-Meter (c) 2004 by Matt Mackall
#
# This software may be used
On Sat, 2007-12-08 at 03:40 +0100, Rafael J. Wysocki wrote:
> Subject : leds: ledtrig-timer calls sleeping function from
> invalid context
> Submitter : Márton Németh <[EMAIL PROTECTED]>
> References: http://bugzilla.kernel.org/show_bug.cgi?id=9264
> Ha
On Sat, 2007-12-08 at 03:40 +0100, Rafael J. Wysocki wrote:
Subject : leds: ledtrig-timer calls sleeping function from
invalid context
Submitter : Márton Németh [EMAIL PROTECTED]
References: http://bugzilla.kernel.org/show_bug.cgi?id=9264
Handled-By: Richard Purdie
-triggers.c | 49 ++--
include/linux/leds.h|3 +-
3 files changed, 30 insertions(+), 28 deletions(-)
Richard Purdie (1):
leds: Fix led trigger locking bugs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
-triggers.c | 49 ++--
include/linux/leds.h|3 +-
3 files changed, 30 insertions(+), 28 deletions(-)
Richard Purdie (1):
leds: Fix led trigger locking bugs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Linus,
Could you please pull from:
git://git.o-hand.com/linux-rpurdie-leds for-linus
for some LED driver bugfixes for 2.6.24.
Thanks, Richard
drivers/leds/leds-gpio.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
David Brownell (1):
leds: bugfixes for
Linus,
Could you please pull from:
git://git.o-hand.com/linux-rpurdie-leds for-linus
for some LED driver bugfixes for 2.6.24.
Thanks, Richard
drivers/leds/leds-gpio.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
David Brownell (1):
leds: bugfixes for
On Sun, 2007-10-28 at 12:22 +0100, Németh Márton wrote:
> Richard Purdie wrote:
> > Hmm, there really is no way to just turn the LED on? :(
>
> Unfortunately I do not have these optional modules so I never saw the LED
> just on without blinking. I don't know if there is any h
On Sun, 2007-10-28 at 12:22 +0100, Németh Márton wrote:
Richard Purdie wrote:
Hmm, there really is no way to just turn the LED on? :(
Unfortunately I do not have these optional modules so I never saw the LED
just on without blinking. I don't know if there is any hardware limitation
turning
On Thu, 2007-10-25 at 22:54 +0100, Richard Purdie wrote:
> On Thu, 2007-10-25 at 13:02 -0700, Andrew Morton wrote:
> > It was in the inital report, at
> > http://bugzilla.kernel.org/show_bug.cgi?id=9217 :
>
> This is the commandline they wanted to use, not the one that was
>
On Thu, 2007-10-25 at 22:54 +0100, Richard Purdie wrote:
On Thu, 2007-10-25 at 13:02 -0700, Andrew Morton wrote:
It was in the inital report, at
http://bugzilla.kernel.org/show_bug.cgi?id=9217 :
This is the commandline they wanted to use, not the one that was
actually used. The one
On Thu, 2007-10-25 at 23:35 +0200, Ingo Oeser wrote:
> On Thursday 25 October 2007, Kristen Carlson Accardi wrote:
> > Enable enclosure management via LED
> >
> > As described in the AHCI spec, some AHCI controllers may support
> > Enclosure management via a variety of protocols. This patch
> >
On Thu, 2007-10-25 at 13:02 -0700, Andrew Morton wrote:
> On Thu, 25 Oct 2007 14:43:36 +0100
> Richard Purdie <[EMAIL PROTECTED]> wrote:
> > Could the original bug reporter please report what commandline the
> > kernel actually uses please? In theory it can only be ei
On Thu, 2007-10-25 at 17:13 +0100, Alan Cox wrote:
> > I'm seriously tempted to add a "kill the process using the most memory"
> > key combination into SysRq which might let me save the desktop but won't
> > help with my remote server. I could also just disable swap I guess.
>
> For specific
I've got a problem I keep running into. My computers have buggy software
which can sometimes run out of control. Two specific examples:
Evolution: Sometimes its memory usage decides to suddenly grow out of
control. It usually idles at around 300MB, you can watch it in top,
doubling, trebling and
On Thu, 2007-10-25 at 14:23 +0200, Lennert Buytenhek wrote:
> On Wed, Oct 24, 2007 at 10:35:33PM -0500, Bill Gatliff wrote:
>
> > >Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.
> > >
> > >I don't know whether it was an ARM patch one of those kernel-wide changes.
> >
On Thu, 2007-10-25 at 14:23 +0200, Lennert Buytenhek wrote:
On Wed, Oct 24, 2007 at 10:35:33PM -0500, Bill Gatliff wrote:
Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.
I don't know whether it was an ARM patch one of those kernel-wide changes.
We have
I've got a problem I keep running into. My computers have buggy software
which can sometimes run out of control. Two specific examples:
Evolution: Sometimes its memory usage decides to suddenly grow out of
control. It usually idles at around 300MB, you can watch it in top,
doubling, trebling and
On Thu, 2007-10-25 at 17:13 +0100, Alan Cox wrote:
I'm seriously tempted to add a kill the process using the most memory
key combination into SysRq which might let me save the desktop but won't
help with my remote server. I could also just disable swap I guess.
For specific applications
On Thu, 2007-10-25 at 13:02 -0700, Andrew Morton wrote:
On Thu, 25 Oct 2007 14:43:36 +0100
Richard Purdie [EMAIL PROTECTED] wrote:
Could the original bug reporter please report what commandline the
kernel actually uses please? In theory it can only be either:
* the one being compiled
On Thu, 2007-10-25 at 23:35 +0200, Ingo Oeser wrote:
On Thursday 25 October 2007, Kristen Carlson Accardi wrote:
Enable enclosure management via LED
As described in the AHCI spec, some AHCI controllers may support
Enclosure management via a variety of protocols. This patch
adds
On Sun, 2007-10-21 at 14:54 +0200, Németh Márton wrote:
> From: Márton Németh <[EMAIL PROTECTED]>
>
> Extends the leds subsystem with a blink_set() callback function which can
> be optionally implemented by a LED driver. If implemented, the driver can use
> the hardware acceleration for blinking
On Sun, 2007-10-21 at 14:55 +0200, Németh Márton wrote:
> diff -uprN linux-2.6.23.orig/Documentation/leds-class.txt
> linux-2.6.23/Documentation/leds-class.txt
> --- linux-2.6.23.orig/Documentation/leds-class.txt2007-10-09
> 22:31:38.0 +0200
> +++
On Sun, 2007-10-21 at 14:55 +0200, Németh Márton wrote:
diff -uprN linux-2.6.23.orig/Documentation/leds-class.txt
linux-2.6.23/Documentation/leds-class.txt
--- linux-2.6.23.orig/Documentation/leds-class.txt2007-10-09
22:31:38.0 +0200
+++ linux-2.6.23/Documentation/leds-class.txt
On Sun, 2007-10-21 at 14:54 +0200, Németh Márton wrote:
From: Márton Németh [EMAIL PROTECTED]
Extends the leds subsystem with a blink_set() callback function which can
be optionally implemented by a LED driver. If implemented, the driver can use
the hardware acceleration for blinking a LED.
ike APM as
a "user" event so the power button triggered a suspend event but
anything in userspace needing to know about (or veto) it could do so.
> > 2. Seeing as my knowledge about this area isn't the best I would
> > appreciate all opinions on the subject from the gurus.
>
&
(or veto) it could do so.
2. Seeing as my knowledge about this area isn't the best I would
appreciate all opinions on the subject from the gurus.
Richard Purdie I think might have some pointers.
Currently I still patch this functionality into the Zaurus kernels
(basically by resurrecting
Linus,
Could you please pull from:
git://git.o-hand.com/linux-rpurdie-leds for-linus
for the LED tree updates for 2.6.24. Just some changes to the cobalt
driver really.
Thanks, Richard
drivers/leds/Kconfig| 13 ++-
drivers/leds/Makefile |3
):
backlight/leds: Make two structs static
Haavard Skinnemoen (1):
backlight: Add Samsung LTV350QV LCD driver
Jesper Juhl (1):
backlight: Fix cr_bllcd allocations and error paths
Richard Purdie (1):
backlight: Convert corgi backlight driver into a more generic driver
):
backlight/leds: Make two structs static
Haavard Skinnemoen (1):
backlight: Add Samsung LTV350QV LCD driver
Jesper Juhl (1):
backlight: Fix cr_bllcd allocations and error paths
Richard Purdie (1):
backlight: Convert corgi backlight driver into a more generic driver
Linus,
Could you please pull from:
git://git.o-hand.com/linux-rpurdie-leds for-linus
for the LED tree updates for 2.6.24. Just some changes to the cobalt
driver really.
Thanks, Richard
drivers/leds/Kconfig| 13 ++-
drivers/leds/Makefile |3
On Mon, 2007-10-01 at 00:52 +0100, Richard Purdie wrote:
> The leds tree doesn't have much in it, basically some changes to the
> cobalt LED drivers.
>
> http://git.o-hand.com/?p=linux-rpurdie-leds;a=shortlog;h=for-mm
>
> Yoichi Yuasa (3):
> leds: Rename leds-cobal
On Sun, 2007-09-30 at 19:43 -0700, Greg KH wrote:
> On Mon, Oct 01, 2007 at 12:52:07AM +0100, Richard Purdie wrote:
> > I've become aware that I should be posting a merge plan, probably
> > slightly earlier than this but better late than never.
>
> Can you post a diffstat t
On Sun, 2007-09-30 at 19:43 -0700, Greg KH wrote:
On Mon, Oct 01, 2007 at 12:52:07AM +0100, Richard Purdie wrote:
I've become aware that I should be posting a merge plan, probably
slightly earlier than this but better late than never.
Can you post a diffstat too, so we get an idea of what
On Mon, 2007-10-01 at 00:52 +0100, Richard Purdie wrote:
The leds tree doesn't have much in it, basically some changes to the
cobalt LED drivers.
http://git.o-hand.com/?p=linux-rpurdie-leds;a=shortlog;h=for-mm
Yoichi Yuasa (3):
leds: Rename leds-cobalt driver
leds: Add Cobalt
-hand.com/?p=linux-rpurdie-backlight;a=shortlog;h=for-mm
Adrian Bunk (1):
backlight/leds: Make two structs static
Haavard Skinnemoen (1):
backlight: Add Samsung LTV350QV LCD driver
Jesper Juhl (1):
backlight: Fix cr_bllcd allocations and error paths
Richard Purdie (1
I've become aware that I should be posting a merge plan, probably
slightly earlier than this but better late than never.
The leds tree doesn't have much in it, basically some changes to the
cobalt LED drivers.
http://git.o-hand.com/?p=linux-rpurdie-leds;a=shortlog;h=for-mm
Yoichi Yuasa (3):
-hand.com/?p=linux-rpurdie-backlight;a=shortlog;h=for-mm
Adrian Bunk (1):
backlight/leds: Make two structs static
Haavard Skinnemoen (1):
backlight: Add Samsung LTV350QV LCD driver
Jesper Juhl (1):
backlight: Fix cr_bllcd allocations and error paths
Richard Purdie (1
I've become aware that I should be posting a merge plan, probably
slightly earlier than this but better late than never.
The leds tree doesn't have much in it, basically some changes to the
cobalt LED drivers.
http://git.o-hand.com/?p=linux-rpurdie-leds;a=shortlog;h=for-mm
Yoichi Yuasa (3):
On Sun, 2007-09-23 at 08:14 +0200, Pierre Ossman wrote:
> rwlocks are used in the structures so make sure the right header
> is included.
>
> Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
I think something similar was already committed in revision
df96efd73b81b8bc2d23b3d8b6025cce3d43db6c.
On Mon, 2007-09-24 at 12:34 +0200, Haavard Skinnemoen wrote:
> On Mon, 24 Sep 2007 10:58:08 +0200 (CEST)
> "Rodolfo Giometti" <[EMAIL PROTECTED]> wrote:
> > I have an LCD panel on a custom PXA27x based board and it must be
> > turned on/off by some special commands via a GPIO throught a I2C chip.
On Mon, 2007-09-24 at 12:34 +0200, Haavard Skinnemoen wrote:
On Mon, 24 Sep 2007 10:58:08 +0200 (CEST)
Rodolfo Giometti [EMAIL PROTECTED] wrote:
I have an LCD panel on a custom PXA27x based board and it must be
turned on/off by some special commands via a GPIO throught a I2C chip.
I'd
On Sun, 2007-09-23 at 08:14 +0200, Pierre Ossman wrote:
rwlocks are used in the structures so make sure the right header
is included.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
I think something similar was already committed in revision
df96efd73b81b8bc2d23b3d8b6025cce3d43db6c.
Cheers,
On Thu, 2007-09-13 at 23:54 +0900, Yoichi Yuasa wrote:
> Add Cobalt Raq LEDs support.
>
> Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
Not the clearest patch I've ever seen or the most helpful patch
description. The rename could probably be split from the additional new
driver at least...
>
On Thu, 2007-09-13 at 23:54 +0900, Yoichi Yuasa wrote:
Add Cobalt Raq LEDs support.
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
Not the clearest patch I've ever seen or the most helpful patch
description. The rename could probably be split from the additional new
driver at least...
diff
On Tue, 2007-09-11 at 17:48 +0900, Yoichi Yuasa wrote:
> This patch has added #include to include/linux/leds.h for
> rwlock_t.
>
> Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
Added to the leds tree[1], thanks.
http://git.o-hand.com/?p=linux-rpurdie-leds;a=shortlog;h=for-mm
Richard
-
To
On Tue, 2007-09-11 at 17:48 +0900, Yoichi Yuasa wrote:
This patch has added #include linux/spinlock.h to include/linux/leds.h for
rwlock_t.
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
Added to the leds tree[1], thanks.
http://git.o-hand.com/?p=linux-rpurdie-leds;a=shortlog;h=for-mm
Add some casts to the LZO compression algorithm after they were removed
during cleanup and shouldn't have been.
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
---
This fixes the reported problems for me, I've checked fairly carefully
and I can't see any other issues. Edward, could y
On Fri, 2007-07-27 at 16:35 +0400, Edward Shishkin wrote:
> Sorry, guys, I am not happy with the modified LZO:
> the compressor tries to test bytes which are out of bounds.
>
> The attached module testlzo.c causes an oops in the second pass:
> AFAIK, both, @m and @m_pos should be in [wrkmem,
1 - 100 of 598 matches
Mail list logo
