Re: [PATCH] misc/lis3lv02d: Delete an error message for a failed memory allocation in lis3lv02d_init_device()
On 08/01/18 22:33, SF Markus Elfring wrote:
From: Markus Elfring <elfr...@users.sourceforge.net>
Date: Mon, 8 Jan 2018 22:26:06 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <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 deletions(-)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index e49888eab87d..ba2bd49c15fa 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -1172,11 +1172,8 @@ int lis3lv02d_init_device(struct lis3lv02d *lis3)
lis3->reg_cache = kzalloc(max(sizeof(lis3_wai8_regs),
sizeof(lis3_wai12_regs)), GFP_KERNEL);
-
- if (lis3->reg_cache == NULL) {
- printk(KERN_ERR DRIVER_NAME "out of memory\n");
+ if (!lis3->reg_cache)
return -ENOMEM;
- }
mutex_init(>mutex);
atomic_set(>wake_thread, 0);
Re: [PATCH] misc/lis3lv02d: Delete an error message for a failed memory allocation in lis3lv02d_init_device()
On 08/01/18 22:33, SF Markus Elfring wrote:
From: Markus Elfring
Date: Mon, 8 Jan 2018 22:26:06 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
Thanks, looks fine.
Signed-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 e49888eab87d..ba2bd49c15fa 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -1172,11 +1172,8 @@ int lis3lv02d_init_device(struct lis3lv02d *lis3)
lis3->reg_cache = kzalloc(max(sizeof(lis3_wai8_regs),
sizeof(lis3_wai12_regs)), GFP_KERNEL);
-
- if (lis3->reg_cache == NULL) {
- printk(KERN_ERR DRIVER_NAME "out of memory\n");
+ if (!lis3->reg_cache)
return -ENOMEM;
- }
mutex_init(>mutex);
atomic_set(>wake_thread, 0);
Re: [PATCHv2 0/4] [RESENT] lis3lv02d: update DT binding for use with Nokia N900
On 27/03/15 15:39, Sebastian Reichel wrote: > Hi, > > [Resent, since I forgot to sent this to drivers/misc > maintainers and had a small typo in my mail address] > > The lis302 has already a DT binding described in [0], > which descibes misc. hardware properties. The current > binding does not support all values needed to convert > the Nokia N900's platform data to DT, though. > > This patchset introduces support for describing inverted > axis, configuration of second wakeup unit and wakeup > threshold support. > > The series is based on top of v4.0-rc1 and has been > tested on my Nokia N900. > > Tony suggested [1], that the whole patchset should go > through Greg's tree: > >> This at least currently does not conflict with anything I have >> queued, so I suggest you try to get Greg to take the whole set: > > [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 patch series in your tree. Cheers, Éric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 0/4] [RESENT] lis3lv02d: update DT binding for use with Nokia N900
On 27/03/15 15:39, Sebastian Reichel wrote: Hi, [Resent, since I forgot to sent this to drivers/misc maintainers and had a small typo in my mail address] The lis302 has already a DT binding described in [0], which descibes misc. hardware properties. The current binding does not support all values needed to convert the Nokia N900's platform data to DT, though. This patchset introduces support for describing inverted axis, configuration of second wakeup unit and wakeup threshold support. The series is based on top of v4.0-rc1 and has been tested on my Nokia N900. Tony suggested [1], that the whole patchset should go through Greg's tree: This at least currently does not conflict with anything I have queued, so I suggest you try to get Greg to take the whole set: [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 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 the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hp_accel: Add support for HP ZBook 15
On 13-11-14 20:57, Takashi Iwai wrote:
From: Dominique Leuenberger
HP ZBook 15 laptop needs a non-standard mapping (x_inverted).
BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=905329
Signed-off-by: Dominique Leuenberger
Cc:
Signed-off-by: Takashi Iwai
Sorry, it got a be delayed... 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 13e14ec1d3d7..b268f4e48471 100644
--- a/drivers/platform/x86/hp_accel.c
+++ b/drivers/platform/x86/hp_accel.c
@@ -237,6 +237,7 @@ static const struct dmi_system_id lis3lv02d_dmi_ids[] = {
AXIS_DMI_MATCH("HPB64xx", "HP ProBook 64", xy_swap),
AXIS_DMI_MATCH("HPB64xx", "HP EliteBook 84", xy_swap),
AXIS_DMI_MATCH("HPB65xx", "HP ProBook 65", x_inverted),
+ AXIS_DMI_MATCH("HPZBook15", "HP ZBook 15", x_inverted),
{ NULL, }
/* Laptop models without axis info (yet):
* "NC6910" "HP Compaq 6910"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hp_accel: Add support for HP ZBook 15
On 13-11-14 20:57, Takashi Iwai wrote:
From: Dominique Leuenberger dims...@opensuse.org
HP ZBook 15 laptop needs a non-standard mapping (x_inverted).
BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=905329
Signed-off-by: Dominique Leuenberger dims...@opensuse.org
Cc: sta...@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, 1 insertion(+)
diff --git a/drivers/platform/x86/hp_accel.c b/drivers/platform/x86/hp_accel.c
index 13e14ec1d3d7..b268f4e48471 100644
--- a/drivers/platform/x86/hp_accel.c
+++ b/drivers/platform/x86/hp_accel.c
@@ -237,6 +237,7 @@ static const struct dmi_system_id lis3lv02d_dmi_ids[] = {
AXIS_DMI_MATCH(HPB64xx, HP ProBook 64, xy_swap),
AXIS_DMI_MATCH(HPB64xx, HP EliteBook 84, xy_swap),
AXIS_DMI_MATCH(HPB65xx, HP ProBook 65, x_inverted),
+ AXIS_DMI_MATCH(HPZBook15, HP ZBook 15, x_inverted),
{ NULL, }
/* Laptop models without axis info (yet):
* NC6910 HP Compaq 6910
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] platform: hp_accel: add a i8042 filter to remove HPQ6000 data from kb bus stream
On 30-10-14 17:57, Giedrius Statkevicius wrote: Add a i8042 filter to hp_accel to remove accelerometer's data with acpi id HPQ6000 from keyboard bus stream. The codes sent by accelerometer are e0 25, e0 26, e0 27 and e0 28. The relevant information is already passed through /dev/freefall so no need to send these undocumented weird signals through the keyboard bus. Also, unclogs `dmesg` because atkbd complained about weird scan codes, saves processing power and disk space. Signed-off-by: Giedrius Statkevičius Acked-by: Dmitry Torokhov Hi, 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 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 path includes. First of all, any Tested-Bys are very welcome by people who also have a accelerometer with acpi id HPQ6000. If it happens with HPQ6007 too we can easily modify this to install the filter when HPQ6007 is detected. For the time being the filter is only installed when HPQ6000 is detected. Now moving to what was changed since the RFC. I reworked the filter function to hopefully make it more clear what it is doing. Since the codes sent by the accelerometer are extended then we need to filter all of 0xe0's and then send one 0xe0 back when the actual key isn't in the range of 0x25-0x28. Also, I've removed the check for errors for i8042_install_filter() because it's unnecessary to check if it failed. If multiple HPQ6000's are in the system then no issue occurs even if multiple i8042_install_filter() are issued because this is handled by i8042 and it's smart enough not to install the same filter two or more times. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=84941. : -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] platform: hp_accel: add a i8042 filter to remove HPQ6000 data from kb bus stream
On 30-10-14 17:57, Giedrius Statkevicius wrote: Add a i8042 filter to hp_accel to remove accelerometer's data with acpi id HPQ6000 from keyboard bus stream. The codes sent by accelerometer are e0 25, e0 26, e0 27 and e0 28. The relevant information is already passed through /dev/freefall so no need to send these undocumented weird signals through the keyboard bus. Also, unclogs `dmesg` because atkbd complained about weird scan codes, saves processing power and disk space. Signed-off-by: Giedrius Statkevičius giedriusw...@gmail.com Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com Hi, 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 of a blank line * Move #includes of i8042.h and serio.h before the relative path includes. First of all, any Tested-Bys are very welcome by people who also have a accelerometer with acpi id HPQ6000. If it happens with HPQ6007 too we can easily modify this to install the filter when HPQ6007 is detected. For the time being the filter is only installed when HPQ6000 is detected. Now moving to what was changed since the RFC. I reworked the filter function to hopefully make it more clear what it is doing. Since the codes sent by the accelerometer are extended then we need to filter all of 0xe0's and then send one 0xe0 back when the actual key isn't in the range of 0x25-0x28. Also, I've removed the check for errors for i8042_install_filter() because it's unnecessary to check if it failed. If multiple HPQ6000's are in the system then no issue occurs even if multiple i8042_install_filter() are issued because this is handled by i8042 and it's smart enough not to install the same filter two or more times. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=84941. : -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] platform: hp_accel: add a i8042 filter to remove accelerometer data
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 about this? > HP doesn't seem to have published any. > > If other people have the same issue with the same scancodes on > accelerometers with different ACPI ids we can go ahead and do what this > patch does without reacting to what hardware the user has. > > And a general question about what other people think of doing this? > Maybe there is some better way I don't know of. Hi, On the HP laptop I had (with HPQ0004), no fake keys were reported. It should be noted that on my laptop, the accelerometer is completely decoupled from the hard disk. For example, when freefall is detected, nothing else happens (that's why you need to run a daemon that will listen to the event, and park the disk head). Looking at the bug report, it seems your laptop does a lot behind the OS, because apparently the disk head is parked automatically. So maybe the scancodes is a new "feature" they have added in order to more easily report what's happening in the back. Now, more related to your proposed solution: is this really what we want? What's wrong with the current state excepted for some warning messages in dmesg? Do we really want to plain drop this information provided by the hardware? How about just associating the scancodes to meaningful keycodes? (I guess one reason no to do that is that it'd likely require creating new keycodes corresponding to these pretty atypical events in the input layer). Is there maybe some general policy about what do to hardware that generate such special scancodes? Cheers, Éric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] platform: hp_accel: add a i8042 filter to remove accelerometer data
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 about this? HP doesn't seem to have published any. If other people have the same issue with the same scancodes on accelerometers with different ACPI ids we can go ahead and do what this patch does without reacting to what hardware the user has. And a general question about what other people think of doing this? Maybe there is some better way I don't know of. Hi, On the HP laptop I had (with HPQ0004), no fake keys were reported. It should be noted that on my laptop, the accelerometer is completely decoupled from the hard disk. For example, when freefall is detected, nothing else happens (that's why you need to run a daemon that will listen to the event, and park the disk head). Looking at the bug report, it seems your laptop does a lot behind the OS, because apparently the disk head is parked automatically. So maybe the scancodes is a new feature they have added in order to more easily report what's happening in the back. Now, more related to your proposed solution: is this really what we want? What's wrong with the current state excepted for some warning messages in dmesg? Do we really want to plain drop this information provided by the hardware? How about just associating the scancodes to meaningful keycodes? (I guess one reason no to do that is that it'd likely require creating new keycodes corresponding to these pretty atypical events in the input layer). Is there maybe some general policy about what do to hardware that generate such special scancodes? Cheers, Éric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: using __this_cpu_write() in preemptible [00000000] code: systemd-udevd/497
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
drivers/platform/x86/hp_accel.c) and couldn't see anything obvious. It
basically does:
status = acpi_evaluate_integer(dev->handle, "ALRD", , );
Is there anything special to take care before calling
acpi_evaluate_integer()? After having a look at some codes calling it
nothing obvious either jumped to my eyes.
>
> [ 10.485588] hp_accel: hardware type HPB64xx found
> [ 10.485772] BUG: using __this_cpu_write() in preemptible [] code:
> systemd-udevd/497
> [ 10.485777] caller is __this_cpu_preempt_check+0x13/0x20
> [ 10.485781] CPU: 3 PID: 497 Comm: systemd-udevd Tainted: GW
> 3.15.0-rc1 #9
> [ 10.485783] Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS
> 68ICF Ver. F.02 04/27/2012
> [ 10.485785] 81a14db5 88022c80b8e0 81604ba4
> 0003
> [ 10.485789] 88022c80b908 81313431
> 0032
> [ 10.485793] 03e8 88022c80b918 81313473
> 88022c80b928
> [ 10.485796] Call Trace:
> [ 10.485802] [] dump_stack+0x4e/0x7a
> [ 10.485805] [] check_preemption_disabled+0xe1/0xf0
> [ 10.485808] [] __this_cpu_preempt_check+0x13/0x20
> [ 10.485813] [] touch_nmi_watchdog+0x28/0x40
> [ 10.485817] [] acpi_os_stall+0x37/0x40
> [ 10.485822] [] acpi_ex_system_do_stall+0x39/0x3d
> [ 10.485825] [] acpi_ex_opcode_1A_0T_0R+0x72/0xa3
> [ 10.485829] [] acpi_ds_exec_end_op+0xd0/0x3e8
> [ 10.485833] [] acpi_ps_parse_loop+0x51d/0x576
> [ 10.485836] [] acpi_ps_parse_aml+0x98/0x289
> [ 10.485839] [] acpi_ps_execute_method+0x1c1/0x26c
> [ 10.485843] [] acpi_ns_evaluate+0x1c1/0x258
> [ 10.485846] [] acpi_evaluate_object+0x126/0x22f
> [ 10.485850] [] ? wake_up_klogd+0x52/0x70
> [ 10.485853] [] acpi_evaluate_integer+0x34/0x52
> [ 10.485858] [] lis3lv02d_acpi_read+0x59/0x70 [hp_accel]
> [ 10.485863] [] lis3lv02d_init_device+0x26/0xc00
> [lis3lv02d]
> [ 10.485866] [] ? acpi_walk_resources+0x77/0x8d
> [ 10.485870] [] ? lis3lv02d_dmi_matched+0x35/0x40
> [hp_accel]
> [ 10.485874] [] lis3lv02d_add+0xe1/0x1d0 [hp_accel]
> [ 10.485878] [] acpi_device_probe+0x41/0xee
> [ 10.485882] [] driver_probe_device+0xfd/0x240
> [ 10.485886] [] __driver_attach+0x93/0xa0
> [ 10.485889] [] ? __device_attach+0x40/0x40
> [ 10.485893] [] bus_for_each_dev+0x63/0xa0
> [ 10.485897] [] driver_attach+0x1e/0x20
> [ 10.485900] [] bus_add_driver+0x178/0x230
> [ 10.485904] [] ? 0xa001cfff
> [ 10.485908] [] driver_register+0x64/0xf0
> [ 10.485911] [] ? 0xa001cfff
> [ 10.485915] [] acpi_bus_register_driver+0x3b/0x43
> [ 10.485919] [] lis3lv02d_driver_init+0x10/0x1000
> [hp_accel]
> [ 10.485923] [] do_one_initcall+0x112/0x160
> [ 10.485927] [] ? set_memory_nx+0x43/0x50
> [ 10.485932] [] load_module+0x1b20/0x22f0
> [ 10.485936] [] ? ref_module+0x120/0x120
> [ 10.485940] [] ? copy_module_from_fd.isra.46+0x10a/0x160
> [ 10.485944] [] SyS_finit_module+0x7e/0x80
> [ 10.485949] [] system_call_fastpath+0x1a/0x1f
>
> Before this BUG, I also have the following, which doesn't seem related
> (but I may be wrong):
:
I also agree with you this second stack dump is probably unrelated :-)
Cheers,
Éric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: using __this_cpu_write() in preemptible [00000000] code: systemd-udevd/497
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 drivers/platform/x86/hp_accel.c) and couldn't see anything obvious. It basically does: status = acpi_evaluate_integer(dev-handle, ALRD, args, lret); Is there anything special to take care before calling acpi_evaluate_integer()? After having a look at some codes calling it nothing obvious either jumped to my eyes. [ 10.485588] hp_accel: hardware type HPB64xx found [ 10.485772] BUG: using __this_cpu_write() in preemptible [] code: systemd-udevd/497 [ 10.485777] caller is __this_cpu_preempt_check+0x13/0x20 [ 10.485781] CPU: 3 PID: 497 Comm: systemd-udevd Tainted: GW 3.15.0-rc1 #9 [ 10.485783] Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS 68ICF Ver. F.02 04/27/2012 [ 10.485785] 81a14db5 88022c80b8e0 81604ba4 0003 [ 10.485789] 88022c80b908 81313431 0032 [ 10.485793] 03e8 88022c80b918 81313473 88022c80b928 [ 10.485796] Call Trace: [ 10.485802] [81604ba4] dump_stack+0x4e/0x7a [ 10.485805] [81313431] check_preemption_disabled+0xe1/0xf0 [ 10.485808] [81313473] __this_cpu_preempt_check+0x13/0x20 [ 10.485813] [810e4eb8] touch_nmi_watchdog+0x28/0x40 [ 10.485817] [81369c29] acpi_os_stall+0x37/0x40 [ 10.485822] [813843e2] acpi_ex_system_do_stall+0x39/0x3d [ 10.485825] [81381138] acpi_ex_opcode_1A_0T_0R+0x72/0xa3 [ 10.485829] [81379a5d] acpi_ds_exec_end_op+0xd0/0x3e8 [ 10.485833] [8138b118] acpi_ps_parse_loop+0x51d/0x576 [ 10.485836] [8138bbc4] acpi_ps_parse_aml+0x98/0x289 [ 10.485839] [8138c41e] acpi_ps_execute_method+0x1c1/0x26c [ 10.485843] [81386dcd] acpi_ns_evaluate+0x1c1/0x258 [ 10.485846] [8138960d] acpi_evaluate_object+0x126/0x22f [ 10.485850] [810a4492] ? wake_up_klogd+0x52/0x70 [ 10.485853] [8136a520] acpi_evaluate_integer+0x34/0x52 [ 10.485858] [a01671e9] lis3lv02d_acpi_read+0x59/0x70 [hp_accel] [ 10.485863] [a014e426] lis3lv02d_init_device+0x26/0xc00 [lis3lv02d] [ 10.485866] [8138dc93] ? acpi_walk_resources+0x77/0x8d [ 10.485870] [a0167265] ? lis3lv02d_dmi_matched+0x35/0x40 [hp_accel] [ 10.485874] [a0167381] lis3lv02d_add+0xe1/0x1d0 [hp_accel] [ 10.485878] [8136d83f] acpi_device_probe+0x41/0xee [ 10.485882] [813eba1d] driver_probe_device+0xfd/0x240 [ 10.485886] [813ebc33] __driver_attach+0x93/0xa0 [ 10.485889] [813ebba0] ? __device_attach+0x40/0x40 [ 10.485893] [813e9b93] bus_for_each_dev+0x63/0xa0 [ 10.485897] [813eb4ae] driver_attach+0x1e/0x20 [ 10.485900] [813eb0e8] bus_add_driver+0x178/0x230 [ 10.485904] [a001d000] ? 0xa001cfff [ 10.485908] [813ec264] driver_register+0x64/0xf0 [ 10.485911] [a001d000] ? 0xa001cfff [ 10.485915] [8136e081] acpi_bus_register_driver+0x3b/0x43 [ 10.485919] [a001d010] lis3lv02d_driver_init+0x10/0x1000 [hp_accel] [ 10.485923] [81000352] do_one_initcall+0x112/0x160 [ 10.485927] [8103c763] ? set_memory_nx+0x43/0x50 [ 10.485932] [810c79f0] load_module+0x1b20/0x22f0 [ 10.485936] [810c4860] ? ref_module+0x120/0x120 [ 10.485940] [810c4b6a] ? copy_module_from_fd.isra.46+0x10a/0x160 [ 10.485944] [810c82ee] SyS_finit_module+0x7e/0x80 [ 10.485949] [81614356] system_call_fastpath+0x1a/0x1f Before this BUG, I also have the following, which doesn't seem related (but I may be wrong): : I also agree with you this second stack dump is probably unrelated :-) Cheers, Éric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers: platform: Mark functions as static in hp_accel.c
On 13-12-13 09:58, Josh Triplett wrote:
On Fri, Dec 13, 2013 at 12:56:34PM +0530, Rashika Kheria wrote:
This patch marks the functions lis3lv02d_acpi_init(),
lis3lv02d_acpi_read() and lis3lv02d_acpi_write() as static in
x86/hp_accel.c because they are not used outside this file.
Thus, it also eliminates the following warnings in x86/hp_accel.c:
drivers/platform/x86/hp_accel.c:91:5: warning: no previous prototype for
‘lis3lv02d_acpi_init’ [-Wmissing-prototypes]
drivers/platform/x86/hp_accel.c:109:5: warning: no previous prototype for
‘lis3lv02d_acpi_read’ [-Wmissing-prototypes]
drivers/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?
Cheers,
Éric
drivers/platform/x86/hp_accel.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/hp_accel.c b/drivers/platform/x86/hp_accel.c
index a8e43cf..01b619e 100644
--- a/drivers/platform/x86/hp_accel.c
+++ b/drivers/platform/x86/hp_accel.c
@@ -88,7 +88,7 @@ MODULE_DEVICE_TABLE(acpi, lis3lv02d_device_ids);
*
* Returns 0 on success.
*/
-int lis3lv02d_acpi_init(struct lis3lv02d *lis3)
+static int lis3lv02d_acpi_init(struct lis3lv02d *lis3)
{
struct acpi_device *dev = lis3->bus_priv;
if (acpi_evaluate_object(dev->handle, METHOD_NAME__INI,
@@ -106,7 +106,7 @@ int lis3lv02d_acpi_init(struct lis3lv02d *lis3)
*
* Returns 0 on success.
*/
-int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg, u8 *ret)
+static int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg, u8 *ret)
{
struct acpi_device *dev = lis3->bus_priv;
union acpi_object arg0 = { ACPI_TYPE_INTEGER };
@@ -129,7 +129,7 @@ int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg, u8
*ret)
*
* Returns 0 on success.
*/
-int lis3lv02d_acpi_write(struct lis3lv02d *lis3, int reg, u8 val)
+static int lis3lv02d_acpi_write(struct lis3lv02d *lis3, int reg, u8 val)
{
struct acpi_device *dev = lis3->bus_priv;
unsigned long long ret; /* Not used when writting */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers: platform: Mark functions as static in hp_accel.c
On 13-12-13 09:58, Josh Triplett wrote:
On Fri, Dec 13, 2013 at 12:56:34PM +0530, Rashika Kheria wrote:
This patch marks the functions lis3lv02d_acpi_init(),
lis3lv02d_acpi_read() and lis3lv02d_acpi_write() as static in
x86/hp_accel.c because they are not used outside this file.
Thus, it also eliminates the following warnings in x86/hp_accel.c:
drivers/platform/x86/hp_accel.c:91:5: warning: no previous prototype for
‘lis3lv02d_acpi_init’ [-Wmissing-prototypes]
drivers/platform/x86/hp_accel.c:109:5: warning: no previous prototype for
‘lis3lv02d_acpi_read’ [-Wmissing-prototypes]
drivers/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, could you pick this patch up in the platform-driver-x86 branch?
Cheers,
Éric
drivers/platform/x86/hp_accel.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/hp_accel.c b/drivers/platform/x86/hp_accel.c
index a8e43cf..01b619e 100644
--- a/drivers/platform/x86/hp_accel.c
+++ b/drivers/platform/x86/hp_accel.c
@@ -88,7 +88,7 @@ MODULE_DEVICE_TABLE(acpi, lis3lv02d_device_ids);
*
* Returns 0 on success.
*/
-int lis3lv02d_acpi_init(struct lis3lv02d *lis3)
+static int lis3lv02d_acpi_init(struct lis3lv02d *lis3)
{
struct acpi_device *dev = lis3-bus_priv;
if (acpi_evaluate_object(dev-handle, METHOD_NAME__INI,
@@ -106,7 +106,7 @@ int lis3lv02d_acpi_init(struct lis3lv02d *lis3)
*
* Returns 0 on success.
*/
-int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg, u8 *ret)
+static int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg, u8 *ret)
{
struct acpi_device *dev = lis3-bus_priv;
union acpi_object arg0 = { ACPI_TYPE_INTEGER };
@@ -129,7 +129,7 @@ int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg, u8
*ret)
*
* Returns 0 on success.
*/
-int lis3lv02d_acpi_write(struct lis3lv02d *lis3, int reg, u8 val)
+static int lis3lv02d_acpi_write(struct lis3lv02d *lis3, int reg, u8 val)
{
struct acpi_device *dev = lis3-bus_priv;
unsigned long long ret; /* Not used when writting */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hp_accel: Add a new PnP ID HPQ6007 for new HP laptops
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, it will extend hardware support (a very little bit), which can be considered material for stable trees, indeed. Cheers, Éric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hp_accel: Add a new PnP ID HPQ6007 for new HP laptops
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, it will extend hardware support (a very little bit), which can be considered material for stable trees, indeed. Cheers, Éric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hp_accel: Add a new PnP ID HPQ6007 for new HP laptops
On 26/02/13 18:19, Takashi Iwai wrote:
The DriveGuard chips on the new HP laptops are with a new PnP ID
"HPQ6007". It should be compatible with older chips.
Signed-off-by: Takashi Iwai
Hi,
Sorry for the delay. The driver is able to detect the actual type of
accelerometer behind, 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/hp_accel.c
index e64a7a8..b6c4305 100644
--- a/drivers/platform/x86/hp_accel.c
+++ b/drivers/platform/x86/hp_accel.c
@@ -77,6 +77,7 @@ static inline void delayed_sysfs_set(struct led_classdev
*led_cdev,
static struct acpi_device_id lis3lv02d_device_ids[] = {
{"HPQ0004", 0}, /* HP Mobile Data Protection System PNP */
{"HPQ6000", 0}, /* HP Mobile Data Protection System PNP */
+ {"HPQ6007", 0}, /* HP Mobile Data Protection System PNP */
{"", 0},
};
MODULE_DEVICE_TABLE(acpi, lis3lv02d_device_ids);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hp_accel: Add a new PnP ID HPQ6007 for new HP laptops
On 26/02/13 18:19, Takashi Iwai wrote:
The DriveGuard chips on the new HP laptops are with a new PnP ID
HPQ6007. It should be compatible with older chips.
Signed-off-by: Takashi Iwai ti...@suse.de
Hi,
Sorry for the delay. The driver is able to detect the actual type of
accelerometer behind, 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/hp_accel.c b/drivers/platform/x86/hp_accel.c
index e64a7a8..b6c4305 100644
--- a/drivers/platform/x86/hp_accel.c
+++ b/drivers/platform/x86/hp_accel.c
@@ -77,6 +77,7 @@ static inline void delayed_sysfs_set(struct led_classdev
*led_cdev,
static struct acpi_device_id lis3lv02d_device_ids[] = {
{HPQ0004, 0}, /* HP Mobile Data Protection System PNP */
{HPQ6000, 0}, /* HP Mobile Data Protection System PNP */
+ {HPQ6007, 0}, /* HP Mobile Data Protection System PNP */
{, 0},
};
MODULE_DEVICE_TABLE(acpi, lis3lv02d_device_ids);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer
On 22-08-12 08:30, AnilKumar Ch wrote:
This patch adds support for lis331dlh digital accelerometer to the
lis3lv02d driver family. Adds ID field for detecting the lis331dlh
module, based on this ID field lis3lv02d driver will export the
lis331dlh module functionality.
Hello AnilKumar,
Sorry 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
Signed-off-by: AnilKumar Ch
---
Changes from v1:
- Removed G range sysfs entry from v1
- Modified documentation to specify lis331dlh is supported
Documentation/misc-devices/lis3lv02d |3 ++-
drivers/misc/lis3lv02d/lis3lv02d.c | 42 +-
drivers/misc/lis3lv02d/lis3lv02d.h | 44 +++-
drivers/misc/lis3lv02d/lis3lv02d_i2c.c |7 -
4 files changed, 87 insertions(+), 9 deletions(-)
diff --git a/Documentation/misc-devices/lis3lv02d
b/Documentation/misc-devices/lis3lv02d
index f1a4ec8..af815b9 100644
--- a/Documentation/misc-devices/lis3lv02d
+++ b/Documentation/misc-devices/lis3lv02d
@@ -4,7 +4,8 @@ Kernel driver lis3lv02d
Supported chips:
* STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
- * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)
+ * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) and
+LIS331DLH (16 bits)
Authors:
Yan Burman
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index 29d12a7..c0a9199 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -80,6 +80,14 @@
#define LIS3_SENSITIVITY_12B ((LIS3_ACCURACY * 1000) / 1024)
#define LIS3_SENSITIVITY_8B (18 * LIS3_ACCURACY)
+/*
+ * LIS3331DLH spec says 1LSBs corresponds 4G/1024 -> 1LSB is 1000/1024 mG.
+ * Sensitivity values for +/-2G, outdata in 12 bits for +/-2G scale. so 4
+ * bits adjustment is required
+ */
+#define LIS3DLH_SENSITIVITY_2G ((LIS3_ACCURACY * 1000) / 1024)
+#define SHIFT_ADJ_2G 4
+
You said later:
Typo mistake this should be 4G/4096
Could you fix the comment. Even better, change LIS3331DLH to LIS331DLH
Also, if I understand correctly, there is currently no support for
changing the sensitivity. It stays at 2G all the time, right? In such
case, please add a sentence in this comment that the driver does only
support the 2G sensitivity for now.
#define LIS3_DEFAULT_FUZZ_12B 3
#define LIS3_DEFAULT_FLAT_12B 3
#define LIS3_DEFAULT_FUZZ_8B 1
@@ -133,6 +141,19 @@ static s16 lis3lv02d_read_12(struct lis3lv02d *lis3, int
reg)
return (s16)((hi << 8) | lo);
}
+/* 12bits for 2G range, 13 bits for 4G range and 14 bits for 8G range */
+static s16 lis3lv02d_read_16(struct lis3lv02d *lis3, int reg)
+{
+ u8 lo, hi;
+ int v;
+
+ lis3->read(lis3, reg - 1, );
+ lis3->read(lis3, reg, );
+ v = (int) ((hi << 8) | lo);
+
+ return (s16) v >> lis3->shift_adj;
+}
As the method reads 12, 13, or 14 bits, it's a bit tricky to call it
"*_read_16". I'd suggest maybe "lis3lv02d_read_12_14",
"lis3lv02d_read_adj_16", or even "lis331dlh_read_data". Pick the one you
prefer :-)
/**
* lis3lv02d_get_axis - For the given axis, give the value converted
* @axis: 1,2,3 - can also be negative
@@ -193,6 +214,7 @@ static void lis3lv02d_get_xyz(struct lis3lv02d *lis3, int
*x, int *y, int *z)
static int lis3_12_rates[4] = {40, 160, 640, 2560};
static int lis3_8_rates[2] = {100, 400};
static int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000};
+static int lis3_3dlh_rates[4] = {50, 100, 400, 1000};
/* ODR is Output Data Rate */
static int lis3lv02d_get_odr(struct lis3lv02d *lis3)
@@ -265,7 +287,7 @@ static int lis3lv02d_selftest(struct lis3lv02d *lis3, s16
results[3])
(LIS3_IRQ1_DATA_READY | LIS3_IRQ2_DATA_READY));
}
- if (lis3->whoami == WAI_3DC) {
+ if ((lis3->whoami == WAI_3DC) || (lis3->whoami == WAI_3DLH)) {
ctlreg = CTRL_REG4;
selftest = CTRL4_ST0;
} else {
@@ -396,9 +418,17 @@ int lis3lv02d_poweron(struct lis3lv02d *lis3)
lis3->read(lis3, CTRL_REG2, );
if (lis3->whoami == WAI_12B)
reg |= CTRL2_BDU | CTRL2_BOOT;
+ else if (lis3->whoami == WAI_3DLH)
+ reg |= CTRL2_BOOT_3DLH;
else
reg |= CTRL2_BOOT_8B;
lis3->write(lis3, CTRL_REG2, reg);
+
+ if (lis3->whoami == WAI_3DLH) {
+ lis3->read(lis3, CTRL_REG4,
Re: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer
On 22-08-12 08:30, AnilKumar Ch wrote:
This patch adds support for lis331dlh digital accelerometer to the
lis3lv02d driver family. Adds ID field for detecting the lis331dlh
module, based on this ID field lis3lv02d driver will export the
lis331dlh module functionality.
Hello AnilKumar,
Sorry 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 eric.p...@tremplin-utc.net
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Changes from v1:
- Removed G range sysfs entry from v1
- Modified documentation to specify lis331dlh is supported
Documentation/misc-devices/lis3lv02d |3 ++-
drivers/misc/lis3lv02d/lis3lv02d.c | 42 +-
drivers/misc/lis3lv02d/lis3lv02d.h | 44 +++-
drivers/misc/lis3lv02d/lis3lv02d_i2c.c |7 -
4 files changed, 87 insertions(+), 9 deletions(-)
diff --git a/Documentation/misc-devices/lis3lv02d
b/Documentation/misc-devices/lis3lv02d
index f1a4ec8..af815b9 100644
--- a/Documentation/misc-devices/lis3lv02d
+++ b/Documentation/misc-devices/lis3lv02d
@@ -4,7 +4,8 @@ Kernel driver lis3lv02d
Supported chips:
* STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
- * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)
+ * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) and
+LIS331DLH (16 bits)
Authors:
Yan Burman burman@gmail.com
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index 29d12a7..c0a9199 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -80,6 +80,14 @@
#define LIS3_SENSITIVITY_12B ((LIS3_ACCURACY * 1000) / 1024)
#define LIS3_SENSITIVITY_8B (18 * LIS3_ACCURACY)
+/*
+ * LIS3331DLH spec says 1LSBs corresponds 4G/1024 - 1LSB is 1000/1024 mG.
+ * Sensitivity values for +/-2G, outdata in 12 bits for +/-2G scale. so 4
+ * bits adjustment is required
+ */
+#define LIS3DLH_SENSITIVITY_2G ((LIS3_ACCURACY * 1000) / 1024)
+#define SHIFT_ADJ_2G 4
+
You said later:
Typo mistake this should be 4G/4096
Could you fix the comment. Even better, change LIS3331DLH to LIS331DLH
Also, if I understand correctly, there is currently no support for
changing the sensitivity. It stays at 2G all the time, right? In such
case, please add a sentence in this comment that the driver does only
support the 2G sensitivity for now.
#define LIS3_DEFAULT_FUZZ_12B 3
#define LIS3_DEFAULT_FLAT_12B 3
#define LIS3_DEFAULT_FUZZ_8B 1
@@ -133,6 +141,19 @@ static s16 lis3lv02d_read_12(struct lis3lv02d *lis3, int
reg)
return (s16)((hi 8) | lo);
}
+/* 12bits for 2G range, 13 bits for 4G range and 14 bits for 8G range */
+static s16 lis3lv02d_read_16(struct lis3lv02d *lis3, int reg)
+{
+ u8 lo, hi;
+ int v;
+
+ lis3-read(lis3, reg - 1, lo);
+ lis3-read(lis3, reg, hi);
+ v = (int) ((hi 8) | lo);
+
+ return (s16) v lis3-shift_adj;
+}
As the method reads 12, 13, or 14 bits, it's a bit tricky to call it
*_read_16. I'd suggest maybe lis3lv02d_read_12_14,
lis3lv02d_read_adj_16, or even lis331dlh_read_data. Pick the one you
prefer :-)
/**
* lis3lv02d_get_axis - For the given axis, give the value converted
* @axis: 1,2,3 - can also be negative
@@ -193,6 +214,7 @@ static void lis3lv02d_get_xyz(struct lis3lv02d *lis3, int
*x, int *y, int *z)
static int lis3_12_rates[4] = {40, 160, 640, 2560};
static int lis3_8_rates[2] = {100, 400};
static int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000};
+static int lis3_3dlh_rates[4] = {50, 100, 400, 1000};
/* ODR is Output Data Rate */
static int lis3lv02d_get_odr(struct lis3lv02d *lis3)
@@ -265,7 +287,7 @@ static int lis3lv02d_selftest(struct lis3lv02d *lis3, s16
results[3])
(LIS3_IRQ1_DATA_READY | LIS3_IRQ2_DATA_READY));
}
- if (lis3-whoami == WAI_3DC) {
+ if ((lis3-whoami == WAI_3DC) || (lis3-whoami == WAI_3DLH)) {
ctlreg = CTRL_REG4;
selftest = CTRL4_ST0;
} else {
@@ -396,9 +418,17 @@ int lis3lv02d_poweron(struct lis3lv02d *lis3)
lis3-read(lis3, CTRL_REG2, reg);
if (lis3-whoami == WAI_12B)
reg |= CTRL2_BDU | CTRL2_BOOT;
+ else if (lis3-whoami == WAI_3DLH)
+ reg |= CTRL2_BOOT_3DLH;
else
reg |= CTRL2_BOOT_8B;
lis3-write(lis3, CTRL_REG2, reg);
+
+ if (lis3-whoami == WAI_3DLH) {
+ lis3-read(lis3, CTRL_REG4, reg);
+ reg |= CTRL4_BDU
Re: [PATCH v3 1/2] lis3: add generic DT matching code
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, Éric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] lis3: add generic DT matching code
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...@tremplin-utc.net Cheers, Éric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use userland-like functions for reading the ACPI table
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 kfree() instead of ACPI_FREE().
>> So I'm missing a lot of the background here.
>>
>> I don't think "sys_open()" is in any way preferable to the alternatives,
>> especially since it depends on thread-global state (the file descriptor
>> table) rather than much more local state ("struct file" that you've
>> opened).
>>
>> I think the calls to sys_open() in init do_dounts etc are very different:
>> they really are more about a real kernel-level almost-user-mode thread
>> than a core driver.
>
> Well, that's what this code is like aswell. That's why I recommended
> to Eric to move it to init/ and make it look like that code. I haven't
> quite caught up with the discussion yet, but Eric think moving it
> there might not be a that good idea. Having this code in drivers/
> even if it's just called in init time is a bad idea, as people will
> copy it. Then again using the functions the code was using before
> isn't any better.
Ok, I see the problem with leaving the code in the drivers/ directory.
Here is a new version of the patch that also moves the code to
init/initramfs.c, the file which seems to have the closer relationship
to the code. It also keeps the address space swapping which I had
mistakenly "cleaned up".
Eric
--
Use userland-like functions for reading the ACPI table
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). Move the function to init/ so that it's obvious that this
code is not ran as a normal core driver. Moreover, use kfree() instead of
ACPI_FREE().
Also, it's recommended to open the file before stating it, to avoid surprises.
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
---
drivers/acpi/osl.c | 62 +--
init/initramfs.c | 63
2 files changed, 64 insertions(+), 61 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 8edba7b..b075781 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -93,6 +93,7 @@ static char osi_additional_string[OSI_STRING_LENGTH_MAX];
#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
static int acpi_no_initrd_override;
+extern struct acpi_table_header *acpi_find_dsdt_initrd(void);
#endif
/*
@@ -324,67 +325,6 @@ acpi_os_predefined_override(const struct
acpi_predefined_names *init_val,
return AE_OK;
}
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-static struct acpi_table_header *acpi_find_dsdt_initrd(void)
-{
- struct file *firmware_file;
- mm_segment_t oldfs;
- unsigned long len, len2;
- struct acpi_table_header *dsdt_buffer, *ret = NULL;
- struct kstat stat;
- char *ramfs_dsdt_name = "/DSDT.aml";
-
- printk(KERN_INFO PREFIX "Checking initramfs for custom DSDT\n");
-
- /*
-* Never do this at home, only the user-space is allowed to open a file.
-* The clean way would be to use the firmware loader.
-* But this code must be run before there is any userspace available.
-* A static/init firmware infrastructure doesn't exist yet...
-*/
- if (vfs_stat(ramfs_dsdt_name, ) < 0)
- return ret;
-
- len = stat.size;
- /* check especially against empty files */
- if (len <= 4) {
- printk(KERN_ERR PREFIX "Failed: DSDT only %lu bytes.\n", len);
- return ret;
- }
-
- firmware_file = filp_open(ramfs_dsdt_name, O_RDONLY, 0);
- if (IS_ERR(firmware_file)) {
- printk(KERN_ERR PREFIX "Failed to open %s.\n", ramfs_dsdt_name);
- return ret;
- }
-
- dsdt_buffer = kmalloc(len, GFP_ATOMIC);
- if (!dsdt_buffer) {
- printk(KERN_ERR PREFIX "Failed to allocate %lu bytes.\n", len);
- goto err;
- }
-
- oldfs = get_fs();
- set_fs(KERNEL_DS);
- len2 = vfs_read(firmware_file, (char __user *)dsdt_buffer, len,
- _file->f_pos);
- set_fs(oldfs);
- if (len2 < len) {
- printk(KERN_ERR PREFIX "Failed to read %lu bytes from %s.\n",
- len, ramfs_dsdt_name);
- ACPI_FREE(dsdt_buffer);
- goto err;
- }
-
- printk(KERN_INFO PREFIX "Found %lu byte DSDT in %s.\n",
- len, ramfs_dsdt_name);
- ret = dsdt_buffer;
-err:
- filp_close(firmware_file, NULL);
- return ret;
-}
-#endif
-
acpi_status
acpi_os_table_override(struct acpi_table_header * existing_table,
struct acpi_table_header ** new_table)
diff --git a/init/initramfs.c
Re: [PATCH] Use userland-like functions for reading the ACPI table
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 kfree() instead of ACPI_FREE().
So I'm missing a lot of the background here.
I don't think sys_open() is in any way preferable to the alternatives,
especially since it depends on thread-global state (the file descriptor
table) rather than much more local state (struct file that you've
opened).
I think the calls to sys_open() in init do_dounts etc are very different:
they really are more about a real kernel-level almost-user-mode thread
than a core driver.
Well, that's what this code is like aswell. That's why I recommended
to Eric to move it to init/ and make it look like that code. I haven't
quite caught up with the discussion yet, but Eric think moving it
there might not be a that good idea. Having this code in drivers/
even if it's just called in init time is a bad idea, as people will
copy it. Then again using the functions the code was using before
isn't any better.
Ok, I see the problem with leaving the code in the drivers/ directory.
Here is a new version of the patch that also moves the code to
init/initramfs.c, the file which seems to have the closer relationship
to the code. It also keeps the address space swapping which I had
mistakenly cleaned up.
Eric
--
Use userland-like functions for reading the ACPI table
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). Move the function to init/ so that it's obvious that this
code is not ran as a normal core driver. Moreover, use kfree() instead of
ACPI_FREE().
Also, it's recommended to open the file before stating it, to avoid surprises.
Signed-off-by: Eric Piel [EMAIL PROTECTED]
---
drivers/acpi/osl.c | 62 +--
init/initramfs.c | 63
2 files changed, 64 insertions(+), 61 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 8edba7b..b075781 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -93,6 +93,7 @@ static char osi_additional_string[OSI_STRING_LENGTH_MAX];
#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
static int acpi_no_initrd_override;
+extern struct acpi_table_header *acpi_find_dsdt_initrd(void);
#endif
/*
@@ -324,67 +325,6 @@ acpi_os_predefined_override(const struct
acpi_predefined_names *init_val,
return AE_OK;
}
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-static struct acpi_table_header *acpi_find_dsdt_initrd(void)
-{
- struct file *firmware_file;
- mm_segment_t oldfs;
- unsigned long len, len2;
- struct acpi_table_header *dsdt_buffer, *ret = NULL;
- struct kstat stat;
- char *ramfs_dsdt_name = /DSDT.aml;
-
- printk(KERN_INFO PREFIX Checking initramfs for custom DSDT\n);
-
- /*
-* Never do this at home, only the user-space is allowed to open a file.
-* The clean way would be to use the firmware loader.
-* But this code must be run before there is any userspace available.
-* A static/init firmware infrastructure doesn't exist yet...
-*/
- if (vfs_stat(ramfs_dsdt_name, stat) 0)
- return ret;
-
- len = stat.size;
- /* check especially against empty files */
- if (len = 4) {
- printk(KERN_ERR PREFIX Failed: DSDT only %lu bytes.\n, len);
- return ret;
- }
-
- firmware_file = filp_open(ramfs_dsdt_name, O_RDONLY, 0);
- if (IS_ERR(firmware_file)) {
- printk(KERN_ERR PREFIX Failed to open %s.\n, ramfs_dsdt_name);
- return ret;
- }
-
- dsdt_buffer = kmalloc(len, GFP_ATOMIC);
- if (!dsdt_buffer) {
- printk(KERN_ERR PREFIX Failed to allocate %lu bytes.\n, len);
- goto err;
- }
-
- oldfs = get_fs();
- set_fs(KERNEL_DS);
- len2 = vfs_read(firmware_file, (char __user *)dsdt_buffer, len,
- firmware_file-f_pos);
- set_fs(oldfs);
- if (len2 len) {
- printk(KERN_ERR PREFIX Failed to read %lu bytes from %s.\n,
- len, ramfs_dsdt_name);
- ACPI_FREE(dsdt_buffer);
- goto err;
- }
-
- printk(KERN_INFO PREFIX Found %lu byte DSDT in %s.\n,
- len, ramfs_dsdt_name);
- ret = dsdt_buffer;
-err:
- filp_close(firmware_file, NULL);
- return ret;
-}
-#endif
-
acpi_status
acpi_os_table_override(struct acpi_table_header * existing_table,
struct acpi_table_header ** new_table)
diff --git a/init/initramfs.c b/init/initramfs.c
index b74e845..9a0563a 100644
---
[PATCH] Use userland-like functions for reading the ACPI table
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 is a s-o-b version
for Len. It's against 2.6.25-rc2.
Eric
--
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 kfree() instead of ACPI_FREE().
Also, it's recommended to open the file before stating it, to avoid surprises.
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
---
drivers/acpi/osl.c | 33 +++--
1 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 34b3386..b836305 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -327,8 +328,7 @@ acpi_os_predefined_override(const struct
acpi_predefined_names *init_val,
#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
static struct acpi_table_header *acpi_find_dsdt_initrd(void)
{
- struct file *firmware_file;
- mm_segment_t oldfs;
+ int fd;
unsigned long len, len2;
struct acpi_table_header *dsdt_buffer, *ret = NULL;
struct kstat stat;
@@ -342,20 +342,21 @@ struct acpi_table_header *acpi_find_dsdt_initrd(void)
* But this code must be run before there is any userspace available.
* A static/init firmware infrastructure doesn't exist yet...
*/
- if (vfs_stat(ramfs_dsdt_name, ) < 0)
- return ret;
+ fd = sys_open(ramfs_dsdt_name, O_RDONLY, 0);
+ if (fd < 0)
+ return ret; /* No need for warning, no DSDT override is normal
*/
+
+ /* There exists 3 different sys_fstat's, all are wrapper to vfs_fstat */
+ if (vfs_fstat(fd, ) < 0) {
+ printk(KERN_ERR PREFIX "Failed to stat %s.\n", ramfs_dsdt_name);
+ goto err;
+ }
len = stat.size;
/* check especially against empty files */
if (len <= 4) {
printk(KERN_ERR PREFIX "Failed: DSDT only %lu bytes.\n", len);
- return ret;
- }
-
- firmware_file = filp_open(ramfs_dsdt_name, O_RDONLY, 0);
- if (IS_ERR(firmware_file)) {
- printk(KERN_ERR PREFIX "Failed to open %s.\n", ramfs_dsdt_name);
- return ret;
+ goto err;
}
dsdt_buffer = kmalloc(len, GFP_ATOMIC);
@@ -364,15 +365,11 @@ struct acpi_table_header *acpi_find_dsdt_initrd(void)
goto err;
}
- oldfs = get_fs();
- set_fs(KERNEL_DS);
- len2 = vfs_read(firmware_file, (char __user *)dsdt_buffer, len,
- _file->f_pos);
- set_fs(oldfs);
+ len2 = sys_read(fd, (char __user *)dsdt_buffer, len);
if (len2 < len) {
printk(KERN_ERR PREFIX "Failed to read %lu bytes from %s.\n",
len, ramfs_dsdt_name);
- ACPI_FREE(dsdt_buffer);
+ kfree(dsdt_buffer);
goto err;
}
@@ -380,7 +377,7 @@ struct acpi_table_header *acpi_find_dsdt_initrd(void)
len, ramfs_dsdt_name);
ret = dsdt_buffer;
err:
- filp_close(firmware_file, NULL);
+ sys_close(fd);
return ret;
}
#endif
--
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/lkml/
[PATCH] Allow populate_rootfs() to be called early (resent, with sob)
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; will such change be acceptable?
>> Yes, that looks like a nice way. Actually, I discovered that for suspend
>> and resume, there is exactly the same need, and a special flag is
>> already available: usermodehelper_disabled.
>>
>> So here is a proposal patch leveraging this flag. The rootfs is
>> populated early but user land execution is forbidden until we reach a
>> sufficient initialization state. I think it even has the bonus of
>> doing _explicitly_ what we want (avoid user land execution).
>>
>> Does this look good? (if so, I can probably make it even cleaner by
>> renaming/removing the rootfs_initcall level)
>
> 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 also rootfs_initcall(), and uses fs_initcall_sync().
> There should be absolutely no difference in behaviour as there was no
> user of fs_initcall_sync() in the kernel.
>
> I'm not sure what should be the best tree to go through. Maybe the ACPI
> tree, as all this is needed for CONFIG_ACPI_CUSTOM_DSDT_INITRD...
>
Len has reminded me that I have to add a s-o-b line to my patches :-)
Here is a corrected version (against 2.6.25-rc2).
Eric
--
For ACPI table override, we need the rootfs available early. So this patch
* removes the kludge calling populate_rootfs early _sometimes_
* leverage the usermodehelper_disabled variable to prevent too early userspace
execution would could lead to oops if the kernel subsystem are not yet
initialised
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
---
include/asm-generic/vmlinux.lds.h |1 -
include/linux/init.h |1 -
init/initramfs.c |7 ---
init/main.c |4
kernel/kmod.c | 15 +++
5 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index f784d2f..19ddbae 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -335,7 +335,6 @@
*(.initcall4s.init) \
*(.initcall5.init) \
*(.initcall5s.init) \
- *(.initcallrootfs.init) \
*(.initcall6.init) \
*(.initcall6s.init) \
*(.initcall7.init) \
diff --git a/include/linux/init.h b/include/linux/init.h
index a404a00..ecd05cd 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -183,7 +183,6 @@ void prepare_namespace(void);
#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
#define fs_initcall(fn)__define_initcall("5",fn,5)
#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
-#define rootfs_initcall(fn)__define_initcall("rootfs",fn,rootfs)
#define device_initcall(fn)__define_initcall("6",fn,6)
#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define late_initcall(fn) __define_initcall("7",fn,7)
diff --git a/init/initramfs.c b/init/initramfs.c
index c0b1e05..b74e845 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -577,10 +577,3 @@ int __init populate_rootfs(void)
}
return 0;
}
-#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-/*
- * if this option is enabled, populate_rootfs() is called _earlier_ in the
- * boot sequence. This insures that the ACPI initialisation can find the file.
- */
-rootfs_initcall(populate_rootfs);
-#endif
diff --git a/init/main.c b/init/main.c
index 8b19820..703ded0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -102,11 +102,7 @@ static inline void mark_rodata_ro(void) { }
extern void tc_init(void);
#endif
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
extern int populate_rootfs(void);
-#else
-static inline void populate_rootfs(void) {}
-#endif
enum system_states system_state;
EXPORT_SYMBOL(system_state);
diff --git a/kernel/kmod.c b/kernel/kmod.c
index bb7df2a..112b261 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -267,14 +267,23 @@ static void __call_usermodehelper(struct work_struct
*work)
}
}
-#ifdef CONFIG_PM
/*
* If set, call_u
[PATCH] Allow populate_rootfs() to be called early (resent, with sob)
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; will such change be acceptable?
Yes, that looks like a nice way. Actually, I discovered that for suspend
and resume, there is exactly the same need, and a special flag is
already available: usermodehelper_disabled.
So here is a proposal patch leveraging this flag. The rootfs is
populated early but user land execution is forbidden until we reach a
sufficient initialization state. I think it even has the bonus of
doing _explicitly_ what we want (avoid user land execution).
Does this look good? (if so, I can probably make it even cleaner by
renaming/removing the rootfs_initcall level)
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 also rootfs_initcall(), and uses fs_initcall_sync().
There should be absolutely no difference in behaviour as there was no
user of fs_initcall_sync() in the kernel.
I'm not sure what should be the best tree to go through. Maybe the ACPI
tree, as all this is needed for CONFIG_ACPI_CUSTOM_DSDT_INITRD...
Len has reminded me that I have to add a s-o-b line to my patches :-)
Here is a corrected version (against 2.6.25-rc2).
Eric
--
For ACPI table override, we need the rootfs available early. So this patch
* removes the kludge calling populate_rootfs early _sometimes_
* leverage the usermodehelper_disabled variable to prevent too early userspace
execution would could lead to oops if the kernel subsystem are not yet
initialised
Signed-off-by: Eric Piel [EMAIL PROTECTED]
---
include/asm-generic/vmlinux.lds.h |1 -
include/linux/init.h |1 -
init/initramfs.c |7 ---
init/main.c |4
kernel/kmod.c | 15 +++
5 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index f784d2f..19ddbae 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -335,7 +335,6 @@
*(.initcall4s.init) \
*(.initcall5.init) \
*(.initcall5s.init) \
- *(.initcallrootfs.init) \
*(.initcall6.init) \
*(.initcall6s.init) \
*(.initcall7.init) \
diff --git a/include/linux/init.h b/include/linux/init.h
index a404a00..ecd05cd 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -183,7 +183,6 @@ void prepare_namespace(void);
#define subsys_initcall_sync(fn) __define_initcall(4s,fn,4s)
#define fs_initcall(fn)__define_initcall(5,fn,5)
#define fs_initcall_sync(fn) __define_initcall(5s,fn,5s)
-#define rootfs_initcall(fn)__define_initcall(rootfs,fn,rootfs)
#define device_initcall(fn)__define_initcall(6,fn,6)
#define device_initcall_sync(fn) __define_initcall(6s,fn,6s)
#define late_initcall(fn) __define_initcall(7,fn,7)
diff --git a/init/initramfs.c b/init/initramfs.c
index c0b1e05..b74e845 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -577,10 +577,3 @@ int __init populate_rootfs(void)
}
return 0;
}
-#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-/*
- * if this option is enabled, populate_rootfs() is called _earlier_ in the
- * boot sequence. This insures that the ACPI initialisation can find the file.
- */
-rootfs_initcall(populate_rootfs);
-#endif
diff --git a/init/main.c b/init/main.c
index 8b19820..703ded0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -102,11 +102,7 @@ static inline void mark_rodata_ro(void) { }
extern void tc_init(void);
#endif
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
extern int populate_rootfs(void);
-#else
-static inline void populate_rootfs(void) {}
-#endif
enum system_states system_state;
EXPORT_SYMBOL(system_state);
diff --git a/kernel/kmod.c b/kernel/kmod.c
index bb7df2a..112b261 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -267,14 +267,23 @@ static void __call_usermodehelper(struct work_struct
*work)
}
}
-#ifdef CONFIG_PM
/*
* If set, call_usermodehelper_exec() will exit immediately returning -EBUSY
* (used for preventing user land processes from being created after the user
* land has been frozen during a system-wide hibernation or suspend operation).
+ * It is also used at boot up to avoid calling a user land process
[PATCH] Use userland-like functions for reading the ACPI table
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 is a s-o-b version
for Len. It's against 2.6.25-rc2.
Eric
--
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 kfree() instead of ACPI_FREE().
Also, it's recommended to open the file before stating it, to avoid surprises.
Signed-off-by: Eric Piel [EMAIL PROTECTED]
---
drivers/acpi/osl.c | 33 +++--
1 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 34b3386..b836305 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -42,6 +42,7 @@
#include acpi/acpi_bus.h
#include acpi/processor.h
#include asm/uaccess.h
+#include linux/syscalls.h
#include linux/efi.h
#include linux/ioport.h
@@ -327,8 +328,7 @@ acpi_os_predefined_override(const struct
acpi_predefined_names *init_val,
#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
static struct acpi_table_header *acpi_find_dsdt_initrd(void)
{
- struct file *firmware_file;
- mm_segment_t oldfs;
+ int fd;
unsigned long len, len2;
struct acpi_table_header *dsdt_buffer, *ret = NULL;
struct kstat stat;
@@ -342,20 +342,21 @@ struct acpi_table_header *acpi_find_dsdt_initrd(void)
* But this code must be run before there is any userspace available.
* A static/init firmware infrastructure doesn't exist yet...
*/
- if (vfs_stat(ramfs_dsdt_name, stat) 0)
- return ret;
+ fd = sys_open(ramfs_dsdt_name, O_RDONLY, 0);
+ if (fd 0)
+ return ret; /* No need for warning, no DSDT override is normal
*/
+
+ /* There exists 3 different sys_fstat's, all are wrapper to vfs_fstat */
+ if (vfs_fstat(fd, stat) 0) {
+ printk(KERN_ERR PREFIX Failed to stat %s.\n, ramfs_dsdt_name);
+ goto err;
+ }
len = stat.size;
/* check especially against empty files */
if (len = 4) {
printk(KERN_ERR PREFIX Failed: DSDT only %lu bytes.\n, len);
- return ret;
- }
-
- firmware_file = filp_open(ramfs_dsdt_name, O_RDONLY, 0);
- if (IS_ERR(firmware_file)) {
- printk(KERN_ERR PREFIX Failed to open %s.\n, ramfs_dsdt_name);
- return ret;
+ goto err;
}
dsdt_buffer = kmalloc(len, GFP_ATOMIC);
@@ -364,15 +365,11 @@ struct acpi_table_header *acpi_find_dsdt_initrd(void)
goto err;
}
- oldfs = get_fs();
- set_fs(KERNEL_DS);
- len2 = vfs_read(firmware_file, (char __user *)dsdt_buffer, len,
- firmware_file-f_pos);
- set_fs(oldfs);
+ len2 = sys_read(fd, (char __user *)dsdt_buffer, len);
if (len2 len) {
printk(KERN_ERR PREFIX Failed to read %lu bytes from %s.\n,
len, ramfs_dsdt_name);
- ACPI_FREE(dsdt_buffer);
+ kfree(dsdt_buffer);
goto err;
}
@@ -380,7 +377,7 @@ struct acpi_table_header *acpi_find_dsdt_initrd(void)
len, ramfs_dsdt_name);
ret = dsdt_buffer;
err:
- filp_close(firmware_file, NULL);
+ sys_close(fd);
return ret;
}
#endif
--
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/lkml/
Re: [PATCH] Allow populate_rootfs() to be called early
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 also rootfs_initcall(), and uses fs_initcall_sync(). >> There should be absolutely no difference in behaviour as there was no >> user of fs_initcall_sync() in the kernel. >> >> I'm not sure what should be the best tree to go through. Maybe the ACPI >> tree, as all this is needed for CONFIG_ACPI_CUSTOM_DSDT_INITRD... > > Actually I've just got a report today where we get an uninitialized > spinlock due to this in -mm. It's probably possible to work around it, > though. What do you mean by "due to this"? Due to userspace helper being called too early? Then this patch should fix the bug. Eric -- 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/lkml/
[PATCH] Allow populate_rootfs() to be called early (was: acpi dsts loading and populate_rootfs)
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, that looks like a nice way. Actually, I discovered that for suspend
> and resume, there is exactly the same need, and a special flag is
> already available: usermodehelper_disabled.
>
> So here is a proposal patch leveraging this flag. The rootfs is
> populated early but user land execution is forbidden until we reach a
> sufficient initialization state. I think it even has the bonus of
> doing _explicitly_ what we want (avoid user land execution).
>
> Does this look good? (if so, I can probably make it even cleaner by
> renaming/removing the rootfs_initcall level)
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 also rootfs_initcall(), and uses fs_initcall_sync().
There should be absolutely no difference in behaviour as there was no
user of fs_initcall_sync() in the kernel.
I'm not sure what should be the best tree to go through. Maybe the ACPI
tree, as all this is needed for CONFIG_ACPI_CUSTOM_DSDT_INITRD...
See you,
Eric
---
For ACPI table override, we need the rootfs available early. So this patch
* removes the kludge calling populate_rootfs early _sometimes_
* leverage the usermodehelper_disabled variable to prevent too early userspace
execution would could lead to oops if the kernel subsystem are not yet
initialised
This solves a theoretical bug where someone has both a DSDT table and a
hotplug helper in his or her initramfs.
---
include/asm-generic/vmlinux.lds.h |1 -
include/linux/init.h |1 -
init/initramfs.c |7 ---
init/main.c |4
kernel/kmod.c | 15 +++
5 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index f784d2f..19ddbae 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -335,7 +335,6 @@
*(.initcall4s.init) \
*(.initcall5.init) \
*(.initcall5s.init) \
- *(.initcallrootfs.init) \
*(.initcall6.init) \
*(.initcall6s.init) \
*(.initcall7.init) \
diff --git a/include/linux/init.h b/include/linux/init.h
index a404a00..ecd05cd 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -183,7 +183,6 @@ void prepare_namespace(void);
#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
#define fs_initcall(fn)__define_initcall("5",fn,5)
#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
-#define rootfs_initcall(fn)__define_initcall("rootfs",fn,rootfs)
#define device_initcall(fn)__define_initcall("6",fn,6)
#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define late_initcall(fn) __define_initcall("7",fn,7)
diff --git a/init/initramfs.c b/init/initramfs.c
index c0b1e05..b74e845 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -577,10 +577,3 @@ int __init populate_rootfs(void)
}
return 0;
}
-#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-/*
- * if this option is enabled, populate_rootfs() is called _earlier_ in the
- * boot sequence. This insures that the ACPI initialisation can find the file.
- */
-rootfs_initcall(populate_rootfs);
-#endif
diff --git a/init/main.c b/init/main.c
index 8b19820..703ded0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -102,11 +102,7 @@ static inline void mark_rodata_ro(void) { }
extern void tc_init(void);
#endif
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
extern int populate_rootfs(void);
-#else
-static inline void populate_rootfs(void) {}
-#endif
enum system_states system_state;
EXPORT_SYMBOL(system_state);
diff --git a/kernel/kmod.c b/kernel/kmod.c
index bb7df2a..112b261 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -267,14 +267,23 @@ static void __call_usermodehelper(struct work_struct
*work)
}
}
-#ifdef CONFIG_PM
/*
* If set, call_usermodehelper_exec() will exit immediately returning -EBUSY
* (used for preventing user land processes from being created after the user
* land has been frozen during a system-wide hibernation or suspend opera
Re: acpi dsts loading and populate_rootfs
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 should be using the firmware loader which works
>>> perfectly fine if you initramfs is set up for it. So please folks,
>>> back to the drawing board, do it properly and send it out to lkml
>>> for review please.
>> Christoph, if you have seen this part of the code, you have probably
>> also read the big fat warning explaining why this cannot be done by
>> firmware loader (ie: userspace cannot be run at this early time,
>> corresponding to acpi_early_init()). However, you probably know the
>> kernel ten times better than me. Could you explain what I misunderstood
>> when writing this warning, and give me some hints about how to use the
>> firmware loader in this case?
>
> Sorry, I misparsed the comment. I took it for the usual I'm too lazy
> to put something that could load firmware into initramfs excuse.
>
> But thinking about it is there a reason acpi initialization needs to
> happen so early that we can't even have userspace in initramfs running?
Hi,
I guess in the complete absolute point of view it's possible to run
userspace without ACPI, after all that's what happens if you don't
activate ACPI in your kernel. However, so far I've taken the init order
as a constant. I'd really prefer not to have to mess with a complete
init order reorganization ;-)
>
> But if we can't use real userspace this could should at least be written
> like the pseudo-userspace in init/do_mounts*.c, using the sys_ syscall
> implementations.
Yes, thank you very much for the links. Attached is a patch that does
this.
>
> As an additional comment the stat + open approach is racy and not a good
> idea. Please just open the file using sys_open, it will tell you
> if the file doesn't exist and then use fstat on it to find the
> length. It would also be useful if this kind of code is not hidden
> inside acpi but rather done somewhere close to the early init code
> because that's where people would expect this kind of nastiness.
The attached patch also fixes the stat + open order.
Concerning the place of the code, I've tried to find a better place.
However, as acpi_early_init(), from which this function is called, is
placed in driver/acpi/ and the acpi_find_dsdt_initrd() function contains
quite a few references to acpi code it really looked strange to move it
out from the current file. If you still think it make much more sense to
move it somewhere else, could you hint me about which you would think it
fit better in?
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.
See you,
Eric
---
Use userland-like functions for reading the ACPI table
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 kfree() instead of ACPI_FREE().
Also, it's recommended to open the file before stating it, to avoid surprises.
---
drivers/acpi/osl.c | 33 +++--
1 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 34b3386..b836305 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -327,8 +328,7 @@ acpi_os_predefined_override(const struct
acpi_predefined_names *init_val,
#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
static struct acpi_table_header *acpi_find_dsdt_initrd(void)
{
- struct file *firmware_file;
- mm_segment_t oldfs;
+ int fd;
unsigned long len, len2;
struct acpi_table_header *dsdt_buffer, *ret = NULL;
struct kstat stat;
@@ -342,20 +342,21 @@ struct acpi_table_header *acpi_find_dsdt_initrd(void)
* But this code must be run before there is any userspace available.
* A static/init firmware infrastructure doesn't exist yet...
*/
- if (vfs_stat(ramfs_dsdt_name, ) < 0)
- return ret;
+ fd = sys_open(ramfs_dsdt_name, O_RDONLY, 0);
+ if (fd < 0)
+ return ret; /* No need for warning, no DSDT override is normal
*/
+
+ /* There exists 3 different sys_fstat's, all are wrapper to vfs_fstat */
+ if (vfs_fstat(fd, ) < 0) {
+ printk(KERN_ERR PREFIX "Failed to stat %s.\n", ramfs_dsdt_name);
+ goto err;
+ }
len = stat.size;
/* check especially against empty files */
if (len <= 4) {
printk(KERN_ERR PREFIX "Failed: DSDT only %lu bytes.\n", len);
- return ret;
- }
-
- firmware_file
Re: acpi dsts loading and populate_rootfs
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 should be using the firmware loader which works
perfectly fine if you initramfs is set up for it. So please folks,
back to the drawing board, do it properly and send it out to lkml
for review please.
Christoph, if you have seen this part of the code, you have probably
also read the big fat warning explaining why this cannot be done by
firmware loader (ie: userspace cannot be run at this early time,
corresponding to acpi_early_init()). However, you probably know the
kernel ten times better than me. Could you explain what I misunderstood
when writing this warning, and give me some hints about how to use the
firmware loader in this case?
Sorry, I misparsed the comment. I took it for the usual I'm too lazy
to put something that could load firmware into initramfs excuse.
But thinking about it is there a reason acpi initialization needs to
happen so early that we can't even have userspace in initramfs running?
Hi,
I guess in the complete absolute point of view it's possible to run
userspace without ACPI, after all that's what happens if you don't
activate ACPI in your kernel. However, so far I've taken the init order
as a constant. I'd really prefer not to have to mess with a complete
init order reorganization ;-)
But if we can't use real userspace this could should at least be written
like the pseudo-userspace in init/do_mounts*.c, using the sys_ syscall
implementations.
Yes, thank you very much for the links. Attached is a patch that does
this.
As an additional comment the stat + open approach is racy and not a good
idea. Please just open the file using sys_open, it will tell you
if the file doesn't exist and then use fstat on it to find the
length. It would also be useful if this kind of code is not hidden
inside acpi but rather done somewhere close to the early init code
because that's where people would expect this kind of nastiness.
The attached patch also fixes the stat + open order.
Concerning the place of the code, I've tried to find a better place.
However, as acpi_early_init(), from which this function is called, is
placed in driver/acpi/ and the acpi_find_dsdt_initrd() function contains
quite a few references to acpi code it really looked strange to move it
out from the current file. If you still think it make much more sense to
move it somewhere else, could you hint me about which you would think it
fit better in?
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.
See you,
Eric
---
Use userland-like functions for reading the ACPI table
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 kfree() instead of ACPI_FREE().
Also, it's recommended to open the file before stating it, to avoid surprises.
---
drivers/acpi/osl.c | 33 +++--
1 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 34b3386..b836305 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -42,6 +42,7 @@
#include acpi/acpi_bus.h
#include acpi/processor.h
#include asm/uaccess.h
+#include linux/syscalls.h
#include linux/efi.h
#include linux/ioport.h
@@ -327,8 +328,7 @@ acpi_os_predefined_override(const struct
acpi_predefined_names *init_val,
#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
static struct acpi_table_header *acpi_find_dsdt_initrd(void)
{
- struct file *firmware_file;
- mm_segment_t oldfs;
+ int fd;
unsigned long len, len2;
struct acpi_table_header *dsdt_buffer, *ret = NULL;
struct kstat stat;
@@ -342,20 +342,21 @@ struct acpi_table_header *acpi_find_dsdt_initrd(void)
* But this code must be run before there is any userspace available.
* A static/init firmware infrastructure doesn't exist yet...
*/
- if (vfs_stat(ramfs_dsdt_name, stat) 0)
- return ret;
+ fd = sys_open(ramfs_dsdt_name, O_RDONLY, 0);
+ if (fd 0)
+ return ret; /* No need for warning, no DSDT override is normal
*/
+
+ /* There exists 3 different sys_fstat's, all are wrapper to vfs_fstat */
+ if (vfs_fstat(fd, stat) 0) {
+ printk(KERN_ERR PREFIX Failed to stat %s.\n, ramfs_dsdt_name);
+ goto err;
+ }
len = stat.size;
/* check especially against empty files */
if (len = 4) {
printk(KERN_ERR PREFIX Failed: DSDT only %lu bytes.\n, len);
- return
[PATCH] Allow populate_rootfs() to be called early (was: acpi dsts loading and populate_rootfs)
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, that looks like a nice way. Actually, I discovered that for suspend
and resume, there is exactly the same need, and a special flag is
already available: usermodehelper_disabled.
So here is a proposal patch leveraging this flag. The rootfs is
populated early but user land execution is forbidden until we reach a
sufficient initialization state. I think it even has the bonus of
doing _explicitly_ what we want (avoid user land execution).
Does this look good? (if so, I can probably make it even cleaner by
renaming/removing the rootfs_initcall level)
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 also rootfs_initcall(), and uses fs_initcall_sync().
There should be absolutely no difference in behaviour as there was no
user of fs_initcall_sync() in the kernel.
I'm not sure what should be the best tree to go through. Maybe the ACPI
tree, as all this is needed for CONFIG_ACPI_CUSTOM_DSDT_INITRD...
See you,
Eric
---
For ACPI table override, we need the rootfs available early. So this patch
* removes the kludge calling populate_rootfs early _sometimes_
* leverage the usermodehelper_disabled variable to prevent too early userspace
execution would could lead to oops if the kernel subsystem are not yet
initialised
This solves a theoretical bug where someone has both a DSDT table and a
hotplug helper in his or her initramfs.
---
include/asm-generic/vmlinux.lds.h |1 -
include/linux/init.h |1 -
init/initramfs.c |7 ---
init/main.c |4
kernel/kmod.c | 15 +++
5 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index f784d2f..19ddbae 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -335,7 +335,6 @@
*(.initcall4s.init) \
*(.initcall5.init) \
*(.initcall5s.init) \
- *(.initcallrootfs.init) \
*(.initcall6.init) \
*(.initcall6s.init) \
*(.initcall7.init) \
diff --git a/include/linux/init.h b/include/linux/init.h
index a404a00..ecd05cd 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -183,7 +183,6 @@ void prepare_namespace(void);
#define subsys_initcall_sync(fn) __define_initcall(4s,fn,4s)
#define fs_initcall(fn)__define_initcall(5,fn,5)
#define fs_initcall_sync(fn) __define_initcall(5s,fn,5s)
-#define rootfs_initcall(fn)__define_initcall(rootfs,fn,rootfs)
#define device_initcall(fn)__define_initcall(6,fn,6)
#define device_initcall_sync(fn) __define_initcall(6s,fn,6s)
#define late_initcall(fn) __define_initcall(7,fn,7)
diff --git a/init/initramfs.c b/init/initramfs.c
index c0b1e05..b74e845 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -577,10 +577,3 @@ int __init populate_rootfs(void)
}
return 0;
}
-#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-/*
- * if this option is enabled, populate_rootfs() is called _earlier_ in the
- * boot sequence. This insures that the ACPI initialisation can find the file.
- */
-rootfs_initcall(populate_rootfs);
-#endif
diff --git a/init/main.c b/init/main.c
index 8b19820..703ded0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -102,11 +102,7 @@ static inline void mark_rodata_ro(void) { }
extern void tc_init(void);
#endif
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
extern int populate_rootfs(void);
-#else
-static inline void populate_rootfs(void) {}
-#endif
enum system_states system_state;
EXPORT_SYMBOL(system_state);
diff --git a/kernel/kmod.c b/kernel/kmod.c
index bb7df2a..112b261 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -267,14 +267,23 @@ static void __call_usermodehelper(struct work_struct
*work)
}
}
-#ifdef CONFIG_PM
/*
* If set, call_usermodehelper_exec() will exit immediately returning -EBUSY
* (used for preventing user land processes from being created after the user
* land has been frozen during a system-wide hibernation or suspend operation).
+ * It is also used at boot up to avoid calling a user land process before all
+ * the kernel subsystems are initialised (such as pipefs).
*/
-static int
Re: [PATCH] Allow populate_rootfs() to be called early
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 also rootfs_initcall(), and uses fs_initcall_sync(). There should be absolutely no difference in behaviour as there was no user of fs_initcall_sync() in the kernel. I'm not sure what should be the best tree to go through. Maybe the ACPI tree, as all this is needed for CONFIG_ACPI_CUSTOM_DSDT_INITRD... Actually I've just got a report today where we get an uninitialized spinlock due to this in -mm. It's probably possible to work around it, though. What do you mean by due to this? Due to userspace helper being called too early? Then this patch should fix the bug. Eric -- 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/lkml/
Re: [2.6 patch] make acpi_no_initrd_override_setup() static
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 a/drivers/acpi/osl.c
> b/drivers/acpi/osl.c
> index 0c37c65..b72a7f1 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -419,7 +419,7 @@ acpi_os_table_override(struct acpi_table_header *
> existing_table,
> }
>
> #ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
> -int __init acpi_no_initrd_override_setup(char *s)
> +static int __init acpi_no_initrd_override_setup(char *s)
> {
> acpi_no_initrd_override = 1;
> return 1;
--
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/lkml/
Re: [2.6 patch] make acpi_no_initrd_override_setup() static
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 a/drivers/acpi/osl.c
b/drivers/acpi/osl.c
index 0c37c65..b72a7f1 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -419,7 +419,7 @@ acpi_os_table_override(struct acpi_table_header *
existing_table,
}
#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-int __init acpi_no_initrd_override_setup(char *s)
+static int __init acpi_no_initrd_override_setup(char *s)
{
acpi_no_initrd_override = 1;
return 1;
--
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/lkml/
Re: acpi dsts loading and populate_rootfs
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?
>
> AFAIR the problem was that the kernel was trying to exec /sbin/hotplug
> before some kernel subsystems (e.g., pipe support) were completely
> initialized, which caused oopses during boot.
>
> Initramfs images generated by distro tools usually do not contain
> /sbin/hotplug, and therefore avoid the problem. (The kernel might
> also call /sbin/modprobe by itself, but it either does not do it
> during early boot, or /sbin/modprobe does not use kernel features
> which had not been initialized yet).
Thanks a lot for the pointer. I was able to find the original bug
report. After reading the various fix proposals and the current code I
think I understand what is going on.
Basically, the problem is that one should not run a user land program
too early because not everything is initialized yet (for instance
pipefs). This might happen because at initialization some drivers can
trigger automatically /sbin/hotplug (via call_usermodehelper()). So the
fix which was applied consists in populating the rootfs only once all
the kernel subsystem is initialized. In this way, the hotplugging is
still triggered but as the user space program doesn't exist it can't be
called! (hehe)
>> One different solution that I implemented [1] was to have an
>> "early_populate_rootfs()" before the acpi_early_init(), leaving
>> populate_rootfs() at the normal place. If the early version fails, it's
>> ok: we can't override the DSDT, but the later version will work as usual
>> anyway. This solution also seems to work quite often (it's used in
>> Ubuntu, Mandriva and PCLinuxOS)
>
> This would not solve the problem, because /sbin/hotplug (if present in
> the initramfs image) will exist too early.
Yes, now that I understand the problem, reading the initramfs twice
would in no way help!
>> 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, that looks like a nice way. Actually, I discovered that for suspend
and resume, there is exactly the same need, and a special flag is
already available: usermodehelper_disabled.
So here is a proposal patch leveraging this flag. The rootfs is
populated early but user land execution is forbidden until we reach a
sufficient initialization state. I think it even has the bonus of
doing _explicitly_ what we want (avoid user land execution).
Does this look good? (if so, I can probably make it even cleaner by
renaming/removing the rootfs_initcall level)
Eric
--
diff --git a/init/initramfs.c b/init/initramfs.c
index c0b1e05..b74e845 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -577,10 +577,3 @@ int __init populate_rootfs(void)
}
return 0;
}
-#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-/*
- * if this option is enabled, populate_rootfs() is called _earlier_ in the
- * boot sequence. This insures that the ACPI initialisation can find the file.
- */
-rootfs_initcall(populate_rootfs);
-#endif
diff --git a/init/main.c b/init/main.c
index 8b19820..703ded0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -102,11 +102,7 @@ static inline void mark_rodata_ro(void) { }
extern void tc_init(void);
#endif
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
extern int populate_rootfs(void);
-#else
-static inline void populate_rootfs(void) {}
-#endif
enum system_states system_state;
EXPORT_SYMBOL(system_state);
diff --git a/kernel/kmod.c b/kernel/kmod.c
index bb7df2a..d6a2b40 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -267,14 +267,23 @@ static void __call_usermodehelper(struct work_struct
*work)
}
}
-#ifdef CONFIG_PM
/*
* If set, call_usermodehelper_exec() will exit immediately returning -EBUSY
* (used for preventing user land processes from being created after the user
* land has been frozen during a system-wide hibernation or suspend operation).
+ * It is also used at boot up to avoid calling a user land process before all
+ * the kernel subsystems are initialised (such as pipefs).
*/
-static int usermodehelper_disabled;
+static int usermodehelper_disabled = 1;
+static int __init enable_usermodehelper(void)
+{
+ usermodehelper_disabled = 0;
+ return 0;
+}
+rootfs_initcall(enable_usermodehelper);
+
+#ifdef CONFIG_PM
/* Number of helpers running */
static atomic_t running_helpers = ATOMIC_INIT(0);
@@ -342,8 +351,6 @@ static void register_pm_notifier_callback(void)
pm_notifier(usermodehelper_pm_callback, 0);
}
#else /* CONFIG_PM */
-#define usermodehelper_disabled0
-
static inline void helper_lock(void) {}
static inline void helper_unlock(void) {}
static inline void
Re: acpi dsts loading and populate_rootfs
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?
AFAIR the problem was that the kernel was trying to exec /sbin/hotplug
before some kernel subsystems (e.g., pipe support) were completely
initialized, which caused oopses during boot.
Initramfs images generated by distro tools usually do not contain
/sbin/hotplug, and therefore avoid the problem. (The kernel might
also call /sbin/modprobe by itself, but it either does not do it
during early boot, or /sbin/modprobe does not use kernel features
which had not been initialized yet).
Thanks a lot for the pointer. I was able to find the original bug
report. After reading the various fix proposals and the current code I
think I understand what is going on.
Basically, the problem is that one should not run a user land program
too early because not everything is initialized yet (for instance
pipefs). This might happen because at initialization some drivers can
trigger automatically /sbin/hotplug (via call_usermodehelper()). So the
fix which was applied consists in populating the rootfs only once all
the kernel subsystem is initialized. In this way, the hotplugging is
still triggered but as the user space program doesn't exist it can't be
called! (hehe)
One different solution that I implemented [1] was to have an
early_populate_rootfs() before the acpi_early_init(), leaving
populate_rootfs() at the normal place. If the early version fails, it's
ok: we can't override the DSDT, but the later version will work as usual
anyway. This solution also seems to work quite often (it's used in
Ubuntu, Mandriva and PCLinuxOS)
This would not solve the problem, because /sbin/hotplug (if present in
the initramfs image) will exist too early.
Yes, now that I understand the problem, reading the initramfs twice
would in no way help!
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, that looks like a nice way. Actually, I discovered that for suspend
and resume, there is exactly the same need, and a special flag is
already available: usermodehelper_disabled.
So here is a proposal patch leveraging this flag. The rootfs is
populated early but user land execution is forbidden until we reach a
sufficient initialization state. I think it even has the bonus of
doing _explicitly_ what we want (avoid user land execution).
Does this look good? (if so, I can probably make it even cleaner by
renaming/removing the rootfs_initcall level)
Eric
--
diff --git a/init/initramfs.c b/init/initramfs.c
index c0b1e05..b74e845 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -577,10 +577,3 @@ int __init populate_rootfs(void)
}
return 0;
}
-#ifndef CONFIG_ACPI_CUSTOM_DSDT_INITRD
-/*
- * if this option is enabled, populate_rootfs() is called _earlier_ in the
- * boot sequence. This insures that the ACPI initialisation can find the file.
- */
-rootfs_initcall(populate_rootfs);
-#endif
diff --git a/init/main.c b/init/main.c
index 8b19820..703ded0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -102,11 +102,7 @@ static inline void mark_rodata_ro(void) { }
extern void tc_init(void);
#endif
-#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
extern int populate_rootfs(void);
-#else
-static inline void populate_rootfs(void) {}
-#endif
enum system_states system_state;
EXPORT_SYMBOL(system_state);
diff --git a/kernel/kmod.c b/kernel/kmod.c
index bb7df2a..d6a2b40 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -267,14 +267,23 @@ static void __call_usermodehelper(struct work_struct
*work)
}
}
-#ifdef CONFIG_PM
/*
* If set, call_usermodehelper_exec() will exit immediately returning -EBUSY
* (used for preventing user land processes from being created after the user
* land has been frozen during a system-wide hibernation or suspend operation).
+ * It is also used at boot up to avoid calling a user land process before all
+ * the kernel subsystems are initialised (such as pipefs).
*/
-static int usermodehelper_disabled;
+static int usermodehelper_disabled = 1;
+static int __init enable_usermodehelper(void)
+{
+ usermodehelper_disabled = 0;
+ return 0;
+}
+rootfs_initcall(enable_usermodehelper);
+
+#ifdef CONFIG_PM
/* Number of helpers running */
static atomic_t running_helpers = ATOMIC_INIT(0);
@@ -342,8 +351,6 @@ static void register_pm_notifier_callback(void)
pm_notifier(usermodehelper_pm_callback, 0);
}
#else /* CONFIG_PM */
-#define usermodehelper_disabled0
-
static inline void helper_lock(void) {}
static inline void helper_unlock(void) {}
static inline void register_pm_notifier_callback(void) {}
--
To unsubscribe
Re: USB Key light on/off state depending on mount
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 off, giving a handy physical indicator that the key is safe to remove. On linux, the light is simply on whenever the key is plugged in. Should linux toggle the light depending on mount state? Is it as trivial as it seems or does this reflect some larger issue? I think that Windows turns off power to the port when you do the "safely remove hardware" on it, or something like that. Mount/unmount doesn't really indicate whether the device is in use in Linux, though, since it can still be potentially accessed even when the device isn't mounted. If there is a way to toggle the power state from userspace, then a desktop environment or userland tool can emulate the Windows behavior if that is desired. A lot of devices can charge via USB now, and this is actually more convenient on Linux than on Windows (in effect Windows requires drivers in order to charge something). However, having direct control over this is useful. Yes, maybe some userspace such as HAL could turn off the usb devices at the same time it's unmounted. Actually that would be rather intuitive way to tell the user the umount is finished. There doesn't seem to be any loss of funcitonality, once it's turned off you can still re-access the device, and it's automatically turned on again (at least on my PC). For the record, here is how one can switch off a usb device (as root): # cd /sys/bus/usb/devices/usb*/[0-9]-[0-9] (just go to the directory of the device) # echo -n 2 > *:1.0/power/state # echo -n 2 > power/state I use this to turn off my optical mouse when watching movies, but it works fine as well to turn off usb storage devices. It can also be turned on with # echo -n 0 > power/state See you, Eric - 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/lkml/
Re: USB Key light on/off state depending on mount
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 off, giving a handy physical indicator that the key is safe to remove. On linux, the light is simply on whenever the key is plugged in. Should linux toggle the light depending on mount state? Is it as trivial as it seems or does this reflect some larger issue? I think that Windows turns off power to the port when you do the safely remove hardware on it, or something like that. Mount/unmount doesn't really indicate whether the device is in use in Linux, though, since it can still be potentially accessed even when the device isn't mounted. If there is a way to toggle the power state from userspace, then a desktop environment or userland tool can emulate the Windows behavior if that is desired. A lot of devices can charge via USB now, and this is actually more convenient on Linux than on Windows (in effect Windows requires drivers in order to charge something). However, having direct control over this is useful. Yes, maybe some userspace such as HAL could turn off the usb devices at the same time it's unmounted. Actually that would be rather intuitive way to tell the user the umount is finished. There doesn't seem to be any loss of funcitonality, once it's turned off you can still re-access the device, and it's automatically turned on again (at least on my PC). For the record, here is how one can switch off a usb device (as root): # cd /sys/bus/usb/devices/usb*/[0-9]-[0-9] (just go to the directory of the device) # echo -n 2 *:1.0/power/state # echo -n 2 power/state I use this to turn off my optical mouse when watching movies, but it works fine as well to turn off usb storage devices. It can also be turned on with # echo -n 0 power/state See you, Eric - 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/lkml/
Re: 2.6.22-rc[23]: blinking capslock led, stuck keys?
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 you don't want it in hard in the kernel ;-) See you, Eric - 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/lkml/
Re: 2.6.22-rc[23]: blinking capslock led, stuck keys?
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 you don't want it in hard in the kernel ;-) See you, Eric - 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/lkml/
Re: Kernel utf-8 handling
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 emulator *for the console*, not for X, that handles utf8? fbiterm, I never dared to try though... See you, Eric - 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/lkml/
Re: Kernel utf-8 handling
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 emulator *for the console*, not for X, that handles utf8? fbiterm, I never dared to try though... See you, Eric - 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/lkml/
[PATCH] wistron_btns: reduce polling frequency (to save power)
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.
Actually, I've tried to decrease the timer to 1 Hz, using round_jiffies
it would have been an even bigger win, but latency was just too big from
a user point of view. It's pity, there doesn't seem to be any API to
synchronize a 2 Hz timer with the rounded timers :-(
It should apply against 2.6.22-rc2 (as well as input tree). It's
completely orthogonal to my previous patch "add led support", so you can
apply both in the order you like ;-) There is no particular urgency in
this patch, so I guess you can keep it for 2.6.23.
See you,
Eric
From: Eric Piel <[EMAIL PROTECTED]>
wriston_btns: Reduce polling frequency
Reduces the polling frequency from 10 Hz to 2 Hz, which should be less a burden
for laptops wrt energy saving. As it is multimedia keys, 500ms (maximum) of
latency should be still fine for the user. In order to keep fluent the feeling
when the user is pressing several keys in a raw (such as changing the volume),
the frequency is increased for a short duration after a key is pressed.
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
--- linux-2.6.21/drivers/input/misc/wistron_btns.c.bak 2007-05-18 00:37:42.0 +0200
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-05-18 00:36:44.0 +0200
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,9 +38,10 @@
*/
#define MAX_POLL_ITERATIONS 64
-#define POLL_FREQUENCY 10 /* Number of polls per second */
+#define POLL_FREQUENCY 2 /* Number of polls per second when idle */
+#define POLL_FREQUENCY_BURST 10 /* Polls per second when a key was recently pressed */
-#if POLL_FREQUENCY > HZ
+#if POLL_FREQUENCY_BURST > HZ
#error "POLL_FREQUENCY too high"
#endif
@@ -1079,6 +1081,8 @@ static void handle_key(u8 code)
static void poll_bios(unsigned long discard)
{
+ static unsigned long jiffies_last_press;
+ unsigned long jiffies_now = jiffies;
u8 qlen;
u16 val;
@@ -1087,11 +1091,17 @@ static void poll_bios(unsigned long disc
if (qlen == 0)
break;
val = bios_pop_queue();
- if (val != 0 && !discard)
+ if (val != 0 && !discard) {
handle_key((u8)val);
+ jiffies_last_press = jiffies_now;
+ }
}
- mod_timer(_timer, jiffies + HZ / POLL_FREQUENCY);
+ /* Increase precision if user is currently pressing keys (< 2s ago) */
+ if (time_after(jiffies_last_press, jiffies_now - (HZ * 2)))
+ mod_timer(_timer, jiffies_now + HZ / POLL_FREQUENCY_BURST);
+ else
+ mod_timer(_timer, jiffies_now + HZ / POLL_FREQUENCY);
}
static int __devinit wistron_probe(struct platform_device *dev)
[PATCH] wistron_btns: reduce polling frequency (to save power)
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.
Actually, I've tried to decrease the timer to 1 Hz, using round_jiffies
it would have been an even bigger win, but latency was just too big from
a user point of view. It's pity, there doesn't seem to be any API to
synchronize a 2 Hz timer with the rounded timers :-(
It should apply against 2.6.22-rc2 (as well as input tree). It's
completely orthogonal to my previous patch add led support, so you can
apply both in the order you like ;-) There is no particular urgency in
this patch, so I guess you can keep it for 2.6.23.
See you,
Eric
From: Eric Piel [EMAIL PROTECTED]
wriston_btns: Reduce polling frequency
Reduces the polling frequency from 10 Hz to 2 Hz, which should be less a burden
for laptops wrt energy saving. As it is multimedia keys, 500ms (maximum) of
latency should be still fine for the user. In order to keep fluent the feeling
when the user is pressing several keys in a raw (such as changing the volume),
the frequency is increased for a short duration after a key is pressed.
Signed-off-by: Eric Piel [EMAIL PROTECTED]
--- linux-2.6.21/drivers/input/misc/wistron_btns.c.bak 2007-05-18 00:37:42.0 +0200
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-05-18 00:36:44.0 +0200
@@ -22,6 +22,7 @@
#include linux/init.h
#include linux/input.h
#include linux/interrupt.h
+#include linux/jiffies.h
#include linux/kernel.h
#include linux/mc146818rtc.h
#include linux/module.h
@@ -37,9 +38,10 @@
*/
#define MAX_POLL_ITERATIONS 64
-#define POLL_FREQUENCY 10 /* Number of polls per second */
+#define POLL_FREQUENCY 2 /* Number of polls per second when idle */
+#define POLL_FREQUENCY_BURST 10 /* Polls per second when a key was recently pressed */
-#if POLL_FREQUENCY HZ
+#if POLL_FREQUENCY_BURST HZ
#error POLL_FREQUENCY too high
#endif
@@ -1079,6 +1081,8 @@ static void handle_key(u8 code)
static void poll_bios(unsigned long discard)
{
+ static unsigned long jiffies_last_press;
+ unsigned long jiffies_now = jiffies;
u8 qlen;
u16 val;
@@ -1087,11 +1091,17 @@ static void poll_bios(unsigned long disc
if (qlen == 0)
break;
val = bios_pop_queue();
- if (val != 0 !discard)
+ if (val != 0 !discard) {
handle_key((u8)val);
+ jiffies_last_press = jiffies_now;
+ }
}
- mod_timer(poll_timer, jiffies + HZ / POLL_FREQUENCY);
+ /* Increase precision if user is currently pressing keys ( 2s ago) */
+ if (time_after(jiffies_last_press, jiffies_now - (HZ * 2)))
+ mod_timer(poll_timer, jiffies_now + HZ / POLL_FREQUENCY_BURST);
+ else
+ mod_timer(poll_timer, jiffies_now + HZ / POLL_FREQUENCY);
}
static int __devinit wistron_probe(struct platform_device *dev)
Re: [patch 3/5] wistron_btns: add led support
[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 supported, on laptops which have them. Depending on the laptop, wifi subsystem may control just the led, or both the led and the wifi card. Wifi led interface is activated only for the former type of laptops, as the latter type is already managed. Leds are controled by the interface in /sys/class/leds. I am not sure if we want to allow controlling WIFI state via leds. I'd rather plug it into RFkill infrastructure once it is merged and have leds only reflect state of the corresponding switch. Sorry if I wasn't clear. This is basically what does the driver. At least, the led interface _do not_ control the WIFI state :-) What I meant is that there are two kinds of laptops: A - the one where wifi led _only_ is controlled by the wistron hardware. Wifi card is controlled completely independently (pcmcia). B - the one where wifi card _and_ wifi led are controlled by the wistron hardware (they are completely bound). So far, only B laptops were handled, à la RFkill: the button directly modifies the wifi state and wifi led with no userspace involvement. My patch adds wifi led interface only to A laptops, only the led is controlled. So wifi state is never modified by led interface. I hope I cleared up what does this patch and that it's ok with you. If not, just let me know which behaviour you think would be more appropriate and I'll hack a new patch :-) See you, Eric - 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/lkml/
Re: [patch 3/5] wistron_btns: add led support
[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 supported, on laptops which have them. Depending on the laptop, wifi subsystem may control just the led, or both the led and the wifi card. Wifi led interface is activated only for the former type of laptops, as the latter type is already managed. Leds are controled by the interface in /sys/class/leds. I am not sure if we want to allow controlling WIFI state via leds. I'd rather plug it into RFkill infrastructure once it is merged and have leds only reflect state of the corresponding switch. Sorry if I wasn't clear. This is basically what does the driver. At least, the led interface _do not_ control the WIFI state :-) What I meant is that there are two kinds of laptops: A - the one where wifi led _only_ is controlled by the wistron hardware. Wifi card is controlled completely independently (pcmcia). B - the one where wifi card _and_ wifi led are controlled by the wistron hardware (they are completely bound). So far, only B laptops were handled, à la RFkill: the button directly modifies the wifi state and wifi led with no userspace involvement. My patch adds wifi led interface only to A laptops, only the led is controlled. So wifi state is never modified by led interface. I hope I cleared up what does this patch and that it's ok with you. If not, just let me know which behaviour you think would be more appropriate and I'll hack a new patch :-) See you, Eric - 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/lkml/
[PATCH 2/2] wistron_btns: add led support
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 linked (meaning
it is already managed by the driver).
This was tested on a TM 610 and a Aspire 3020.
Eric
(sorry for the multiple receptions)
From: Eric Piel <[EMAIL PROTECTED]>
wriston_btns: Add led support
Add support to wistron_btns for leds that comes with the multimedia keys. Mail
and wifi leds are supported, on laptops which have them. Depending on the
laptop, wifi subsystem may control just the led, or both the led and the wifi
card. Wifi led interface is activated only for the former type of laptops, as
the latter type is already managed. Leds are controled by the interface in
/sys/class/leds.
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
--- linux-2.6.21/drivers/input/misc/wistron_btns.c.bak 2007-04-07 15:09:30.0 +0200
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-04-14 12:42:38.0 +0200
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/*
* Number of attempts to read data from queue per poll;
@@ -46,11 +47,12 @@
/* BIOS subsystem IDs */
#define WIFI 0x35
#define BLUETOOTH 0x34
+#define MAIL_LED 0x31
MODULE_AUTHOR("Miloslav Trmac <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Wistron laptop button driver");
MODULE_LICENSE("GPL v2");
-MODULE_VERSION("0.2");
+MODULE_VERSION("0.3");
static int force; /* = 0; */
module_param(force, bool, 0);
@@ -251,6 +253,7 @@
static const struct key_entry *keymap; /* = NULL; Current key map */
static int have_wifi;
static int have_bluetooth;
+static int have_leds;
static int __init dmi_matched(struct dmi_system_id *dmi)
{
@@ -263,6 +266,8 @@
else if (key->type == KE_BLUETOOTH)
have_bluetooth = 1;
}
+ have_leds = key->code & (FE_MAIL_LED | FE_WIFI_LED);
+
return 1;
}
@@ -1028,6 +1033,83 @@
input_sync(input_dev);
}
+
+ /* led management */
+static void wistron_mail_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ bios_set_state(MAIL_LED, (value != LED_OFF) ? 1 : 0);
+}
+
+/* same as setting up wifi card, but for laptops on which the led is managed */
+static void wistron_wifi_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ bios_set_state(WIFI, (value != LED_OFF) ? 1 : 0);
+}
+
+static struct led_classdev wistron_mail_led = {
+ .name = "mail:green",
+ .brightness_set = wistron_mail_led_set,
+};
+
+static struct led_classdev wistron_wifi_led = {
+ .name = "wifi:red",
+ .brightness_set = wistron_wifi_led_set,
+};
+
+static void __devinit wistron_led_init(struct device *parent)
+{
+ if (have_leds & FE_WIFI_LED) {
+ u16 wifi = bios_get_default_setting(WIFI);
+ if (wifi & 1) {
+ wistron_wifi_led.brightness = (wifi & 2) ? LED_FULL : LED_OFF;
+ if (led_classdev_register(parent, _wifi_led))
+have_leds &= ~FE_WIFI_LED;
+ else
+bios_set_state(WIFI, wistron_wifi_led.brightness);
+
+ } else
+ have_leds &= ~FE_WIFI_LED;
+ }
+
+ if (have_leds & FE_MAIL_LED) {
+ /* bios_get_default_setting(MAIL) always retuns 0, so just turn the led off */
+ wistron_mail_led.brightness = LED_OFF;
+ if (led_classdev_register(parent, _mail_led))
+ have_leds &= ~FE_MAIL_LED;
+ else
+ bios_set_state(MAIL_LED, wistron_mail_led.brightness);
+ }
+}
+
+static void __devexit wistron_led_remove(void)
+{
+ if (have_leds & FE_MAIL_LED)
+ led_classdev_unregister(_mail_led);
+
+ if (have_leds & FE_WIFI_LED)
+ led_classdev_unregister(_wifi_led);
+}
+
+static inline void wistron_led_suspend(void)
+{
+ if (have_leds & FE_MAIL_LED)
+ led_classdev_suspend(_mail_led);
+
+ if (have_leds & FE_WIFI_LED)
+ led_classdev_suspend(_wifi_led);
+}
+
+static inline void wistron_led_resume(void)
+{
+ if (have_leds & FE_MAIL_LED)
+ led_classdev_resume(_mail_led);
+
+ if (have_leds & FE_WIFI_LED)
+ led_classdev_resume(_wifi_led);
+}
+
/* Driver core */
static int wifi_enabled;
@@ -1125,6 +1207,7 @@
bios_set_state(BLUETOOTH, bluetooth_enabled);
}
+ wistron_led_init(>dev);
poll_bios(1); /* Flush stale event queue and arm timer */
return 0;
@@ -1133,6 +1216,7 @@
static int __devexit wistron_remove(struct platform_device *dev)
{
del_timer_sync(_timer);
+ wistron_led_remove();
input_unregister_device(input_dev);
bios_detach();
@@ -1150,6 +1233,7 @@
if (have_bluetooth)
bios_set_state(BLUETOOTH, 0);
+ wistron_led_suspend();
return 0;
}
@@ -1161,6 +1245,7 @@
if (have_bluetooth)
bios_set_state(BLUETOOTH, bluetooth_enabled);
+ wistron_led_resume();
poll_bios(1);
return 0;
--- linux-2.6.21/drivers/input/misc/Kconfig.bak 2007-04-09 23:18:49.0 +0200
+++ linux-2.6.21/drivers/input/misc/Kconfig 2007-04-14 02:53:01.0 +0200
@@ -43,9 +43,12 @@
config INPUT_WISTRON_BTNS
tristate "x86 Wistron laptop button
[PATCH 0/2] wistron_btns: small fix and led support
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 you, Eric - 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/lkml/
[PATCH 1/2] wistron_btns: add led support
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.
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
--- linux-2.6.21/drivers/input/misc/wistron_btns.c.bak 2007-04-07 15:09:30.0 +0200
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-04-07 15:09:44.0 +0200
@@ -490,7 +490,7 @@
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x11, {KEY_PROG1} },
- { KE_KEY, 0x12, {KEY_PROG3} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
{ KE_KEY, 0x13, {KEY_PROG3} },
{ KE_KEY, 0x14, {KEY_MAIL} },
{ KE_KEY, 0x15, {KEY_WWW} },
Re: [PATCH 2/2] wistron_btns: add led support
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? Ooops, sorry, this mail was not mean to be sent yet (my thunderbird and I misunderstood each other). It works here but I'll try it on another laptop to confirm the patch is good. Hopefully, I'll come back to you tomorrow with no changes and a little 1/2 patch :-) Eric - 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/lkml/
Re: [PATCH 2/2] wistron_btns: add led support
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? Ooops, sorry, this mail was not mean to be sent yet (my thunderbird and I misunderstood each other). It works here but I'll try it on another laptop to confirm the patch is good. Hopefully, I'll come back to you tomorrow with no changes and a little 1/2 patch :-) Eric - 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/lkml/
[PATCH 0/2] wistron_btns: small fix and led support
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 you, Eric - 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/lkml/
[PATCH 1/2] wistron_btns: add led support
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.
Signed-off-by: Eric Piel [EMAIL PROTECTED]
--- linux-2.6.21/drivers/input/misc/wistron_btns.c.bak 2007-04-07 15:09:30.0 +0200
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-04-07 15:09:44.0 +0200
@@ -490,7 +490,7 @@
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x11, {KEY_PROG1} },
- { KE_KEY, 0x12, {KEY_PROG3} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
{ KE_KEY, 0x13, {KEY_PROG3} },
{ KE_KEY, 0x14, {KEY_MAIL} },
{ KE_KEY, 0x15, {KEY_WWW} },
[PATCH 2/2] wistron_btns: add led support
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 linked (meaning
it is already managed by the driver).
This was tested on a TM 610 and a Aspire 3020.
Eric
(sorry for the multiple receptions)
From: Eric Piel [EMAIL PROTECTED]
wriston_btns: Add led support
Add support to wistron_btns for leds that comes with the multimedia keys. Mail
and wifi leds are supported, on laptops which have them. Depending on the
laptop, wifi subsystem may control just the led, or both the led and the wifi
card. Wifi led interface is activated only for the former type of laptops, as
the latter type is already managed. Leds are controled by the interface in
/sys/class/leds.
Signed-off-by: Eric Piel [EMAIL PROTECTED]
--- linux-2.6.21/drivers/input/misc/wistron_btns.c.bak 2007-04-07 15:09:30.0 +0200
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-04-14 12:42:38.0 +0200
@@ -30,6 +30,7 @@
#include linux/timer.h
#include linux/types.h
#include linux/platform_device.h
+#include linux/leds.h
/*
* Number of attempts to read data from queue per poll;
@@ -46,11 +47,12 @@
/* BIOS subsystem IDs */
#define WIFI 0x35
#define BLUETOOTH 0x34
+#define MAIL_LED 0x31
MODULE_AUTHOR(Miloslav Trmac [EMAIL PROTECTED]);
MODULE_DESCRIPTION(Wistron laptop button driver);
MODULE_LICENSE(GPL v2);
-MODULE_VERSION(0.2);
+MODULE_VERSION(0.3);
static int force; /* = 0; */
module_param(force, bool, 0);
@@ -251,6 +253,7 @@
static const struct key_entry *keymap; /* = NULL; Current key map */
static int have_wifi;
static int have_bluetooth;
+static int have_leds;
static int __init dmi_matched(struct dmi_system_id *dmi)
{
@@ -263,6 +266,8 @@
else if (key-type == KE_BLUETOOTH)
have_bluetooth = 1;
}
+ have_leds = key-code (FE_MAIL_LED | FE_WIFI_LED);
+
return 1;
}
@@ -1028,6 +1033,83 @@
input_sync(input_dev);
}
+
+ /* led management */
+static void wistron_mail_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ bios_set_state(MAIL_LED, (value != LED_OFF) ? 1 : 0);
+}
+
+/* same as setting up wifi card, but for laptops on which the led is managed */
+static void wistron_wifi_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ bios_set_state(WIFI, (value != LED_OFF) ? 1 : 0);
+}
+
+static struct led_classdev wistron_mail_led = {
+ .name = mail:green,
+ .brightness_set = wistron_mail_led_set,
+};
+
+static struct led_classdev wistron_wifi_led = {
+ .name = wifi:red,
+ .brightness_set = wistron_wifi_led_set,
+};
+
+static void __devinit wistron_led_init(struct device *parent)
+{
+ if (have_leds FE_WIFI_LED) {
+ u16 wifi = bios_get_default_setting(WIFI);
+ if (wifi 1) {
+ wistron_wifi_led.brightness = (wifi 2) ? LED_FULL : LED_OFF;
+ if (led_classdev_register(parent, wistron_wifi_led))
+have_leds = ~FE_WIFI_LED;
+ else
+bios_set_state(WIFI, wistron_wifi_led.brightness);
+
+ } else
+ have_leds = ~FE_WIFI_LED;
+ }
+
+ if (have_leds FE_MAIL_LED) {
+ /* bios_get_default_setting(MAIL) always retuns 0, so just turn the led off */
+ wistron_mail_led.brightness = LED_OFF;
+ if (led_classdev_register(parent, wistron_mail_led))
+ have_leds = ~FE_MAIL_LED;
+ else
+ bios_set_state(MAIL_LED, wistron_mail_led.brightness);
+ }
+}
+
+static void __devexit wistron_led_remove(void)
+{
+ if (have_leds FE_MAIL_LED)
+ led_classdev_unregister(wistron_mail_led);
+
+ if (have_leds FE_WIFI_LED)
+ led_classdev_unregister(wistron_wifi_led);
+}
+
+static inline void wistron_led_suspend(void)
+{
+ if (have_leds FE_MAIL_LED)
+ led_classdev_suspend(wistron_mail_led);
+
+ if (have_leds FE_WIFI_LED)
+ led_classdev_suspend(wistron_wifi_led);
+}
+
+static inline void wistron_led_resume(void)
+{
+ if (have_leds FE_MAIL_LED)
+ led_classdev_resume(wistron_mail_led);
+
+ if (have_leds FE_WIFI_LED)
+ led_classdev_resume(wistron_wifi_led);
+}
+
/* Driver core */
static int wifi_enabled;
@@ -1125,6 +1207,7 @@
bios_set_state(BLUETOOTH, bluetooth_enabled);
}
+ wistron_led_init(dev-dev);
poll_bios(1); /* Flush stale event queue and arm timer */
return 0;
@@ -1133,6 +1216,7 @@
static int __devexit wistron_remove(struct platform_device *dev)
{
del_timer_sync(poll_timer);
+ wistron_led_remove();
input_unregister_device(input_dev);
bios_detach();
@@ -1150,6 +1233,7 @@
if (have_bluetooth)
bios_set_state(BLUETOOTH, 0);
+ wistron_led_suspend();
return 0;
}
@@ -1161,6 +1245,7 @@
if (have_bluetooth)
bios_set_state(BLUETOOTH, bluetooth_enabled);
+ wistron_led_resume();
poll_bios(1);
return 0;
--- linux-2.6.21/drivers/input/misc/Kconfig.bak 2007-04-09 23:18:49.0 +0200
+++ linux-2.6.21/drivers/input/misc/Kconfig 2007-04-14 02:53:01.0 +0200
@@
[PATCH 2/2] wistron_btns: add led support
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 multimedia keys. Mail
and wifi leds are supported, on laptops which have them. Depending on the
laptop, wifi subsystem may control just the led, or both the led and the wifi
card. Wifi led interface is activated only for the former type of laptops, as
the latter type is already managed. Leds are controled by the interface in
/sys/class/leds.
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
--- linux-2.6.21/drivers/input/misc/wistron_btns.c.bak 2007-04-07 15:09:30.0 +0200
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-04-14 12:42:38.0 +0200
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/*
* Number of attempts to read data from queue per poll;
@@ -46,11 +47,12 @@
/* BIOS subsystem IDs */
#define WIFI 0x35
#define BLUETOOTH 0x34
+#define MAIL_LED 0x31
MODULE_AUTHOR("Miloslav Trmac <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Wistron laptop button driver");
MODULE_LICENSE("GPL v2");
-MODULE_VERSION("0.2");
+MODULE_VERSION("0.3");
static int force; /* = 0; */
module_param(force, bool, 0);
@@ -251,6 +253,7 @@
static const struct key_entry *keymap; /* = NULL; Current key map */
static int have_wifi;
static int have_bluetooth;
+static int have_leds;
static int __init dmi_matched(struct dmi_system_id *dmi)
{
@@ -263,6 +266,8 @@
else if (key->type == KE_BLUETOOTH)
have_bluetooth = 1;
}
+ have_leds = key->code & (FE_MAIL_LED | FE_WIFI_LED);
+
return 1;
}
@@ -1028,6 +1033,83 @@
input_sync(input_dev);
}
+
+ /* led management */
+static void wistron_mail_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ bios_set_state(MAIL_LED, (value != LED_OFF) ? 1 : 0);
+}
+
+/* same as setting up wifi card, but for laptops on which the led is managed */
+static void wistron_wifi_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ bios_set_state(WIFI, (value != LED_OFF) ? 1 : 0);
+}
+
+static struct led_classdev wistron_mail_led = {
+ .name = "mail:green",
+ .brightness_set = wistron_mail_led_set,
+};
+
+static struct led_classdev wistron_wifi_led = {
+ .name = "wifi:red",
+ .brightness_set = wistron_wifi_led_set,
+};
+
+static void __devinit wistron_led_init(struct device *parent)
+{
+ if (have_leds & FE_WIFI_LED) {
+ u16 wifi = bios_get_default_setting(WIFI);
+ if (wifi & 1) {
+ wistron_wifi_led.brightness = (wifi & 2) ? LED_FULL : LED_OFF;
+ if (led_classdev_register(parent, _wifi_led))
+have_leds &= ~FE_WIFI_LED;
+ else
+bios_set_state(WIFI, wistron_wifi_led.brightness);
+
+ } else
+ have_leds &= ~FE_WIFI_LED;
+ }
+
+ if (have_leds & FE_MAIL_LED) {
+ /* bios_get_default_setting(MAIL) always retuns 0, so just turn the led off */
+ wistron_mail_led.brightness = LED_OFF;
+ if (led_classdev_register(parent, _mail_led))
+ have_leds &= ~FE_MAIL_LED;
+ else
+ bios_set_state(MAIL_LED, wistron_mail_led.brightness);
+ }
+}
+
+static void __devexit wistron_led_remove(void)
+{
+ if (have_leds & FE_MAIL_LED)
+ led_classdev_unregister(_mail_led);
+
+ if (have_leds & FE_WIFI_LED)
+ led_classdev_unregister(_wifi_led);
+}
+
+static inline void wistron_led_suspend(void)
+{
+ if (have_leds & FE_MAIL_LED)
+ led_classdev_suspend(_mail_led);
+
+ if (have_leds & FE_WIFI_LED)
+ led_classdev_suspend(_wifi_led);
+}
+
+static inline void wistron_led_resume(void)
+{
+ if (have_leds & FE_MAIL_LED)
+ led_classdev_resume(_mail_led);
+
+ if (have_leds & FE_WIFI_LED)
+ led_classdev_resume(_wifi_led);
+}
+
/* Driver core */
static int wifi_enabled;
@@ -1125,6 +1207,7 @@
bios_set_state(BLUETOOTH, bluetooth_enabled);
}
+ wistron_led_init(>dev);
poll_bios(1); /* Flush stale event queue and arm timer */
return 0;
@@ -1133,6 +1216,7 @@
static int __devexit wistron_remove(struct platform_device *dev)
{
del_timer_sync(_timer);
+ wistron_led_remove();
input_unregister_device(input_dev);
bios_detach();
@@ -1150,6 +1233,7 @@
if (have_bluetooth)
bios_set_state(BLUETOOTH, 0);
+ wistron_led_suspend();
return 0;
}
@@ -1161,6 +1245,7 @@
if (have_bluetooth)
bios_set_state(BLUETOOTH, bluetooth_enabled);
+ wistron_led_resume();
poll_bios(1);
return 0;
--- linux-2.6.21/drivers/input/misc/Kconfig.bak 2007-04-09 23:18:49.0 +0200
+++ linux-2.6.21/drivers/input/misc/Kconfig 2007-04-14 02:53:01.0 +0200
@@ -43,9 +43,12 @@
config INPUT_WISTRON_BTNS
tristate "x86 Wistron laptop button interface"
depends on X86 && !X86_64
+ select NEW_LEDS
+ select LEDS_CLASS
help
Say Y here for support of Winstron laptop button interface, used on
- laptops of various brands, including Acer and Fujitsu-Siemens.
+ laptops of various brands, including Acer and
[PATCH 2/2] wistron_btns: add led support
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 multimedia keys. Mail
and wifi leds are supported, on laptops which have them. Depending on the
laptop, wifi subsystem may control just the led, or both the led and the wifi
card. Wifi led interface is activated only for the former type of laptops, as
the latter type is already managed. Leds are controled by the interface in
/sys/class/leds.
Signed-off-by: Eric Piel [EMAIL PROTECTED]
--- linux-2.6.21/drivers/input/misc/wistron_btns.c.bak 2007-04-07 15:09:30.0 +0200
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-04-14 12:42:38.0 +0200
@@ -30,6 +30,7 @@
#include linux/timer.h
#include linux/types.h
#include linux/platform_device.h
+#include linux/leds.h
/*
* Number of attempts to read data from queue per poll;
@@ -46,11 +47,12 @@
/* BIOS subsystem IDs */
#define WIFI 0x35
#define BLUETOOTH 0x34
+#define MAIL_LED 0x31
MODULE_AUTHOR(Miloslav Trmac [EMAIL PROTECTED]);
MODULE_DESCRIPTION(Wistron laptop button driver);
MODULE_LICENSE(GPL v2);
-MODULE_VERSION(0.2);
+MODULE_VERSION(0.3);
static int force; /* = 0; */
module_param(force, bool, 0);
@@ -251,6 +253,7 @@
static const struct key_entry *keymap; /* = NULL; Current key map */
static int have_wifi;
static int have_bluetooth;
+static int have_leds;
static int __init dmi_matched(struct dmi_system_id *dmi)
{
@@ -263,6 +266,8 @@
else if (key-type == KE_BLUETOOTH)
have_bluetooth = 1;
}
+ have_leds = key-code (FE_MAIL_LED | FE_WIFI_LED);
+
return 1;
}
@@ -1028,6 +1033,83 @@
input_sync(input_dev);
}
+
+ /* led management */
+static void wistron_mail_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ bios_set_state(MAIL_LED, (value != LED_OFF) ? 1 : 0);
+}
+
+/* same as setting up wifi card, but for laptops on which the led is managed */
+static void wistron_wifi_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ bios_set_state(WIFI, (value != LED_OFF) ? 1 : 0);
+}
+
+static struct led_classdev wistron_mail_led = {
+ .name = mail:green,
+ .brightness_set = wistron_mail_led_set,
+};
+
+static struct led_classdev wistron_wifi_led = {
+ .name = wifi:red,
+ .brightness_set = wistron_wifi_led_set,
+};
+
+static void __devinit wistron_led_init(struct device *parent)
+{
+ if (have_leds FE_WIFI_LED) {
+ u16 wifi = bios_get_default_setting(WIFI);
+ if (wifi 1) {
+ wistron_wifi_led.brightness = (wifi 2) ? LED_FULL : LED_OFF;
+ if (led_classdev_register(parent, wistron_wifi_led))
+have_leds = ~FE_WIFI_LED;
+ else
+bios_set_state(WIFI, wistron_wifi_led.brightness);
+
+ } else
+ have_leds = ~FE_WIFI_LED;
+ }
+
+ if (have_leds FE_MAIL_LED) {
+ /* bios_get_default_setting(MAIL) always retuns 0, so just turn the led off */
+ wistron_mail_led.brightness = LED_OFF;
+ if (led_classdev_register(parent, wistron_mail_led))
+ have_leds = ~FE_MAIL_LED;
+ else
+ bios_set_state(MAIL_LED, wistron_mail_led.brightness);
+ }
+}
+
+static void __devexit wistron_led_remove(void)
+{
+ if (have_leds FE_MAIL_LED)
+ led_classdev_unregister(wistron_mail_led);
+
+ if (have_leds FE_WIFI_LED)
+ led_classdev_unregister(wistron_wifi_led);
+}
+
+static inline void wistron_led_suspend(void)
+{
+ if (have_leds FE_MAIL_LED)
+ led_classdev_suspend(wistron_mail_led);
+
+ if (have_leds FE_WIFI_LED)
+ led_classdev_suspend(wistron_wifi_led);
+}
+
+static inline void wistron_led_resume(void)
+{
+ if (have_leds FE_MAIL_LED)
+ led_classdev_resume(wistron_mail_led);
+
+ if (have_leds FE_WIFI_LED)
+ led_classdev_resume(wistron_wifi_led);
+}
+
/* Driver core */
static int wifi_enabled;
@@ -1125,6 +1207,7 @@
bios_set_state(BLUETOOTH, bluetooth_enabled);
}
+ wistron_led_init(dev-dev);
poll_bios(1); /* Flush stale event queue and arm timer */
return 0;
@@ -1133,6 +1216,7 @@
static int __devexit wistron_remove(struct platform_device *dev)
{
del_timer_sync(poll_timer);
+ wistron_led_remove();
input_unregister_device(input_dev);
bios_detach();
@@ -1150,6 +1233,7 @@
if (have_bluetooth)
bios_set_state(BLUETOOTH, 0);
+ wistron_led_suspend();
return 0;
}
@@ -1161,6 +1245,7 @@
if (have_bluetooth)
bios_set_state(BLUETOOTH, bluetooth_enabled);
+ wistron_led_resume();
poll_bios(1);
return 0;
--- linux-2.6.21/drivers/input/misc/Kconfig.bak 2007-04-09 23:18:49.0 +0200
+++ linux-2.6.21/drivers/input/misc/Kconfig 2007-04-14 02:53:01.0 +0200
@@ -43,9 +43,12 @@
config INPUT_WISTRON_BTNS
tristate x86 Wistron laptop button interface
depends on X86 !X86_64
+ select NEW_LEDS
+ select LEDS_CLASS
help
Say Y here for support of Winstron laptop button interface, used on
- laptops of various brands,
Re: [PATCH] Make ati_remote button repeat sensitivity soft-configurable
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
+++ drivers/usb/input/ati_remote.c 2007-04-04 22:35:59.0 +0200
:
@@ -174,6 +179,8 @@
unsigned char old_data[2]; /* Detect duplicate events */
unsigned long old_jiffies;
unsigned long acc_jiffies; /* handle acceleration */
+unsigned long first_jiffies;
space warning!
Sorry for being annoying ;-)
Eric
-
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/lkml/
Re: [PATCH] Make ati_remote button repeat sensitivity soft-configurable
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 one hard coded value soft configurable and does not change the default. This default value is set to 300 ms. On my Xserver, the default value is 660 ms and by default in my distrib it's set to 500 ms. So, indeed, the default value of the ati_remote is quite small. Maybe you could increase FILTER_MAX to 10 (= 600 ms) in order to have something saner? That was my two cents :-) See you, Eric - 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/lkml/
Re: [PATCH] Make ati_remote button repeat sensitivity soft-configurable
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 one hard coded value soft configurable and does not change the default. This default value is set to 300 ms. On my Xserver, the default value is 660 ms and by default in my distrib it's set to 500 ms. So, indeed, the default value of the ati_remote is quite small. Maybe you could increase FILTER_MAX to 10 (= 600 ms) in order to have something saner? That was my two cents :-) See you, Eric - 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/lkml/
Re: [PATCH] Make ati_remote button repeat sensitivity soft-configurable
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
+++ drivers/usb/input/ati_remote.c 2007-04-04 22:35:59.0 +0200
:
@@ -174,6 +179,8 @@
unsigned char old_data[2]; /* Detect duplicate events */
unsigned long old_jiffies;
unsigned long acc_jiffies; /* handle acceleration */
+unsigned long first_jiffies;
space warning!
Sorry for being annoying ;-)
Eric
-
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/lkml/
Re: [PATCH 0/2] wistron_btns: More keymaps
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 (for instance: laptop/external/both) The possible keycodes that we could assign to them: KEY_SCREEN KEY_MEDIA KEY_MODE KEY_VIDEO KEY_SWITCHVIDEOMODE KEY_COMPUTER KEY_PC From the discussion, I had the feeling this association would be the less incorrect: Screen on/off : KEY_SCREEN It looks like DVB folks chose to ise KEY_SCREEN and KEY_WINDOW to switch applications between full screen and windowed modes Just for info, I couldn't find any reference to KEY_WINDOW. Anyway, indeed, KEY_SCREEN is already used for "full screen" (although sometimes it's KEY_ZOOM :-/) so better not using it if something else is possible. so we'll have to invent our own keycode. KEY_DISPLAYTOGGLE anyone? What about KEY_DISPLAYONOFF ? :-) What should be its value? Would 239 be fine? Display selection : KEY_SWITCHVIDEOMODE I agree here. BTW, I'm thinking of implementing led support. However, there are two mechanisms for leds in the kernel: the "input layer" leds and the "full feature" leds. The laptops may have up to three leds: mail, wifi, bluetooth. The input layer has LED_MAIL but no wifi nor bluetooth. The led subsystem has the advantage of the very extensible "trigger" mechanism. Which of the subsystems would you recommend me to use? See you, Eric - 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/lkml/
Re: [PATCH 0/2] wistron_btns: More keymaps
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 (for instance: laptop/external/both) The possible keycodes that we could assign to them: KEY_SCREEN KEY_MEDIA KEY_MODE KEY_VIDEO KEY_SWITCHVIDEOMODE KEY_COMPUTER KEY_PC From the discussion, I had the feeling this association would be the less incorrect: Screen on/off : KEY_SCREEN It looks like DVB folks chose to ise KEY_SCREEN and KEY_WINDOW to switch applications between full screen and windowed modes Just for info, I couldn't find any reference to KEY_WINDOW. Anyway, indeed, KEY_SCREEN is already used for full screen (although sometimes it's KEY_ZOOM :-/) so better not using it if something else is possible. so we'll have to invent our own keycode. KEY_DISPLAYTOGGLE anyone? What about KEY_DISPLAYONOFF ? :-) What should be its value? Would 239 be fine? Display selection : KEY_SWITCHVIDEOMODE I agree here. BTW, I'm thinking of implementing led support. However, there are two mechanisms for leds in the kernel: the input layer leds and the full feature leds. The laptops may have up to three leds: mail, wifi, bluetooth. The input layer has LED_MAIL but no wifi nor bluetooth. The led subsystem has the advantage of the very extensible trigger mechanism. Which of the subsystems would you recommend me to use? See you, Eric - 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/lkml/
[PATCH 0/3] wistron_btns: More keymaps, take 2
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 discussion they seemed the "less bad" keycodes. * keymaps are now declared initdata in order to save some memory Patch 1 adds all the database of acerhk which fits this driver (about 25 more laptops). Patch 2 adds a generic map that should fit most users but has the disadvantage of not being automatic. Patch 3 declares all the keymaps as initdata and copy the right one in memory. Dmitry, I've tried to make them against your tree (tm610 already applied). Still, if they don't apply cleanly, just tell me and I'll try harder! See you, Eric - 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/lkml/
[PATCH 2/3] wistron_btns: Generic keymap
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 non-supported laptop will have a
quick and dirty way to use the multimedia keys.
Eric
From: Eric Piel <[EMAIL PROTECTED]>
wistron_btns: Generic keymap
It turns out that the mapping of the wistron code is always the same, the
main difference being some keys which may not exist and leds which might not be
present. Therefore it's possible to write a generic keymap which would allow
the use of an unknown keyboard with little drawbacks. The user can select it
specifying the parameter "keymap=generic".
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
--- linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-03-17 10:09:11.0 +0100
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c~full 2007-03-17 10:09:14.0 +0100
@@ -58,7 +58,7 @@ MODULE_PARM_DESC(force, "Load even if co
static char *keymap_name; /* = NULL; */
module_param_named(keymap, keymap_name, charp, 0);
-MODULE_PARM_DESC(keymap, "Keymap name, if it can't be autodetected");
+MODULE_PARM_DESC(keymap, "Keymap name, if it can't be autodetected [generic, 1557/MS2141]");
static struct platform_device *wistron_device;
@@ -568,6 +568,42 @@ static struct key_entry keymap_wistron_m
{ KE_END, FE_UNTESTED }
};
+static struct key_entry keymap_wistron_generic[] = {
+ { KE_KEY, 0x01, {KEY_HELP} },
+ { KE_KEY, 0x02, {KEY_CONFIG} },
+ { KE_KEY, 0x03, {KEY_POWER} },
+ { KE_KEY, 0x05, {KEY_SWITCHVIDEOMODE} }, /* Display selection */
+ { KE_KEY, 0x06, {KEY_SCREEN} }, /* Display on/off */
+ { KE_KEY, 0x08, {KEY_MUTE} },
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_KEY, 0x13, {KEY_PROG3} },
+ { KE_KEY, 0x14, {KEY_MAIL} },
+ { KE_KEY, 0x15, {KEY_WWW} },
+ { KE_KEY, 0x20, {KEY_VOLUMEUP} },
+ { KE_KEY, 0x21, {KEY_VOLUMEDOWN} },
+ { KE_KEY, 0x22, {KEY_REWIND} },
+ { KE_KEY, 0x23, {KEY_FORWARD} },
+ { KE_KEY, 0x24, {KEY_PLAYPAUSE} },
+ { KE_KEY, 0x25, {KEY_STOPCD} },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x36, {KEY_WWW} },
+ { KE_KEY, 0x37, {KEY_SCREEN} }, /* Display on/off */
+ { KE_KEY, 0x40, {KEY_WLAN} },
+ { KE_KEY, 0x49, {KEY_CONFIG} },
+ { KE_SW, 0x4a, {.sw = {SW_LID, 1}} }, /* lid close */
+ { KE_SW, 0x4b, {.sw = {SW_LID, 0}} }, /* lid open */
+ { KE_KEY, 0x6a, {KEY_CONFIG} },
+ { KE_KEY, 0x6d, {KEY_POWER} },
+ { KE_KEY, 0x71, {KEY_STOPCD} },
+ { KE_KEY, 0x72, {KEY_PLAYPAUSE} },
+ { KE_KEY, 0x74, {KEY_REWIND} },
+ { KE_KEY, 0x78, {KEY_FORWARD} },
+ { KE_WIFI, 0x30 },
+ { KE_BLUETOOTH, 0x44 },
+ { KE_END, 0 }
+};
+
/*
* If your machine is not here (which is currently rather likely), please send
* a list of buttons and their key codes (reported when loading this module
@@ -886,15 +922,17 @@ static struct dmi_system_id dmi_ids[] __
static int __init select_keymap(void)
{
+ dmi_check_system(dmi_ids);
if (keymap_name != NULL) {
if (strcmp (keymap_name, "1557/MS2141") == 0)
keymap = keymap_wistron_ms2141;
+ else if (strcmp (keymap_name, "generic") == 0)
+ keymap = keymap_wistron_generic;
else {
printk(KERN_ERR "wistron_btns: Keymap unknown\n");
return -EINVAL;
}
}
- dmi_check_system(dmi_ids);
if (keymap == NULL) {
if (!force) {
printk(KERN_ERR "wistron_btns: System unknown\n");
[PATCH 3/3] wistron_btns: Declare keymaps as initdata
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 is very unlikely to reduce, this patch
helps to reduce the memory consumption. Declare all the keymaps as __initdata,
and copy during the detection the right keymap. On my x86, this make the module
size at runtime going from 10616 to 9428: a bit more than 1kb saved.
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
--- linux-2.6.21/drivers/input/misc/wistron_btns.c~full 2007-03-17 10:09:14.0 +0100
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-03-18 19:15:57.0 +0100
@@ -50,7 +50,7 @@
MODULE_AUTHOR("Miloslav Trmac <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Wistron laptop button driver");
MODULE_LICENSE("GPL v2");
-MODULE_VERSION("0.1");
+MODULE_VERSION("0.2");
static int force; /* = 0; */
module_param(force, bool, 0);
@@ -266,11 +266,11 @@ static int __init dmi_matched(struct dmi
return 1;
}
-static struct key_entry keymap_empty[] = {
+static struct key_entry keymap_empty[] __initdata = {
{ KE_END, 0 }
};
-static struct key_entry keymap_fs_amilo_pro_v2000[] = {
+static struct key_entry keymap_fs_amilo_pro_v2000[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x11, {KEY_PROG1} },
{ KE_KEY, 0x12, {KEY_PROG2} },
@@ -280,7 +280,7 @@ static struct key_entry keymap_fs_amilo_
{ KE_END, 0 }
};
-static struct key_entry keymap_fujitsu_n3510[] = {
+static struct key_entry keymap_fujitsu_n3510[] __initdata = {
{ KE_KEY, 0x11, {KEY_PROG1} },
{ KE_KEY, 0x12, {KEY_PROG2} },
{ KE_KEY, 0x36, {KEY_WWW} },
@@ -292,7 +292,7 @@ static struct key_entry keymap_fujitsu_n
{ KE_END, 0 }
};
-static struct key_entry keymap_wistron_ms2111[] = {
+static struct key_entry keymap_wistron_ms2111[] __initdata = {
{ KE_KEY, 0x11, {KEY_PROG1} },
{ KE_KEY, 0x12, {KEY_PROG2} },
{ KE_KEY, 0x13, {KEY_PROG3} },
@@ -301,7 +301,7 @@ static struct key_entry keymap_wistron_m
{ KE_END, FE_MAIL_LED }
};
-static struct key_entry keymap_wistron_md40100[] = {
+static struct key_entry keymap_wistron_md40100[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x31, {KEY_MAIL} },
@@ -310,7 +310,7 @@ static struct key_entry keymap_wistron_m
{ KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
};
-static struct key_entry keymap_wistron_ms2141[] = {
+static struct key_entry keymap_wistron_ms2141[] __initdata = {
{ KE_KEY, 0x11, {KEY_PROG1} },
{ KE_KEY, 0x12, {KEY_PROG2} },
{ KE_WIFI, 0x30 },
@@ -323,7 +323,7 @@ static struct key_entry keymap_wistron_m
{ KE_END, 0 }
};
-static struct key_entry keymap_acer_aspire_1500[] = {
+static struct key_entry keymap_acer_aspire_1500[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x03, {KEY_POWER} },
{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -336,7 +336,7 @@ static struct key_entry keymap_acer_aspi
{ KE_END, FE_UNTESTED }
};
-static struct key_entry keymap_acer_aspire_1600[] = {
+static struct key_entry keymap_acer_aspire_1600[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x03, {KEY_POWER} },
{ KE_KEY, 0x08, {KEY_MUTE} },
@@ -352,7 +352,7 @@ static struct key_entry keymap_acer_aspi
};
/* 3020 has been tested */
-static struct key_entry keymap_acer_aspire_5020[] = {
+static struct key_entry keymap_acer_aspire_5020[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x03, {KEY_POWER} },
{ KE_KEY, 0x05, {KEY_SWITCHVIDEOMODE} }, /* Display selection */
@@ -366,7 +366,7 @@ static struct key_entry keymap_acer_aspi
{ KE_END, FE_MAIL_LED | FE_UNTESTED }
};
-static struct key_entry keymap_acer_travelmate_2410[] = {
+static struct key_entry keymap_acer_travelmate_2410[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x6d, {KEY_POWER} },
{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -379,7 +379,7 @@ static struct key_entry keymap_acer_trav
{ KE_END, FE_MAIL_LED | FE_UNTESTED }
};
-static struct key_entry keymap_acer_travelmate_110[] = {
+static struct key_entry keymap_acer_travelmate_110[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x03, {KEY_POWER} },
@@ -396,7 +396,7 @@ static struct key_entry keymap_acer_trav
{ KE_END, FE_MAIL_LED | FE_UNTESTED }
};
-static struct key_entry keymap_acer_travelmate_300[] = {
+static struct key_entry keymap_acer_travelmate_300[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x03, {KEY_POWER} },
@@ -412,7 +412,7 @@ static struct key_entry keymap_acer_trav
{ KE_END, FE_MAIL_LED | FE_UNTESTED }
};
-static struct key_entry keymap_acer_travelmate_380[] = {
+static struct key_entry keymap_acer_travelmate_380[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x03,
[PATCH 1/3] wriston_btns: Add acerhk laptop database
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 not). Surprisingly, the dmi information could be found on
google for a majority of the laptops, so it might not work so badly.
The information about which laptop has which led is also imported,
however for now it doesn't do anything. It's just in case someone adds
led support later, in order to avoid hunting information in the acerhk
for a second time.
Eric
From: Eric Piel <[EMAIL PROTECTED]>
wriston_btns: Add acerhk laptop database
acerhk supports already a lot of laptops. Lets import its database so that
everyone can benefit of the work of Olaf Tauber. Only the "tm_new" laptops were
imported. "tm_old" laptops could be possible but requires more testing and
probably only few laptops are still alive. "dritek" laptops should
probably be imported into a different driver. Also compress the keymaps by
fitting each entry on an int. Most of the dmi matching was written based on
google searches, so it's rather prone to errors. That's why I'm asking people
to confirm it works.
Support to generate switch input events was added as some laptops indicate lid
open/close through this interface.
This adds the following hardware:
Acer TravelMate 370
Acer TravelMate 380
Acer TravelMate C300
Acer TravelMate C100
Acer TravelMate C110
Acer TravelMate 250
Acer TravelMate 350
Acer TravelMate 620
Acer TravelMate 630
Acer TravelMate 220
Acer TravelMate 230
Acer TravelMate 260
Acer TravelMate 280
Acer TravelMate 360
Acer TravelMate 2100
Acer TravelMate 2410
Acer Aspire 1500
Acer Aspire 1600
Acer Aspire 3020
Acer Aspire 5020
Medion MD 2900
Medion MD 40100
Medion MD 95400
Medion MD 96500
Fujitsu Siemens Amilo 7820
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
--- linux-2.6.21/drivers/input/misc/wistron_btns.c~tm610 2007-03-10 01:41:23.0 +0100
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-03-17 10:09:11.0 +0100
@@ -233,10 +233,20 @@ static void bios_set_state(u8 subsys, in
struct key_entry {
char type; /* See KE_* below */
u8 code;
- unsigned keycode; /* For KE_KEY */
+ union {
+ u16 keycode; /* For KE_KEY */
+ struct { /* For KE_SW */
+ u8 code;
+ u8 value;
+ } sw;
+ };
};
-enum { KE_END, KE_KEY, KE_WIFI, KE_BLUETOOTH };
+enum { KE_END, KE_KEY, KE_SW, KE_WIFI, KE_BLUETOOTH };
+
+#define FE_MAIL_LED 0x01
+#define FE_WIFI_LED 0x02
+#define FE_UNTESTED 0x80
static const struct key_entry *keymap; /* = NULL; Current key map */
static int have_wifi;
@@ -261,104 +271,301 @@ static struct key_entry keymap_empty[] =
};
static struct key_entry keymap_fs_amilo_pro_v2000[] = {
- { KE_KEY, 0x01, KEY_HELP },
- { KE_KEY, 0x11, KEY_PROG1 },
- { KE_KEY, 0x12, KEY_PROG2 },
- { KE_WIFI, 0x30, 0 },
- { KE_KEY, 0x31, KEY_MAIL },
- { KE_KEY, 0x36, KEY_WWW },
+ { KE_KEY, 0x01, {KEY_HELP} },
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_WIFI, 0x30 },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x36, {KEY_WWW} },
{ KE_END, 0 }
};
static struct key_entry keymap_fujitsu_n3510[] = {
- { KE_KEY, 0x11, KEY_PROG1 },
- { KE_KEY, 0x12, KEY_PROG2 },
- { KE_KEY, 0x36, KEY_WWW },
- { KE_KEY, 0x31, KEY_MAIL },
- { KE_KEY, 0x71, KEY_STOPCD },
- { KE_KEY, 0x72, KEY_PLAYPAUSE },
- { KE_KEY, 0x74, KEY_REWIND },
- { KE_KEY, 0x78, KEY_FORWARD },
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_KEY, 0x36, {KEY_WWW} },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x71, {KEY_STOPCD} },
+ { KE_KEY, 0x72, {KEY_PLAYPAUSE} },
+ { KE_KEY, 0x74, {KEY_REWIND} },
+ { KE_KEY, 0x78, {KEY_FORWARD} },
{ KE_END, 0 }
};
static struct key_entry keymap_wistron_ms2111[] = {
- { KE_KEY, 0x11, KEY_PROG1 },
- { KE_KEY, 0x12, KEY_PROG2 },
- { KE_KEY, 0x13, KEY_PROG3 },
- { KE_KEY, 0x31, KEY_MAIL },
- { KE_KEY, 0x36, KEY_WWW },
- { KE_END, 0 }
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_KEY, 0x13, {KEY_PROG3} },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x36, {KEY_WWW} },
+ { KE_END, FE_MAIL_LED }
+};
+
+static struct key_entry keymap_wistron_md40100[] = {
+ { KE_KEY, 0x01, {KEY_HELP} },
+ { KE_KEY, 0x02, {KEY_CONFIG} },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x36, {KEY_WWW} },
+ { KE_KEY, 0x37, {KEY_SCREEN} }, /* Display on/off */
+ { KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
};
static struct key_entry keymap_wistron_ms2141[] = {
- { KE_KEY, 0x11, KEY_PROG1 },
- { KE_KEY, 0x12, KEY_PROG2 },
- { KE_WIFI, 0x30, 0 },
- { KE_KEY, 0x22, KEY_REWIND },
- { KE_KEY, 0x23, KEY_FORWARD },
- { KE_KEY, 0x24, KEY_PLAYPAUSE },
- { KE_KEY, 0x25, KEY_STOPCD },
- { KE_KEY, 0x31, KEY_MAIL },
- { KE_KEY, 0x36, KEY_WWW },
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_WIFI, 0x30 },
+ { KE_KEY,
[PATCH 3/3] wistron_btns: Declare keymaps as initdata
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 is very unlikely to reduce, this patch
helps to reduce the memory consumption. Declare all the keymaps as __initdata,
and copy during the detection the right keymap. On my x86, this make the module
size at runtime going from 10616 to 9428: a bit more than 1kb saved.
Signed-off-by: Eric Piel [EMAIL PROTECTED]
--- linux-2.6.21/drivers/input/misc/wistron_btns.c~full 2007-03-17 10:09:14.0 +0100
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-03-18 19:15:57.0 +0100
@@ -50,7 +50,7 @@
MODULE_AUTHOR(Miloslav Trmac [EMAIL PROTECTED]);
MODULE_DESCRIPTION(Wistron laptop button driver);
MODULE_LICENSE(GPL v2);
-MODULE_VERSION(0.1);
+MODULE_VERSION(0.2);
static int force; /* = 0; */
module_param(force, bool, 0);
@@ -266,11 +266,11 @@ static int __init dmi_matched(struct dmi
return 1;
}
-static struct key_entry keymap_empty[] = {
+static struct key_entry keymap_empty[] __initdata = {
{ KE_END, 0 }
};
-static struct key_entry keymap_fs_amilo_pro_v2000[] = {
+static struct key_entry keymap_fs_amilo_pro_v2000[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x11, {KEY_PROG1} },
{ KE_KEY, 0x12, {KEY_PROG2} },
@@ -280,7 +280,7 @@ static struct key_entry keymap_fs_amilo_
{ KE_END, 0 }
};
-static struct key_entry keymap_fujitsu_n3510[] = {
+static struct key_entry keymap_fujitsu_n3510[] __initdata = {
{ KE_KEY, 0x11, {KEY_PROG1} },
{ KE_KEY, 0x12, {KEY_PROG2} },
{ KE_KEY, 0x36, {KEY_WWW} },
@@ -292,7 +292,7 @@ static struct key_entry keymap_fujitsu_n
{ KE_END, 0 }
};
-static struct key_entry keymap_wistron_ms2111[] = {
+static struct key_entry keymap_wistron_ms2111[] __initdata = {
{ KE_KEY, 0x11, {KEY_PROG1} },
{ KE_KEY, 0x12, {KEY_PROG2} },
{ KE_KEY, 0x13, {KEY_PROG3} },
@@ -301,7 +301,7 @@ static struct key_entry keymap_wistron_m
{ KE_END, FE_MAIL_LED }
};
-static struct key_entry keymap_wistron_md40100[] = {
+static struct key_entry keymap_wistron_md40100[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x31, {KEY_MAIL} },
@@ -310,7 +310,7 @@ static struct key_entry keymap_wistron_m
{ KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
};
-static struct key_entry keymap_wistron_ms2141[] = {
+static struct key_entry keymap_wistron_ms2141[] __initdata = {
{ KE_KEY, 0x11, {KEY_PROG1} },
{ KE_KEY, 0x12, {KEY_PROG2} },
{ KE_WIFI, 0x30 },
@@ -323,7 +323,7 @@ static struct key_entry keymap_wistron_m
{ KE_END, 0 }
};
-static struct key_entry keymap_acer_aspire_1500[] = {
+static struct key_entry keymap_acer_aspire_1500[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x03, {KEY_POWER} },
{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -336,7 +336,7 @@ static struct key_entry keymap_acer_aspi
{ KE_END, FE_UNTESTED }
};
-static struct key_entry keymap_acer_aspire_1600[] = {
+static struct key_entry keymap_acer_aspire_1600[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x03, {KEY_POWER} },
{ KE_KEY, 0x08, {KEY_MUTE} },
@@ -352,7 +352,7 @@ static struct key_entry keymap_acer_aspi
};
/* 3020 has been tested */
-static struct key_entry keymap_acer_aspire_5020[] = {
+static struct key_entry keymap_acer_aspire_5020[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x03, {KEY_POWER} },
{ KE_KEY, 0x05, {KEY_SWITCHVIDEOMODE} }, /* Display selection */
@@ -366,7 +366,7 @@ static struct key_entry keymap_acer_aspi
{ KE_END, FE_MAIL_LED | FE_UNTESTED }
};
-static struct key_entry keymap_acer_travelmate_2410[] = {
+static struct key_entry keymap_acer_travelmate_2410[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x6d, {KEY_POWER} },
{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -379,7 +379,7 @@ static struct key_entry keymap_acer_trav
{ KE_END, FE_MAIL_LED | FE_UNTESTED }
};
-static struct key_entry keymap_acer_travelmate_110[] = {
+static struct key_entry keymap_acer_travelmate_110[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x03, {KEY_POWER} },
@@ -396,7 +396,7 @@ static struct key_entry keymap_acer_trav
{ KE_END, FE_MAIL_LED | FE_UNTESTED }
};
-static struct key_entry keymap_acer_travelmate_300[] = {
+static struct key_entry keymap_acer_travelmate_300[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x03, {KEY_POWER} },
@@ -412,7 +412,7 @@ static struct key_entry keymap_acer_trav
{ KE_END, FE_MAIL_LED | FE_UNTESTED }
};
-static struct key_entry keymap_acer_travelmate_380[] = {
+static struct key_entry keymap_acer_travelmate_380[] __initdata = {
{ KE_KEY, 0x01, {KEY_HELP} },
{ KE_KEY, 0x02, {KEY_CONFIG} },
{ KE_KEY, 0x03, {KEY_POWER} }, /*
[PATCH 1/3] wriston_btns: Add acerhk laptop database
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 not). Surprisingly, the dmi information could be found on
google for a majority of the laptops, so it might not work so badly.
The information about which laptop has which led is also imported,
however for now it doesn't do anything. It's just in case someone adds
led support later, in order to avoid hunting information in the acerhk
for a second time.
Eric
From: Eric Piel [EMAIL PROTECTED]
wriston_btns: Add acerhk laptop database
acerhk supports already a lot of laptops. Lets import its database so that
everyone can benefit of the work of Olaf Tauber. Only the tm_new laptops were
imported. tm_old laptops could be possible but requires more testing and
probably only few laptops are still alive. dritek laptops should
probably be imported into a different driver. Also compress the keymaps by
fitting each entry on an int. Most of the dmi matching was written based on
google searches, so it's rather prone to errors. That's why I'm asking people
to confirm it works.
Support to generate switch input events was added as some laptops indicate lid
open/close through this interface.
This adds the following hardware:
Acer TravelMate 370
Acer TravelMate 380
Acer TravelMate C300
Acer TravelMate C100
Acer TravelMate C110
Acer TravelMate 250
Acer TravelMate 350
Acer TravelMate 620
Acer TravelMate 630
Acer TravelMate 220
Acer TravelMate 230
Acer TravelMate 260
Acer TravelMate 280
Acer TravelMate 360
Acer TravelMate 2100
Acer TravelMate 2410
Acer Aspire 1500
Acer Aspire 1600
Acer Aspire 3020
Acer Aspire 5020
Medion MD 2900
Medion MD 40100
Medion MD 95400
Medion MD 96500
Fujitsu Siemens Amilo 7820
Signed-off-by: Eric Piel [EMAIL PROTECTED]
--- linux-2.6.21/drivers/input/misc/wistron_btns.c~tm610 2007-03-10 01:41:23.0 +0100
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-03-17 10:09:11.0 +0100
@@ -233,10 +233,20 @@ static void bios_set_state(u8 subsys, in
struct key_entry {
char type; /* See KE_* below */
u8 code;
- unsigned keycode; /* For KE_KEY */
+ union {
+ u16 keycode; /* For KE_KEY */
+ struct { /* For KE_SW */
+ u8 code;
+ u8 value;
+ } sw;
+ };
};
-enum { KE_END, KE_KEY, KE_WIFI, KE_BLUETOOTH };
+enum { KE_END, KE_KEY, KE_SW, KE_WIFI, KE_BLUETOOTH };
+
+#define FE_MAIL_LED 0x01
+#define FE_WIFI_LED 0x02
+#define FE_UNTESTED 0x80
static const struct key_entry *keymap; /* = NULL; Current key map */
static int have_wifi;
@@ -261,104 +271,301 @@ static struct key_entry keymap_empty[] =
};
static struct key_entry keymap_fs_amilo_pro_v2000[] = {
- { KE_KEY, 0x01, KEY_HELP },
- { KE_KEY, 0x11, KEY_PROG1 },
- { KE_KEY, 0x12, KEY_PROG2 },
- { KE_WIFI, 0x30, 0 },
- { KE_KEY, 0x31, KEY_MAIL },
- { KE_KEY, 0x36, KEY_WWW },
+ { KE_KEY, 0x01, {KEY_HELP} },
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_WIFI, 0x30 },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x36, {KEY_WWW} },
{ KE_END, 0 }
};
static struct key_entry keymap_fujitsu_n3510[] = {
- { KE_KEY, 0x11, KEY_PROG1 },
- { KE_KEY, 0x12, KEY_PROG2 },
- { KE_KEY, 0x36, KEY_WWW },
- { KE_KEY, 0x31, KEY_MAIL },
- { KE_KEY, 0x71, KEY_STOPCD },
- { KE_KEY, 0x72, KEY_PLAYPAUSE },
- { KE_KEY, 0x74, KEY_REWIND },
- { KE_KEY, 0x78, KEY_FORWARD },
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_KEY, 0x36, {KEY_WWW} },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x71, {KEY_STOPCD} },
+ { KE_KEY, 0x72, {KEY_PLAYPAUSE} },
+ { KE_KEY, 0x74, {KEY_REWIND} },
+ { KE_KEY, 0x78, {KEY_FORWARD} },
{ KE_END, 0 }
};
static struct key_entry keymap_wistron_ms2111[] = {
- { KE_KEY, 0x11, KEY_PROG1 },
- { KE_KEY, 0x12, KEY_PROG2 },
- { KE_KEY, 0x13, KEY_PROG3 },
- { KE_KEY, 0x31, KEY_MAIL },
- { KE_KEY, 0x36, KEY_WWW },
- { KE_END, 0 }
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_KEY, 0x13, {KEY_PROG3} },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x36, {KEY_WWW} },
+ { KE_END, FE_MAIL_LED }
+};
+
+static struct key_entry keymap_wistron_md40100[] = {
+ { KE_KEY, 0x01, {KEY_HELP} },
+ { KE_KEY, 0x02, {KEY_CONFIG} },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x36, {KEY_WWW} },
+ { KE_KEY, 0x37, {KEY_SCREEN} }, /* Display on/off */
+ { KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
};
static struct key_entry keymap_wistron_ms2141[] = {
- { KE_KEY, 0x11, KEY_PROG1 },
- { KE_KEY, 0x12, KEY_PROG2 },
- { KE_WIFI, 0x30, 0 },
- { KE_KEY, 0x22, KEY_REWIND },
- { KE_KEY, 0x23, KEY_FORWARD },
- { KE_KEY, 0x24, KEY_PLAYPAUSE },
- { KE_KEY, 0x25, KEY_STOPCD },
- { KE_KEY, 0x31, KEY_MAIL },
- { KE_KEY, 0x36, KEY_WWW },
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_WIFI, 0x30 },
+ { KE_KEY, 0x22,
[PATCH 2/3] wistron_btns: Generic keymap
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 non-supported laptop will have a
quick and dirty way to use the multimedia keys.
Eric
From: Eric Piel [EMAIL PROTECTED]
wistron_btns: Generic keymap
It turns out that the mapping of the wistron code is always the same, the
main difference being some keys which may not exist and leds which might not be
present. Therefore it's possible to write a generic keymap which would allow
the use of an unknown keyboard with little drawbacks. The user can select it
specifying the parameter keymap=generic.
Signed-off-by: Eric Piel [EMAIL PROTECTED]
--- linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-03-17 10:09:11.0 +0100
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c~full 2007-03-17 10:09:14.0 +0100
@@ -58,7 +58,7 @@ MODULE_PARM_DESC(force, Load even if co
static char *keymap_name; /* = NULL; */
module_param_named(keymap, keymap_name, charp, 0);
-MODULE_PARM_DESC(keymap, Keymap name, if it can't be autodetected);
+MODULE_PARM_DESC(keymap, Keymap name, if it can't be autodetected [generic, 1557/MS2141]);
static struct platform_device *wistron_device;
@@ -568,6 +568,42 @@ static struct key_entry keymap_wistron_m
{ KE_END, FE_UNTESTED }
};
+static struct key_entry keymap_wistron_generic[] = {
+ { KE_KEY, 0x01, {KEY_HELP} },
+ { KE_KEY, 0x02, {KEY_CONFIG} },
+ { KE_KEY, 0x03, {KEY_POWER} },
+ { KE_KEY, 0x05, {KEY_SWITCHVIDEOMODE} }, /* Display selection */
+ { KE_KEY, 0x06, {KEY_SCREEN} }, /* Display on/off */
+ { KE_KEY, 0x08, {KEY_MUTE} },
+ { KE_KEY, 0x11, {KEY_PROG1} },
+ { KE_KEY, 0x12, {KEY_PROG2} },
+ { KE_KEY, 0x13, {KEY_PROG3} },
+ { KE_KEY, 0x14, {KEY_MAIL} },
+ { KE_KEY, 0x15, {KEY_WWW} },
+ { KE_KEY, 0x20, {KEY_VOLUMEUP} },
+ { KE_KEY, 0x21, {KEY_VOLUMEDOWN} },
+ { KE_KEY, 0x22, {KEY_REWIND} },
+ { KE_KEY, 0x23, {KEY_FORWARD} },
+ { KE_KEY, 0x24, {KEY_PLAYPAUSE} },
+ { KE_KEY, 0x25, {KEY_STOPCD} },
+ { KE_KEY, 0x31, {KEY_MAIL} },
+ { KE_KEY, 0x36, {KEY_WWW} },
+ { KE_KEY, 0x37, {KEY_SCREEN} }, /* Display on/off */
+ { KE_KEY, 0x40, {KEY_WLAN} },
+ { KE_KEY, 0x49, {KEY_CONFIG} },
+ { KE_SW, 0x4a, {.sw = {SW_LID, 1}} }, /* lid close */
+ { KE_SW, 0x4b, {.sw = {SW_LID, 0}} }, /* lid open */
+ { KE_KEY, 0x6a, {KEY_CONFIG} },
+ { KE_KEY, 0x6d, {KEY_POWER} },
+ { KE_KEY, 0x71, {KEY_STOPCD} },
+ { KE_KEY, 0x72, {KEY_PLAYPAUSE} },
+ { KE_KEY, 0x74, {KEY_REWIND} },
+ { KE_KEY, 0x78, {KEY_FORWARD} },
+ { KE_WIFI, 0x30 },
+ { KE_BLUETOOTH, 0x44 },
+ { KE_END, 0 }
+};
+
/*
* If your machine is not here (which is currently rather likely), please send
* a list of buttons and their key codes (reported when loading this module
@@ -886,15 +922,17 @@ static struct dmi_system_id dmi_ids[] __
static int __init select_keymap(void)
{
+ dmi_check_system(dmi_ids);
if (keymap_name != NULL) {
if (strcmp (keymap_name, 1557/MS2141) == 0)
keymap = keymap_wistron_ms2141;
+ else if (strcmp (keymap_name, generic) == 0)
+ keymap = keymap_wistron_generic;
else {
printk(KERN_ERR wistron_btns: Keymap unknown\n);
return -EINVAL;
}
}
- dmi_check_system(dmi_ids);
if (keymap == NULL) {
if (!force) {
printk(KERN_ERR wistron_btns: System unknown\n);
[PATCH 0/3] wistron_btns: More keymaps, take 2
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 discussion they seemed the less bad keycodes. * keymaps are now declared initdata in order to save some memory Patch 1 adds all the database of acerhk which fits this driver (about 25 more laptops). Patch 2 adds a generic map that should fit most users but has the disadvantage of not being automatic. Patch 3 declares all the keymaps as initdata and copy the right one in memory. Dmitry, I've tried to make them against your tree (tm610 already applied). Still, if they don't apply cleanly, just tell me and I'll try harder! See you, Eric - 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/lkml/
Re: [PATCH 0/2] wistron_btns: More keymaps
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 user presses corresponding button - does the display actually goes off? Maybe we need another switch. Sorry, Dmitry, I probably should have documented it back then, I don't have the slightest idea anymore. That's what I was afraid of ;) Well, maybe we should just use it to indicate display switch and add a comment to that effect to input.h... Digging somewhat deeper into my memory, I think it just so happened that there was a keyboard with a key with a pictogram of a computer screen on it with no really defined purpose. Since at that time there was only a limited number of different extended keyboard types, it was added. I think it'd make sense to use it eg. for the key that switches between internal and external output on laptops, if the laptop generates a keycode for the key at all. But maybe that function is already taken by KEY_SWITCHVIDEOMODE ... 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 (for instance: laptop/external/both) The possible keycodes that we could assign to them: KEY_SCREEN KEY_MEDIA KEY_MODE KEY_VIDEO KEY_SWITCHVIDEOMODE KEY_COMPUTER KEY_PC From the discussion, I had the feeling this association would be the less incorrect: Screen on/off : KEY_SCREEN Display selection : KEY_SWITCHVIDEOMODE Is that ok with everyone? If not, please suggest something better ;-) See you, Eric PS: So far, I believe that for all laptops, those keys are just normal keys (as opposed to a key which would also do by itself its intended action). At least on a 3020, pressing "screen on/off" doesn't automatically switch on/off the screen. - 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/lkml/
Re: [PATCH 0/2] wistron_btns: More keymaps
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 user presses corresponding button - does the display actually goes off? Maybe we need another switch. Sorry, Dmitry, I probably should have documented it back then, I don't have the slightest idea anymore. That's what I was afraid of ;) Well, maybe we should just use it to indicate display switch and add a comment to that effect to input.h... Digging somewhat deeper into my memory, I think it just so happened that there was a keyboard with a key with a pictogram of a computer screen on it with no really defined purpose. Since at that time there was only a limited number of different extended keyboard types, it was added. I think it'd make sense to use it eg. for the key that switches between internal and external output on laptops, if the laptop generates a keycode for the key at all. But maybe that function is already taken by KEY_SWITCHVIDEOMODE ... 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 (for instance: laptop/external/both) The possible keycodes that we could assign to them: KEY_SCREEN KEY_MEDIA KEY_MODE KEY_VIDEO KEY_SWITCHVIDEOMODE KEY_COMPUTER KEY_PC From the discussion, I had the feeling this association would be the less incorrect: Screen on/off : KEY_SCREEN Display selection : KEY_SWITCHVIDEOMODE Is that ok with everyone? If not, please suggest something better ;-) See you, Eric PS: So far, I believe that for all laptops, those keys are just normal keys (as opposed to a key which would also do by itself its intended action). At least on a 3020, pressing screen on/off doesn't automatically switch on/off the screen. - 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/lkml/
Re: [PATCH 0/2] wistron_btns: More keymaps
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 toggling > > display on and off. I am CCing Vojtech - he must know what the > > original intent of this key code was. BTW, when user presses > > corresponding button - does the display actually goes off? Maybe we > > need another switch. > > Sorry, Dmitry, I probably should have documented it back then, I don't > have the slightest idea anymore. > That's what I was afraid of ;) Well, maybe we should just use it to indicate display switch and add a comment to that effect to input.h... Oh, wait, DVB uses this code to request switchin full screen mode, we better not touch it. Isn't that what is supposed to do KEY_SWITCHVIDEOMODE? Humm... I've got a feeling that it's not clear where the documentation is or that documentation is missing ;-) IIRC, about a month ago someone already asked for precision on the meaning of some KEY_* . It would probably worth documenting more each key. More specifically, it could be interesting to decide if the keycode has to be associated to the physical symbol displayed on the key or associated to the function that the user (developer) expects when pressing this key. Eric - 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/lkml/
Re: [PATCH 0/2] wistron_btns: More keymaps
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: http://www.usb.org/developers/devclass_docs/Hut1_12.pdf SW_LID shoudl be used to signal lid state instead. The keycodes put in the keymap are simply the same as in acerhk, just because I couldn't think of better. Indeed, KEY_OPEN and KEY_CLOSE seem to badly fit if they might be interpreted by userland as opening or closing a document! That would be better to generate a SW_LID event, but I'm not sure how to do that, is it just about using input_report_switch(x, SW_LID, 0 or 1) instead of using input_report_key()? Probably I need to update input_dev->swbit as well. Do I have to anything else to generate switch events? Sincerely, I don't think anyone is using this info (especially because probably the info is also passed though ACPI) so that would be fine with me to just not generate any event :-P Tell me if you think it worths it. 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 user presses corresponding button - does the display actually goes off? Maybe we need another switch. Only few laptops generate an event for this key (most of the laptop simply switch the screen). I don't have access to any of those, so I've no idea if it's the userland which has to control the display or if it's just information for the userland. Maybe Olaf knows? I don't think it's possible to convert it to a switch event because it doesn't report the information about if screen is on or off. On the same topic, there are some "KEY_MEDIA" generated when key to change display output is pressed. Is it fine for you or do have a more suiting keycode in mind? 3. The number of keymap tables grew considerably ;) Do you think it woudl make sense to allocate memory for keymap at device creation time and copy selected keymap and them mark all original keymaps as __initdata so they are discarded one module completed initialization? In the patch, I've reduced the keymap structure to only take 32bits per key. So, in the absolute, it's not that terrible with each keymap taking about 40 bytes. Still, it wouldn't hurt to save space knowing that it's likely that the list keeps growing up. It shouldn't be hard to do as you propose with the __initdata. I had thought about a different way: as the generic keymap should fit most of the laptop, we could save only the difference of a given laptop to this keymap (then behaving more like a "quirk"). This would have the advantage of saving space even in the source file ;-) I'll try to tinker a bit with both approaches and see what fit best. Anyway, is it ok for you to merge those patches first and later I'll come up with a space-saver patch? See you, Eric - 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/lkml/
Re: [PATCH 0/2] wistron_btns: More keymaps
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: http://www.usb.org/developers/devclass_docs/Hut1_12.pdf SW_LID shoudl be used to signal lid state instead. The keycodes put in the keymap are simply the same as in acerhk, just because I couldn't think of better. Indeed, KEY_OPEN and KEY_CLOSE seem to badly fit if they might be interpreted by userland as opening or closing a document! That would be better to generate a SW_LID event, but I'm not sure how to do that, is it just about using input_report_switch(x, SW_LID, 0 or 1) instead of using input_report_key()? Probably I need to update input_dev-swbit as well. Do I have to anything else to generate switch events? Sincerely, I don't think anyone is using this info (especially because probably the info is also passed though ACPI) so that would be fine with me to just not generate any event :-P Tell me if you think it worths it. 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 user presses corresponding button - does the display actually goes off? Maybe we need another switch. Only few laptops generate an event for this key (most of the laptop simply switch the screen). I don't have access to any of those, so I've no idea if it's the userland which has to control the display or if it's just information for the userland. Maybe Olaf knows? I don't think it's possible to convert it to a switch event because it doesn't report the information about if screen is on or off. On the same topic, there are some KEY_MEDIA generated when key to change display output is pressed. Is it fine for you or do have a more suiting keycode in mind? 3. The number of keymap tables grew considerably ;) Do you think it woudl make sense to allocate memory for keymap at device creation time and copy selected keymap and them mark all original keymaps as __initdata so they are discarded one module completed initialization? In the patch, I've reduced the keymap structure to only take 32bits per key. So, in the absolute, it's not that terrible with each keymap taking about 40 bytes. Still, it wouldn't hurt to save space knowing that it's likely that the list keeps growing up. It shouldn't be hard to do as you propose with the __initdata. I had thought about a different way: as the generic keymap should fit most of the laptop, we could save only the difference of a given laptop to this keymap (then behaving more like a quirk). This would have the advantage of saving space even in the source file ;-) I'll try to tinker a bit with both approaches and see what fit best. Anyway, is it ok for you to merge those patches first and later I'll come up with a space-saver patch? See you, Eric - 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/lkml/
Re: [PATCH 0/2] wistron_btns: More keymaps
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 toggling display on and off. I am CCing Vojtech - he must know what the original intent of this key code was. BTW, when user presses corresponding button - does the display actually goes off? Maybe we need another switch. Sorry, Dmitry, I probably should have documented it back then, I don't have the slightest idea anymore. That's what I was afraid of ;) Well, maybe we should just use it to indicate display switch and add a comment to that effect to input.h... Oh, wait, DVB uses this code to request switchin full screen mode, we better not touch it. Isn't that what is supposed to do KEY_SWITCHVIDEOMODE? Humm... I've got a feeling that it's not clear where the documentation is or that documentation is missing ;-) IIRC, about a month ago someone already asked for precision on the meaning of some KEY_* . It would probably worth documenting more each key. More specifically, it could be interesting to decide if the keycode has to be associated to the physical symbol displayed on the key or associated to the function that the user (developer) expects when pressing this key. Eric - 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/lkml/
Re: [PATCH] Wistron button support for TravelMate 610
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, I would like to try to add all the database of keyboards available in acerhk (that Olaf has written). That would be nice. I have one request though - please send patches inline instead of attachments, or, if you need to send it as an attachment then put patch description and signed-off-by there as well so I don't have to reassemble it. Ok, sorry for the troubles. I'll keep patch and description together next time :-) See you, Eric - 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/lkml/
Re: [PATCH] Wistron button support for TravelMate 610
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, I would like to try to add all the database of keyboards available in acerhk (that Olaf has written). That would be nice. I have one request though - please send patches inline instead of attachments, or, if you need to send it as an attachment then put patch description and signed-off-by there as well so I don't have to reassemble it. Ok, sorry for the troubles. I'll keep patch and description together next time :-) See you, Eric - 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/lkml/
Re: O2micro smartcard reader driver.
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 like to see it as soon as possible in the upstream kernel before some kernel api changes again which affects your current driver. Hi Markus, Thank you very much for finding new bugs ;-) Actually, right now I've just moved and don't have internet at home which is kind of slowing down development... Anyway, I'll check if I have some more fixes on my computer than on my website. Also, it would be good to double check some lines which I've commented XXX. In particular, IIRC there were some suspicious sleep saying it was sleeping a microsecond and sleeping one millisecond! I'm also a bit concerned about the userspace "driver" for pscd which comes with the original driver once the patch will be part of the default kernel. Maybe this userspace part could become part of the pscdlite distribution. Wrt the module having always a usecount value of 1, it was worrying me too at the begining until I noticed it decreased back to 0 once the card is "ejected" (pccardctl eject 1). Although a bit surprising, I don't think it's a bug, is it? See you, Eric - 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/lkml/
Re: O2micro smartcard reader driver.
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 like to see it as soon as possible in the upstream kernel before some kernel api changes again which affects your current driver. Hi Markus, Thank you very much for finding new bugs ;-) Actually, right now I've just moved and don't have internet at home which is kind of slowing down development... Anyway, I'll check if I have some more fixes on my computer than on my website. Also, it would be good to double check some lines which I've commented XXX. In particular, IIRC there were some suspicious sleep saying it was sleeping a microsecond and sleeping one millisecond! I'm also a bit concerned about the userspace driver for pscd which comes with the original driver once the patch will be part of the default kernel. Maybe this userspace part could become part of the pscdlite distribution. Wrt the module having always a usecount value of 1, it was worrying me too at the begining until I noticed it decreased back to 0 once the card is ejected (pccardctl eject 1). Although a bit surprising, I don't think it's a bug, is it? See you, Eric - 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/lkml/
Re: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
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 kernel. Revised again. Subject: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size might result in allocation failure for the reserving itself on some platforms (for example typical 32bit MIPS). Make it (and CARDBUS_IO_SIZE too) customizable by "pci=" option for such platforms. : diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 25d2985..ace7a9a 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1259,6 +1259,12 @@ and is between 256 and 4096 characters. This sorting is done to get a device order compatible with older (<= 2.4) kernels. nobfsortDon't sort PCI devices into breadth-first order. + cbiosize=nn[KMG]A fixed amount of bus space is + reserved for CardBus bridges. + The default value is 256 bytes. + cbmemsize=nn[KMG] A fixed amount of bus space is + reserved for CardBus bridges. + The default value is 64 megabytes. Hi, I've got the feeling that those two parameters don't do the same things, although they have the same description ;-) Maybe the texts could be: * The fixed amount of bus space which is reserved for the CardBus bridges IO window. * The fixed amount of bus space which is reserved for the CardBus bridges memory window. See you, Eric - 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/lkml/
Re: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
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 kernel. Revised again. Subject: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size might result in allocation failure for the reserving itself on some platforms (for example typical 32bit MIPS). Make it (and CARDBUS_IO_SIZE too) customizable by pci= option for such platforms. : diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 25d2985..ace7a9a 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1259,6 +1259,12 @@ and is between 256 and 4096 characters. This sorting is done to get a device order compatible with older (= 2.4) kernels. nobfsortDon't sort PCI devices into breadth-first order. + cbiosize=nn[KMG]A fixed amount of bus space is + reserved for CardBus bridges. + The default value is 256 bytes. + cbmemsize=nn[KMG] A fixed amount of bus space is + reserved for CardBus bridges. + The default value is 64 megabytes. Hi, I've got the feeling that those two parameters don't do the same things, although they have the same description ;-) Maybe the texts could be: * The fixed amount of bus space which is reserved for the CardBus bridges IO window. * The fixed amount of bus space which is reserved for the CardBus bridges memory window. See you, Eric - 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/lkml/
