The maestro3 driver in ac9 oopses, due to trying to deref an
unitialized pointer. Here's the oops:
ksymoops 2.3.7 on i686 2.4.1-pre7. Options used
-v /boot/vmlinuz (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.1-pre7/ (default)
-m
I've noticed this as well in my logs. In linux/include/net/tcp.h,
TCP_DEBUG is turned on; in linux/net/ipv4/tcp_input.c,
tcp_ack_update_window() contains the following:
#ifdef TCP_DEBUG
snip
printk(KERN_DEBUG "TCP: peer %u.%u.%u.%u:%u/%u shrinks window %u:%u:%u. Bad, what else
can I say?\n",
Just a warning; I was informed by Alan that doing this for video
drivers was unnecessary, since video devices were already enabled
during bootup.
On Wed, Apr 25, 2001 at 01:06:24PM +0200, Marcus Meissner wrote:
On Wed, Apr 25, 2001 at 09:04:38AM +0200, Marcus Meissner wrote:
Hi Alan,
driers/chipsets that
wouldn't allow them to be used as a second video device (therefore
not requiring pci_enable_device)?
On Wed, Apr 25, 2001 at 11:04:55AM -0400, Jeff Garzik wrote:
Andres Salomon wrote:
Just a warning; I was informed by Alan that doing this for video
drivers
I'm kind of curious; deregister is used quite often in the kernel:
pcmcia_deregister_client
pcmcia_deregister_erase_queue
misc_deregister
atm_dev_deregister
atm_proc_dev_deregister
usb_deregister_bus
usb_deregister
usb_serial_deregister
scsi_deregister_blocked_host
matroxfb_dh_deregisterfb
Not
On Sun, Apr 29, 2001 at 10:27:29PM -0300, Rik van Riel wrote:
On Sun, 29 Apr 2001, Andres Salomon wrote:
Not to mention in various comments and documentation. Deregister,
according to www.m-w.com (and many other dictionaries), is not a word.
Is there some sort of historical
I'm about halfway through the video directory, making all the pci
drivers that access resources/irq use pci_enable_device first.
Here's the first 8 patches (1 patch per driver); if you prefer, I'll
send you the rest when I'm done, or I can just tell you and you
can grab 'em off
http://lwn.net/2001/0329/kernel.php3
The LWN kernel editor will apparently be doing some reporting for the
event.
On Fri, Mar 30, 2001 at 01:01:09PM -0800, Torrey Hoffman wrote:
snip
Is anything like that available? I'm really hoping that some of the people
present at least post summaries
Dmitry Torokhov wrote:
On 2/16/07, Andres Salomon [EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
On Thursday 15 February 2007 20:30, Andrew Morton wrote:
On Thu, 15 Feb 2007 19:55:29 -0500
Andres Salomon [EMAIL PROTECTED] wrote:
[...]
Perhaps a nicer implementation would be to have
Allow ALPS, LOGIPS2PP, LIFEBOOK, and TRACKPOINT protocol extensions (in
the psmouse driver) to be disabled during compilation. The synaptics
stuff is left alone for now, since it needs special handling for
synaptic pass-through ports.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git
Initial framework for disabling PS/2 protocol extensions. The current
protocols can only be disabled if CONFIG_EMBEDDED is selected. No
source files are changed, merely build stuff.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse
Allow disabling of synaptics via CONFIG_MOUSE_PS2_SYNAPTICS;
we leave synaptic_detect and synaptic_reset (for synaptics hardware
that emulates other protocols), but get rid of synaptic_init.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers
Andrew Morton wrote:
On Thu, 15 Feb 2007 05:08:21 -0500
Andres Salomon [EMAIL PROTECTED] wrote:
Initial framework for disabling PS/2 protocol extensions. The current
protocols can only be disabled if CONFIG_EMBEDDED is selected. No
source files are changed, merely build stuff.
ugleee
Dmitry Torokhov wrote:
On Thursday 15 February 2007 20:30, Andrew Morton wrote:
On Thu, 15 Feb 2007 19:55:29 -0500
Andres Salomon [EMAIL PROTECTED] wrote:
[...]
Perhaps a nicer implementation would be to have a separate .c file for each
variant.
Having completely separate sub-drivers
Dmitry Torokhov wrote:
On 2/16/07, Andres Salomon [EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
On Thursday 15 February 2007 20:30, Andrew Morton wrote:
On Thu, 15 Feb 2007 19:55:29 -0500
Andres Salomon [EMAIL PROTECTED] wrote:
[...]
Perhaps a nicer implementation would be to have
the base-lock, but that's fine (and
their responsibility). Let me know if there's some reason why the lock
should be held, and I can rework this.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 51556b9..b43bccb 100644
--- a/kernel
,
rather than vice-versa.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/include/asm-i386/tsc.h b/include/asm-i386/tsc.h
index e997891..6207fc0 100644
--- a/include/asm-i386/tsc.h
+++ b/include/asm-i386/tsc.h
@@ -1 +1,66 @@
-#include asm-x86_64/tsc.h
+/*
+ * linux/include/asm-i386
Thomas Gleixner wrote:
On Fri, 2007-03-02 at 21:52 -0500, Andres Salomon wrote:
[...]
The BUG is somewhere else. the tick timer should never be seen in
hrtimer_run_queues. The tick timer is operated solely from the timer
interrupt.
The question is, how the tick timer gets enqueued
The description for HRTIMER_CB_IRQSAFE_NO_SOFTIRQ is backwards; NO
SOFTIRQ sounds a whole lot like it means it must not be run in a
softirq. :)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 3bef961..b9f163d 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
The description for the hrtimer_clock_base struct describes
hrtimer_base. That should be hrtimer_clock_base.
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 3bef961..3000539 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -139,7 +139,7 @@ struct
The description for the hrtimer_clock_base struct describes
hrtimer_base. That should be hrtimer_clock_base.
(Resending; forgot to sign off)
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 3bef961..3000539 100644
--- a/include
The description for HRTIMER_CB_IRQSAFE_NO_SOFTIRQ is backwards; NO
SOFTIRQ sounds a whole lot like it means it must not be run in a
softirq. :)
(Resending; forgot to sign off)
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index
.
And an additional request, just to make it explicit that we should not
have any NO_SOFTIRQ callbacks in the tree; BUG out if we encounter such
a thing.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
diff --git a/kernel/hrtimer.c b/kernel
Ingo Molnar wrote:
* Andres Salomon [EMAIL PROTECTED] wrote:
Thomas Gleixner wrote:
The question is, how the tick timer gets enqueued in the softirq queue.
Can you isolate the codepath, where this happens ?
The TIMER_SOFTIRQ runs the hrtimers during bootup until a usable
clocksource
run_hrtimer_queue is called from a softirq context, and should never run
a callback that is classified as HRTIMER_CB_IRQSAFE_NO_SOFTIRQ. A bug
in unrelated code had managed to trigger that bug, so let's add an
explicit warning to this function.
Signed-off-by: Andres Salomon [EMAIL PROTECTED
If CONFIG_ZONE_DMA is ever undefined, ZONE_DMA will also not be defined,
and setup.c won't compile. This wraps it with an #ifdef.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
index 0b476e1..b69626e 100644
--- a/arch/i386/kernel
Dave Jones wrote:
On Tue, Mar 06, 2007 at 05:52:46PM -0800, Andrew Morton wrote:
On Tue, 06 Mar 2007 18:52:59 -0500
Andres Salomon [EMAIL PROTECTED] wrote:
If CONFIG_ZONE_DMA is ever undefined, ZONE_DMA will also not be defined,
and setup.c won't compile. This wraps
Christoph Lameter wrote:
On Tue, 6 Mar 2007, Andres Salomon wrote:
It would've been nice to see the ZONE_DMA removal patches just #define
ZONE_DMA regardless, and include less #ifdefs scattered about; but at
this point, I'd just as soon prefer to see a proper way to allocate
things based
The lifebook driver may register a second input device, but it never
unregisters it. This fixes that.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/input/mouse/lifebook.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/input/mouse/lifebook.c
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/input/mouse/hil_ptr.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/input/mouse/hil_ptr.c b/drivers/input/mouse/hil_ptr.c
index 27f88fb..de8b836 100644
--- a/drivers/input/mouse/hil_ptr.c
+++ b
). This calls input_unregister_device
from the error path, and sets input_dev to NULL so that we don't
attempt to also call input_free_device on it.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/input/mouse/psmouse-base.c |2 ++
1 files changed, 2 insertions(+), 0 deletions
By default, we allocate DMA buffers when actually reading from the video
capture device. On a system with 128MB or 256MB of ram, it's very easy
for that memory to quickly become fragmented. We've had users report
having 30+MB of memory free, but the cafe_ccic driver is still unable to
allocate
On Wed, 19 Sep 2007 15:34:42 -0700 (PDT)
Trent Piepho [EMAIL PROTECTED] wrote:
On Wed, 19 Sep 2007, Jonathan Corbet wrote:
Andres Salomon [EMAIL PROTECTED] wrote:
This patch makes DMA buffer allocation happen during device probe by
default, and changes the parameter
below; that was done so patch #4
wasn't stupidly large.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/power_supply_core.c |9 +++
drivers/power/power_supply_leds.c | 18 +
drivers/power/power_supply_sysfs.c | 123
include/linux
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/pda_power.c | 40
1 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
index c058f28..4012a2f 100644
--- a/drivers/power
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/olpc_battery.c | 413 +
1 files changed, 252 insertions(+), 161 deletions(-)
diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
index af7a231..419aca2 100644
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/power_supply_core.c | 17 +---
drivers/power/power_supply_leds.c | 30 ++-
drivers/power/power_supply_sysfs.c | 158 +---
include/linux/power_supply.h | 47 ---
4 files
This allows us to share the uevent callback code w/ the dynamic attrib
stuff.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/power_supply_sysfs.c | 50
include/linux/power_supply.h |9 ++
2 files changed, 20 insertions
.
On Sun, Dec 16, 2007 at 09:36:24PM -0500, David Woodhouse wrote:
On Sun, 2007-12-16 at 21:24 -0500, Andres Salomon wrote:
This API has the power_supply drivers device their own device_attribute
list; I find this to be a lot more flexible and cleaner.
I don't see how this is more
On Mon, 17 Dec 2007 14:24:16 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Mon, Dec 17, 2007 at 02:41:39AM -0500, Andres Salomon wrote:
[...]
On Sun, 2007-12-16 at 21:24 -0500, Andres Salomon wrote:
This API has the power_supply drivers device their own
device_attribute
On Wed, 19 Dec 2007 15:35:46 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Tue, Dec 18, 2007 at 02:10:01AM -0500, Andres Salomon wrote:
On Mon, 17 Dec 2007 14:24:16 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Mon, Dec 17, 2007 at 02:41:39AM -0500, Andres Salomon wrote
On Wed, 19 Dec 2007 21:50:50 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Wed, Dec 19, 2007 at 01:02:41PM -0500, Andres Salomon wrote:
[...]
Hm. It occurs to me that there's nothing keeping us from having a
single callback for the driver properties. Keeping the other patches
On Thu, 20 Dec 2007 18:07:16 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
Hi Andres,
[...]
Then, what the power supply subsystem is for? Just place all the
drivers together in driver/power/, and let them create sysfs
attributes by their own. You'll get a medley, not the subsystem.
for such a thing,
and we should certainly not encourage drivers to provide CAPACITY_LEVEL
stubs.
The following removes support for POWER_SUPPLY_PROP_CAPACITY_LEVEL. The
OLPC battery driver is the only driver making use of this, so it's
removed from there as well.
Signed-off-by: Andres Salomon [EMAIL
it to unregister the correct attrib.
Another line which was unnecessarily line wrapped is also unwrapped.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
drivers/power/power_supply_sysfs.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/power
Simple cosmetic update for the cs5536 reboot fixup; define the MSR that's used
for rebooting in geode.h, and use the define.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/reboot_fixups_32.c
b/arch/x86/kernel/reboot_fixups_32.c
index 8b30b26..1a07bbe 100644
(geode_gpio(3)|geode_gpio(4), ...)
will only return true iff both GPIOs are set.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/geode_32.c b/arch/x86/kernel/geode_32.c
index f12d8c5..9c7f7d3 100644
--- a/arch/x86/kernel/geode_32.c
+++ b/arch/x86/kernel/geode_32.c
@@ -1,6 +1,7
On Thu, 18 Oct 2007 15:51:24 +0200
Florian Fainelli [EMAIL PROTECTED] wrote:
This patch adds the generic GPIO support to the x86
architecture. We do the same as for MIPS, we let
the machine override the gpio callbacks and provide
defaults one in mach-generic.
[...]
+
+int
On Tue, 21 Aug 2007 18:21:55 +0200 (CEST)
Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Tue, 21 Aug 2007, Andres Salomon wrote:
I would really like to avoid another input mode.
I think it be better to implement this as a combination of -s -D
default and the silent mode is adjusted
. For example, 'conf -n -y foo'
is perfectly valid now (input_mode will be set_yes). Previously, that
would have been an error (can't find file -y).
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
scripts/kconfig/conf.c | 28 +---
1 files changed, 13 insertions
On Fri, 19 Oct 2007 14:01:56 +0200
Florian Fainelli [EMAIL PROTECTED] wrote:
Hi Andres,
Le jeudi 18 octobre 2007, Andres Salomon a écrit :
While I certainly would like to see a generic GPIO API, this one
isn't really useful for geode GPIOs. It would be nice to have one
that did work
Thanks for Cc'ing me. I just tested this on an XO-1, and it doesn't
appear to break anything. So, looks fine to me.
Acked-by: Andres Salomon dilin...@queued.net
On Mon, 24 Sep 2012 16:27:19 -0700 H. Peter
Anvin h...@linux.intel.com wrote:
From: H. Peter Anvin h...@linux.intel.com
%cr4
-by: Andres Salomon [EMAIL PROTECTED]
Em Qua, 2007-09-19 às 01:44 -0400, Andres Salomon escreveu:
By default, we allocate DMA buffers when actually reading from the video
capture device. On a system with 128MB or 256MB of ram, it's very easy
for that memory to quickly become fragmented
reports from someone with a 5535.
--
Andres Salomon [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
master DMA, and unsetting it when we tear down the BM's DMA.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
sound/pci/cs5535audio/cs5535audio_pcm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/pci/cs5535audio/cs5535audio_pcm.c
b/sound/pci/cs5535audio
to the 5536
data sheet, section 5.3.7.4, power-down procedure). This patch reworks
all that to first disable DMA, and then save PRD registers.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
sound/pci/cs5535audio/cs5535audio.h |1 -
sound/pci/cs5535audio/cs5535audio_pcm.c |2 --
sound
Save the PCI state before disabling the device, and add some error checking.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
sound/pci/cs5535audio/cs5535audio_pm.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/sound/pci/cs5535audio/cs5535audio_pm.c
b
ACcording to 6.3.2.7 of the cs5535/cs5536 data sheets, the ACC_BM[x]_CMD
registers are only 8 bits wide. This driver treats them as 32 bits wide,
and also has bits in the wrong place. Simple fix to the definitions.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
sound/pci/cs5535audio
-by: Andres Salomon [EMAIL PROTECTED]
---
sound/pci/cs5535audio/cs5535audio.c | 24 +++-
sound/pci/cs5535audio/cs5535audio.h | 31 +--
2 files changed, 4 insertions(+), 51 deletions(-)
diff --git a/sound/pci/cs5535audio/cs5535audio.c
b/sound/pci
On Tue, 14 Aug 2007 20:23:23 +0200
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Tuesday, 14 August 2007 12:39, Pavel Machek wrote:
Hi!
Thanks, updated below!
serial: turn serial console suspend a boot rather than compile time option
From: Andres Salomon [EMAIL
it for strings; I'm
assuming that we don't actually care about i18n in conf.c, and that the
_() stuff was just copied from elsewhere. If that's not the case, I
can update the patch to wrap strings properly.
Comments/suggestions/critique welcome.
Signed-off-by: Andres Salomon [EMAIL
On Tue, 21 Aug 2007 17:29:36 +0200 (CEST)
Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Mon, 20 Aug 2007, Andres Salomon wrote:
AFAICT, there is nothing similar when using *_defconfig; one must copy
a .config manually, and then run silentoldconfig. Simply running the
associated
, and don't feel that it
increases bloat. If people strongly disagree, let me know and I'll submit
the other patch.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt|8
Documentation/power/basic-pm-debugging.txt |4 ++--
arch/powerpc
On Wed, 8 Aug 2007 15:41:30 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 8 Aug 2007 18:35:35 -0400
Andres Salomon [EMAIL PROTECTED] wrote:
[...]
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -172,6 +172,8 @@ extern int __printk_ratelimit(int ratelimit_jiffies
On Wed, 8 Aug 2007 16:13:45 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 8 Aug 2007 19:07:13 -0400
Andres Salomon [EMAIL PROTECTED] wrote:
On Wed, 8 Aug 2007 15:41:30 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 8 Aug 2007 18:35:35 -0400
Andres Salomon [EMAIL
CC'ing lkml for relevance..
On Thu, 07 Jul 2005 03:08:18 -0400, David S.
Miller wrote:
From: Jurij Smakov [EMAIL PROTECTED]
Date: Thu, 7 Jul 2005 00:38:00 -0400 (EDT)
In fact, Debian is actively working on resolving this situation.
Keep defending yourselves. This was a disaster
On Thu, 07 Jul 2005 11:06:37 -0400, Andres Salomon wrote:
[...]
like this one. And no, ladies and gentlemen; the GPL is *not* a valid
license for binary firmware. The key wording here is The source code for
I should be more explicit; I'm talking about binary-only firmware.
Obviously
Clearly I picked a bad week to go on vacation..
On Fri, 04 Mar 2005
10:18:41 -0800, Linus Torvalds wrote:
[...]
Alan, I think your problem is that you really think that the tree _I_ want
is what _you_ want.
I look at this from a _layering_ standpoint. Not from a stable tree
standpoint
On Thu, 03 Mar 2005 23:15:03 +0100, Adrian Bunk wrote:
On Thu, Mar 03, 2005 at 04:28:52PM -0500, Jeff Garzik wrote:
Bill Rugolsky Jr. wrote:
I've watched you periodically announce hey, I'm doing an update for
FC3/FC2, please test on the mail list, and a handful of people go test.
If we could
On Sat, 05 Mar 2005 11:43:05 +0100, Andries Brouwer wrote:
On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
Anything else anyone can think of? Any objections to any of these?
I based them off of Linus's original list.
thanks,
greg k-h
--
Rules on what kind of patches
and it must _not_ contain anything else,
such as 'trivial' fixes.
is _obviously_ not the same as:
It must fix a problem.
(Notice how quickly even the obvious becomes unobvious ...;).
--
Andres Salomon [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed
On Sun, 2005-03-06 at 15:10 -0500, Adam Kropelin wrote:
Andres Salomon [EMAIL PROTECTED] wrote:
On Sat, 05 Mar 2005 11:43:05 +0100, Andries Brouwer wrote:
On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
- It must fix a real bug that bothers people (not a, This could
:49 GMT Andres Salomon [EMAIL PROTECTED] patch-155
Summary:
tag 2.6.10-as7
Revision:
linux--dilinger--0--patch-155
modified files:
000-extraversion.patch
2005-03-10 21:50:21 GMT Andres Salomon [EMAIL PROTECTED] patch-154
Summary:
144
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:
[...]
Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
==
[...]
Andres Salomon:
o Possible AMD8111e free irq issue
o Possible VIA-Rhine free irq issue
Those two were
On Mon, 04 Apr 2005 20:44:17 +0100, Paulo Marques wrote:
Hi,
This patch creates a new kstrdup library function and changes the
local implementations in several places to use this function.
This is just a cleanup to allow reusing the strdup code, and to prevent
bugs in future
, and not send me
anything but clear bug-fixes etc. We're definitely well into -rc land. So
keep it quiet out there,
Linus
Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
==
[...]
Andres Salomon:
o Possible AMD8111e free
, and not send me
anything but clear bug-fixes etc. We're definitely well into -rc land. So
keep it quiet out there,
Linus
Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
==
[...]
Andres Salomon:
o Possible AMD8111e free
On Tue, 05 Apr 2005 11:39:02 +0200, Christoph Hellwig wrote:
On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
One of the options is to even ship the firmware in the kernel tarbal but
from a separate directory with a clear license clarification text in it.
I think that's
/~dilinger/patches/2.6.10/as5/
4c44b02bb9fe6295bb683e364604d74f ChangeLog
72421ac55f99af28e0bae87b948a241e linux-2.6.10-as5.tar.gz
1a9c1a7ec584c67a91c307ce8169f164 patch-2.6.10-as5.gz
Changes from 2.6.10-as3:
2005-02-23 02:58:11 GMT Andres Salomon [EMAIL PROTECTED] patch-131
Summary
/patches/2.6.10/as6/
27354299d1a76c69c2d8bca60dea9646 ChangeLog
cad896bc0a7a256c124a0a83f7d4d6f1 linux-2.6.10-as6.tar.gz
c8085158617f9f10a831bb1eae15dc31 patch-2.6.10-as6.gz
Changes from 2.6.10-as5:
2005-02-26 07:40:27 GMT Andres Salomon [EMAIL PROTECTED] patch-152
Summary:
tag
7457076a2c54af9f534ed053fb3e42de linux-2.6.10-as3.tar.gz
87ce1ab9312837b4bb35d490abbfba7e patch-2.6.10-as3.gz
Changes from 2.6.10-as2:
2005-02-01 07:48:41 GMT Andres Salomon [EMAIL PROTECTED] patch-90
Summary:
tag 2.6.10-as3
Revision:
linux--dilinger--0--patch-90
modified files
are the changes from 2.6.10-as1:
2005-01-16 05:02:31 GMT Andres Salomon [EMAIL PROTECTED] patch-52
Summary:
tag 2.6.10-as2
Revision:
linux--dilinger--0--patch-52
modified files:
000-extraversion.patch
2005-01-16 05:01:53 GMT Andres Salomon [EMAIL
The OLPC EC (Embedded Controller) code that is currently upstream is
x86-only, originally written for the XO-1. Since then, we've had the
XO-1.5 (also x86), and XO-1.75 (arm-based) enter mass production. The
1.75 uses a vastly different EC protocol, and future hardware revisions
are likely to
The OLPC EC driver has outgrown arch/x86/platform/. It's time to both
share common code amongst different architectures, as well as move it out
of arch/x86/. The XO-1.75 is ARM-based, and the EC driver shares a lot of
code with the x86 code.
Signed-off-by: Andres Salomon dilin...@queued.net
Switch over to using olpc-ec.h in multiple steps, so as not to break
builds. This covers every driver that calls olpc_ec_cmd().
Signed-off-by: Andres Salomon dilin...@queued.net
---
arch/x86/include/asm/olpc.h|1 -
arch/x86/platform/olpc/olpc-xo1-pm.c |1 +
arch/x86
, and
they will by serialized and sleep while only one executes on the EC at a time.
We don't provide an unregister function, as that doesn't make sense within
the context of OLPC machines - there's only ever 1 EC, it's critical to
functionality, and it certainly not hotpluggable.
Signed-off-by: Andres
-by: Andres Salomon dilin...@queued.net
---
drivers/platform/olpc/olpc-ec.c | 46
++- 1 files changed, 45
insertions(+), 1 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c
b/drivers/platform/olpc/olpc-ec.c index d00523c..cfba41f 100644
--- a/drivers
This uses the new EC driver framework in drivers/platform/olpc. The
XO-1 and XO-1.5-specific code is still in arch/x86, but the generic
stuff (including a new workqueue; no more running EC commands with IRQs
disabled!) can be shared with other architectures.
Signed-off-by: Andres Salomon dilin
There's nothing about the debugfs interface for the EC driver that is
architecture-specific, so move it into the arch-independent driver.
The code is mostly unchanged with the exception of renamed variables,
coding style changes, and API updates.
Signed-off-by: Andres Salomon dilin...@queued.net
Populate olpc_ec_priv.
Signed-off-by: Andres Salomon dilin...@queued.net
---
drivers/platform/olpc/olpc-ec.c | 48
++ 1 files changed, 28
insertions(+), 20 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c
b/drivers/platform/olpc/olpc-ec.c index
The new EC driver calls platform-specific suspend and resume hooks; run
XO-1-specific EC commands from there, rather than deep in s/r code. If
we attempt to run EC commands after the new EC driver has suspended, it
is refused by the ec-suspended checks.
Signed-off-by: Andres Salomon dilin
the EC's resume hooks earlier than other drivers (which may want to run EC
commands).
Signed-off-by: Andres Salomon dilin...@queued.net
---
drivers/platform/olpc/olpc-ec.c | 48 +++
include/linux/olpc-ec.h |6 +
2 files changed, 54 insertions(+), 0
Damnit, my mailer mangled the resend. Okay, 3rd time's a charm..
(sorry for the noise!)
On Wed, 18 Jul 2012 21:28:27 -0700
Andres Salomon dilin...@queued.net wrote:
This uses the new EC driver framework in drivers/platform/olpc. The
XO-1 and XO-1.5-specific code is still in arch/x86
The OLPC EC (Embedded Controller) code that is currently upstream is
x86-only, originally written for the XO-1. Since then, we've had the
XO-1.5 (also x86), and XO-1.75 (arm-based) enter mass production. The
1.75 uses a vastly different EC protocol, and future hardware revisions
are likely to
The OLPC EC driver has outgrown arch/x86/platform/. It's time to both
share common code amongst different architectures, as well as move it out
of arch/x86/. The XO-1.75 is ARM-based, and the EC driver shares a lot of
code with the x86 code.
Signed-off-by: Andres Salomon dilin...@queued.net
Switch over to using olpc-ec.h in multiple steps, so as not to break builds.
This covers every driver that calls olpc_ec_cmd().
Signed-off-by: Andres Salomon dilin...@queued.net
---
arch/x86/include/asm/olpc.h|1 -
arch/x86/platform/olpc/olpc-xo1-pm.c |1 +
arch/x86
, and
they will by serialized and sleep while only one executes on the EC at a time.
We don't provide an unregister function, as that doesn't make sense within
the context of OLPC machines - there's only ever 1 EC, it's critical to
functionality, and it certainly not hotpluggable.
Signed-off-by: Andres
the EC's resume hooks earlier than other drivers (which may want to run EC
commands).
Signed-off-by: Andres Salomon dilin...@queued.net
---
drivers/platform/olpc/olpc-ec.c | 48 +++
include/linux/olpc-ec.h |6 +
2 files changed, 54 insertions(+), 0
-off-by: Andres Salomon dilin...@queued.net
---
drivers/platform/olpc/olpc-ec.c | 46 ++-
1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index d00523c..cfba41f 100644
--- a/drivers
This uses the new EC driver framework in drivers/platform/olpc. The
XO-1 and XO-1.5-specific code is still in arch/x86, but the generic stuff
(including a new workqueue; no more running EC commands with IRQs disabled!)
can be shared with other architectures.
Signed-off-by: Andres Salomon dilin
1 - 100 of 293 matches
Mail list logo
