/gmane.linux.ports.arm.omap/125020
Hi,
Sorry for the delay. I've reviewed the patch series and it looks fine on
my side :-)
Reviewed-by: Éric Piel eric.p...@tremplin-utc.net
Greg, if that's good with you, please take this patch series in your tree.
Cheers,
Éric
--
To unsubscribe from this list: send
lfring <elfr...@users.sourceforge.net>
Thanks, looks fine.
Signed-off-by: Éric Piel <eric.p...@tremplin-utc.net>
Maybe the "Kernel Janitors" can just pick it up?
Cheers,
Éric
---
drivers/misc/lis3lv02d/lis3lv02d.c | 5 +
1 file changed, 1 insertion(+), 4 deleti
... but it looks completely fine :-)
Signed-off-by: Éric Piel
Darren, would you wind picking up this patch via your tree?
Cheers,
Éric
---
drivers/platform/x86/hp_accel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/hp_accel.c b/drivers/platform/x86/hp_accel.c
index
t:
>
> [0] Documentation/devicetree/bindings/misc/lis302.txt
> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/125020
Hi,
Sorry for the delay. I've reviewed the patch series and it looks fine on
my side :-)
Reviewed-by: Éric Piel
Greg, if that's good with you, please take this
. If Dmitry thinks the
behaviour is fine then I've got nothing more to say :-)
Reviewed-by: Éric Piel
Darren, could you pick up this patch in your tree?
Cheers,
Éric
---
Changes in v2:
* Remove a unnecessary deletion of a blank line
* Move #includes of i8042.h and serio.h before the relative
On 22/10/14 15:20, Giedrius Statkevicius wrote:
:
> My questions are these:
> - Does any system with the accelerometer whose ACPI id is HPQ0004 or
> HPQ6007 run into the same issues?
> - If so, what are the scancodes reported by atkbd?
> - If not, then where can I find some documentation to find
On 15/04/14 01:55, Luis Henriques wrote:
>
> (Cc'ing both lis3lv02d and ACPI maintainers)
>
> Since commit 188a81409ff7de1c5aae947a96356ddd8ff4aaa3 ("percpu: add
> preemption checks to __this_cpu ops") I've been seeing the following:
Hi,
I've had a quick look at the lis3lv02d_acpi_read() (in
This patch adds support for mail and wifi leds. It modifies the Kconfig
file to automatically pull led_class with wistron_btns, hopefully
everyone is fine with this.
Eric
From: Eric Piel [EMAIL PROTECTED]
wriston_btns: Add led support
Add support to wistron_btns for leds that comes with the
18.04.2007 06:25, Dmitry Torokhov wrote/a écrit:
On Saturday 14 April 2007 12:09, Éric Piel wrote:
This patch adds support for mail and wifi leds. It modifies the Kconfig
file to automatically pull led_class with wistron_btns, hopefully
everyone is fine with this.
Was there 1/2 file
Hello,
The following two patches are against the input tree and improve the
wistron_btns driver.
The first patch is mostly trivial, it fixes a typo that I introduced in
the previous batch.
The second patch adds led support to the driver (and therefore also
dependency on the led class).
See
This fix a typo on the TM610 definition, inserted in my recent patch
add-acerhk-database.
Eric
From: Eric Piel [EMAIL PROTECTED]
wriston_btns: Fix typo for TM610
I did a typo in a previous patch for wistron_btns add acerhk database. This
patch fixes this typo that prevented PROG2 key to work.
This patch adds support for mail and wifi leds. It modifies the Kconfig
file to automatically pull led_class with wistron_btns, hopefully
everyone is fine with this.
It doesn't add support for bluetooth led because, so far, it seems all
the laptops with bluetooth have led and bluetooth system
03/14/2007 02:54 PM, Dmitry Torokhov wrote/a écrit:
Hi Eric,
:
I have couple of comments/requests:
1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the
lid, they correspond to Accpication Control Open and Close keys from
USB HID HUT spec:
03/14/2007 08:02 PM, Dmitry Torokhov wrote/a écrit:
On 3/14/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 3/14/07, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Wed, Mar 14, 2007 at 09:54:27AM -0400, Dmitry Torokhov wrote:
Hi Eric,
2. I also have a concern about using KEY_SCREEN to signal
03/14/2007 08:02 PM, Vojtech Pavlik wrote/a écrit:
On Wed, Mar 14, 2007 at 02:58:49PM -0400, Dmitry Torokhov wrote:
2. I also have a concern about using KEY_SCREEN to signal toggling
display on and off. I am CCing Vojtech - he must know what the
original intent of this key code was. BTW, when
02/17/2007 04:55 AM, Markus Rechberger wrote/a écrit:
Hi Eric,
I committed your code to linuxtv.org to review and modify it there.
http://linuxtv.org/hg/~mrechberger/chipcardreader
one thing I noticed is the error handling in ozscr_probe.
I'll continue the rest during the next few days, I'd
This patch declares keymaps as initdata, so they are discarded at
runtime, saving about 1kb (10% of the module size). This idea to save
memory comes from Dmitry Torokhov.
Eric
From: Eric Piel [EMAIL PROTECTED]
wriston_btns: Declare keymaps as initdata
As the number of keymaps increases and
This patch adds all the tm_new laptops information that is in acerhk
to wistron_btns. That's about 25 more laptops. Obviously, I couldn't try
them all. I've just tried the Aspire 3020. For this reason, I've also
added a printk which ask the users of those laptops to confirm me it
works (or
This patch adds a generic map. That is, a keymap that should output the
correct keycodes for most laptops. This is simply based on the
observation of all those keymaps already gathered, as most of the
wistron codes are always mapped to the same keycode.
Hopefully, this way users which have a
Hello,
This is a new version of my patch to add support for more laptops to the
wistron_btns driver. Modifications from the previous version:
* sends lid close/open event as a switch event (not a key event)
* Display on/off is KEY_SCREEN and Display selection is
KEY_SWITCHVIDEOMODE, from the
19.03.2007 22:28, Dmitry Torokhov wrote/a écrit:
On 3/15/07, Éric Piel [EMAIL PROTECTED] wrote:
Ok, so let me summarize:
There are two kinds of keys on those laptops (for which we are not sure
about the keycode that it should generate):
* Laptop screen on/off
* Display output selection
03/06/2007 02:36 PM, Dmitry Torokhov wrote/a écrit:
Hi Eric,
I believe we have KEY_WLAN for Wifi, not KEY_XFER. I will fix that up.
Oh! Yes, this sounds better, I used KEY_XFER just for historical reasons
;-) Thanks
I'm sending just this one for now (as I can test it) but if you like it,
04/04/2007 02:34 AM, Karl Pickett wrote/a écrit:
The ati_remote driver is a little too sensitive for my wife... if you
do anything but barely tap the button you can get multiple events
reported. We prefer a more conservative no-repeat setting. This is a
pretty trivial patch which just makes
04/04/2007 10:52 PM, Vincent Vanackere wrote/a écrit:
:
I'm attaching a very small adaptation of your patch (re-added the
repeat_count check and a small comment, compile run-time tested).
Works fine for me...
--- drivers/usb/input/ati_remote.c.orig 2007-04-04 22:05:10.0 +0200
+++
11/02/08 14:47, Sergey Vlasov wrote/a écrit:
On Sun, 10 Feb 2008 12:58:09 +0100 Eric Piel wrote:
I guess the problem that Linus solved by moving populate_rootfs()
happens only rarely or on only few configurations. Linus, do you
remember what kind of problem it was? How can I reproduce it?
13/02/08 22:30, Adrian Bunk wrote/a écrit:
acpi_no_initrd_override_setup() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Oh, indeed, no one else uses this function.
Acked-by: Eric Piel [EMAIL PROTECTED]
---
1778953a9751288a9bee1d4f6a8b4f3d22e37f52 diff --git
for taking so long to review your patch. Overall, it looks great :-)
There are just a few points that almost code-style/comment that needs to
be fixed. See below. Could you fix these small issues, and submit a new
patch for Andrew to pick it in his queue?
Here is my:
Reviewed-by: Éric Piel
25/08/07 12:49, James Bruce wrote/a écrit:
Robert Hancock wrote:
Casey Dahlin wrote:
Most USB keys nowadays have a small LED somewhere inside of them that
lights up when they are plugged in. On a windows box, the key is lit
up whenever it is mounted, and as soon as it is unmounted it turns
[re-CC'ing lkml as it's back to the original topic]
26.04.2007 17:50, Dmitry Torokhov wrote/a écrit:
On 4/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
From: Eric Piel [EMAIL PROTECTED]
Add support to wistron_btns for leds that comes with the multimedia keys.
Mail and wifi leds are
On 08-03-13 23:59, Shuah Khan wrote:
:
Should this be tagged for stables releases? This patch went into suse
git and just checking to see if it should go into stable releases.
Hello,
This patch will make the module automatically load on some new HP
laptops. So although it's not fixing a bug,
, so indeed it should work fine.
Thanks for the patch, here is my:
Acked-by: Éric Piel eric.p...@tremplin-utc.net
Matthew, could you pick this patch into your tree?
Cheers,
Éric
---
drivers/platform/x86/hp_accel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86
01/19/2007 04:57 AM, Atsushi Nemoto wrote/a écrit:
On Fri, 19 Jan 2007 12:19:10 +0900 (JST), Atsushi Nemoto [EMAIL PROTECTED]
wrote:
OK, here is a revised patch which uses pci= option instead of config
parameters.
Sorry, this patch would cause build failure if setup-bus.c was not
built into
On 07-08-12 20:49, Daniel Mack wrote:
:
I fixed all these issues now and attached a v4.
Sorry for the late reply, I had read the v3 but didn't find time to send
comments. They are all addressed in v4.
For both [PATCH v4 1/2] and [PATCH v3 2/2], here is my:
Reviewed-by: Éric Piel eric.p
12/02/08 06:37, Christoph Hellwig wrote/a écrit:
[skipping the populate_rootfs discussion as it seems you have a better
handle on that than me]
On Sun, Feb 10, 2008 at 12:58:09PM +0100, Eric Piel wrote:
And while we're at it the file reading thing in there is utter crap
aswell. You really
12/02/08 00:41, Éric Piel wrote/a écrit:
11/02/08 14:47, Sergey Vlasov wrote/a écrit:
Would that seem an acceptable solution? Or what other way exists?
Disabling call_usermodehelper() until all core initializers had
completed would fix the problem too; will such change be acceptable?
Yes
21/02/08 20:04, Christoph Hellwig wrote/a écrit:
On Thu, Feb 21, 2008 at 08:02:36PM +0100, Eric Piel wrote:
It's been a week and no one has screamed, so I guess the idea looks fine
to everyone :-)
Here is a boot tested patch for integration. In addition to the previous
version, it removes
21/02/08 20:02, Éric Piel wrote/a écrit:
12/02/08 00:41, Éric Piel wrote/a écrit:
11/02/08 14:47, Sergey Vlasov wrote/a écrit:
Would that seem an acceptable solution? Or what other way exists?
Disabling call_usermodehelper() until all core initializers had
completed would fix the problem too
21/02/08 19:46, Éric Piel wrote/a écrit:
In the mean time, here is a patch which should get the situation already
much cleaner. It has been tested on various configs (with and without
DSDT). Let me know if you think it is acceptable.
It seems the patch looks ok for people around so here
24/02/08 02:31, Christoph Hellwig wrote/a écrit:
On Sat, Feb 23, 2008 at 12:45:38PM -0800, Linus Torvalds wrote:
As recommended by Christoph Hellwig, even if we can't rely on the userspace
firmware loader so early at boot, at least use normal syscall (as in
init/do_mounts_*.c). Similarly, use
06/01/2007 04:20 PM, DervishD wrote/a écrit:
Hi all :)
Hi!
Will the console work as it works now if I can live with latin1
accented characters only?
Just tested here, it _seems_ to work right on the console with Spanish
and French accentuated characters.
Is there any terminal
06/04/2007 01:24 PM, Pavel Machek wrote/a écrit:
Hi!
I started getting blinking capslock leds in 2.6.22-somewhere. Every 5
seconds or so, capslock led toggles on thinkpad x60. Ouch.
Could it be related to commit f038f9a361a764ed013447174b7170073f89cbe9
aka Add keyboard blink driver ? Probably
Hello,
I'm usually not a fashion victim, but I felt into the trap this time:
I've launched powertop. As I noticed that wistron_btns was part of the
topers (10 wake-up's per seconds), here is a patch that should reduce
the problem. The driver now polls the hardware only twice per second.
/platform/x86/hp_accel.c:132:5: warning: no previous prototype for
‘lis3lv02d_acpi_write’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria rashika.khe...@gmail.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
Yes, looks fine.
Signed-off-by: Éric Piel eric.p...@tremplin-utc.net
Matthew
On 15/04/14 01:55, Luis Henriques wrote:
(Cc'ing both lis3lv02d and ACPI maintainers)
Since commit 188a81409ff7de1c5aae947a96356ddd8ff4aaa3 (percpu: add
preemption checks to __this_cpu ops) I've been seeing the following:
Hi,
I've had a quick look at the lis3lv02d_acpi_read() (in
On 22/10/14 15:20, Giedrius Statkevicius wrote:
:
My questions are these:
- Does any system with the accelerometer whose ACPI id is HPQ0004 or
HPQ6007 run into the same issues?
- If so, what are the scancodes reported by atkbd?
- If not, then where can I find some documentation to find
,
Looks fine with respect to the hp accel driver. If Dmitry thinks the
behaviour is fine then I've got nothing more to say :-)
Reviewed-by: Éric Piel eric.p...@tremplin-utc.net
Darren, could you pick up this patch in your tree?
Cheers,
Éric
---
Changes in v2:
* Remove a unnecessary deletion
...@vger.kernel.org
Signed-off-by: Takashi Iwai ti...@suse.de
Sorry, it got a be delayed... but it looks completely fine :-)
Signed-off-by: Éric Piel eric.p...@tremplin-utc.net
Darren, would you wind picking up this patch via your tree?
Cheers,
Éric
---
drivers/platform/x86/hp_accel.c | 1 +
1 file changed
03/14/2007 02:54 PM, Dmitry Torokhov wrote/a écrit:
Hi Eric,
:
I have couple of comments/requests:
1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the
lid, they correspond to Accpication Control Open and Close keys from
USB HID HUT spec:
03/14/2007 08:02 PM, Dmitry Torokhov wrote/a écrit:
On 3/14/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
On 3/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 14, 2007 at 09:54:27AM -0400, Dmitry Torokhov wrote:
> > Hi Eric,
> >
> > 2. I also have a concern about using
03/14/2007 08:02 PM, Vojtech Pavlik wrote/a écrit:
On Wed, Mar 14, 2007 at 02:58:49PM -0400, Dmitry Torokhov wrote:
2. I also have a concern about using KEY_SCREEN to signal toggling
display on and off. I am CCing Vojtech - he must know what the
original intent of this key code was. BTW, when
This patch declares keymaps as initdata, so they are discarded at
runtime, saving about 1kb (10% of the module size). This idea to save
memory comes from Dmitry Torokhov.
Eric
From: Eric Piel <[EMAIL PROTECTED]>
wriston_btns: Declare keymaps as initdata
As the number of keymaps increases and
This patch adds all the "tm_new" laptops information that is in acerhk
to wistron_btns. That's about 25 more laptops. Obviously, I couldn't try
them all. I've just tried the Aspire 3020. For this reason, I've also
added a printk which ask the users of those laptops to confirm me it
works (or
This patch adds a generic map. That is, a keymap that should output the
correct keycodes for most laptops. This is simply based on the
observation of all those keymaps already gathered, as most of the
wistron codes are always mapped to the same keycode.
Hopefully, this way users which have a
Hello,
This is a new version of my patch to add support for more laptops to the
wistron_btns driver. Modifications from the previous version:
* sends lid close/open event as a switch event (not a key event)
* Display on/off is KEY_SCREEN and Display selection is
KEY_SWITCHVIDEOMODE, from the
19.03.2007 22:28, Dmitry Torokhov wrote/a écrit:
On 3/15/07, Éric Piel <[EMAIL PROTECTED]> wrote:
Ok, so let me summarize:
There are two kinds of keys on those laptops (for which we are not sure
about the keycode that it should generate):
* Laptop screen on/off
* Display output sel
04/04/2007 02:34 AM, Karl Pickett wrote/a écrit:
The ati_remote driver is a little too sensitive for my wife... if you
do anything but barely tap the button you can get multiple events
reported. We prefer a more conservative no-repeat setting. This is a
pretty trivial patch which just makes
04/04/2007 10:52 PM, Vincent Vanackere wrote/a écrit:
:
I'm attaching a very small adaptation of your patch (re-added the
repeat_count check and a small comment, compile & run-time tested).
Works fine for me...
--- drivers/usb/input/ati_remote.c.orig 2007-04-04 22:05:10.0 +0200
+++
03/06/2007 02:36 PM, Dmitry Torokhov wrote/a écrit:
Hi Eric,
I believe we have KEY_WLAN for Wifi, not KEY_XFER. I will fix that up.
Oh! Yes, this sounds better, I used KEY_XFER just for historical reasons
;-) Thanks
I'm sending just this one for now (as I can test it) but if you like it,
01/19/2007 04:57 AM, Atsushi Nemoto wrote/a écrit:
On Fri, 19 Jan 2007 12:19:10 +0900 (JST), Atsushi Nemoto <[EMAIL PROTECTED]>
wrote:
OK, here is a revised patch which uses pci= option instead of config
parameters.
Sorry, this patch would cause build failure if setup-bus.c was not
built
02/17/2007 04:55 AM, Markus Rechberger wrote/a écrit:
Hi Eric,
I committed your code to linuxtv.org to review and modify it there.
http://linuxtv.org/hg/~mrechberger/chipcardreader
one thing I noticed is the error handling in ozscr_probe.
I'll continue the rest during the next few days, I'd
[re-CC'ing lkml as it's back to the original topic]
26.04.2007 17:50, Dmitry Torokhov wrote/a écrit:
On 4/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
From: Eric Piel <[EMAIL PROTECTED]>
Add support to wistron_btns for leds that comes with the multimedia keys.
Mail and wifi leds are
This patch adds support for mail and wifi leds. It modifies the Kconfig
file to automatically pull led_class with wistron_btns, hopefully
everyone is fine with this.
Eric
From: Eric Piel <[EMAIL PROTECTED]>
wriston_btns: Add led support
Add support to wistron_btns for leds that comes with the
18.04.2007 06:25, Dmitry Torokhov wrote/a écrit:
On Saturday 14 April 2007 12:09, Éric Piel wrote:
This patch adds support for mail and wifi leds. It modifies the Kconfig
file to automatically pull led_class with wistron_btns, hopefully
everyone is fine with this.
Was there 1/2 file
Hello,
The following two patches are against the input tree and improve the
wistron_btns driver.
The first patch is mostly trivial, it fixes a typo that I introduced in
the previous batch.
The second patch adds led support to the driver (and therefore also
dependency on the led class).
See
This fix a typo on the TM610 definition, inserted in my recent patch
"add-acerhk-database".
Eric
From: Eric Piel <[EMAIL PROTECTED]>
wriston_btns: Fix typo for TM610
I did a typo in a previous patch for wistron_btns "add acerhk database". This
patch fixes this typo that prevented PROG2 key to
This patch adds support for mail and wifi leds. It modifies the Kconfig
file to automatically pull led_class with wistron_btns, hopefully
everyone is fine with this.
It doesn't add support for bluetooth led because, so far, it seems all
the laptops with bluetooth have led and bluetooth system
06/04/2007 01:24 PM, Pavel Machek wrote/a écrit:
Hi!
I started getting blinking capslock leds in 2.6.22-somewhere. Every 5
seconds or so, capslock led toggles on thinkpad x60. Ouch.
Could it be related to commit f038f9a361a764ed013447174b7170073f89cbe9
aka "Add keyboard blink driver" ?
Hello,
I'm usually not a fashion victim, but I felt into the trap this time:
I've launched powertop. As I noticed that wistron_btns was part of the
topers (10 wake-up's per seconds), here is a patch that should reduce
the problem. The driver now polls the hardware only twice per second.
06/01/2007 04:20 PM, DervishD wrote/a écrit:
Hi all :)
Hi!
Will the console work as it works now if I can live with latin1
accented characters only?
Just tested here, it _seems_ to work right on the console with Spanish
and French accentuated characters.
Is there any terminal
25/08/07 12:49, James Bruce wrote/a écrit:
Robert Hancock wrote:
Casey Dahlin wrote:
Most USB keys nowadays have a small LED somewhere inside of them that
lights up when they are plugged in. On a windows box, the key is lit
up whenever it is mounted, and as soon as it is unmounted it turns
/platform/x86/hp_accel.c:132:5: warning: no previous prototype for
‘lis3lv02d_acpi_write’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
Yes, looks fine.
Signed-off-by: Éric Piel
Matthew, could you pick this patch up in the platform-driver-x86 branch
so indeed it should work fine.
Thanks for the patch, here is my:
Acked-by: Éric Piel
Matthew, could you pick this patch into your tree?
Cheers,
Éric
---
drivers/platform/x86/hp_accel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/hp_accel.c b/drivers/platform/x86/
On 08-03-13 23:59, Shuah Khan wrote:
:
Should this be tagged for stables releases? This patch went into suse
git and just checking to see if it should go into stable releases.
Hello,
This patch will make the module automatically load on some new HP
laptops. So although it's not fixing a bug,
-off-by: Éric Piel
Maybe the "Kernel Janitors" can just pick it up?
Cheers,
Éric
---
drivers/misc/lis3lv02d/lis3lv02d.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index e4
11/02/08 14:47, Sergey Vlasov wrote/a écrit:
> On Sun, 10 Feb 2008 12:58:09 +0100 Eric Piel wrote:
>
>> I guess the problem that Linus solved by moving populate_rootfs()
>> happens only rarely or on only few configurations. Linus, do you
>> remember what kind of problem it was? How can I
13/02/08 22:30, Adrian Bunk wrote/a écrit:
> acpi_no_initrd_override_setup() can become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Oh, indeed, no one else uses this function.
Acked-by: Eric Piel <[EMAIL PROTECTED]>
>
> ---
> 1778953a9751288a9bee1d4f6a8b4f3d22e37f52 diff --git
for taking so long to review your patch. Overall, it looks great :-)
There are just a few points that almost code-style/comment that needs to
be fixed. See below. Could you fix these small issues, and submit a new
patch for Andrew to pick it in his queue?
Here is my:
Reviewed-by: Éric Piel
On 07-08-12 20:49, Daniel Mack wrote:
:
I fixed all these issues now and attached a v4.
Sorry for the late reply, I had read the v3 but didn't find time to send
comments. They are all addressed in v4.
For both [PATCH v4 1/2] and [PATCH v3 2/2], here is my:
Reviewed-by: Éric Piel
Cheers
12/02/08 06:37, Christoph Hellwig wrote/a écrit:
> [skipping the populate_rootfs discussion as it seems you have a better
> handle on that than me]
>
> On Sun, Feb 10, 2008 at 12:58:09PM +0100, Eric Piel wrote:
>>> And while we're at it the file reading thing in there is utter crap
>>> aswell.
12/02/08 00:41, Éric Piel wrote/a écrit:
> 11/02/08 14:47, Sergey Vlasov wrote/a écrit:
>>> Would that seem an acceptable solution? Or what other way exists?
>> Disabling call_usermodehelper() until all core initializers had
>> completed would fix the problem too; will s
21/02/08 20:04, Christoph Hellwig wrote/a écrit:
> On Thu, Feb 21, 2008 at 08:02:36PM +0100, Eric Piel wrote:
>> It's been a week and no one has screamed, so I guess the idea looks fine
>> to everyone :-)
>>
>> Here is a boot tested patch for integration. In addition to the previous
>> version,
21/02/08 20:02, Éric Piel wrote/a écrit:
> 12/02/08 00:41, Éric Piel wrote/a écrit:
>> 11/02/08 14:47, Sergey Vlasov wrote/a écrit:
>>>> Would that seem an acceptable solution? Or what other way exists?
>>> Disabling call_usermodehelper() until all core initialize
21/02/08 19:46, Éric Piel wrote/a écrit:
> In the mean time, here is a patch which should get the situation already
> much cleaner. It has been tested on various configs (with and without
> DSDT). Let me know if you think it is acceptable.
>
It seems the patch looks ok for people ar
24/02/08 02:31, Christoph Hellwig wrote/a écrit:
> On Sat, Feb 23, 2008 at 12:45:38PM -0800, Linus Torvalds wrote:
>>> As recommended by Christoph Hellwig, even if we can't rely on the userspace
>>> firmware loader so early at boot, at least use normal syscall (as in
>>> init/do_mounts_*.c).
84 matches
Mail list logo
